Who is accountable when a termination event does not revoke facility access?

Why This Matters for Security Teams

When a termination event does not revoke facility access, the failure is not just an access control miss. It is a lifecycle control breakdown across HR, identity governance, and physical security. The key question is who owns the end-to-end revocation workflow, because accountability cannot be split across disconnected systems and still be considered complete. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and revocation processes, which is why these gaps persist long after a termination is processed. The same governance problem appears in physical access when badge systems, HR records, and approval chains do not reconcile in real time. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls treats access revocation as a control obligation, not a courtesy, and the obligation has to be assigned to a named owner. In practice, many security teams discover the gap only after a terminated employee is still able to enter a facility, rather than through intentional reconciliation testing.

How It Works in Practice

The accountable party is the organisation that controls the lifecycle process and the systems of record, usually with HR as the trigger, identity governance as the orchestrator, and physical access management as the enforcement layer. If any one of those layers is missing from the chain, the revocation event is incomplete even if one team believes it has “closed” the ticket. Practitioners should treat termination as a workflow, not a single action. The workflow should confirm four things: the trigger was received, the access decision was executed, the physical credential was disabled, and the outcome was verified.

For NHI and other machine identities, the same pattern applies to secrets and tokens: the offboarding event must revoke access at the source, not just mark an account inactive. The NHI Lifecycle Management Guide and the Lifecycle Processes for Managing NHIs section both reinforce that lifecycle governance only works when revocation is automated, logged, and validated. For security teams, the operational steps usually include:

• Define a single control owner for termination-to-revocation, even if multiple teams execute tasks.
• Synchronize HR, PIAM, and PACS events so termination cannot be “complete” until all systems report revocation.
• Use time-bound exception handling for delayed badge return, escorted exit, or legal hold cases.
• Require post-action verification, such as access log checks and badge status confirmation.

This is also where policy matters. A named owner should be accountable for the control, while system administrators remain responsible for execution in their domains. The OWASP Non-Human Identity Top 10 is useful here because it frames stale access and weak lifecycle management as recurring identity risks, not isolated operational mistakes. These controls tend to break down when facility access is administered locally, HR data is delayed, and no shared revocation audit exists because ownership becomes ambiguous at the exact moment response speed matters most.

Common Variations and Edge Cases

Tighter revocation control often increases operational friction, requiring organisations to balance rapid offboarding against exceptions for contractors, travelers, and regulated retention cases. In some environments, a termination event may not mean immediate full revocation if there is a legal, safety, or investigations hold. Best practice is evolving, but the hold must be explicit, time-limited, and approved, not an informal delay that leaves access open by accident. That distinction matters because a delayed deprovisioning request is not the same as a controlled exception.

Edge cases also arise when access is indirect. A terminated employee may lose badge access but still retain entrance through shared doors, escort policies, or third-party managed facilities. In those situations, accountability still sits with the organisation that owns the process, even if a vendor operates the equipment. NHI Management Group’s Top 10 NHI Issues and Key Challenges and Risks sections make the broader point: lifecycle gaps become security events when no one can prove what was revoked, when, and by whom. For physical access, the same logic applies. The accountable owner is the one who can enforce and evidence revocation, not the team that simply recorded the termination.

Related resources from NHI Mgmt Group

• Who is accountable when access logs or policy decisions are missing during assessment?
• Who is accountable for third-party access in healthcare zero trust?
• Who is accountable when business associates access ePHI without strong MFA?
• Who is accountable for exposing remote access services to the internet?