Access approval authorises a new or changed entitlement, while access certification confirms that existing access still matches business need. Approval is forward-looking and tied to request handling. Certification is verification and remediation focused, which makes it the stronger control for catching privilege drift after access has already been granted.
How access approval and access certification differ in governance
Access approval and access certification solve different governance problems. Approval decides whether a request should be granted in the first place, based on role, business need, and policy. Certification checks whether already-granted access still belongs there. That difference matters because governance is not only about safe onboarding, but also about removing drift, stale entitlements, and accumulated privilege over time.
Approval is usually tied to a request, an owner, and a future state. Certification is tied to an existing entitlement set and a present-state review. In practice, approval answers “should this access exist?” while certification answers “does this access still need to exist?” That is why certification is often used to validate periodic access reviews, while approval is used to control the point of entry into the access model.
The two controls also sit at different points in the lifecycle. Approval is a gate before access is created or changed, so it is strongest when the business process is well-defined and the requester’s need can be judged up front. Certification is a backstop after access has already accumulated, so it is stronger at finding excess privilege, orphaned access, and exceptions that have outlived their justification. NHIMG’s IAM and IGA Basics is a useful starting point for the broader governance model, and the Access Reviews and Certification Guide is the more direct reference for making certification effective rather than ceremonial.
Why certification catches what approval cannot
Approval works best when the request context is current and complete, but governance problems often appear later. A user can change role, project, vendor relationship, or employment status after the original grant, and those changes may never flow back into the approval record. Certification is the control that re-evaluates that older decision against today’s need, so it is the mechanism that exposes privilege creep rather than assuming the original approval remains valid.
That is also why certification is usually broader in scope than approval. Approval is typically narrow and transactional, focused on one request and one decision. Certification is comparative and evidence-based, because reviewers must assess whether access is still proportionate to the user’s duties, risk, and ownership. In mature governance programs, approval and certification are complementary: approval prevents inappropriate access from entering the environment, while certification removes access that became inappropriate later.
For identity governance teams, the practical distinction is between creating justified access and proving continued justification. IGA Buyer’s Guide is useful where you are selecting or tuning a platform around both request workflows and review workflows, because the product choice often needs to support both without collapsing them into one generic control.
What governance teams should do with both controls
Approval and certification should not be treated as interchangeable workflow variants. Approval belongs in the request path, with clear approvers, policy checks, and an auditable decision at the moment access is introduced. Certification belongs in the review path, with an owner who can challenge inherited access, risky entitlements, and dormant access that approvals alone will not surface. The governance goal is to make the two controls reinforce each other, not duplicate each other.
That distinction becomes more important as entitlements scale across roles, applications, contractors, and non-human accounts. Review quality drops when certifiers are asked to re-approve everything without context, or when approvers are asked to validate business need after the fact. Governance works better when approvals are precise and time-bound, and certifications are risk-weighted, periodic, and backed by entitlement evidence. Joiner-Mover-Leaver (JML) Guide and Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs both help show why lifecycle events matter when governance has to keep pace with change.
Risk and Threat Considerations
When approval and certification are conflated, organisations tend to create blind spots, either by over-trusting the original request or by treating every review like a fresh request. The first failure mode leaves stale access in place, while the second produces rubber-stamping and reviewer fatigue. The governance risk is not just administrative inefficiency, it is that excess privilege can persist long after the original business reason has disappeared.
Failure mechanism: approval-only governance misses post-grant drift, while weak certification collapses into a paper exercise and fails to remove outdated or excessive access.
Impact: users, contractors, or systems retain permissions beyond business need, increasing the chance of unauthorized access, segregation-of-duties conflicts, and larger blast radius after compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Access certification and approval both enforce least-privilege decisions over time. |
| AC-2 — Account Management | Approval and certification are core account and entitlement lifecycle controls. | |
| Recommendation — Review entitlements regularly and revoke access that no longer aligns with least privilege. Control account creation, changes, and reviews through governed lifecycle processes. | ||
| CIS Controls v8 | CIS-5 — Account Management | The difference between request approval and access review sits inside account governance. |
| Recommendation — Implement account approval and periodic review processes for all access paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Approval and certification are both access-control governance activities. |
| A.8.2 — Privileged access rights | Certification is especially important for reviewing standing privileged access. | |
| Recommendation — Define access approval and review procedures that reflect business need and policy. Review privileged access periodically and remove rights that are no longer justified. | ||
Practitioner Guidance
What to prioritise: Keep approval decisions and certification decisions on separate control objectives. Approvals should validate requested access against policy and role fit; certifications should challenge existing access against current need, ownership, and risk.
What to verify: Each certification campaign should have a clear reviewer, a defensible entitlement source, and a remediation path for revoked access. If a review cannot lead to removal, it is not functioning as a control.
Common mistake: Treating a manager approval as ongoing evidence that access remains justified. That assumption breaks as soon as the user changes job scope, project, vendor status, or environment.
Practitioner takeaway: Use approval to prevent bad access from entering, and use certification to remove good access that has become stale; governance is materially stronger when the second control is allowed to overrule the first over time.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between human IAM controls and NHI governance?