Presence Is Not Proof: Reconciling Door Events With Network Identity
Photo: Giles Laurent, CC BY-SA 4.0, via Wikimedia Commons
A member of staff taps a badge at 08:41, walks to a desk, opens a laptop and is online by 08:44. Three systems recorded that sequence: the access control platform, the wireless controller and the DHCP server. None of the three knows what the others saw. In a great many UK estates this is treated as unremarkable, and for most of the working day it is. The difficulty is that the same structural silence also covers the contractor whose badge expired on Friday but whose device certificate did not, the second person who followed the first through a door without presenting anything, and the meeting-room port that has been live and unauthenticated since the room was refurbished.
Zero-trust architecture is fond of the phrase never trust, always verify. Physical presence is where that phrase is most often quietly suspended. A body inside the building is treated as a proxy for an authorised identity, and the network is configured to behave as though the proxy were evidence. It is not evidence. It is a coincidence of geography that happens to correlate well enough, often enough, to survive without scrutiny.
Two systems, two truths
A physical access control system (PACS) is an availability-first estate. Its records describe a credential presented at a reader, a decision taken, and a door released. A network access estate is a confidentiality-first estate. Its records describe a supplicant, a network access server, a policy decision and a session. Both produce timestamps. Both produce identities. Neither is authoritative about the other, and in most organisations they are owned by different teams, funded from different budgets and reviewed against different risk registers.
The practical consequence is that the join between them is nobody's control. Facilities can tell you who entered. The network team can tell you who authenticated. Almost nobody can tell you, with confidence, whether the second follows from the first.
What the audit actually joins
An effective reconciliation starts by enumerating the evidence that already exists. In a typical UK enterprise estate the minimum set is: badge events from the PACS, including reader, door, credential and decision; 802.1X authentication records from RADIUS or the equivalent, including supplicant identity, switch and port, and outcome; DHCP leases mapping hardware addresses to addresses and lease windows; session records from firewalls, VPN concentrators and identity providers; and switch MAC address tables for wired segments.
The join keys are less obvious than they appear. Credential identifiers must map to a person or a sponsor, and that mapping is frequently held in a spreadsheet maintained by a security team rather than in the identity provider. Hardware addresses must map to device records. Room and desk allocations must map to switch ports. Where any of these mappings is incomplete, the audit does not fail — it simply produces a category of unmatched records that must be reported honestly rather than explained away.
| Evidence source | Typical join key | Common defect |
|---|---|---|
| PACS badge event | Credential ID to person | Contractor records held outside the HR feed |
| 802.1X authentication | Supplicant identity to device | Machine certificates reused after reissue |
| DHCP lease | Hardware address to asset record | Virtual machines sharing a physical host record |
| Session logs | User principal to session | Shared service accounts obscuring attribution |
Clock discipline before correlation
Correlation is an ordering problem, and ordering depends on time. Before a single exception is raised, the auditor should confirm that PACS controllers, network access servers, DHCP servers and log pipelines are synchronised to a common time source and that drift is measured rather than assumed. A two-minute offset between a door controller and a RADIUS server is enough to make a tailgating event look like a legitimate sequence, or the reverse. Any reconciliation performed without that check is decoration.
Three failures the join exposes
The first is the tailgate. One badge presentation, two authenticated devices appearing on the same floor within a plausible window. On its own this is ambiguous — a colleague may have arrived by another door — which is why the finding should be expressed as a ratio across a period rather than as an accusation about a morning.
The second is credential persistence. A contractor's badge is withdrawn when the engagement ends, but the device certificate issued to their laptop remains valid for the remainder of its lifetime, and the machine account in the directory remains enabled. The person cannot open a door; the device can still reach the resource. This is the most common form of quiet over-privilege in UK estates, and it survives because the two lifecycles are managed by two processes that never meet.
The third is the dormant port. Meeting rooms, hot-desking areas and temporary project spaces frequently contain switch ports that have been enabled for convenience and placed in a general-purpose VLAN without authentication. Presence in the room becomes sufficient cause for connectivity. A visitor with a patch cable and a reasonable manner is a network identity.
Designing controls at the boundary
The correct posture is that a door event may request trust but must never confer it. That principle translates into a small number of concrete engineering decisions.
- Bind the badge lifecycle and the credential lifecycle to a single joiner-mover-leaver record, with contractor sponsorship carrying an explicit expiry date and a named internal sponsor who is notified before it lapses.
- Treat presence as a signal for re-authentication rather than a substitute for it. A badge-in event can trigger a posture check; it cannot satisfy the check.
- Make 802.1X mandatory on access ports, with no unauthenticated VLAN except a documented onboarding service that issues nothing until a sponsor approves the device.
- Place meeting-room and shared-space ports into a quarantine profile by default, releasing them only against an authenticated device and a current asset record.
- Correlate occupancy against session count at floor level, and set thresholds that generate reviewable exceptions rather than an unreadable alert stream.
- Extend the same correlation out of hours, where a single badge-in and six active sessions is a more interesting question than any dashboard metric.
Ownership is the control that keeps the others alive
Physical security often reports into facilities management while network access sits with the infrastructure function. The join between them therefore falls between two reporting lines, and controls that fall between reporting lines decay. The remedy is unglamorous: a named owner for the reconciliation, a monthly evidence pack signed by both sides, and an entry in the risk register that describes the failure mode rather than the tooling.
None of this requires a new platform. It requires an organisation to decide that physical presence is a claim to be tested, and to keep testing it on a schedule, with the results written down and reviewed by someone with the authority to act on them. The badge is a request. The network should be the thing that answers.
