Smart Door Lock System: A Low-Cost Prototype with Local Fingerprint Authentication and IoT Monitoring

Tehreem Kanwal

doi:10.20944/preprints202610.2805.v1

Submitted:

26 October 2026

Posted:

28 October 2026

You are already at the latest version

Abstract

This paper documents a low-cost smart door-lock proof-of-concept with two separate control paths: local fingerprint authentication using an Arduino Uno and an R307 fingerprint sensor, and a Wi-Fi browser interface implemented on an ESP32-CAM. The biometric subsystem includes a relay, a solenoid lock, a 16×2 I²C LCD, and status LEDs. The ESP32-CAM firmware serves a browser page, a camera stream, and an HTTP action endpoint. Source-code inspection found no HTTP authentication, no JSON door-state endpoint, and no signal linking the Arduino’s biometric decision to the ESP32-CAM. The network control endpoint is therefore not protected by application-level authentication in the reviewed implementation. Because independently verifiable trial-level records were unavailable for this revision, quantitative biometric performance claims are not reported. Instead, the paper describes the architecture, firmware behavior, implementation limitations, and security improvements needed before deployment. No formal network penetration or biometric spoofing evaluation is claimed.

Keywords:

smart door lock

;

biometric authentication

;

fingerprint recognition

;

internet of things

;

Arduino Uno

;

ESP32-CAM

;

home security

;

access control

Subject:

Computer Science and Mathematics - Hardware and Architecture

Introduction

Residential access control has traditionally relied on physical keys, mechanical locks, and, more recently, keypad-based electronic mechanisms. Although these approaches can be inexpensive and familiar to users, they also introduce practical weaknesses. A physical key can be misplaced, copied, or obtained by an unauthorized person, while a shared keypad code can be disclosed or observed. Electronic access systems therefore increasingly incorporate biometrics, embedded controllers, wireless communication, and connected monitoring to reduce dependence on transferable credentials and to provide additional control functionality.

Fingerprint recognition is particularly suitable for small embedded access-control systems because it provides a user-bound biometric characteristic while allowing enrollment and matching to be performed locally. In a typical fingerprint-lock architecture, the sensor captures a fingerprint image, extracts or compares a representation of the fingerprint, and returns a match decision associated with an enrolled identifier. The microcontroller can then use that decision to actuate a relay and an electric lock. Previous work has investigated Arduino-based fingerprint locks, Bluetooth-enabled access systems, IoT-enhanced door locking, and broader security and accuracy considerations for fingerprint biometrics.

IoT connectivity adds a second dimension to the access-control problem. A connected controller can expose status information or control functions through a network interface, while a camera can provide visual context around the doorway. However, connectivity also introduces an attack surface that does not exist in a purely local biometric lock. A prototype can therefore be functionally successful while still requiring substantial cybersecurity hardening before it can be considered suitable for deployment in a security-sensitive environment.

The system developed in this study is a modular, low-cost proof-of-concept. The Arduino Uno performs local fingerprint matching and actuates its relay, while the ESP32-CAM provides a Wi-Fi browser interface, a camera stream, and a separate relay-control output. The supplied firmware does not connect the biometric controller’s decision to the ESP32-CAM; the two paths operate independently.

The contributions are: (1) implementation of a fingerprint-based local access prototype; (2) integration of an ESP32-CAM browser interface and live stream; (3) a source-code-based review of implementation behavior; and (4) an implementation-level security review that identifies missing network authentication, missing TLS, hard-coded Wi-Fi credentials, and the lack of coordination between the biometric and network paths.

Related Work

Fingerprint-based door locks have been implemented with Arduino-class microcontrollers because these platforms provide a simple interface between biometric sensors, relay modules, displays, and electromechanical locks. Existing work has explored standalone fingerprint locks as well as systems that add Bluetooth or IoT communication Such systems demonstrate the feasibility of replacing physical keys with biometric access decisions, but their evaluation depth varies considerably [1,3,4,8].

