They underestimate how quickly unmanaged access becomes business risk. Identity work is not just account setup or periodic cleanup; it is the control surface that determines whether users and systems can reach sensitive resources appropriately. When teams treat it as clerical work, governance usually arrives too late to matter.
Why This Matters for Security Teams
When identity is treated as an administrative queue, teams optimise for ticket closure instead of access assurance. That creates blind spots in provisioning, privilege creep, orphaned accounts, and delayed revocation, which are exactly the conditions attackers exploit. NHI Management Group’s research shows the scale of the problem: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges in modern enterprises, according to the Ultimate Guide to NHIs.
The mistake is not just operational, it is architectural. Identity is the control plane that determines who, what, and which workload can reach sensitive systems, and whether that access remains appropriate over time. The more cloud, SaaS, automation, and API-driven business processes expand, the less “manual cleanup” scales as a security model. Guidance in the NIST Cybersecurity Framework 2.0 reinforces that identity governance must support continuous protection, not periodic clerical review. In practice, many security teams discover identity risk only after secrets leak or a dormant account is abused, rather than through intentional access design.
How It Works in Practice
Effective identity security treats access as a lifecycle control with clear ownership, policy, and telemetry. That means defining who can approve access, what evidence is required, how long access lasts, how it is reviewed, and what triggers revocation. For NHIs, the same logic applies to service accounts, API keys, OAuth apps, certificates, and agent identities. The control objective is not merely to “create accounts,” but to ensure every identity is tied to a business purpose, a bounded privilege set, and a revocation path.
Teams usually need three things in place:
- Central visibility into all identities, including third-party and machine identities, so shadow access does not accumulate.
- Policy-based provisioning and deprovisioning, with JIT access where possible and automatic revocation when the task ends.
- Continuous monitoring for privilege drift, stale secrets, and inactive identities, with alerts tied to real risk rather than calendar cycles.
For agentic and automation-heavy environments, that discipline needs to extend to runtime decisions. Static RBAC alone cannot safely model an AI agent that chains tools or changes intent mid-task. Current practice increasingly uses workload identity, short-lived tokens, and real-time policy evaluation, as described in NIST AI 600-1 GenAI Profile and the NIST AI risk guidance. The practical lesson is that identity should prove what a workload is and what it is allowed to do right now, not merely what role it was assigned last quarter. NHIMG’s Top 10 NHI Issues aligns with this by emphasising visibility, rotation, and offboarding as first-class controls. These controls tend to break down in highly fragmented environments where identity changes are still tracked in spreadsheets, ticket trails, and disconnected tooling.
Common Variations and Edge Cases
Tighter identity control often increases operational overhead, requiring organisations to balance faster delivery against stronger assurance. That tradeoff is real, especially where development teams expect self-service access and platform teams manage thousands of machine identities. Best practice is evolving, but there is no universal standard for exactly how often every identity should be reviewed or which risks justify manual approval versus automated policy.
Two edge cases matter most. First, third-party access can look low-risk until OAuth apps, contractor accounts, or vendor-managed service principals retain privileges long after the business need ends. Second, emergency access paths can undermine the whole model if they are not time-boxed and logged. This is why NHI offboarding, secret rotation, and exception handling need the same rigor as onboarding. NHIMG research on the 52 NHI Breaches Analysis shows how often compromise follows dormant or over-privileged access rather than sophisticated initial access. For teams aligning identity to broader assurance programs, the NIST IR 8596 Cyber AI Profile is useful where automation or AI-assisted decisions influence access.
The operational warning is simple: once identity is delegated to administration alone, governance becomes reactive. That model fails fastest in environments with SaaS sprawl, CI/CD automation, and loosely owned machine access, because no one has a complete view of who can still reach what.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF 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 stale access are core NHI lifecycle risks. |
| NIST CSF 2.0 | PR.AC-1 | Administrative identity handling often misses access governance and least privilege. |
| NIST AI RMF | AI governance depends on managing identity, accountability, and operational risk at runtime. |
Embed identity controls into AI risk management so access decisions are traceable, bounded, and monitored.
Related resources from NHI Mgmt Group
- What do teams get wrong when they treat identity verification as a one-time compliance task?
- What do security teams get wrong when they think access management is enough?
- What do teams get wrong when they treat self-service request portals as identity governance?
- What do teams get wrong when they treat AI security as a detection-only problem?
