What is the difference between provisioning and access review in IGA?

Why This Matters for Security Teams

Provisioning and access review are both identity governance functions, but they solve different problems. Provisioning is about issuing, changing, or removing access at the point of need. Access review is about validating whether that access should continue. In practice, teams that treat them as the same workflow often miss the real risk: access can be technically granted correctly and still be inappropriate, stale, or far broader than intended.

This distinction matters because identity sprawl usually outpaces governance. NHI Mgmt Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts. That makes provisioning a scale and integration problem, while review becomes a visibility and decision-quality problem. For background on lifecycle control, see NHI Lifecycle Management Guide and the broader Ultimate Guide to NHIs.

The security stakes rise when provisioning is fast but review is weak, because dormant access accumulates even in mature environments. Many teams also underestimate how review quality depends on context, not just approvals. In practice, many security teams encounter access creep only after an incident review, rather than through intentional governance.

How It Works in Practice

Provisioning usually starts with an entitlement request, role assignment, or automation event. The IAM or IGA platform then creates the account, binds roles, assigns group membership, or pushes entitlements into connected applications. For NHIs, that can also include API keys, certificates, service accounts, or other secrets. Review works differently: it pulls a snapshot of existing access, routes it to an owner or manager, and asks whether each entitlement is still required. The best review programs tie decisions to business context, but current guidance suggests that without strong ownership data, reviews devolve into checkbox approvals.

A useful way to separate the two is to ask whether the system is being changed or merely evaluated. Provisioning changes state. Review validates state.

• Provisioning depends on application integration, role logic, and automated entitlement mapping.
• Access review depends on accurate inventories, clear approvers, and evidence of actual usage.
• Provisioning can be JIT or event-driven; review is periodic or continuous, depending on maturity.
• Provisioning failures usually create broken access. Review failures usually create excess access.

For NHI-heavy environments, the difference is more pronounced. If secrets and service accounts are created automatically, the control point shifts to whether those identities are short-lived, scoped, and rotated. NHI Mgmt Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs explains why lifecycle discipline matters, while the OWASP Non-Human Identity Top 10 helps frame common control failures such as over-privileged accounts and weak secret handling. Provisioning also needs to align with Zero Trust principles, because access granted once is not automatically safe forever. These controls tend to break down in fast-moving CI/CD environments because ownership, usage, and entitlement state change faster than review cycles can track.

Common Variations and Edge Cases

Tighter provisioning often increases operational overhead, requiring organisations to balance speed against control depth. That tradeoff is especially visible when applications lack APIs or when entitlements are embedded in legacy workflows. In those cases, provisioning may require manual steps, while review may still be automated, which creates an uneven governance posture.

There is no universal standard for review frequency or reviewer depth. Current guidance suggests using higher scrutiny for privileged, sensitive, or external-facing access, and lighter workflows for low-risk entitlements. But that only works if ownership is accurate. If nobody can confidently attest to who owns an account, a review can confirm the wrong thing with great efficiency.

Edge cases appear most often with shared accounts, break-glass access, and machine-to-machine credentials. A provisioning control may be valid at creation time, yet the review process may not be able to interpret actual usage if logs are incomplete or the entitlement is inherited through nested roles. For deeper lifecycle and risk context, see Top 10 NHI Issues and 52 NHI Breaches Analysis. In practice, these controls become unreliable when ownership is ambiguous, entitlements are inherited, and reviews happen long after the business context has changed.

Related resources from NHI Mgmt Group

• What is the difference between onboarding access and NHI provisioning?
• What is the difference between public link control and standard access review?
• What is the difference between access review and credential review for SaaS?
• What is the difference between periodic access review and identity observability?