What is the difference between access recertification and access provisioning?

Why This Matters for Security Teams

access provisioning and access recertification are often discussed together, but they answer different governance questions. Provisioning is about granting the right access at the right time; recertification is about proving that access is still justified after business conditions change. That distinction matters most for non-human identities, where service accounts, API keys, and workload tokens can persist long after the original use case ends. The NHI lifecycle view in the NHI Lifecycle Management Guide makes this separation explicit, and OWASP’s OWASP Non-Human Identity Top 10 frames stale or over-privileged identities as a recurring risk rather than a one-time mistake. In practice, the control failure is not usually that access was granted incorrectly on day one, but that no one can prove when it should have been removed.

This is why the difference is operational, not semantic. Provisioning controls entry into systems, environments, and data paths. Recertification validates persistence, which is where privilege creep appears, especially in automation-heavy stacks where owners rotate, pipelines change, and dependencies outlive projects. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, a signal that the real problem is often not initial access creation but ongoing failure to trim it. In practice, many security teams encounter this only after an incident review reveals an identity that was never retired, rather than through intentional access governance.

How It Works in Practice

Provisioning should be treated as an authorization workflow: a request is made, policy is checked, identity is created or modified, and the resulting access is scoped to a specific purpose. For NHIs, that usually means pairing Lifecycle Processes for Managing NHIs with least-privilege design, short-lived credentials, and a defined owner. Recertification is a separate control cycle. It asks whether the access is still needed, whether the owner is still valid, and whether the underlying workload or integration still exists.

A practical model splits the work into three checks:

• Provisioning check: does the requester have a valid business case and approved scope?
• Usage check: has the identity behaved within expected boundaries since issuance?
• Recertification check: does the identity still map to an active system, service, or workflow owner?

That separation helps teams avoid mixing change management with periodic review. It also aligns with Zero Trust thinking in the OWASP Non-Human Identity Top 10, where identity trust is not assumed to persist simply because it once existed. NHI Mgmt Group guidance in the Key Challenges and Risks section also highlights how mismanaged NHIs amplify exposure when visibility is weak or ownership is unclear.

For human identities, recertification can often rely on managers and app owners. For NHIs, better practice is to bind each identity to a named system owner, expiration policy, and rotation or revocation workflow. These controls tend to break down when identities are embedded in CI/CD pipelines with no clear business owner, because the system that created the access is often not the system that should approve its continuation.

Common Variations and Edge Cases

Tighter recertification often increases administrative overhead, requiring organisations to balance assurance against operational speed. That tradeoff is especially visible where access is created dynamically, such as ephemeral jobs, short-lived API integrations, or container workloads that spin up and disappear in minutes. In those environments, current guidance suggests that recertification should focus less on manually approving each individual credential and more on validating the policy, owner, and expiration rules that govern the identity class.

There is no universal standard for how often NHI access should be recertified, because the right cadence depends on risk, lifecycle length, and blast radius. A high-privilege service account tied to production data should be reviewed more aggressively than a low-risk build token. For organisations trying to reduce review fatigue, the most useful pattern is to recertify by category: service accounts, secrets, integrations, and machine-to-machine credentials each get different thresholds, evidence requirements, and exception paths. The broader lifecycle context in Ultimate Guide to NHIs and the breach patterns documented in 52 NHI Breaches Analysis show why one-size-fits-all review programs miss the identities most likely to cause harm.

One useful rule is simple: provisioning creates the access event, recertification governs the access lifespan. If the process cannot answer both questions cleanly, then the organisation has not implemented two controls, only one control with two names.

Related resources from NHI Mgmt Group

• What is the difference between onboarding access and NHI provisioning?
• What is the difference between reviewing human access and reviewing NHIs?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between protecting applications and protecting access?