QR Code Access Control: Static vs Dynamic QR, Turnstiles and 4G Controllers

Dynamic QR code access control gives each person a code generated by your management platform for specific doors and a set time window, usually signed or encrypted, so a screenshot or photocopy stops working once the window closes. A camera-based reader scans the code; the reader, a standalone controller or a server validates it and then releases a door, barrier or turnstile. Static QR codes still have a place, but only where a copied code would not matter.

This guide explains how the pieces fit, how to connect QR readers to controllers and turnstiles, when a 4G cloud controller makes sense, and what to check for security.

How QR code access control works

A QR code access control system has four parts:

1. Issuer. Management software, a cloud platform or a visitor-management system creates the code and delivers it by app, email, SMS or printed badge.
2. Reader. A camera module with its own illumination decodes the QR symbol, which is defined in ISO/IEC 18004. Many access-control QR readers also decode symbologies such as Data Matrix and PDF417, and many include a 13.56 MHz card reader for ISO/IEC 14443A card UIDs, so staff can use cards while visitors use QR.
3. Decision point. The reader itself, a standalone controller or a server checks whether the code is valid for this door at this moment.
4. Output. A relay releases the lock, or a signal tells a barrier or turnstile to allow one passage.

QR readers work at palm distance, not across a lane. The readers in our QR code reader range are specified for scan distances from a few centimeters up to about 18 cm, so users hold the phone or ticket up to the scan window. That makes mounting height and angle important, especially on turnstiles.

Screens and paper behave differently. Phone screens reflect ambient light and vary in brightness, and cracked screens or heavy screen protectors can break up the symbol. Paper codes need adequate print size and contrast. Test both before rollout.

Static vs dynamic, time-limited QR codes

A static QR code always contains the same data, typically a user or card number. It behaves exactly like a card number printed on paper: anyone who photographs it can use it until an administrator revokes it. That is acceptable for low-risk doors or single-day events, not for staff entrances.

What is a dynamic QR code? A dynamic QR code is generated for a specific user and validity window and differs every time it is issued. The platform typically encodes an identifier, a start and end time and sometimes door or zone data, then signs or encrypts the payload with a key shared with the readers or controllers. The reader can then check, even offline, that the code is genuine, unaltered and inside its window.

Code type	What the code carries	Validity	Screenshot reuse risk	Typical use
Static	Fixed user or card number	Until revoked	High: works like a copied card	Low-risk doors, internal use
Time-limited dynamic	ID + start/end time, signed or encrypted	Minutes to days, set per code	Only within the window	Visitors, contractors, deliveries
Rolling (auto-refresh)	ID + current time slot, signed	Seconds; the app redraws the code	Very low: a screenshot expires quickly	Staff and members using a phone app
One-time	ID + unique code number, signed	Until first use or expiry	Low, if used codes are tracked	Couriers, single-entry tickets

Three technical details decide whether dynamic codes work in practice:

• Clock accuracy. A time window is only as good as the device’s clock. Networked devices should synchronize time, for example over NTP or from the cloud platform, and standalone controllers need a real-time clock with backup so a power cut does not reset the date.
• Single use needs memory. To reject a second scan of a one-time code, something has to remember that it was used. A standalone controller can do this for its own door; across several doors, only a server or a shared controller can enforce it.
• Rolling codes need an app. The refreshing code is either computed in the user’s app from a shared secret and the current time, similar in concept to the time-based one-time passwords of RFC 6238, or fetched from the server. Either way it requires an app, not an emailed image.

A note on terms: in marketing, “dynamic QR code” usually means a short link that redirects to a URL you can change later. That is unrelated to access control, where dynamic means the credential itself changes and expires.

Reader mode vs standalone controller

Reader mode. The QR device acts purely as a reader and sends what it decodes to an access controller or PC. This is the right choice when you already have a panel, but the interface decides what data can pass:

Interface	Data per read	Typical maximum cable length	Notes
Wiegand 26	24 data bits (8-bit facility code + 16-bit number) + 2 parity bits	about 150 m (500 ft)	One-way, unencrypted; fits a card number, not a dynamic QR payload
Wiegand 34	32 data bits + 2 parity bits	about 150 m (500 ft)	Same limits, larger ID range
RS485	Full decoded string (protocol-dependent)	up to 1,200 m (4,000 ft) at low data rates	Multidrop bus; twisted pair with 120 Ω termination at both ends
USB (keyboard emulation or virtual COM)	Full decoded string	5 m (16 ft) for USB 2.0 without extenders	PCs, kiosks and reception desks
TCP/IP (Ethernet)	Full decoded string or API event	100 m (328 ft) per copper segment	Needs network infrastructure; suits server-side validation

Wiegand is the key limitation. A signed dynamic payload is far longer than 32 bits, so it cannot pass through a Wiegand port intact. Either the reader validates the code itself and outputs the matching user’s card number in Wiegand 26 or 34 format (the Wiegand 26-bit format guide shows how that number is structured), or you use RS485, USB or TCP/IP so your software receives the full content and validates it.

Standalone controller. A standalone QR controller combines the reader, the validation logic, a user list and a relay (NO/COM/NC) with inputs for an exit button and door status sensor. It suits single doors, gates and small sites. Many standalone units, including those in our QR code access controllers range, can also run in reader mode over Wiegand or RS485, which gives you a path forward if the site later adds a central panel.

As with any device that switches a lock, think about where the relay sits. A standalone unit on the unsecured side of the door exposes the lock wiring if someone removes it. For higher-security doors, run it in reader mode into a controller on the secure side.

QR code turnstile integration over Wiegand or RS485

