Accountability should sit with the organisation that owns the access workflow and its control design. HR, IT, and physical security each carry responsibility for their part, but the enterprise must define one authoritative process for access decisions, logging, and review. Without clear ownership, mismatches between HR status and badge access become compliance and safety failures.
Why This Matters for Security Teams
When physical access decisions do not match HR status or security policy, the issue is rarely just a badge problem. It signals a broken control chain across joiner, mover, leaver events, where one system believes a person is active while another has already changed the risk posture. That creates real exposure at doors, in data centers, and in other restricted spaces where badge decisions are expected to be immediate and deterministic.
For security teams, the harder problem is accountability. HR may own employment status, physical security may own badge issuance, and IT may own identity records, but none of those functions alone can explain an incorrect access grant. The enterprise needs one authoritative decision process, plus evidence that revocation, review, and exception handling are working end to end. NIST’s Cybersecurity Framework 2.0 and the NHIMG Ultimate Guide to NHIs both reinforce that identity governance fails when ownership is fragmented. In practice, many security teams discover the mismatch only after a terminated or transferred user still opens a door, rather than through intentional control testing.
How It Works in Practice
The most defensible model is a single access workflow with clear source-of-truth rules, usually anchored in HR for employment status and in physical security for badge lifecycle execution. HR should trigger status changes, but the access decision itself must be governed by policy that maps status, role, location, and exception approvals into an auditable outcome. That means the workflow should log who requested access, who approved it, what policy allowed it, when it was issued, and when it was revoked.
Current guidance suggests that the control owner should not be the same as every contributing system owner. HR is accountable for accurate status events, IT is accountable for identity data synchronization, and physical security is accountable for enforcement at the door. The enterprise, however, is accountable for the control design. That includes reconciliation between HR records and badge entitlements, periodic access recertification, and fast revocation on termination or transfer. NHI operations often mirror this problem: if identity state is fragmented, access remains valid longer than intended. NHIMG’s State of Non-Human Identity Security reports that lack of credential rotation and weak logging are major causes of compromise, which is a useful warning for badge governance too.
- Use one authoritative workflow for badge provisioning and revocation.
- Synchronise HR events into the physical access system with near real-time updates.
- Require documented exception handling for temporary access and contractors.
- Reconcile badge holders against active employees on a scheduled basis.
- Preserve immutable logs for approvals, revocations, and manual overrides.
For program design, align access decisions to the NIST SP 800-53 Rev. 5 control families that cover access enforcement, audit logging, and personnel security. These controls tend to break down when mergers, outsourced facilities, or manual badge desk processes introduce parallel approval paths that bypass the authoritative workflow.
Common Variations and Edge Cases
Tighter badge governance often increases operational overhead, requiring organisations to balance rapid facility access against the risk of over-approval. That tradeoff becomes more visible for contractors, visitors, shared spaces, and after-hours responders, where policy exceptions are common and delay can affect business continuity.
There is no universal standard for this yet, but current practice is to treat exceptions as time-bound and explicitly owned. If HR records lag behind a resignation or termination, physical security should not be left to infer intent from stale data. Likewise, if a manager requests emergency access, the approval path should be visible, limited, and automatically reviewed after the event. The same governance principle appears in the NHIMG 52 NHI Breaches Analysis: once control ownership is unclear, attackers and insiders exploit the gap between systems rather than the system itself.
For organisations with multiple sites, outsourced guards, or legacy badge systems, the practical answer is not more handoffs. It is clearer accountability, stronger reconciliation, and fewer manual overrides. Where those conditions are missing, mismatches persist because no single team can prove it owns the full decision lifecycle.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Access decisions must be governed and attributable to one owner. |
| NIST SP 800-53 Rev 5 | AC-2 | Accountability depends on accurate account lifecycle management and revocation. |
| NIST AI RMF | Governance principles apply when multiple systems influence a decision. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Fragmented identity governance creates stale access and delayed revocation risks. |
| CSA MAESTRO | GOV-1 | Multi-system access workflows need explicit ownership and auditability. |
Assign a named control owner for badge access decisions and review exceptions on a fixed cadence.
Related resources from NHI Mgmt Group
- How should organisations implement policy-based access control in identity-centric security programmes?
- Who should be accountable for API policy and compliance when development moves faster than security reviews?
- Who is accountable when workflow access reviews and source-of-truth decisions are inconsistent?
- How should security teams run access reviews for non-human identities?
