Access control is an identity problem wearing a hard hat

A business will spend real effort on getting joiners and leavers right in its IT systems: accounts provisioned from a role, disabled on the day someone finishes, reviewed periodically.

Then the same business hands out access cards from a drawer, tracked in a spreadsheet that somebody maintains when they remember, and has no idea how many active credentials exist for the side door.

Both systems answer “should this person be able to get in”. One of them has been treated as an IT discipline and the other as a facilities cupboard.

Where the two lists diverge

The failure is always the same shape. A person leaves. Their account is disabled that afternoon, because payroll told IT. Their card keeps working, because nobody told the person who administers the door system, or because that person is on leave, or because the card was never assigned to a name in the first place.

Multiply across a few years and a site accumulates working credentials belonging to people who no longer work there, contractors from a project that finished, and cards that were issued as spares and never recovered.

The uncomfortable part is that this is usually worse than the equivalent IT gap, because a stale card is not visible in any report anybody reads, and because physical access frequently defeats every logical control anyway. Somebody standing in front of a server, a network cabinet or an unlocked terminal has options.

Treating physical access as identity

The fix is conceptual before it is technical: the same person should exist once, and their access should be derived from their role rather than issued separately by each system.

In practice:

One authoritative list of people. Whatever drives account creation should drive card issuance. Where the systems can integrate, integrate them. Where they cannot, at minimum make the offboarding checklist include the card and give it to the same person who disables the account.

Cards assigned to named individuals, never to a role or a drawer. An unassigned credential cannot be revoked with any confidence, because nobody knows who has it.

Time-bound contractor access by default. A contractor card expires on the date their engagement ends. Extending it is deliberate. This is the same argument as time-bound seasonal accounts, for the same reason.

Periodic review, comparing lists. Once or twice a year, put the active card list next to the active staff list and look at the difference. It is a dull afternoon that consistently finds something.

Logs someone can retrieve. Not for surveillance, for the question that arrives after an incident: who had access to that area, and when. If the answer takes two days and a call to an installer, the system is not doing its job.

And they share a network

There is a second reason these belong together. Controllers, readers and cameras are network devices. They ship with default credentials, they are rarely patched, and they are frequently installed on whatever switch was closest by an installer who is excellent at doors and was not asked about segmentation.

A door controller is a small computer sitting inside your network with a cable running to the outside of the building. It should be on its own segment, with a changed password and a known firmware version. That is not an exotic requirement, but it only happens if whoever installed it thinks about networks.

Why we do both

We hold a PSPLA licence and we design, install and manage physical security systems ourselves. That is partly a commercial choice and mostly a practical one: the same practice that runs your identity and your network installing your access control is how these two lists stay in agreement, and how the controller stops being the weakest device on the LAN.

If you have never compared your active card list to your staff list, that comparison is the cheapest security exercise available to you this quarter.