It decides. The reader collects the credential; the controller checks it against the rules, drives the lock and records what happened.

Keeping the decision at the controller is a security requirement, not an architectural preference. A reader that decides for itself and simply closes a relay can be defeated by shorting the wires behind it.

The controller also holds the schedules, the door timings, the anti-passback rules and whatever else the site has configured.

It monitors the door as well as opening it - position, forced, held open - which the reader has no visibility of.

And it buffers events so nothing is lost when the network is down.

That is why a controller is sited inside the area its doors protect, in a locked enclosure.

More than the site's whole population, with headroom - because the cache is what keeps the doors working during an outage.

Controllers vary enormously in cache size, and the figure is easy to overlook in a specification.

A controller holding fewer records than the site has people starts turning away legitimate staff mid-outage, which is the worst possible moment for it.

Some systems download only the cardholders relevant to that controller's doors, which reduces the requirement - but check what happens when someone's access changes and the network is down.

Event buffer size matters equally. Offline events must be stored and uploaded on reconnection or the audit trail has a hole covering the incident.

Test it at commissioning by disconnecting the network and trying the doors, including with a recently enrolled credential.

Cost per door and failure domain - and often where the unit is physically mounted.

Single-door controllers mount near their door, frequently on the network and sometimes powered by it. A failure affects one door.

Multi-door panels sit centrally in an enclosure with one power supply and one standby battery, which is simpler to maintain and cheaper per door.

The trade is concentration. Every door on a panel shares its power, its processor and its enclosure.

Cable distance usually decides the matter anyway: reader and lock circuits have maximum runs, so a central panel cannot serve a distant wing regardless of its port count.

Mixed designs are common and sensible - panels where doors cluster, edge controllers where they are isolated.

The modern supervised, encrypted protocol - and it should be enabled, not merely available.

The legacy reader interface sends credential numbers in clear over an unsupervised pair. Anyone reaching that cable can capture or inject numbers.

The modern protocol is bidirectional, encrypts the channel and supervises the connection, so a cut cable or a substituted reader is reported.

It also lets several readers share one bus, which materially reduces cabling on large installations, and allows central configuration and firmware updates.

Many installations buy capable hardware and run it in legacy mode because that is the default. Make enabling it a commissioning deliverable with evidence.

Where legacy readers must remain for now, keep their cabling entirely within the secure area.

At minimum a lock output, a door position input and a request-to-exit input - and more if tampers, emergency releases or auxiliary devices are monitored.

Counting only readers and locks is the classic under-specification, and it surfaces at commissioning when there is nowhere to land the door contacts.

A monitored emergency release, an enclosure tamper, a fire alarm interface and an auxiliary relay for a barrier or a lift each consume a point.

Supervised inputs, which detect a shorted or cut cable as well as an open or closed contact, are worth specifying and use end-of-line resistors.

Leave spare capacity. Adding a door contact later to a fully populated controller means an expansion board or a new controller.

Check the relay ratings against the actual lock current, particularly for magnetic locks and for inrush when several release together.

Rarely within one system - controllers are usually tightly bound to their management software, and that is the main source of vendor lock-in in access control.

The reader-to-controller interface is standardised enough that readers can often be mixed. The controller-to-software interface generally is not.

Some platforms support hardware from several manufacturers, and open architectures exist, but the claim needs verifying against the specific models rather than accepted in principle.

This is worth deciding early, because it determines how expensive a change of software will be in ten years.

Where a site wants flexibility, choose the software platform first and then a controller it genuinely supports rather than the reverse.

Ask what happens at end of support: whether the controllers can be adopted by another platform, or become scrap.

As embedded equipment: its own network segment, changed default credentials, current firmware, and no route from the internet.

A controller is a small computer wired to a lock relay, and it has the maintenance profile of an appliance rather than a server.

Put controllers on a dedicated segment with tightly controlled routing. There is no reason a general user device should be able to reach one.

Default passwords are the commonest finding in any access control audit. Change them at commissioning and record where they are held.

Firmware needs a maintenance plan, because vulnerabilities in access hardware are published like any other.

Integrator remote access should be through a path the customer controls and can switch off, not a permanent tunnel nobody remembers authorising.