Build a Standalone RFID Access Control Reader with a PN532 and ESP32
A commercial RFID access control panel for a workshop door, tool cabinet, or shed runs anywhere from $150 to well over $500 once you add a controller, reader, and strike relay — and most of that cost is a locked-down, subscription-gated system built for commercial buildings, not a maker's garage. A PN532-based reader and an ESP32 build the same core function — tap a card or fob, unlock a door — for well under $30 in parts, fully standalone with no cloud account required, and it's a genuinely useful first hardware-security project that teaches NFC/RFID fundamentals, relay switching, and safe low-voltage access control wiring. This project covers the electronics build; it does not cover defeating or cloning access control systems, which is a different topic entirely (see our Flipper Zero RFID/NFC hacking guides if that's what you're after).
How It Works
The PN532 module reads 13.56MHz NFC tags (MIFARE Classic/Ultralight, NTAG, and similar) over SPI, I2C, or UART depending on how you wire it — this build uses I2C for simplicity with only two data wires. The ESP32 reads each tag's unique ID (UID), checks it against a stored list of authorized UIDs, and if it matches, energizes a relay for a few seconds to release an electric strike or magnetic lock. Because it runs standalone on the ESP32 with UIDs stored in flash, it works without WiFi or a phone app, though you can optionally add WiFi for remote UID management or a log of access events.
Wiring
PN532 PinESP32 Pin VCC3.3V GNDGND SDAGPIO21 (default I2C SDA) SCLGPIO22 (default I2C SCL)Most PN532 breakout boards have a small switch or solder jumpers to select I2C/SPI/UART mode — confirm it's set to I2C before wiring. The relay module's signal pin connects to a free GPIO (e.g. GPIO25), with the relay's own VCC/GND run from the ESP32's 5V and GND (most relay modules want 5V logic to switch reliably even though they'll often trigger from 3.3V). Wire the relay's normally-open (NO) contact in series with the strike's power feed from the 12V supply — the relay simply completes or breaks that 12V circuit, keeping the strike's higher current entirely isolated from the ESP32's low-voltage side. Add a flyback diode across the strike coil if your relay module doesn't already have one on board; without it, the inductive kickback from the strike coil switching off can damage the relay contacts over time.
Firmware
Use the Adafruit_PN532 Arduino library, which handles the low-level NFC protocol and exposes a simple readPassiveTargetID() call that returns the tag's UID as a byte array:
#include <Wire.h> #include <Adafruit_PN532.h> Adafruit_PN532 nfc(-1, -1); // I2C mode const int RELAY_PIN = 25; // Store authorized UIDs as byte arrays byte authorizedUIDs[][4] = { {0xDE, 0xAD, 0xBE, 0xEF}, {0x12, 0x34, 0x56, 0x78} }; void setup() { Serial.begin(115200); pinMode(RELAY_PIN, OUTPUT); digitalWrite(RELAY_PIN, LOW); nfc.begin(); nfc.SAMConfig(); } void loop() { uint8_t uid[7]; uint8_t uidLength; if (nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, uid, &uidLength, 1000)) { if (isAuthorized(uid, uidLength)) { digitalWrite(RELAY_PIN, HIGH); delay(4000); // strike held open ~4s digitalWrite(RELAY_PIN, LOW); } } } bool isAuthorized(uint8_t *uid, uint8_t len) { for (auto &known : authorizedUIDs) { if (memcmp(uid, known, 4) == 0) return true; } return false; }For anything beyond a handful of fobs, move the UID list into ESP32 flash storage (Preferences library or SPIFFS) rather than hardcoding it, and consider adding a simple web server over WiFi so you can add/remove UIDs without reflashing every time. Add the buzzer and RGB LED for immediate audible/visual feedback on access granted vs denied — this makes a huge difference in how usable the finished reader feels versus a silent relay click.
Fail-Safe vs Fail-Secure Strikes
This matters and is easy to get backwards: a fail-safe strike unlocks when power is removed (used where egress during a power outage or fire matters — many jurisdictions require fail-safe on primary egress doors), while a fail-secure strike stays locked when power is removed and only unlocks when energized (used for cabinets, sheds, and secondary doors where you want it to default to locked). Check local code requirements before installing anything on an occupied building's egress path — for a workshop, tool cabinet, or shed this is generally a non-issue, but it's worth understanding before you buy hardware.
Security Considerations
Be aware going in that basic MIFARE Classic cards have well-documented cryptographic weaknesses and their UID can be cloned with cheap, readily available tools (including a Flipper Zero) — this project is a genuinely useful convenience access system for a garage, shed, or tool cabinet, but it is not equivalent to a commercial-grade access control system and shouldn't be the only layer of security on anything that actually needs to resist a motivated attacker. If security against cloning matters for your application, look at MIFARE DESFire or other cards that support real cryptographic authentication rather than a bare UID check, which adds complexity but closes the most obvious cloning vector.
Mounting and Enclosure
For an exterior-facing reader, use a weatherproof enclosure and route the strike wiring through a grommet or cable gland rather than a drilled hole with no seal. A quick 3D printed bracket or enclosure works well for the reader itself if you keep the PN532 module's antenna area (usually the far end from the header pins) unobstructed by anything conductive, which can detune the antenna and shorten read range.
Related Guides
- How to Hack RFID and NFC with the Flipper Zero: LF, HF, MIFARE, and iButton
- How to Analyze EMV Payment Cards with the Flipper Zero: NFC, APDU Commands, and Security Architecture
- How to Read Bad Blocks on a Flipper Zero — NFC Deep Dive
- Setting Up Marauder on the ESP32 Wi-Fi Dev Board for Flipper
- Flipper Zero NFC Tools — Reading and Analyzing NFC Tags
- Cloning and Emulating RFID/NFC Cards with Flipper Zero
- ESP32 as a WiFi Sniffer/Deauth Detector
- ESP32 Secure Boot and Flash Encryption: Protecting Firmware and Data on Deployed Devices