Why do access review and onboarding initiatives often stall even when leadership supports them?

Why This Matters for Security Teams

access review and onboarding programs rarely fail because the underlying need is disputed. They stall because the request is framed as a security task instead of an operational decision. That distinction matters in NHI governance too: if a team cannot see the business risk, workload impact, and ownership change, it will defer action. Current guidance from the OWASP Non-Human Identity Top 10 and NIST control baselines both point to least privilege, traceability, and periodic review, but those controls only move when the process is translated into the language of the receiving team.

For NHIs, the stakes are sharper because unused access, stale secrets, and overbroad entitlements create silent exposure even when no one is actively using the account. NHI Management Group research shows that 97% of NHIs carry excessive privileges and only 20% of organisations have formal offboarding and API key revocation processes, which helps explain why onboarding and review queues become backlog items instead of governance actions. The Ultimate Guide to NHIs is explicit that lifecycle discipline is the difference between control and drift. In practice, many security teams encounter resistance only after access has already expanded, not through deliberate review design.

How It Works in Practice

Successful programs treat onboarding and access review as shared operational workflows, not one-off security tickets. The first step is to translate the request into the recipient’s objective: finance cares about cost and auditability, HR cares about process continuity, and engineering cares about deployment velocity. From there, the request should define the minimum decision set needed to act. For example: who owns the account, what system it touches, whether the access is still needed, and what the impact is if it is removed today.

For NHIs, this same approach should be tied to identity lifecycle controls. The NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Key Challenges and Risks show why reviews fail when ownership is unclear, secrets are embedded in code, or service accounts are treated as static plumbing. A practical review flow usually includes:

• inventorying the account or secret, including its owner and system dependency
• rating the access by business criticality, not just technical privilege
• deciding whether the identity can be converted to just-in-time or short-lived access
• auto-removing stale entitlements after a defined inactivity window
• requiring evidence for exceptions, with a named approver and expiry date

This is also where NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful: it gives security teams a control vocabulary, but the operational work is translating it into a form that each stakeholder can approve without slowing delivery. These controls tend to break down when account ownership is embedded in tribal knowledge because no one can answer the review questions quickly enough.

Common Variations and Edge Cases

Tighter review and onboarding controls often increase coordination overhead, so organisations have to balance governance quality against release speed and administrative load. That tradeoff is especially visible in NHIs, where service accounts, CI/CD identities, and API keys may be created by automation rather than by a person waiting for approval. In those environments, a manual review queue can become the bottleneck even when leadership supports the policy.

Best practice is evolving toward risk-based segmentation rather than one uniform process for every identity. High-impact production identities should get stricter approval, shorter review intervals, and explicit expiry; lower-risk sandbox identities may use lighter-touch attestation. For service accounts, the hardest edge case is shared ownership. If no single team can revoke the access, the review process becomes performative.

Where consensus is still forming is how to model ownership for ephemeral and delegated NHIs created by pipelines, bots, and agentic workflows. Current guidance suggests using a mix of system ownership, workload metadata, and lifecycle hooks rather than human manager review alone. This is consistent with findings in the 52 NHI Breaches Analysis, which shows that governance failures often surface only after access has been abused. The same pattern appears in broader identity breaches referenced by NIST and OWASP, and it is why access review succeeds only when it is made measurable, time-bound, and tied to actual removal authority.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• Why do healthcare passwordless programmes often stall even when leaders support them?
• Why do IAM initiatives often stall even when the technology works?
• How should security teams run access reviews for non-human identities?