TL;DR: Unosecur’s Cloud Compliance Pulse H1 2025 found that 94% of organisations had at least one high-severity cloud identity gap, with an average of 40 identity and access control failures per tenant and 68% failing privileged MFA. Cloud identity governance is still breaking at the control layer, where basic privileges, credentials and vault discipline are not consistently enforced.
At a glance
What this is: This is a cloud identity compliance benchmark showing that most enterprise tenants still carry high-severity control gaps, with privileged MFA failures and credential hygiene issues leading the pattern.
Why it matters: It matters because IAM, PAM and NHI programmes are being judged on measurable cloud control outcomes, not policy intent, and the same gaps raise audit, insurance and breach exposure.
👉 Read Unosecur's Cloud Compliance Pulse H1 2025 on cloud identity compliance gaps
Context
Cloud identity compliance is the gap between what an organisation says should govern access and what is actually enforced across cloud tenants. In this case, the control problem is not theoretical: privileged MFA, over-privileged roles, stale credentials and unmanaged service-account keys all remain visible in live environments.
Unosecur’s benchmark draws from automated scans of public-cloud estates and maps findings to control families that matter to audit and incident readiness. The central message is that identity governance in cloud environments is still being measured by exceptions that should already have been removed.
For IAM and PAM teams, the article points to a familiar but unresolved pattern. The issue is not a shortage of frameworks, but a failure to consistently apply them to privileged users, service accounts and access keys at tenant level.
Key questions
Q: What should teams fix first when cloud identity compliance gaps are still widespread?
A: Start with the controls that most directly reduce standing risk: privileged MFA, high-privilege role scope, service-account key hygiene and vaulting. These are the controls most likely to show whether cloud identity governance is actually enforced, because they affect both audit readiness and the blast radius of a compromised identity.
Q: Why do privileged cloud identities create such persistent audit and breach risk?
A: Because they concentrate access and often outlive the task that justified them. When privileged MFA is missing and access is permanently assigned, the same account can become both an audit exception and a breach path, which multiplies the cost of a single governance failure.
Q: What breaks when service-account keys are not treated as lifecycle-managed credentials?
A: They accumulate in scripts, automation and cloud workflows after the original use case has changed, so revocation and rotation are delayed or missed. That leaves a hidden access layer that auditors cannot easily see and attackers can exploit if the key leaks or is reused.
Q: How should IAM and PAM teams judge whether cloud identity controls are actually working?
A: Look at the proportion of privileged identities protected by MFA, the number of standing high-privilege assignments, the age profile of access keys, and the amount of secret material stored outside a managed vault. If those measures do not improve month by month, the programme is not reducing risk.
Technical breakdown
Why privileged MFA still fails in cloud tenants
Privileged multifactor authentication is the baseline control for reducing account takeover risk, yet it still fails when administrators are exempted, bypass paths are left open, or cloud and identity-provider policies are not aligned. In cloud estates, this usually reflects inconsistent enforcement across tenants rather than a single missing setting. Once privileged access is reachable without MFA, the control ceases to be a boundary and becomes a paper requirement. The article’s finding shows that privileged MFA remains one of the clearest measures of whether cloud identity governance is real or merely documented.
Practical implication: verify that privileged MFA is enforced centrally and that no cloud-admin path can be created outside the identity provider.
How over-privileged roles and standing access create audit risk
Over-privileged roles create audit pressure because they widen the effective blast radius of any compromised or misused identity. When standing administrator assignments persist beyond the task that justified them, access reviews become retrospective accounting instead of prevention. In cloud environments, this also complicates evidence collection, because the same excessive role may map to multiple controls across ISO 27001, SOC 2 and PCI DSS v4. The result is a governance problem as much as a security one: too much standing privilege produces both exposure and compliance drag.
Practical implication: move permanent high-privilege assignments into a narrow exception set and force task-scoped elevation for routine administration.
Why unmanaged service-account keys keep reappearing
Service-account keys become a recurring weakness when they are created faster than they are inventoried, rotated or revoked. Unlike interactive human access, these credentials are often embedded in automation, scripts and cloud workflows, which makes them harder to see and easier to leave behind. That persistence creates a long tail of exposure even after the original use case has ended. The article links these keys to one of the four most common high-severity gap families, which is consistent with NHI programmes that fail when lifecycle ownership is unclear.
Practical implication: inventory service-account keys separately from human credentials and enforce rotation and vaulting on a fixed lifecycle schedule.
Threat narrative
Attacker objective: The attacker seeks durable access to cloud identities and the permissions needed to reach sensitive data or infrastructure at scale.
- Entry occurs when a privileged cloud identity, service account key or stale credential is usable without strong multifactor controls or timely revocation.
- Escalation follows when over-privileged roles or permanent admin assignments let the attacker expand access beyond the initial account.
- Impact lands in cloud data exposure, audit failure and increased breach likelihood because the same control families recur across environments.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cloud identity compliance is still failing at the control layer, not the policy layer: The problem is no longer whether organisations know the rules. It is whether privileged MFA, role scoping and key governance are enforced consistently across tenants, identities and workflows. That is why the same four gap families keep reappearing in cloud audits and breach reviews. Practitioners should treat tenant-level enforcement as the real governance test.
Standing privilege is the compounding error in cloud IAM: Permanent administrator access turns a single account issue into an enterprise-wide exposure problem. Once privilege is left standing, every other control has to compensate for it, including recertification, incident response and audit evidence. The practical implication is that cloud IAM maturity should be judged by how quickly standing access is removed, not by how many roles exist.
Unmanaged service-account keys remain a classic NHI lifecycle failure: These credentials persist because ownership, rotation and offboarding are not treated as first-class controls. That makes them especially dangerous in cloud environments where automation can outlive the team that created it. The lesson is straightforward: if the key has no lifecycle owner, the control model has already failed.
Cloud compliance findings are becoming operational risk signals, not just audit metrics: The article shows that the same identity gaps are now tied to insurance pricing, supervisory scrutiny and breach patterns. That means identity governance has to be measured as a live risk function, not a quarterly certification exercise. Practitioners should expect cloud identity evidence to be consumed by auditors, insurers and incident responders alike.
Identity blast radius is the right concept for this category: The article’s recurring failures are less about isolated misconfigurations than about how far a single identity can reach once controls are loose. That shift matters because the governance question is not only who can sign in, but how much damage that identity can do once inside. Teams should design cloud identity controls around blast-radius reduction, not checkbox compliance.
What this signals
Identity compliance in cloud estates now needs to be treated as a control-performance problem: The meaningful question is not whether a policy exists, but whether privileged MFA, role scoping and key governance are enforced tenant by tenant. That is where cloud identity programmes either reduce exposure or quietly preserve it.
Service-account lifecycle ownership is the strongest NHI signal in this article: When keys and secrets outlive the business process that created them, the organisation has already lost control of the credential lifecycle. That makes ownership, rotation and offboarding the real indicators of NHI maturity in cloud environments.
For practitioners
- Enforce privileged MFA at the identity provider Remove local exceptions for cloud-admin access and validate that every privileged path depends on centrally enforced multifactor authentication.
- Replace standing admin roles with task-scoped elevation Review permanent high-privilege assignments and convert routine administration to just-in-time access with explicit expiry and approval boundaries.
- Rotate and vault service-account keys on a fixed lifecycle Track service-account secrets separately from human credentials, rotate keys older than thirty days, and store them in a managed vault with owner assignment.
- Measure cloud identity control health monthly Use the four indicators from the article: privileged MFA coverage, permanent high-privilege roles, key age distribution, and the share of service-account secrets in a managed vault.
Key takeaways
- Cloud identity compliance gaps persist because basic enforcement is still uneven across privileged users, roles and service-account credentials.
- The reported scale is material, with high-severity gaps present in most tenants and privileged MFA still one of the most common failures.
- The strongest corrective move is to reduce standing privilege and treat cloud credentials as lifecycle-managed assets, not static configuration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Over-privileged roles are one of the article's four recurring cloud identity gap families. |
| NHI-07 — Long-Lived Secrets | The article highlights stale access keys and unmanaged service-account keys as a major failure family. | |
| NHI-01 — Improper Offboarding | Stale credentials and lingering privilege reflect missing lifecycle offboarding for cloud identities. | |
| Recommendation — Reduce permanent high-privilege assignments and move routine administration to task-scoped elevation. Rotate and vault service-account secrets before they become long-lived access paths. Revoke cloud credentials as soon as the business need ends and verify offboarding completion. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key rotation and credential lifecycle management map directly to authenticator governance. |
| Recommendation — Apply authenticator management to enforce rotation, revocation and inventory for cloud credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on access permissions, privileged entitlements and their enforcement gaps. |
| Recommendation — Review and tighten cloud entitlements so privileged access is limited, justified and continuously verified. | ||
Key terms
- Multi-Factor Authentication: Multi-factor authentication requires two or more independent verification factors before access is granted. In practice, it reduces the chance that a stolen password alone will open a system, but it only works well when applied consistently across all high-risk access paths and identity types.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Service-account key: A service-account key is a non-human credential used by a workload, integration, or automation process to authenticate without a person present. When keys are stale, duplicated, or stored outside a managed vault, they become difficult to govern and easy to overlook during lifecycle reviews.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
What's in the full report
Unosecur's full report covers the operational detail this post intentionally leaves for the source:
- The full breakdown of the 50-company sample methodology and control mapping across ISO 27001, PCI DSS v4, SOC 2, CIS v8 and GDPR
- The exact distribution of the four recurring gap families across enterprise cloud estates
- The monthly measurement model for privileged MFA coverage, permanent high-privilege roles, key age and service-account secrets
- The remediation guidance for replacing standing admin roles with just-in-time elevation and rotating older keys
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity-security programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org