Guide
Integrating visitor management with access control
How to connect a visitor system to the doors: issuing time-bound visitor credentials, deciding what data flows each way, and the questions to put to both vendors before anyone writes a line of configuration.
A visitor management system knows who is expected, who they are visiting and when they arrived. An access control system knows which doors open for which credential. Left apart, the two leave a gap that reception fills by hand: a pool card from a drawer, a name written on a list, a card that is never handed back.
Connecting them closes that gap. A visitor signs in, receives a credential that opens only the doors they need, only for the time they need them, and loses it the moment they sign out. Done well, it is one of the most useful things a visitor system can do. Done carelessly, it quietly hands door permissions to a front-desk tablet.
This guide covers what integration actually involves, how to scope visitor access, what data should pass between the systems, and what to ask both vendors.
Three levels of integration
“Integrates with access control” can mean very different things on a product page. In practice there are three levels, and it helps to be explicit about which one you are buying.
Level one is where most sites start: two systems running side by side. Reception signs the visitor in, then either keys them into the access system or hands over a card from a pool. It works, but every step depends on someone remembering it.
Level two is a one-way push. Signing in, or pre-registering, creates the visitor in the access control system with a defined access level and validity period. This removes the re-keying and makes expiry automatic.
Level three adds traffic in the other direction. The access system tells the visitor system when a credential was used, returned or revoked, so a visitor who leaves through the turnstiles can be signed out without visiting the desk. This matters if you depend on visitor data for evacuation roll-call — see our guide to running an evacuation roll-call.
Where the two functions come from one product, the integration question changes shape. The LobbyExpress directory (98 products, October 2026) lists 25 access control platforms with a visitor module, where visitor and door data share a platform. For everyone else, it is a connection between two vendors’ systems, and the rest of this guide applies in full.
Choosing the visitor credential
The credential has to be something your readers can actually read. That sounds obvious, but it is the constraint that most often sinks a plan.
| Credential | How it works | Watch for |
|---|---|---|
| Pool card | A reusable card from a managed stock, enrolled to the visitor for the visit | Cards not returned; stock tracking; re-enrolment on every visit |
| Printed code | A QR or barcode printed on the visitor badge | Readers must support it; codes can be photographed and shared |
| Mobile credential | A pass delivered to the visitor’s phone | Visitor needs a compatible phone and app or wallet support |
| PIN | A short code entered at a keypad | Codes are easily passed on; best for low-risk doors |
Check the reader estate before choosing. A building with older card-only readers may need new readers at the doors visitors use before printed or mobile credentials are possible. Our guide to choosing visitor sign-in hardware covers the reception end of the same decision.
Scope access by place and by time
A visitor credential should open as little as possible for as short a time as possible. Two settings do the work.
Access level. Map each visitor type to a small number of predefined access levels — for example, “ground floor meeting rooms” or “workshop, escorted”. The visitor system should choose from a list that security has defined, not build new permissions on the fly.
Validity window. The credential should be inactive until the visitor signs in, and should expire at a fixed time whether or not they sign out. Sign-out should revoke it immediately. The fixed expiry is the safety net for everyone who walks out without stopping at the desk.
Unreturned pool cards deserve a specific rule. If a card is not handed back, the integration should disable it at expiry and flag it, so it can be recovered or removed from stock. A card that silently stays live is the most common weakness of level-one set-ups.
Decide what data crosses the line
An integration is a data flow, and it should be designed as one. Write down every field that passes between the systems, in which direction and why. Our guide to GDPR and visitor data covers the wider principles; here, the rule is simply that the access system should receive what it needs to open doors and nothing more.
Then ask how the connection works and what happens when it fails. Is it a direct interface between the two products, or does it pass through middleware or a shared directory? If the link drops, does sign-in still work, and do credentials that were already issued keep working until expiry? If a push fails, does anyone get told? A visitor standing at a locked turnstile is the usual way people find out.
Who owns the permissions
The most important design decision is organisational. Reception owns the visit; security owns the doors. The integration should let reception pick from a list of approved visitor access levels and nothing else. Changing what those levels open is a security task, made in the access control system, with its own approval and audit trail.
Review the visitor access levels at a set interval, the same way you review staff access. Check that the audit logs on both sides can be matched, so you can show which visit a credential belonged to. And involve your data protection lead before turning on level-three sync: door events tied to named visitors are personal data, and you should be clear why you are keeping them and for how long.
What to ask both vendors
Integrations sit between two contracts, which is exactly where problems go unowned. Ask each vendor its own questions, then ask both the same shared ones and compare the answers.
Ask for a reference configuration — a description of a working set-up between the two products at the versions you run — and test it in a non-production environment. Our list of security questions to ask a visitor management vendor covers the wider security review that should run alongside.
Where to go next
If your visitors include contractors, credentials and inductions are tightly linked: read contractor management: inductions, permits and insurance. If you are considering ID scanning at sign-in as part of the same project, our analysis of ID scanning and watchlists sets out where the line should sit. To compare products by category, start with the vendor directory.