Research on fingerprint biometrics also emphasizes that recognition performance depends on both the biometric technology and the conditions under which samples are acquired. Reviews have discussed security and accuracy considerations, including the need to distinguish false acceptance from false rejection and to evaluate biometric systems using appropriate performance measures For a door-lock prototype, this distinction is important because an overly permissive system may create an access-control risk, whereas an overly restrictive system can frustrate legitimate users [2,12,16].

Other studies have combined fingerprint authentication with voice control, shared-access mechanisms, and enhanced security functions. Broader work on continuous and multi-modal biometric authentication further suggests that access-control systems should be assessed not only for whether the lock opens, but also for response time, reliability, resistance to impersonation, and continuous verification throughout a session [5,6,7,9,10,11,12].

A second research direction concerns the integration of biometric access control with IoT platforms. Network connectivity can provide convenient monitoring and remote commands, but it changes the security boundary of the system. Once an embedded web server is reachable over a network, endpoint authentication, authorization, transport protection, input handling, and exposure of device interfaces become relevant security considerations. A local fingerprint decision therefore does not by itself make the complete connected system secure [13,17].

The reviewed literature also indicates a recurring gap between functional demonstrations and comprehensive security evaluation. Many low-cost academic prototypes emphasize successful fingerprint matching and relay actuation but provide limited quantitative testing, limited multi-user analysis, or limited cybersecurity assessment The present work therefore focuses on architecture and source-code inspection. It does not claim quantitative biometric performance or network attack resistance because reproducible trial-level records and formal security-test results were not available for this revision [14].

Research Gap

Three gaps are particularly relevant to this study. First, low-cost demonstrations often report that a lock works without providing a transparent confusion matrix from which FAR, FRR, and accuracy can be independently calculated. Second, the addition of an IoT interface can create a second access path whose security properties differ from those of the fingerprint sensor Third, a single successful authentication test does not establish resistance to spoofing, replay, unauthorized network access, or other cyberattacks [10,11,12].

This paper addresses these concerns at the proof-of-concept level by documenting the actual network interface implemented in the ESP32 firmware and distinguishing source-code findings from performance claims that cannot be substantiated with reproducible trial records.

Requirements and Proposed Solution

The project was developed as a single-door, single-household academic proof-of-concept. The requirements were therefore selected to support keyless entry, physical actuation, local biometric processing, and basic network monitoring and control without assuming production-grade security features that were not implemented.

Functional Requirements

The biometric subsystem is required to enroll fingerprint templates, detect a presented fingerprint, compare it with the stored templates, and make an access decision. When an authorized fingerprint is recognized, the controller activates the relay so that the 12V solenoid releases the door for a programmed interval. When no matching fingerprint is found, the system keeps the lock secured and provides a visual rejection indication through LEDs and the LCD.

The network subsystem connects the ESP32-CAM to Wi-Fi, serves a browser page, accepts HTTP action requests, and exposes the camera stream. The reviewed firmware does not implement endpoint authentication or a door-state JSON endpoint. Its network control path is independent of fingerprint matching.

Non-Functional Requirements

The prototype emphasizes low cost, simple operation, short response time, and modularity. It should be understandable to users without requiring a dedicated mobile application, and its major components should be replaceable or configurable without redesigning the entire system. Security and privacy are treated as design considerations, not as implemented guarantees. The reviewed ESP32-CAM web interface has no HTTP authentication and does not use HTTPS/TLS.

Comparison with Conventional Approaches

Table 1 summarizes the conceptual differences between conventional mechanisms and the implemented prototype. The table is phrased in terms of implemented capabilities rather than unverified security superiority.

System Architecture and Design

The prototype consists of two functionally distinct subsystems: a local biometric lock controller (Arduino Uno) and an ESP32-CAM network interface. The supplied firmware contains no bridge connection or shared state between the two controllers. The fingerprint path can operate without network connectivity, and the network path does not require fingerprint authentication. The overall conceptual organization is shown in Figure 1.

