What is the difference between deprovisioning and access certification in SaaS governance?

Deprovisioning removes access, while access certification asks an authorised reviewer whether access should remain. Deprovisioning is an execution control, and certification is a decision control. Strong programmes use both: certification to validate need, and deprovisioning to enforce the result quickly and consistently.

Why This Matters for Security Teams

Deprovisioning and access certification are often discussed together, but they solve different governance problems. Certification is the review step: an authorised owner validates whether access is still justified. Deprovisioning is the enforcement step: the entitlement is removed, usually in IAM, SaaS admin consoles, or connected directories. When teams blur the two, review outcomes do not translate into actual reduction in exposure.

That distinction matters because SaaS permissions accumulate quietly across apps, vendors, and delegated admin paths. NHI governance research shows how often hidden access persists: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes every delayed removal more dangerous. See The State of Non-Human Identity Security and the lifecycle guidance in NHI Lifecycle Management Guide for the control context.

Practically, certification gives governance evidence, while deprovisioning reduces attack surface. NIST’s NIST Cybersecurity Framework 2.0 treats access control and continuous monitoring as complementary functions, not interchangeable ones. In practice, many security teams discover the gap only after an expired entitlement is still active during an incident review, rather than through intentional certification follow-through.

How It Works in Practice

In a mature SaaS governance workflow, access certification starts with an inventory of human and non-human accounts, app roles, OAuth grants, service accounts, and delegated admin rights. Reviewers then assess whether each entitlement is still needed for a business process, integration, or workflow. If the answer is no, the review should trigger deprovisioning automatically or through a tightly tracked ticket.

Deprovisioning is the execution mechanism. It may remove a user from a SaaS role, revoke an API token, disable a service account, or sever a vendor OAuth grant. Certification is the decision record that justifies that action. This is why the best programmes tie review cadence to lifecycle events such as job changes, vendor offboarding, and application retirement. The lifecycle framing in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here, especially when SaaS access is granted outside a central IAM path.

• Use certification to validate need, ownership, and business justification.
• Use deprovisioning to remove access immediately after approval, not at the next quarterly sweep.
• Require evidence for exceptions, especially for shared, inherited, or vendor-managed SaaS access.
• Track completion separately from approval so stale entitlements do not survive the review cycle.

Current guidance suggests pairing the two with monitoring so that revoked access cannot be silently reintroduced through shadow admins, token refreshes, or unsanctioned app reauthorisation. OWASP’s OWASP Non-Human Identity Top 10 is helpful for identifying the identity and token risks that certification alone will not remove. These controls tend to break down when SaaS is federated across multiple tenants because entitlement state is fragmented and revocation ownership is unclear.

Common Variations and Edge Cases

Tighter certification often increases operational overhead, requiring organisations to balance auditability against review fatigue and support burden. That tradeoff becomes sharper in SaaS environments with many ephemeral accounts, shared inboxes, or app-to-app integrations, where the wrong review cadence can either miss risk or overwhelm approvers.

One common edge case is service accounts and API-based access. These are often not fit for manual user-style certification because the owner may be a team, a pipeline, or an application rather than a person. Best practice is evolving here: many teams certify the business use case and technical owner, then deprovision based on TTL, rotation policy, or application retirement rather than waiting for a human to notice. The broader risk patterns are covered in Top 10 NHI Issues and the incident context in 52 NHI Breaches Analysis.

Another edge case is delegated SaaS administration. A reviewer may certify that access should remain, but the actual deprovisioning must happen in a downstream tenant, partner portal, or connected identity provider. If those systems are not integrated, the approval is real but the enforcement is partial. That is why certification workflows should not be treated as a substitute for direct removal controls, and why deprovisioning SLAs matter as much as approval SLAs. In environments with complex vendor-managed access and multiple OAuth trust chains, the model breaks down because no single system has full authority over the entitlement.

Related resources from NHI Mgmt Group

• What is the difference between access governance and privileged access management in SaaS?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between access review and credential review for SaaS?
• What is the difference between JIT access and zero standing privilege for NHI governance?