What breaks when cloud access reviews are still run like on-premise recertifications?

Why This Matters for Security Teams

Cloud access reviews break when they are treated like quarterly recertifications for a stable data centre. Cloud and SaaS identities are more fluid, more integrated, and more automated, so a review that only checks whether a name still appears on a list misses the real control problem: what the identity can do right now. The result is stale entitlements, inherited roles, shared service accounts, and access paths that no one is actively watching.

This is especially dangerous for non-human identities, where the practical unit of control is not a person but a workload, token, secret, or integration. Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG research both point to the same operational gap: entitlement review alone does not solve credential sprawl. NHIMG’s Ultimate Guide to NHIs shows why identity lifecycle management has to follow workload reality, not calendar review cycles.

One useful signal from the 2024 Non-Human Identity Security Report is that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, which helps explain why manual recertification keeps missing cloud risk. In practice, many security teams encounter overprivileged cloud access only after a breach review, rather than through intentional governance.

How It Works in Practice

In on-premise recertification, the review unit is usually a person, a role, and a small set of applications. In cloud environments, the review unit must expand to include non-human identities, ephemeral credentials, API permissions, service-to-service trust, and infrastructure automation. That means a review has to answer different questions: does this workload still need this scope, is the token still valid, is the secret still reachable, and does the integration still match the business intent?

Practically, effective reviews rely on inventory, telemetry, and policy rather than spreadsheet recertification alone. Teams should map each cloud entitlement to a workload owner, a runtime purpose, and a revocation path. They should also distinguish between standing access and just-in-time access, because JIT reduces the time window in which a compromised account or integration can be abused. For secrets management, the key issue is not just who approved access once, but whether the secret is still long-lived and reusable when it should be short-lived and automatically rotated.

That is why cloud review programs increasingly align with the identity lifecycle in the NHI Lifecycle Management Guide and the attack patterns documented in the 52 NHI Breaches Analysis. Those patterns repeatedly show that access survives longer than the workload that justified it. For implementation, the practical controls are: enumerate all cloud identities, tag them by owner and purpose, set time-bound review windows for high-risk access, and revoke anything that lacks a current business or technical dependency. Where available, use policy-as-code and workload identity instead of static secrets, because it makes revalidation machine-readable and faster to enforce.

• Review the entitlement, the credential, and the runtime purpose together.
• Prioritise privileged and machine-to-machine access over ordinary user roles.
• Use JIT and short TTLs for sensitive cloud operations rather than standing access.
• Require an explicit owner for every service account, token, and integration.

These controls tend to break down when cloud permissions are inherited through nested roles and unmanaged service connections because the review process cannot reliably see the real effective privilege.

Common Variations and Edge Cases

Tighter cloud access review often increases operational overhead, requiring organisations to balance stronger control against release speed and platform complexity. That tradeoff becomes sharper in multi-cloud, hybrid, and heavily automated environments, where a single identity may touch infrastructure, CI/CD, SaaS, and ephemeral compute. There is no universal standard for how often every cloud entitlement should be recertified; current guidance suggests risk-based cadence is more practical than a fixed schedule for all access.

One edge case is shared service accounts, where teams may be tempted to keep long-lived access because ownership is ambiguous. Another is outsourced or partner-managed access, where traditional recertification captures the named user but not the underlying tooling, keys, or delegated tokens. Both cases can create a false sense of assurance if the review focuses on human approvers instead of the actual control surface. The Sisense breach is a useful reminder that cloud compromise often rides on overextended access paths, not just missing approvals.

For that reason, practitioners should treat recertification as one input to a broader cloud governance loop, not the control itself. The right question is not only “should this identity still exist?” but “should this identity still be able to act at this scope, from this location, using this credential type, at this moment?” That framing aligns better with cloud reality and with the controls discussed in the Ultimate Guide to NHIs — Key Challenges and Risks and the OWASP guidance on non-human identity risk. A review model that cannot answer those runtime questions will keep missing the access that matters most.

Related resources from NHI Mgmt Group

• What breaks when cloud access reviews do not include machine identities?
• How should security teams run access reviews for non-human identities?
• How should security teams implement cloud user access reviews across SaaS and multi-cloud environments?
• When do NHI access reviews create more value than a one-time cleanup?