Should organisations separate access provisioning from access review?

Why This Matters for Security Teams

Separating provisioning from review is a practical control for reducing entitlement drift, especially where service accounts, API keys, and automation identities accumulate privileges over time. The issue is not just process hygiene. When the same group both grants and certifies access, review becomes a formality, and exceptions survive far longer than intended. That is one reason NHI governance requires lifecycle discipline, not just inventory work, as described in the Ultimate Guide to NHIs.

This matters because non-human identities often outnumber human identities by 25x to 50x in modern enterprises, which makes informal access decisions scale poorly. The risk is amplified by privileged access, shared accounts, and cross-system reuse, where the approver has limited independent evidence that the access is still justified. Current guidance in the OWASP Non-Human Identity Top 10 treats excessive standing privilege and weak lifecycle governance as core exposure points, not edge cases. In practice, many security teams encounter improper certification only after a service account has already been reused across multiple systems and no one can prove who still needs it.

How It Works in Practice

The cleanest model is simple: one workflow approves and provisions access, while a separate control owner or risk owner certifies whether that access should remain active. For NHIs, that usually means tying provisioning to a ticket, change request, or policy engine, then having periodic reviews pull from authoritative entitlement data rather than from memory or team preference. The review should ask whether the identity still has a business purpose, whether its scope matches the task, and whether the credential lifetime still fits the operating need.

For higher-risk systems, current best practice is to combine segregation of duties with short-lived credentials, workload identity, and runtime authorization. That means replacing long-lived secrets with ephemeral tokens, issuing access just in time, and validating the request against context at execution time. This approach aligns with NHI lifecycle controls in the NHI Lifecycle Management Guide and with the broader lifecycle and offboarding expectations in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

• Separate the approver, provisioner, and reviewer roles so no single workflow can create and certify the same entitlement.
• Use authoritative source data for review, such as IAM logs, vault records, and service ownership metadata.
• Prefer workload identity and short TTL credentials over reusable static secrets for automation paths.
• Make review evidence-based, requiring usage, purpose, and owner confirmation before renewal.

When organisations also map this to zero trust and least privilege, review becomes a verification step rather than a re-approval of old assumptions. The control is strongest when paired with secret rotation, offboarding triggers, and exception expiry. These controls tend to break down in environments with shared service accounts, unmanaged scripts, or CI/CD pipelines that mint credentials outside the main IAM process because access provenance becomes too fragmented to review reliably.

Common Variations and Edge Cases

Tighter separation often increases operational overhead, requiring organisations to balance assurance against speed for release and support teams. That tradeoff is real, especially where access requests are frequent or systems are highly automated. Best practice is evolving for lower-risk environments, but there is no universal standard for how much separation is enough. For example, small teams may use a second reviewer rather than a fully independent function, while regulated environments usually need stronger independence and documented evidence.

Edge cases matter. Emergency access, delegated administration, and vendor-managed service accounts often justify temporary exceptions, but those exceptions should expire automatically and be reviewed after the event, not simply carried forward. The OWASP Non-Human Identity Top 10 is useful here because it highlights how privilege creep and weak review processes combine into persistent exposure. The Ultimate Guide to NHIs — Key Challenges and Risks also shows why the largest failures usually come from poor visibility, not from a single bad approval.

In practice, separation of provisioning and review works best when it is paired with ownership clarity, expiration dates, and a real offboarding process. Without those, independent review can still become a rubber stamp, just with more steps.

Related resources from NHI Mgmt Group

• When should organizations review access controls?
• Should organisations separate human and non-human access review processes for SOC 2?
• Should organisations separate AI configuration creation from publication rights?
• How should organisations govern consumer-permissioned financial data access?