Who is accountable when identity friction blocks compliance progress?

Why This Matters for Security Teams

identity friction is not just an inconvenience. It is a control failure that slows approvals, pushes teams toward workarounds, and leaves compliance evidence fragmented across IT, security, operations, and audit. When access models are inconsistent, the organisation cannot prove that least privilege, revocation, and review are operating as intended. NIST’s Cybersecurity Framework 2.0 frames this as a governance issue as much as a technical one, because accountability must be traceable across the full lifecycle.

NHIMG research shows why the issue persists: the Ultimate Guide to NHIs reports that 68% of organisations do not know how to fully address NHI risks, while 90% of IT leaders say proper NHI management is essential for zero trust. That gap between policy intent and operational reality is where compliance stalls, especially when identity owners, application teams, and control owners are not aligned on who approves, who implements, and who signs off. In practice, many security teams discover that accountability was assumed rather than assigned only after audit exceptions and access delays have already accumulated.

How It Works in Practice

Accountability should be distributed, but not blurred. The identity programme owner is accountable for the access model, lifecycle rules, and control design. Operational teams are accountable for using approved workflows, requesting access through the right channels, and removing exceptions when systems change. Compliance is accountable for defining the evidence standard and testing whether the control actually works. That three-way split is the practical answer to identity friction because no single team can own both business continuity and audit assurance.

Current guidance suggests that teams should move from ticket-driven approvals to policy-driven access decisions. That means standardising identity sources, shortening exception paths, and building evidence capture into the workflow instead of collecting screenshots later. The Lifecycle Processes for Managing NHIs material is especially relevant here because compliance progress depends on provisioning, rotation, revocation, and offboarding being owned end to end, not as one-off tasks. For control language, map the work to the NIST CSF access and governance functions, then prove that each access event can be traced to an approved policy decision and a named owner.

• Identity owners define the access standard and publish the approved control path.
• Platform and application teams implement the workflow without bypasses or shadow grants.
• Compliance validates evidence completeness, exception handling, and review cadence.
• Operations escalates blockers early, rather than creating manual one-time approvals.

When these responsibilities are explicit, identity friction becomes measurable and removable. These controls tend to break down when legacy systems require manual admin intervention because the approval chain and the technical enforcement path no longer match.

Common Variations and Edge Cases

Tighter governance often increases process overhead, so organisations must balance auditability against delivery speed. That tradeoff becomes more visible in regulated environments, public safety systems, and mixed human plus machine access models, where a single missed entitlement can delay critical operations. Best practice is evolving here: there is no universal standard for whether the compliance function should merely attest to control design or actively co-own operational enforcement.

Where regulated data and mission-critical systems intersect, accountability often needs to extend to the business owner of the process, not just the IAM team. The 52 NHI Breaches Analysis and the Top 10 NHI Issues both reinforce a common pattern: failures rarely start with policy absence, but with unclear ownership, stale access, and unmanaged exceptions. For compliance programmes, the practical test is simple. If the team cannot name who approves, who implements, and who can revoke access immediately, then accountability is still unresolved.

In mature environments, the right answer is usually a shared model with a single accountable executive and clearly delegated control owners. In fragmented environments, identity friction often survives because every team believes another team is responsible, and auditors are left to reconstruct accountability after the fact.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• Why do non-human identities create compliance risk even when policies exist?