They stall because access problems cut across people, devices, applications, vendors, and regulated workflows. If IAM, PAM, compliance, and operations do not align on ownership and enforcement, teams create gaps in provisioning, review, and revocation. Progress improves when organisations treat identity as an operating model, not just a set of features.
Why This Matters for Security Teams
Identity and access programmes stall when they are treated as ticket queues or product deployments, because the real problem is cross-functional control over who or what can act, under which conditions, and for how long. That gap is especially visible in non-human identity estates, where the volume and velocity of service accounts, API keys, and automation tokens outpace manual governance. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs.
The issue is not that tools are missing. It is that IAM, PAM, compliance, cloud, and engineering often optimise separate steps without agreeing on ownership, enforcement, and exception handling. That creates a false sense of progress: a vault gets deployed, a review campaign runs, or a rotation policy is published, but access still remains over-provisioned, stale, or unrecoverable in practice. The OWASP Non-Human Identity Top 10 reflects how quickly this breaks down when machine identities are not governed as first-class assets. In practice, many security teams encounter the failure only after a secret leak, privilege abuse, or offboarding gap has already exposed the weakness in the operating model.
How It Works in Practice
Successful programmes treat identity as an operating model, not a software rollout. That means defining decision rights across application owners, platform teams, security, and audit, then enforcing those decisions through policy, workflow, and telemetry. NIST SP 800-53 Rev. 5 is useful here because it separates the control objective from the implementation choice: account lifecycle, access enforcement, and logging must all be governed, even if the tooling differs by environment.
For NHI-heavy estates, the practical sequence is usually:
- Inventory every human and non-human identity, including orphaned keys, hidden service accounts, and third-party access paths.
- Assign an accountable owner for each identity class, system, or workload, not just for the tool that stores its credentials.
- Define provisioning, review, rotation, and revocation rules in the same process, so one team cannot approve access that another team cannot remove.
- Automate enforcement where possible, especially for short-lived secrets, just-in-time access, and offboarding.
- Measure drift continuously, because periodic reviews do not catch privilege sprawl fast enough.
This is why the Ultimate Guide to NHIs — Key Challenges and Risks emphasizes lifecycle management, visibility, rotation, and offboarding as connected controls rather than isolated tasks. When teams adopt that model, IAM and PAM stop competing as separate projects and instead become enforcement layers inside a shared identity governance process. These controls tend to break down when ownership spans multiple vendors and cloud accounts because no single team can verify end-to-end revocation.
Common Variations and Edge Cases
Tighter identity governance often increases operational overhead, requiring organisations to balance stronger control against delivery speed and platform autonomy. That tradeoff is manageable in stable enterprise applications, but it becomes harder in platform engineering, M&A integrations, and regulated third-party ecosystems where identities are created and retired continuously.
There is no universal standard for how much should be centralised versus delegated. Current guidance suggests central policy with local execution works best: security defines minimum control requirements, while application and platform teams implement them in context. The Top 10 NHI Issues resource highlights the same pattern in practice, especially where secrets are stored outside vaults or where revocation is slow after a compromise.
Edge cases also matter. Legacy systems may not support modern lifecycle hooks, shared service accounts may be difficult to split immediately, and some CI/CD pipelines will fail if rotation is too aggressive. In those cases, best practice is evolving toward compensating controls such as tighter monitoring, segmented privilege, and time-bounded exceptions with explicit expiry. Organisations that ignore these constraints usually end up with policy that looks strong on paper but cannot survive real deployment pressure.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity sprawl and weak lifecycle control are central to stalled NHI programmes. |
| OWASP Agentic AI Top 10 | A-04 | Autonomous access patterns need runtime governance, not static role assumptions. |
| CSA MAESTRO | MAESTRO-2 | Programmes stall when security, ops, and app teams lack shared governance for identity. |
| NIST AI RMF | GOVERN | Identity programmes fail without clear accountability and risk ownership. |
| NIST CSF 2.0 | PR.AA-01 | Authentication and authorisation must be coordinated across systems and workflows. |
Inventory all NHIs, assign owners, and enforce lifecycle controls across provisioning through revocation.
Related resources from NHI Mgmt Group
- Why do identity and access governance projects fail when teams treat them as purely technical initiatives?
- Why do identity security programmes often fail when access reviews focus only on applications and not on the data being reached?
- Why do non-employee access programmes often create governance gaps in identity security?
- How should security teams treat DNS in identity and access programmes?
