A credential, a reader, a controller, a locking device and the exit-side hardware - plus software to administer them.

The credential is what a person carries or presents. The reader collects it at the door and sends it onward. It makes no decision of its own in most architectures.

The controller holds the access rules and takes the decision. It energises or de-energises the lock and puts the event in the log.

The locking device - a maglock, an electric strike, an electrified lockset - is what physically holds the door. It is usually specified with the door rather than with the access system.

The exit side carries a request-to-exit sensor or an exit button so leaving does not raise an alarm, and an emergency release so people can get out if everything fails.

Management software ties it together: enrolling people, writing schedules, and holding the audit trail that makes the system worth having.

No. Free escape is a life-safety requirement that access control is not permitted to obstruct, and this is settled law in essentially every jurisdiction.

Access control governs entry. On a designated escape route the door must release for anyone leaving, without a key, a code or a credential, and usually with a single action.

That is why emergency release units are wired to cut lock power directly, independently of the controller. A release that asks the software for permission is not a release.

Fail-safe locks - which unlock when power is removed - are the usual answer on escape routes. Fail-secure locks stay locked without power and belong on doors that are not part of an escape route.

The specifics differ: which doors are escape routes, how many actions are permitted, whether delayed egress is allowed at all and for how long. These are set by local fire and building regulations, and they should be established before hardware is chosen rather than after.

It depends on who administers it and how many sites there are - but in both cases the access decision itself should stay at the controller.

On-premises means the server and database sit on the customer's network. It suits organisations with their own IT function, strict data residency requirements, or a preference for capital rather than operating expenditure.

Cloud-hosted removes the server, the backups and the version upgrades from the customer's plate, and makes multi-site administration considerably easier. The cost becomes a recurring subscription.

The important point is separate from that choice: controllers should hold their rules and cardholder data locally so doors keep working when the link is down. Ask how many cardholders each controller caches and what happens when the number is exceeded.

Data residency deserves an explicit answer in a cloud deployment, because access logs are personal data in most privacy regimes and some organisations are not permitted to hold them outside a given territory.

Older 125 kHz proximity credentials transmit a fixed number with no authentication and can be copied with inexpensive, widely available equipment.

The technology was designed for convenience in an era when the threat model was a borrowed key, not a cloning device. It has been thoroughly demonstrated as copyable, and the tools are neither rare nor expensive.

Smart card credentials answer this by authenticating cryptographically: the card and the reader prove knowledge of a shared key without transmitting anything reusable.

Mobile credentials work similarly, with the added benefit that issuing and revoking one happens in software, with nothing to hand over or recover.

Migration does not have to be sudden. Multi-technology readers accept both old and new credentials, so a site can replace readers first and reissue cards over the following renewal cycle.

Where the estate cannot be replaced yet, adding a second factor - a PIN, or a biometric on the highest-value doors - raises the bar considerably without touching the card population.

It is the modern, supervised, encrypted protocol between a reader and its controller - the replacement for the older one-way wiring that has no protection at all.

The legacy reader interface sends the credential number down a pair of data lines in clear, one way, with no supervision. Anyone who reaches the wiring behind a reader can record numbers and replay them.

The modern protocol is bidirectional, supports encryption of the reader-to-controller channel, and supervises the connection so a cut or a substituted reader is reported rather than silently ignored.

It also allows several readers to share a bus, which reduces cabling on large installations, and lets the controller manage reader configuration and firmware centrally.

Practically: specify readers and controllers that support it, and make sure it is actually enabled with encryption turned on. A great many installations buy capable hardware and then run it in legacy mode because that was the default.

Enough that a single failure does not open or lock out an unacceptable part of the building - which usually means smaller controllers than the price list encourages.

High-capacity panels are cheaper per door and reduce the number of enclosures, power supplies and network points. That is a real saving on a large site.

The counterweight is failure domain. Every door on one controller shares its fate, so a 32-door panel is a 32-door outage. Splitting critical doors across controllers costs a little and contains the damage.

Cable distance is the other constraint. Readers and locks have limits on how far they can be driven, so the controller has to be near the doors regardless of its capacity.

Also check the offline cardholder cache per controller, not per system. A panel that caches only part of the population will refuse valid users during a network outage, which is exactly when nobody can fix it.

Every access decision with its outcome, every door state change, every administrative change to the rules, and every tamper or fault event.

Granted and denied events are the obvious ones, and denials are frequently the more useful of the two - repeated denials at an unusual hour are the signal an investigation starts from.

Door state matters independently of the decision. A door forced open, or held open past its timer, is an event even though no credential was involved.

Administrative changes are the ones most often overlooked. Who granted this person access to that door, and when, is the question an audit will ask, and a system that logs only card swipes cannot answer it.

Retention is a policy decision with a legal component: access logs identify individuals and their movements, so most data protection regimes expect the reason for holding them to be written down and the period to be finite.

Yes, and the integrations worth having are with the intruder alarm, video, the lifts, and the directory that already knows who works there.

Video is the most common: an access event gives the recorded footage a bookmark, which turns hours of review into a single click.

Intruder alarm integration lets a valid credential disarm an area on entry and arm it on last-out, which removes the separate keypad and the shared code that goes with it.

Directory integration is the one that saves the most administrative effort. When the identity system is the source of truth, a leaver loses building access at the same moment they lose their email account, rather than whenever someone remembers.

Lift integration restricts which floors a credential can select, which is how multi-tenant buildings are usually secured.

Check how each integration is licensed. Interfaces to third-party systems are a common place for a separately chargeable module to appear late in a project.

Software licences or subscription, credential replacement, standby batteries, and the administrative time to keep the cardholder database honest.

Licensing is the largest and least visible. Models are per door, per reader, per cardholder or per site, and adding doors later can cost more than the hardware.

Credentials are a recurring consumable. Cards are lost, damaged and never returned by leavers, and the annual replacement rate on a large population is significant.

Standby batteries in the panels have a finite life and fail quietly. They need a scheduled replacement cycle, not a reactive one.

Administration is the cost nobody budgets. Enrolments, leavers, lost cards, temporary access and visitor passes are a continuous workload, and a system whose database has drifted from reality provides very little security.

For cloud deployments, confirm what happens to the data and the doors if the subscription lapses.

Through a temporary credential with a hard expiry, issued against a named host and recorded in the same audit trail as everyone else.

The failure mode is a pool of unassigned visitor cards handed out at reception and never reconciled. Those cards accumulate, stay active, and eventually go missing.

Any credential issued to a visitor should carry an automatic expiry - end of day is typical - so an unreturned card stops working by itself.

Contractors need something in between: access for the duration of the works, to the areas the works cover, expiring on the end date in the contract rather than when someone notices.

Mobile credentials suit both cases well, because issuing and revoking one is instant and there is no physical card to chase.

Whatever the mechanism, the visitor record and the access log should be linked. Knowing that a card was used is not useful unless you also know who was holding it.