What breaks when access recertification is designed only for human users?

Why This Matters for Security Teams

access recertification is often treated as a governance checkbox, but human-centric review models do not map cleanly to service accounts, API keys, workload tokens, or AI agents. Human users have managers, job titles, and predictable review cycles; NHIs often do not. That matters because privilege drift accumulates quietly, and reviewers may approve access simply because the account name is unfamiliar, not because they validated actual operational need.

NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which helps explain why periodic human recertification can create a false sense of control. The problem is not only visibility, but also context: an NHI may support a pipeline, rotate across environments, or be embedded in code and orchestration logic. The OWASP Non-Human Identity Top 10 treats weak lifecycle governance as a core risk because access that is “reviewed” but not truly understood remains exploitable.

In practice, many security teams discover stale NHI access only after an incident review, rather than through intentional recertification.

How It Works in Practice

Human-only recertification fails when the review unit is the person instead of the workload. For NHIs, the correct question is not “Does this user still need access?” but “Does this workload still require this permission in this context?” That pushes the process toward workload identity, explicit ownership, and runtime policy checks rather than quarterly attestation alone.

A practical model starts by inventorying each NHI, its owning system, its purpose, its token or secret source, and its downstream dependencies. The recertification workflow should then validate four things: current business purpose, active runtime use, least-privilege scope, and expiry or rotation status. Where possible, use short-lived credentials and just-in-time issuance so approval is tied to a task rather than a permanent entitlement. Current guidance suggests pairing this with policy-as-code and real-time authorization so access decisions can be evaluated when the workload requests them, not just during a review window. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it frames lifecycle drift, secret sprawl, and missing ownership as recurring failure modes.

• Assign each NHI a named owner, system purpose, and revocation path.
• Re-certify against actual API calls, pipelines, and tool usage, not job titles.
• Rotate or revoke credentials automatically when purpose or environment changes.
• Require evidence of runtime need before approving long-lived access.

These controls tend to break down in highly automated environments where multiple services share one credential and no single team can prove end-to-end ownership.

Common Variations and Edge Cases

Tighter recertification often increases operational overhead, requiring organisations to balance reduced privilege drift against the reality of ephemeral workloads and release velocity. That tradeoff is especially sharp in CI/CD, data engineering, and agentic AI systems, where one “service account” may represent many deployment stages or autonomous actions. Best practice is evolving, but there is no universal standard for this yet.

In some environments, recertification should be task-based rather than calendar-based. For example, an ephemeral deployment token may never need a quarterly review if it is issued per build and automatically expires. In other cases, a long-lived integration account should be recertified more frequently, with evidence drawn from logs, secret managers, and workload telemetry. The 52 NHI Breaches Analysis shows why this matters: access misuse often persists because governance processes lag behind actual system behavior.

For agentic workloads, recertification also needs to account for tool chaining and emergent behavior. That is where OWASP Non-Human Identity Top 10 guidance aligns with runtime control, because static approvals cannot reliably predict what an autonomous agent will do next. The right control is not just who can approve access, but whether the access model can be revoked, narrowed, and re-evaluated fast enough to keep pace with the workload.

Related resources from NHI Mgmt Group

• What breaks when workload identity access is governed like human access?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• What is the difference between reviewing human access and reviewing NHIs?