Why do legacy access certifications fail in cloud and SaaS environments?

They fail because reviewers are asked to approve or revoke access without the context needed to judge business need. When last use, frequency, and peer comparisons are absent, certification becomes a compliance exercise instead of a control that tests whether access is still justified.

Why legacy access certifications break down in cloud and SaaS

Legacy certification workflows were built for slower, more static environments where access could be judged against a stable role, application, and manager relationship. In cloud and SaaS, entitlements change faster, permissions are more granular, and access is often indirect through groups, roles, integrations, and tokens. That makes a periodic review weak unless it is paired with usage and entitlement context.

That gap matters because reviewers are asked to approve or revoke access based on incomplete evidence. Without signals such as last use, frequency, role drift, and peer comparisons, the review becomes an assertion check instead of a control that tests whether access is still justified.

What cloud and SaaS change about the certification problem

Cloud and SaaS shift access from a small set of obvious accounts to a layered model of permissions, delegated administration, federated login, service access, and cross-application sharing. A reviewer may see that a user has access, but not whether that access is inherited, dormant, indirectly granted, or needed only in rare exception cases. The result is that the certification owner is forced to guess at business need.

That is why legacy campaigns often produce either rubber-stamping or overcorrection. If the reviewer cannot see what the access is used for, they will either keep too much by default or remove access that is still operationally necessary. In cloud and SaaS, both outcomes are common because entitlement data is fragmented across the platform, the identity layer, and the application itself.

The strongest access review programs tie the certification record to actual entitlement behavior. They show who used the access, when it was used, whether it matches peers in the same function, and whether the access is part of a known administrative pattern. NHIMG’s Access Reviews and Certification Guide explains how to move from broad campaigns to risk-based reviews that are easier to judge and harder to game.

Why the evidence gap makes certifications ineffective

Legacy certifications assume that a manager or app owner can infer necessity from the title of the access item. In cloud and SaaS, that assumption fails because permission objects are often too abstract, too numerous, or too technical for title-only review. A reviewer does not need more alerts, they need enough context to answer one question: does this person still need this access for their job?

Frequency and last use help distinguish active access from inherited clutter. Peer comparisons help reveal outliers, such as one user with a permissions set that is far broader than others in the same role. Without those signals, a certification campaign cannot separate useful access from old drift, which is why it loses control value over time.

That context problem is not solved by adding more reviewers or longer questionnaires. It is solved by better entitlement evidence, cleaner role design, and tighter linkage between access governance and the systems that create or use the access. IAM and IGA Basics is a useful reference for the underlying governance model, while IGA Buyer’s Guide is helpful when evaluating tools that can surface usage and entitlement context during reviews.

How to make certifications useful again

Modern access certifications work best when they are narrow, evidence-based, and exception-driven. Reviews should focus on the access that is most likely to create exposure, especially privileged access, stale entitlements, and cross-environment permissions. Low-risk, routine access can often be handled through automation, while reviewers concentrate on edge cases that require human judgment.

Closed-loop remediation is also critical. If a reviewer revokes access but the system does not actually remove it, the certification was only paperwork. Likewise, if revoked access is silently re-added through a role or integration, the control never held. NHI Lifecycle Management Guide and Joiner-Mover-Leaver (JML) Guide are useful for thinking about the lifecycle side of that problem, because recertification without provisioning and deprovisioning discipline does not reduce risk.

Where organizations have many roles or repeated access patterns, Role Mining and Role Design Guide can help reduce review volume by improving the role structure that certifications depend on. Better roles do not eliminate recertification, but they make it more reviewable.

Risk and Threat Considerations

When certifications lack usage context, dormant or overbroad access tends to survive review, and that creates avoidable exposure. The risk is not only compliance failure, but also retained access that can be abused after role changes, offboarding, or compromise.

Failure mechanism: Reviewers cannot distinguish justified access from historical or inherited access, so they approve stale entitlements, miss privilege creep, or remove access that business teams later restore outside the control.

Impact: Organizations keep unnecessary privilege in cloud and SaaS, lose confidence in the certification process, and increase the blast radius of account compromise or insider misuse.

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, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Access certifications are part of account and entitlement review in cloud and SaaS.
	AC-6 — Least Privilege	The issue is overbroad access surviving review when business need is unclear.
Recommendation — Use AC-2 to review and remove unnecessary accounts and privileges on a recurring basis. Apply AC-6 to minimize access to only what each user or system needs.
CIS Controls v8	CIS-5 — Account Management	Periodic certification depends on account inventory, review, and removal of stale access.
Recommendation — Use CIS-5 to continuously review, right-size, and remove unnecessary accounts.
ISO/IEC 27001:2022	A.5.15 — Access control	Certification failure is an access control governance problem in cloud and SaaS.
Recommendation — Apply A.5.15 to ensure access is granted, reviewed, and withdrawn on business need.
OWASP ASVS	V8 — Authorization	The core failure is judging whether access is still authorized without sufficient context.
Recommendation — Use V8 to verify authorization decisions with current, testable access evidence.

Practitioner Guidance

What to verify: Before trusting any certification result, verify that the review item shows last use, frequency, and the grant path, not just a name and description. If those fields are missing, treat the review as incomplete rather than authoritative.

Decision rule: If the reviewer cannot see whether access is active, inherited, or exceptional, do not ask them to make a binary approve or revoke decision. Route that access to a higher-context workflow or enrich the entitlement data first.

Practitioner takeaway: Legacy certifications fail in cloud and SaaS when they ask humans to judge access without enough evidence. The control becomes meaningful only when review decisions are tied to actual usage, role context, and automated removal of what is no longer justified.