What is the difference between access certification and provisioning?

Why This Matters for Security Teams

access certification and provisioning are often discussed together, but they solve different problems in the identity lifecycle. Certification is a governance control: it asks whether access is still justified. Provisioning is an operational control: it creates, changes, or removes the entitlement in the source system. If those steps are disconnected, review outcomes become paperwork instead of enforcement, and stale access stays live long after it should have been removed.

That gap is especially dangerous for non-human identities, where service accounts, API keys, and automation tokens often outlive the systems they support. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes review accuracy and timely revocation central to reducing blast radius. For broader lifecycle context, see the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. Current guidance also aligns with the OWASP Non-Human Identity Top 10, which emphasizes lifecycle control and privilege hygiene.

In practice, many security teams discover the difference only after a review says “remove access” and the entitlement remains active in production.

How It Works in Practice

A mature program links certification results to the systems that actually hold the entitlement. Certification campaigns collect approval from application owners, managers, or workload owners. Provisioning then executes the decision in an identity governance platform, directory, cloud control plane, vault, or SaaS admin console. The important point is that certification does not itself change access. It produces an authoritative decision that provisioning must carry out and then verify.

For human users, that might mean removing a group membership, disabling an account, or reassigning a role. For NHIs, the workflow is often more specific: rotate a secret, revoke an API key, delete a dormant service account, or replace a long-lived credential with a short-lived one. The lifecycle view in the Ultimate Guide to NHIs is useful here because certification is only one checkpoint in a broader process that also includes issuance, rotation, offboarding, and monitoring. NHI Mgmt Group’s research also notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is why review-to-remediation automation matters.

• Certification answers “should this access remain?”
• Provisioning answers “change the entitlement now.”
• Verification answers “did the target system actually enforce the change?”
• Evidence answers “can audit prove the decision was completed?”

Controls map cleanly to identity governance only when the review engine, the provisioning connector, and the audit trail are all in the same workflow. This guidance tends to break down in multi-cloud environments with unmanaged local accounts because there is no single source system to enforce the decision.

Common Variations and Edge Cases

Tighter certification-to-provisioning linkage often increases operational overhead, requiring organisations to balance strong governance against application complexity and change latency. That tradeoff is real, especially where legacy systems, vendor-managed platforms, or outsourced operations limit direct automation.

One common edge case is delayed remediation. A reviewer may approve removal, but the entitlement persists because the connector failed, the target system lacks an API, or the change requires manual execution. Another is role explosion: certification can validate a role at a high level, while provisioning must deal with the individual entitlements hidden inside it. In those cases, the certification result may be correct, but the operational change is incomplete. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce a practical lesson: lifecycle gaps become breach paths when credentials remain valid after policy says they should not.

There is no universal standard for every environment, but current best practice is to treat certification as the decision layer and provisioning as the enforcement layer, then require post-change validation before the review closes. That matters even more for NHIs, where a stale secret can remain usable long after the business believes access has ended. The distinction is simplest in theory and most important where access control spans cloud, SaaS, CI/CD, and secrets management at the same time.

Related resources from NHI Mgmt Group

• 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?
• What is the difference between access convenience and access governance for NHIs?