The Arduino Uno reads the R307 fingerprint sensor over SoftwareSerial (RX = D2, TX = D3) and executes the local access decision. A successful match drives the active-LOW relay to energize the solenoid for five seconds. Three status LEDs and a 16×2 I²C LCD provide local feedback. The reviewed Arduino code does not define a D8 output for communicating the unlock state to the ESP32-CAM.

The ESP32-CAM connects to Wi-Fi, starts an HTTP server on port 80, and serves a browser page with door-control buttons and an action endpoint. A second server on port 81 provides the MJPEG camera stream. The reviewed code does not register a ‘/status‘ endpoint and does not implement HTTP Basic authentication. The network-control endpoint is consequently unauthenticated, and the transport is plain HTTP. These are limitations of the supplied implementation, not merely future deployment considerations. The functional use cases are summarized in Figure 2.

Hardware Components

The major hardware components (assembled prototype in Figure 3) are:

• Arduino Uno: executes fingerprint authentication and relay control.
• R307 fingerprint sensor: enrollment, template storage, and matching (manufacturer-rated capacity of 1,000 templates); connected via SoftwareSerial at 57,600 baud (RX = D2, TX = D3).
• 5V relay module (Arduino side): active LOW; HIGH keeps the 12V solenoid locked, LOW energizes it. Driven from Arduino D4.
• 12V solenoid lock: electromechanical locking action.
• Status LEDs: red and yellow indicate rejection; green indicates a granted unlock.
• 16×2 I²C LCD (address 0x27): displays boot state, match/no-match feedback, and lock state.
• ESP32-CAM (AI-Thinker): Wi-Fi, HTTP server, camera streaming, and a separate output used by the network action handler. The reviewed code does not document or implement an inter-board bridge line.

Software Architecture

The Arduino firmware is written in C++ and uses the Adafruit_Fingerprint library. The matching operation is a full linear search (fingerSearch()), not a fast search, so latency scales with the number of enrolled templates. The access-control path is: initialize the sensor, wait for a finger, capture an image, convert to the sensor’s internal representation, search the stored template database, evaluate the match result, and actuate the relay only after a successful match. During the five-second unlock interval, the Arduino drives the green LED. No bridge output is implemented in the supplied Arduino sketch.

The ESP32 firmware uses the ESP-IDF HTTP server interface. Port 80 serves the root page and ‘/action‘ endpoint; port 81 serves ‘/stream‘ for MJPEG video. The browser sends ‘forward‘ and ‘stop‘ values through the ‘go‘ query parameter. Code inspection also identified a control-flow defect in the action handler: the ‘else‘ branch is attached to the second ‘if‘ statement, so a ‘forward‘ request can set the output and still return an HTTP 500 response. This should be corrected and retested before describing the remote action path as reliable. The supplied firmware contains no ‘/status‘ handler, no HTTP authentication, and no bridge signal from the Arduino.

Methodology and Implementation

Fingerprint Enrollment

Before authentication testing, fingerprints are enrolled into the sensor using the stock Adafruit enrollment sketch. The process assigns an identifier to a finger, captures the finger twice, constructs a fingerprint model, and stores that model in the sensor’s local database. The deployed prototype was enrolled with a registered user during project development. The firmware uses getTemplateCount() to check whether at least one template is present; this source-code behavior is not a substitute for a documented performance test. Local storage is relevant to privacy because the prototype does not require a fingerprint template to be uploaded to a remote service. Nevertheless, local storage is not equivalent to complete biometric security: physical access to the sensor, template-management weaknesses, and sensor-specific implementation risks remain outside the scope of the present experiment.

Local Authentication and Lock Control

During normal operation the user places a finger on the sensor. If the sensor returns a recognized identifier, the Arduino drives the active-LOW relay LOW to energize the solenoid, holds it for five seconds (implemented as a blocking delay(5000)), and then returns the relay to HIGH. The green LED is driven HIGH for the same interval. Rejections drive the red and yellow LEDs HIGH for 1.5 s and display “No match” on the LCD. No buzzer, failure counter, maximum-attempt lockout, remote alert routine, or persistent event log is implemented; consequently none of these features is claimed in this paper.

