TL;DR: An average of 40 identity and access control failures per tenant was found, with 94% of organisations showing at least one high-severity gap and 68% failing privileged MFA, based on scans of 50 companies, according to Unosecur’s Cloud Compliance Pulse H1 2025. The pattern shows cloud identity governance is still failing at the control-layer basics, not just at the edges.
At a glance
What this is: This benchmark report shows that cloud identity governance remains weak, with high-severity control gaps widespread across enterprise tenants.
Why it matters: It matters because privileged access, credential hygiene, and service-account governance now affect audit readiness, breach exposure, and insurance outcomes across NHI, autonomous, and human identity programmes.
By the numbers:
- 94% of participating organisations exhibited at least one high-severity gap.
- The single most frequently violated requirement was ISO 27002 - 5.17, which mandates multifactor authentication for privileged accounts; 68% of tenants failed this control.
- Four recurring gap families, missing multifactor authentication, over-privileged roles, stale or duplicate credentials, and unmanaged service-account keys, together accounted for 70% of all high-severity findings.
- The research team selected a stratified, pseudonymised sample of fifty companies from 169 organisations.
👉 Read Unosecur's Cloud Compliance Pulse H1 2025 on cloud identity gaps
Context
Cloud identity compliance is the discipline of proving that privileged access, credentials, and service accounts are controlled well enough to satisfy audit, security, and operational requirements. In this report, the primary problem is not policy absence. It is the persistence of basic control failures across cloud estates, especially around privileged access and credential hygiene.
The report’s scope is broad enough to matter to human IAM, NHI governance, and adjacent autonomous access models because the same control failures show up across roles, keys, and service accounts. When a tenant has dozens of unresolved identity findings, the issue becomes governance drift, not a single misconfiguration.
The starting position described here is unfortunately typical for cloud estates that have grown faster than their identity controls. The findings are best read as a market-wide signal, not an outlier event.
Key questions
Q: How should security teams reduce privileged access risk in cloud environments?
A: Start with privileged MFA, then remove standing administrative access that does not have a time-bound business purpose. Cloud estates fail when elevated access is treated as a convenience layer rather than a governed control. The safest programmes pair identity provider enforcement with regular review of role scope, exception paths, and break-glass access.
Q: Why do stale service-account keys create so much cloud identity risk?
A: Because one old key can preserve trust long after the original workload, owner, or approval path has changed. Stale service-account keys are dangerous when they are duplicated, stored outside a managed vault, or never rotated. They create hidden persistence that is hard to inventory and easy to exploit.
Q: What do security teams get wrong about cloud identity compliance?
A: They often treat compliance as evidence collection instead of access containment. A tenant can pass a worksheet review and still retain over-privileged roles, unmanaged secrets, and weak MFA enforcement. The practical mistake is measuring documentation quality instead of actual control state.
Q: Who is accountable when privileged access controls fail in cloud environments?
A: Accountability usually sits with the identity, platform, and cloud operations teams together, because the failure spans authentication, role design, and secret handling. Governance frameworks such as the NIST Cybersecurity Framework 2.0 expect control ownership to be explicit. If no team owns the full path from grant to revocation, the gap persists.
Technical breakdown
Privileged MFA failures in cloud tenants
Privileged multifactor authentication is a control that binds elevated access to a second verification factor, reducing the value of stolen passwords or reused secrets. In cloud environments, the control breaks when privileged users or admin paths still rely on password-only access, local exceptions, or identity provider gaps. ISO 27002-5.17 makes the requirement explicit, but compliance often fails because the control is not consistently enforced at the tenant and role layer. The result is not just weak authentication. It is an audit and breach path that remains open even when other identity controls look mature.
Practical implication: enforce privileged MFA at the identity provider and verify that no admin path bypasses it.
Over-privileged roles and standing access
Over-privileged roles are permissions that exceed the minimum required for the task, while standing access is persistent privilege that remains active outside the moment of need. In cloud estates, these two conditions often overlap, especially when teams clone roles, inherit defaults, or leave administrative grants in place after projects end. That combination increases blast radius because one compromised account can do more than it should, for longer than it should. The report’s finding that permanent high-privilege assignments remain common shows that access modelling is still being done for convenience, not for containment.
Practical implication: map permanent high-privilege assignments and remove any role that is not time-bound to a business need.
Service-account keys and credential sprawl
Service-account keys are non-human credentials used by workloads, integrations, and automation to authenticate without a person present. They become dangerous when they are stale, duplicated, unmanaged, or stored outside a controlled vault. In that state, one secret often represents multiple systems and a long-lived trust relationship that no one can easily inventory. The report groups unmanaged service-account keys with stale or duplicate credentials because both create hidden identity persistence. In practice, this is where NHI governance overlaps with cloud compliance: the estate can appear functional while exposure quietly accumulates underneath.
Practical implication: inventory service-account keys, track their age, and force managed storage for every secret that can be centrally governed.
Threat narrative
Attacker objective: The objective is to turn identity weakness into broad cloud control through privileged access, credential reuse, and persistence.
- Entry begins when weak or missing privileged MFA allows attackers or insiders to reuse credentials against cloud administrative paths.
- Escalation follows when over-privileged roles or standing administrator access let the actor move from a single identity to broader tenant control.
- Impact occurs when stale credentials and unmanaged service-account keys expand the blast radius into audit failure, data exposure, or cloud compromise.
Breaches seen in the wild
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
- IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cloud identity compliance is really a control aggregation problem, not a checklist problem. The report’s average of forty identity and access failures per tenant shows that organisations are accumulating separate but related weaknesses across privileged MFA, roles, keys, and service accounts. When those failures cluster, audit pain and security risk rise together. The practical conclusion is that cloud identity programmes need control-level ownership, not just periodic review.
Privileged MFA remains the clearest proof that cloud identity governance is not consistently enforced at the point of access. When 68% of tenants still fail the single most frequently violated requirement, the issue is not awareness. It is enforcement drift across tenant boundaries, exception paths, and administrative workflows. Frameworks such as OWASP-NHI and NIST CSF both point to the same reality: elevated access must be continuously constrained, not periodically assumed safe. Practitioners should treat privileged MFA failure as evidence of governance breakdown, not a narrow technical miss.
Unmanaged service-account keys are a non-human identity problem hiding inside a cloud compliance story. The same estate that fails privileged MFA often also retains stale or duplicate machine credentials, which means NHI governance and cloud compliance are the same conversation once automation and workloads enter the picture. That is why standing access, key age, and vaulting belong in the same risk model. The practitioner implication is simple: if service-account secrets are not lifecycle-managed, cloud compliance is incomplete.
Standing privilege creates identity blast radius that compliance worksheets only partially capture. A tenant can appear remediated on paper while permanent administrator grants still exist in practice. That gap matters because one lingering role can amplify the effect of a compromised password, a leaked key, or a duplicated secret. The governance lesson is that access duration and access scope must be reviewed together, not separately.
Identity compliance metrics are beginning to map directly to operational and financial exposure. The report links gap counts to audit effort, insurance pricing, and incident likelihood, which means identity governance is no longer confined to security operations. Once underwriters and auditors use the same evidence set, cloud identity posture becomes a board-visible control domain. Practitioners should expect identity metrics to be asked for outside the IAM team, and prepare accordingly.
From our research:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- That gap matters because agentic governance is already moving into operational identity work, so Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the right next reference point.
What this signals
Cloud compliance metrics are becoming identity governance metrics. When privileged MFA failures, standing roles, and secret age all appear in the same dashboard, the programme can no longer be run as an audit exercise alone. That is the shift practitioners should prepare for: identity posture will be judged by evidence quality, not policy intent.
With 67% of organisations still relying heavily on static credentials, the cloud compliance problem is moving from isolated misconfiguration to structural credential dependence. That is why the operational boundary between human IAM and NHI governance keeps shrinking in cloud environments. Teams that separate those disciplines will miss the shared control plane.
Identity blast radius is now a board-level planning concept. The report shows that weak privilege design, stale keys, and unmanaged service-account secrets create a common failure surface across cloud estates. Practitioners should expect more pressure to prove not only that access exists, but that it is scoped, expiring, and recoverable.
For practitioners
- Enforce privileged MFA everywhere admin access exists Verify that every cloud administrative path inherits identity provider MFA, including break-glass accounts, cross-account roles, and console access used by platform teams.
- Eliminate permanent high-privilege assignments Review standing administrator grants and replace any role that does not have a defined business trigger, expiry condition, and documented owner.
- Inventory and age-track service-account keys Build a live register of every service-account secret, then flag keys older than thirty days, duplicated keys, and any secret outside a managed vault.
- Tie audit evidence to identity controls, not screenshots Collect proof for privileged MFA, key rotation, and role scope from system telemetry so audit work reflects actual control state rather than manual attestations.
- Use monthly control metrics for board reporting Track the percentage of privileged identities with MFA, permanent high-privilege role counts, access-key age distribution, and the share of secrets held in managed vaults.
Key takeaways
- Most enterprise cloud tenants still carry multiple identity control failures, which means governance maturity is lagging behind cloud adoption.
- Privileged MFA, standing access, and unmanaged secrets are the recurring failure families that drive most high-severity findings.
- Teams should measure access scope, secret age, and MFA enforcement together because those three signals determine whether cloud identity risk is shrinking or compounding.
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 address the attack and risk surface, while NIST CSF 2.0 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-03 | Credential rotation and secret hygiene are central to the recurring findings. |
| NIST CSF 2.0 | PR.AC-1 | Access permissions and privileged MFA failures map directly to access control outcomes. |
| NIST CSF 2.0 | PR.AC-4 | Standing roles and over-privilege show weak entitlement governance. |
Audit service-account keys and rotate any unmanaged or stale credential path immediately.
Key terms
- Privileged MFA: Privileged multifactor authentication is the requirement that administrative or otherwise elevated access must be verified with more than one factor. In cloud identity programmes, it is one of the clearest controls for reducing the value of stolen credentials and limiting unauthorised administrative action.
- Standing privilege: Standing privilege is permanent or long-lived elevated access that remains available outside a specific task or approval window. It increases identity blast radius because the account is always capable of acting at a high level, even when no active business need exists.
- 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: Identity blast radius is the amount of damage that can occur when one credential, role, or account is abused. In cloud environments it depends on privilege scope, credential longevity, and how many downstream systems trust the same identity path.
What's in the full report
Unosecur's full research covers the operational detail this post intentionally leaves for the source:
- The full 70-page benchmark methodology, including how the sample was stratified and pseudonymised across sectors and cloud providers.
- Control-by-control mappings to ISO 27001/27002, PCI DSS v4, SOC 2, CIS v8, and GDPR for audit and remediation planning.
- The four recurring gap families broken down into practical remediation priorities for privileged MFA, role scope, secret age, and vaulting.
- The incident-response and insurance implications that link identity gaps to breach likelihood and premium calculations.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2026-06-16.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org