Turnstiles, swing gates and speed gates are where QR access is most common: visitor lobbies, gyms, stadiums and transit-style entrances. A typical lane looks like this:

• One QR reader per direction (entry and exit), mounted in or on the gate cabinet at a comfortable scan height and angle.
• Each reader connects to an access controller over Wiegand (one port per reader) or RS485 (one bus, a unique address per reader).
• The controller validates the code and closes a relay into the gate’s control board. Many gate boards accept a separate dry-contact input for each passage direction, and a short pulse authorizes one passage.
• A passage-complete output from the gate back to the controller lets the system count actual passages and enforce anti-passback. Without it, the controller knows a code was accepted, not that someone walked through.

Where the QR device has its own validation and relay, it can pulse the gate input directly and skip the controller. That is simple for a single lane but gives up central anti-passback across lanes.

RS485 has two advantages at turnstiles. It carries the full decoded content for server-side validation, and one twisted-pair bus can serve every reader in a bank of lanes. Use shielded twisted pair, terminate both ends of the bus and set a unique address on each reader.

Mechanical details decide the user experience. Keep the scan window out of direct sun, angle it so people do not have to twist their wrists, and mark it clearly, because a QR lane stalls when users hunt for the window. See turnstile access control for more on lane design.

4G access control: cloud controllers for sites without a LAN

Some sites have power but no network: construction compounds, remote car park barriers, farm gates, storage yards and short-term rental properties. A 4G cloud controller carries its own cellular modem and talks to a cloud platform, so administrators can issue dynamic QR codes, manage users and open doors remotely without running network cable.

Before specifying one, check:

• LTE bands. Confirm LTE band compatibility with your country and carrier before ordering the 4G variant. A module built for one region’s bands may not register on networks elsewhere.
• Older networks. Many carriers have shut down, or are shutting down, 2G and 3G. Avoid devices that rely on them as a fallback.
• SIM and data plan. Access events use little data, while firmware updates and photo uploads use more. Confirm SIM size, APN settings and who pays for the plan.
• Signal at the mounting point. Measure signal strength where the controller will sit. Metal enclosures, basements and plant rooms may need an external antenna.
• Offline behavior. Ask what still works when the network drops. Controllers that cache the user list and verify signed codes locally keep working; those that validate every code in the cloud do not.
• Platform dependency. Find out who hosts the cloud service, what the subscription covers and whether the controller can operate locally if the service ends.
• Power. Cellular modems draw current in short bursts while transmitting. Size the power supply for peak load plus the lock.

The Bluetooth and 4G cloud controllers category covers both approaches. Bluetooth suits small sites where users stand at the door with a phone; 4G suits sites where administrators need remote control without a local network.

Visitor workflows

QR codes suit visitors because they can be sent before arrival and expire on their own. A typical pre-registered visit runs like this:

1. The host registers the visitor in the management platform with a date, time window and the doors or floors they need.
2. The platform sends a dynamic QR code by email, SMS or app link.
3. On arrival, the visitor scans at the lobby turnstile or entrance reader, and the event is logged against the host.
4. Access is limited to the permitted doors and hours; when the window closes, the code stops working.
5. The log shows who entered, when, and who invited them.

Common variations: walk-in visitors registered at reception receive a code on screen or a printed badge; contractors receive a multi-day code limited to working hours; couriers receive a one-time code for a delivery room or parcel area; gyms issue day-pass codes for paid sessions.

Keep personal data out of the code. The payload should be an opaque identifier plus validity data. Names, phone numbers and email addresses belong in the platform, not in a symbol anyone can decode with a phone camera.

Security considerations

QR access is only as secure as the way codes are generated, checked and wired:

• Avoid static codes for anything important. A static code is a copyable credential; use signed or encrypted dynamic codes instead.
• Keep windows short. A time-limited code can still be shared within its window. Use tight windows, rolling codes for regular users, and a PIN or face verification at sensitive doors.
• Protect the keys. Use a unique key per site, restrict access to configuration tools, and plan how to rotate keys if a device or admin account is compromised.
• Test forgery rejection. At commissioning, scan a self-made QR code containing a valid-looking user number and confirm the reader rejects it. If it grants access, the system is effectively running static codes.
• Protect the clock. Anyone who can set a controller’s clock back can make expired codes valid again. Restrict time changes to authenticated administrators and use network time sync.
• Secure the wiring. Wiegand is cleartext, so a device spliced into the cable can capture and replay IDs. Keep reader cabling inside the secure area where possible, connect tamper switches, and consider OSDP with Secure Channel over RS485 where both reader and controller support it. Our Wiegand vs OSDP guide explains the difference.
• Keep the relay on the secure side for doors that matter, as described above.

QR access control deployment checklist

• Code type chosen per door: static only for low-risk; time-limited, rolling or one-time elsewhere
• Codes signed or encrypted, and forged-code rejection tested at commissioning
• Controller clock synchronized and protected against unauthorized changes
• Interface matches the controller: Wiegand 26/34 with ID mapping, or RS485, USB or TCP/IP for full payloads
• One reader per direction and passage-feedback wiring for turnstiles that need counting or anti-passback
• Scan window height, angle and sun exposure tested with real phones and printed codes
• For 4G: LTE bands confirmed for your country and carrier, signal measured on site, offline behavior documented
• Visitor workflow defined: who issues codes, validity windows, permitted doors and log retention
• Personal data kept out of QR payloads
• Relay on the secure side and tamper switches connected

Next steps

Send us your door or lane count, whether the site has a LAN, the controller or turnstile you need to connect to, and how you plan to issue codes. We will confirm reader or controller options, interface compatibility and LTE bands for your country, and test before dispatch. Request a quote or sample and we will reply within 24 hours.