Network Monitoring and Control

The ESP32-CAM connects to a configured Wi-Fi network and prints its assigned IP address on the serial console at boot. A client on a reachable network can open ‘http://<ip>/‘ to load the browser interface. The page sends ‘/action?go=forward‘ and ‘/action?go=stop‘ requests; the stream is served at ‘/stream‘ on port 81. The supplied code does not provide a JSON status endpoint or require credentials. Code inspection found a conditional-branch issue in the action handler that may cause a ‘forward‘ request to return HTTP 500 even after changing the output. Therefore, remote actuation should be treated as an implementation requiring correction and retesting, not as a fully validated control feature. The data flow is shown in Figure 4, and the browser interface in Figure 5.

Authentication Decision Process

Let x denote the captured fingerprint sample and T = {t₁, t₂, …, tₙ} the set of templates stored in the sensor. The matching operation produces a binary decision D(x, T) ∈ {match, no match}. The access-control rule is

A (F) = \{\begin{array}{l} 1, & if M (F, D) returns a valid enrolled match, \\ 0, & otherwise . \end{array}

When a fingerprint match is returned, the relay is commanded to unlock the solenoid for the programmed interval. When no match is returned, the relay remains in the locked state and the rejection indication is displayed. This simple binary rule is appropriate for the current single-door proof-of-concept but does not provide role-based permissions or differentiated access levels.

Implementation Procedure

The implementation followed a practical sequence: hardware assembly, wiring verification, fingerprint-sensor enrollment, Arduino firmware upload, ESP32-CAM firmware configuration, Wi-Fi connection, browser-interface verification, and functional testing. The author performed repeated informal checks using her own enrolled fingerprint, including successful matches and unsuccessful verification attempts, to observe the prototype’s responses. These checks were not recorded as a structured trial-level dataset. The physical lock-control path was kept separate from the network interface; browser activity was not treated as a biometric event.

The firmware review and the available project description are treated separately. The implementation findings below are based on inspection of the supplied sketches. Because no contemporaneous trial-level records or instrumented timing measurements were retained, quantitative biometric performance metrics and measured response-time statistics are omitted. No claim is made that the network action handler has been corrected or that HTTP authentication has been added.

Functional Verification and Evaluation Scope

The project materials describe fingerprint enrollment and local relay actuation, as well as an ESP32-CAM browser interface and camera stream. The author reports repeated informal self-tests with her own fingerprint, including successful and unsuccessful verification attempts. However, no contemporaneous records documenting the number and outcomes of individual attempts, timing measurements, or a predefined test protocol were available for independent verification. Consequently, this paper does not report accuracy, false acceptance rate (FAR), false rejection rate (FRR), a confusion matrix, or numerical response-time results.

The firmware inspection is not a cybersecurity penetration test. No systematic attempt was made to exploit the ESP32 web server, bypass access controls, perform packet manipulation, test credential attacks, conduct fingerprint spoofing, or quantify network attack success. These remain important directions for future work and should not be interpreted as tests that have already been completed.

Use of AI-Assisted Tools

Generative AI tools were used to assist with manuscript drafting, language editing, and LaTeX formatting. The author is responsible for reviewing the manuscript, verifying factual claims and references, and approving the final content.

Implementation Review Findings

Source-code inspection identified several limitations in the supplied ESP32-CAM firmware. The browser control endpoint uses plain HTTP and does not implement application-level authentication. The firmware does not expose a JSON door-state endpoint and does not include a signal linking the Arduino’s fingerprint decision to the ESP32-CAM control path. The two controllers therefore operate as independent access paths in the reviewed implementation.

The action handler also contains a conditional-branch defect: the ‘else‘ branch is associated with the second ‘if‘, so a ‘forward‘ request can set the output and still return an HTTP 500 response. This is a source-code finding and should be retested on hardware after correction. No quantitative biometric or network-security result is claimed because the underlying trial-level or security-test records are unavailable.

Discussion

Limits of Performance Evidence

The available project files did not include independently verifiable records of individual fingerprint trials or instrumented response-time measurements. For that reason, numerical claims about biometric accuracy, FAR, FRR, or latency are excluded from this version. A future evaluation should record each authorized and unauthorized attempt, define the test protocol in advance, retain anonymized trial outcomes, and calculate performance metrics with suitable uncertainty intervals. The test should include multiple participants, repeated attempts, varied finger placement, and relevant environmental conditions.

IoT Functionality and the Two Subsystems

The prototype contains two independent control paths. The Arduino reads the R307 sensor and actuates its relay following a fingerprint match. Separately, the ESP32-CAM exposes an HTTP action endpoint and controls its own output without consulting the fingerprint sensor. The reviewed code does not include the claimed Arduino D8-to-ESP32 GPIO13 bridge, so the browser cannot distinguish biometric from network unlocks through a shared state signal. The two paths do not gate one another, which is a substantive architectural limitation.

The ESP32-CAM endpoint is served over plain HTTP and has no authentication in the reviewed firmware. Any client able to reach the endpoint can attempt to issue control requests; the identified action-handler defect means that behavior must be corrected and tested before reliable remote actuation can be claimed. The Wi-Fi SSID and password are also stored as string constants in the firmware, which creates a credential-exposure risk if the source or flash contents are shared. The absence of TLS means that HTTP traffic is not protected in transit.

Security and Privacy Analysis

The principal security boundary in the biometric path is the fingerprint sensor’s matching decision; however, its quantitative performance cannot be characterized from the records available for this manuscript. The network boundary is weaker in the supplied code: the ESP32-CAM serves its control endpoint without authentication, and the transport is plain HTTP rather than TLS. The Wi-Fi SSID and password are stored as string constants in the ESP32 firmware. Anyone with access to the source can read them; source code intended for public release should have credentials removed, and the Wi-Fi password should be changed if a live credential was exposed.

The two controllers do not share authentication state. A remote request is not conditioned on a successful fingerprint match. In addition, the ‘/action‘ handler’s ‘if‘/‘else‘ structure can return an HTTP 500 response for ‘forward‘ requests even though the output assignment has run. This is a functional defect to fix and retest. The ESP32 output is configured on GPIO12 in the supplied code, a strapping pin on the ESP32; this can affect boot behavior depending on the connected relay module. The Arduino firmware uses blocking delays during access feedback and the five-second unlock interval, so it cannot process another fingerprint attempt during those delays.

Limitations

A reproducible trial-level dataset was not available for this revision, so the biometric subsystem cannot be quantitatively evaluated here. The system implements binary fingerprint authentication rather than differentiated multi-user permissions. Continuous or post-entry biometric verification is not implemented. Formal biometric spoofing or presentation-attack testing was not performed. No network vulnerability scan or penetration test was conducted. The supplied ESP32 web interface has no HTTP authentication and does not use HTTPS/TLS; Wi-Fi credentials are compiled into the firmware as plaintext. The biometric and network paths do not share an authentication state. The ‘/action‘ handler has a conditional-branch defect that requires correction and retesting. The ESP32 output is driven from GPIO12, a strapping pin whose behavior depends on the hardware configuration [10,14].

Future Work

Future development should extend both the functional scope and the rigor of evaluation. Multi-user fingerprint profiles could provide differentiated access identifiers. Continuous or post-entry authentication could reduce the limitation of relying on a single authentication event at the doorway Binding the network path to a live biometric event—for example, requiring a successful fingerprint match within the past 5 seconds before a remote unlock command is accepted—would convert the parallel architecture into a coordinated one. The network interface requires a separate security-hardening track, including HTTPS/TLS, credential storage in NVS rather than firmware constants, and endpoint validation. A documented biometric dataset with multiple users and repeated trials per user would allow FAR/FRR estimates and uncertainty intervals to be calculated [10,11,12].

Conclusions

This paper documented a low-cost smart door-lock proof-of-concept with a local Arduino/R307 fingerprint path and a separate ESP32-CAM network interface. Source-code inspection found that the ESP32-CAM serves a browser page, an HTTP action endpoint, and an MJPEG stream, but does not implement HTTP authentication, a JSON status endpoint, or a bridge to the Arduino controller. The network action handler also contains a conditional-branch defect that should be corrected and retested. Because independently verifiable fingerprint trial records were unavailable, this version does not claim quantitative biometric accuracy or false-acceptance/rejection rates. The network path is not fingerprint-gated and should not be deployed as a security-sensitive remote lock in its current form. Future work should correct and validate the action handler, add authentication and TLS, remove hard-coded Wi-Fi credentials, coordinate the two control paths, and conduct a reproducible biometric evaluation and a separate security assessment.

Data Availability

No structured or independently verifiable trial-level biometric dataset was created or retained. The paper therefore does not report quantitative biometric performance metrics. Firmware and project materials may be made available by the author upon reasonable request, after removing credentials and any personal or biometric information.

Ethical Considerations

Functional fingerprint checks were performed by the author using her own fingerprints, including repeated successful and unsuccessful verification attempts. No other individuals’ fingerprint samples were used. Aqsa Irfan assisted with operating the device but did not provide fingerprint samples for testing. No formal research ethics committee approval or written exemption was obtained for this project, and the manuscript does not claim such approval or exemption. No identifiable fingerprint images or third-party biometric data are included in this manuscript.

Competing Interests

The author declares no competing interests.

Funding

This research received no external funding.

References

Aqib, M. “How to Create a Fingerprint Sensor Door Lock With an Arduino UNO,” Maker Pro, Nov. 2018. Available online: https://maker.pro/arduino/projects/how-to-create-a-fingerprint-reading-door-lock-system-with-an-arduino-uno.
Yang, W.; et al. Security and Accuracy of Fingerprint-Based Biometrics: A Review. Symmetry 2019, vol. 11(no. 2), 141. [Google Scholar] [CrossRef]
Kaur, J.; Gill, H. S.; Kumar, A.; Singh, J. Fingerprint Door Lock System Using Arduino and Bluetooth Application. In in Energy Systems, Drives and Automations: Proceedings of ESDA 2021; Springer, 2023; pp. 293–301. [Google Scholar] [CrossRef]
Shanthini, M.; et al. IoT Enhanced Smart Door Locking System. Proc. 3rd Int. Conf. Smart Systems and Inventive Technology (ICSSIT), 2020; pp. 92–96. [Google Scholar] [CrossRef]
Priya, Hathi Manasa; Reddy, B. B.; Babu, G. S. Surendra; Praveen, K. Finger Print Door Lock System and Voice Controlled Home Appliances Using Arduino. Int. J. Sci. Res. Comput. Sci. Eng. Inf. Technol. 2020, vol. 6(no. 5), 29–35. [Google Scholar]
Sarma, M.; Gogoi, A.; Saikia, R.; Bora, D. J. Fingerprint Based Door Access System Using Arduino. Int. J. Sci. Res. Eng. Manag. (IJSREM) 2020, vol. 4(no. 8), 1–5. [Google Scholar]
Alnabhi, H.; Al-naamani, Y.; Al-madhehagi, M.; Alhamzi, M. Enhanced Security Methods of Door Locking Based on Fingerprint. Int. J. Innov. Technol. Explor. Eng. (IJITEE) 2020, vol. 9(no. 3), 1173–1178. [Google Scholar] [CrossRef]
Paul, P.; Achib, M. A. A.; Hossain, H. S.; Hossain, M. K. “Smart Door Lock Using Fingerprint Sensor,” technical report. In BRAC University; 2019. [Google Scholar] [CrossRef]
Baidya, J.; Saha, T.; Moyashir, R.; Palit, R. Design and Implementation of a Fingerprint Based Lock System for Shared Access. 2017 IEEE 7th Annual Computing and Communication Workshop and Conference (CCWC), 2017; pp. 1–6. [Google Scholar] [CrossRef]
Dahia, G.; Jesus, L.; Segundo, M. P. Continuous Authentication Using Biometrics: An Advanced Review. WIREs Data Min. Knowl. Discov. 2020, vol. 10(no. 4), e1365. [Google Scholar] [CrossRef]
Ayeswarya, S.; Singh, K. J. A Comprehensive Review on Secure Biometric-Based Continuous Authentication and User Profiling. IEEE Access 2024, vol. 12, 82996–83021. [Google Scholar] [CrossRef]
Alrawili, R.; AlQahtani, A. A. S.; Khan, M. K. Comprehensive Survey: Biometric User Authentication Application, Evaluation, and Discussion. Comput. Electr. Eng. 2024, vol. 119, 109485. [Google Scholar] [CrossRef]
Goyal, P. K.; Giri, M.; Verma, S. IoT-Based Smart Door Lock System with Face Recognition Using ESP32 CAM and Android App. In Innovations in Electrical and Electronic Engineering: Proceedings of ICEEE 2023; Springer, 2024; vol. 1115, pp. 365–376. [Google Scholar] [CrossRef]
Motwani, Y.; Seth, S.; Dixit, D.; Bagubali, A.; Rajesh, R. Multifactor Door Locking Systems: A Review. Mater. Today Proc. 2021, vol. 46(no. 17), 7973–7979. [Google Scholar] [CrossRef]
Basavaraja, B.; Naikodi, C. A Review on Fingerprint Oriented Lock and Unlock Identification System. Int. J. Eng. Res. Technol. (IJERT) 2023, vol. 11(no. 5). [Google Scholar] [CrossRef]
Hemalatha, S. A Systematic Review on Fingerprint Based Biometric Authentication System. 2020 Int. Conf. Emerging Trends in Information Technology and Engineering (ic-ETITE), 2020; pp. 1–4. [Google Scholar] [CrossRef]
Ziad; Darnila, E.; Kurniawati. Development and Implementation of an ESP32 Microcontroller and Monitoring System for Smart Door Lock Using RFID Sensor for E-KTP ID and Fingerprint Based on the Internet of Things. Proc. Malikussaleh Int. Conf. Multidiscip. Stud. (MICoMS) 2024, vol. 4. [Google Scholar] [CrossRef]

Figure 1. Hardware-level organization based on the supplied firmware. The Arduino/R307 path controls its relay locally; the ESP32-CAM independently serves a browser interface and camera stream and controls its own output. No inter-board bridge signal is implemented in the reviewed code.

Figure 2. Functional use-case representation of the prototype; network access is independent of fingerprint authentication.

Figure 3. Assembled prototype: Arduino Uno, R307 fingerprint sensor, active-LOW relay, 12V solenoid, 16×2 I²C LCD, and status LEDs.

Figure 4. Data flow for the two independent paths. The supplied firmware does not implement a signal or shared authentication state between the Arduino and ESP32-CAM.

Figure 5. ESP32-CAM browser interface showing the live camera stream and door control buttons. The reviewed page does not display a lock-state badge.

Table 1. Conceptual Comparison of Access-Control Approaches.

Criterion	Conventional/basic	Implemented prototype
Credential	Physical key or keypad code	Fingerprint template (R307)
Local access	Manual unlocking	Fingerprint match $\to$ relay $\to$ 12V solenoid
Remote interface	Usually absent	ESP32-CAM HTTP action endpoint (no authentication)
Visual monitoring	Not inherent	Live MJPEG stream (port 81)
Biometric path	Not applicable	Local at sensor; not IoT-mediated
Web security	Depends on mechanism	No HTTP authentication; no HTTPS/TLS
Evaluation	Often qualitative	Architecture and firmware review; no verified trial-level dataset

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

© 2026 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

Copyright: This open access article is published under a Creative Commons CC BY 4.0 license, which permit the free download, distribution, and reuse, provided that the author and preprint are cited in any reuse.