How can organisations tell whether their access governance model is keeping up?

Why This Matters for Security Teams

access governance usually looks healthy until the inventory expands beyond employees. Service accounts, SaaS integrations, vendor OAuth grants, machine identities, and now agent access can all sit outside the same review, approval, and revocation process. That creates a false sense of control: the policy says least privilege, but the actual footprint includes identities with no owner, no expiration, and no evidence of recertification.

The most useful signal is coverage. If a team can map human users but not NHIs, it is already operating with partial governance. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames this as an auditability problem as much as a security problem: if an identity cannot be attributed, reviewed, and revoked on time, it is outside defensible control. Current guidance in NIST Cybersecurity Framework 2.0 also pushes organisations toward governance that spans the full access lifecycle, not just periodic access review.

In practice, many security teams encounter NHI sprawl only after a credential leak, a broken integration, or a failed audit exposes how much access had never been brought under the model.

How It Works in Practice

A governance model is keeping up when every identity class follows the same control logic even if the implementation differs. That means an organisation can answer four questions for each access path: who owns it, what it can reach, when it was last reviewed, and how it is revoked. NHIs should not be treated as exceptions with separate spreadsheets and informal approvals; they need lifecycle management that is tied to provisioning, monitoring, rotation, and retirement, as outlined in NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

A practical maturity check starts with coverage by identity class:

• Human users under RBAC and access recertification
• Service accounts with named owners, scope limits, and expiry
• OAuth and SaaS integrations with approved business purpose
• API keys, tokens, and certificates with rotation and revocation hooks
• Agent or AI tool access with runtime policy checks and short-lived credentials

The issue is not whether a control exists, but whether it operates at the same cadence as the access footprint. For example, a quarterly review can be adequate for a stable SaaS role, but it is weak for ephemeral automation that creates and deletes identities in minutes. The same is true for detection: monitoring a login stream is not enough if the identity is an API token used only by another system.

OWASP’s OWASP Non-Human Identity Top 10 highlights the common failure pattern: orphaned secrets, excessive permissions, and weak lifecycle controls. Organisations that still rely on manual exception handling usually discover that their governance model breaks down when identity creation is automated, ownership is distributed, or revocation depends on a human ticket queue.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, so organisations must balance control depth against the speed of delivery. That tradeoff is real, especially where engineering teams deploy ephemeral workloads, third-party vendors manage their own integrations, or business units buy SaaS tools without central intake. Best practice is evolving, but there is no universal standard for exactly how to review every non-human identity class yet.

One common edge case is delegated administration. A vendor may own the technical integration, but the business still owns the risk. Another is inherited access through platform defaults, where a new app or agent comes with broad permissions before any explicit governance step occurs. In both cases, the model is behind if it cannot force a named owner, a bounded scope, and a revocation path.

NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both point to the same operational lesson: governance usually lags where identities are easiest to create and hardest to remember. The most mature programmes therefore measure coverage by exception rate, orphan rate, overdue review rate, and time-to-revoke, not by the number of policies written. Where those metrics cannot be produced, the model is not keeping up.

Related resources from NHI Mgmt Group

• How can organisations tell whether their identity controls are keeping up with machine-speed access?
• How can organisations tell whether NHI governance is actually working?
• How do organisations decide whether to prioritise secrets management or access governance first?
• How can organisations tell whether SOX access governance is actually working?