Forty cloud identity control failures expose hidden compliance risk

At a glance

What this is: This is a cloud compliance analysis showing that everyday identity and access management failures still create large, measurable exposure across multi-cloud estates.

Why it matters: It matters because IAM, NHI, and human identity programmes all inherit the same control weaknesses when privileged access, keys, and audit evidence are inconsistent across cloud platforms.

By the numbers:

• Between January 1st and June 30th 2025, Unosecur scanned 50 multi-cloud environments.
• The team logged an average of 40 identity-related control failures per cloud tenant.
• In Unosecur’s data set, ISO 27001 clause 5.17 was violated by 68% of companies.
• Teams spent an extra 26 hours on average gathering evidence for every 10 unresolved findings.

👉 Read Unosecur's analysis of hidden cloud compliance risks across multi-cloud environments

Context

Cloud compliance risk is often treated as a documentation problem, but this article shows it is really an identity governance problem. When privileged accounts lack MFA, machine keys are duplicated, and roles stay broader than needed, the result is not just audit friction. It is a control environment that makes ordinary cloud estates easy to mismanage across AWS, Azure, and Google Cloud.

The sample is broad enough to matter: 50 multi-cloud environments across finance, healthcare, manufacturing, and SaaS. The pattern is also familiar. These are not exotic weaknesses, but the same access and credential issues that appear in NHI lifecycle gaps, standing privilege, and weak privileged access governance.

Key questions

Q: What breaks when privileged MFA is missing in multi-cloud environments?

A: Without privileged MFA, cloud access control loses its strongest checkpoint for high-risk accounts. A single password, token, or exposed secret can become a direct path into administrative functions, especially when roles are over-broad. In practice, missing MFA increases both breach likelihood and audit exposure because the same gap is visible to attackers and assessors alike.

Q: Why do standing admin roles make cloud risk harder to contain?

A: Standing admin roles extend access beyond the moment it is needed, so any credential compromise has immediate reach. That persistence also increases the number of systems an attacker can touch before detection. Organisations reduce risk most effectively when elevation is task-scoped and reversible, not permanently assigned.

Q: How can security teams know if cloud identity governance is actually working?

A: The clearest signals are fewer unresolved access findings, shorter evidence-collection cycles, lower counts of stale keys, and reduced reliance on manual review. If teams still spend days reconstructing access state, governance is not operating continuously. Effective programmes can show current MFA coverage, role scope, and credential age on demand.

Q: Who is accountable when cloud identity failures trigger audit or breach exposure?

A: Accountability should sit with the identity and cloud governance owners who define access policy, not only with audit teams who report on outcomes. When service keys, admin roles, and MFA coverage are managed separately, no single team owns the full control loop. Clear ownership across IAM, PAM, and cloud platform teams is essential.

Technical breakdown

Why identity-related control failures stack up in multi-cloud estates

Multi-cloud environments create duplicated identity surfaces, separate policy models, and inconsistent evidence trails. That combination makes the same access mistake appear in different forms across providers, especially when teams manage privileged accounts, service keys, and role assignments separately. A failure to standardise identity controls does not just create technical drift. It creates compliance drift, because the audit artefact, the enforcement point, and the operational owner are rarely the same across cloud platforms.

Practical implication: map every cloud identity control to a single governance owner and evidence source before you try to fix individual findings.

Standing privilege and stale keys as the main attack surface

The article points to privileged MFA gaps, over-broad roles, and duplicate machine keys as the everyday problems attackers exploit first. These are not isolated weaknesses. Together they create standing access that persists longer than operational need, which is exactly the condition ransomware crews and opportunistic intruders look for. In cloud environments, a leaked key or permanently enabled admin role is effectively an always-open path into workloads, data, and adjacent permissions.

Practical implication: treat stale secrets and persistent admin rights as exposure windows, not housekeeping issues.

Why audit effort rises when identity evidence is fragmented

Compliance work becomes expensive when teams have to reconstruct identity evidence from disconnected cloud systems. The extra hours are not caused by the audit itself, but by the absence of a consistent control baseline for MFA, role scope, key age, and service-account visibility. Once evidence is manually assembled, it is already stale. That is why identity governance and audit readiness should be designed together, not treated as separate operating streams.

Practical implication: automate evidence capture for privileged access, key rotation, and role assignment so audit reporting reflects current state rather than historical reconstruction.

Threat narrative

Attacker objective: The attacker aims to turn routine cloud identity weakness into broad access that supports disruption, exfiltration, or later ransomware staging.

1. Entry occurs through ordinary identity weakness, such as a privileged account without MFA, a stale service key, or an over-broad cloud role.
2. Escalation follows when the exposed identity already carries standing access, allowing the attacker to move from one unlocked door to additional cloud permissions.
3. Impact appears as ransomware enablement, data exposure, audit findings, and higher insurance cost once identity control failures are chained together.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

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 compliance is an identity governance failure before it is an audit failure. The article’s 40 identity-related control failures per tenant show that cloud risk is being created at the access layer, not the reporting layer. Privileged MFA, role scope, and key hygiene are governance controls first, audit controls second. The practitioner conclusion is that compliance remediation has to start where identities are granted and maintained.

Standing privilege is the hidden multiplier behind routine cloud exposure. Over-broad roles and always-on admin access turn simple mistakes into durable compromise paths. Once a credential or role is persistent, every other cloud weakness becomes easier to exploit and harder to contain. The practitioner conclusion is to treat privilege persistence as the control problem, not just the indicator of one.

Identity evidence debt is the real reason multi-cloud audits consume time. The reported 26 extra hours per 10 unresolved findings reflects fragmented ownership, not just larger environments. When access state has to be rebuilt manually, governance has already lost its control loop. The practitioner conclusion is that evidence collection and access enforcement must be designed as one process.

Unmanaged machine keys should be read as workload identity debt, not a tooling issue. Duplicate machine keys behave like unmanaged service credentials across clouds, creating a silent access layer that auditors, defenders, and incident responders all struggle to enumerate. That problem sits squarely in NHI governance, where lifecycle, rotation, and visibility are inseparable. The practitioner conclusion is to govern machine credentials as first-class identities.

Unlocked-door cloud risk is the same pattern across human IAM, NHI, and workload access. The article’s four gap families are not separate categories in practice, but different expressions of the same governance weakness: access outliving need. That is why IAM, PAM, and NHI programmes should be aligned around one lifecycle model instead of isolated control checklists. The practitioner conclusion is to unify governance across identity types.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to the 2024 Non-Human Identity Security Report.
• Our research also found that 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge.
• That gap points straight to lifecycle discipline, so review the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns.

What this signals

Identity evidence debt: As cloud estates grow, the cost of proving control effectiveness rises faster than the cost of enforcing it. That is why evidence collection needs to be built into the identity layer, not bolted on after the fact.

With 35.6% of organisations naming consistent access across hybrid and multi-cloud environments as their top NHI security challenge, the governance problem is already structural. Teams that still manage cloud access per platform will keep recreating the same gaps in different places.

The next maturity step is to align human IAM, workload identities, and cloud governance under the same lifecycle model. When access, evidence, and ownership live in one operating rhythm, audit readiness becomes a by-product of control rather than a separate project.

For practitioners

• Map identity controls to a single cloud governance baseline Align privileged MFA, role assignment, key rotation, and evidence collection to one control model across AWS, Azure, and Google Cloud. This reduces duplicate remediation paths and makes audit findings easier to trace back to an owner.
• Eliminate standing admin access wherever it is still enabled Review cloud roles for persistent elevation, remove always-on administrator assignments, and require task-scoped elevation for high-risk actions. Persistent access is what turns minor exposure into attacker-friendly access.
• Rotate stale keys and retire duplicate machine credentials Inventory machine keys, identify keys older than 30 days, and remove duplicate or shared secrets that cannot be traced to a clear owner. Treat every unmanaged key as an open door into workload access.
• Automate evidence gathering for privileged access controls Capture MFA status, role scope, and key age directly from cloud control planes instead of assembling evidence manually at audit time. That shortens audit cycles and keeps compliance reporting tied to live configuration.

Key takeaways

• Forty identity-related control failures per tenant is not a noise level problem. It is proof that common cloud access controls still fail at scale.
• The biggest exposure comes from standing privilege, stale keys, and fragmented evidence, because those conditions convert routine mistakes into persistent risk.
• Teams need one governance model for access, lifecycle, and audit evidence across human and non-human identities, or multi-cloud compliance will keep drifting.

Key terms

• Standing Privilege: Standing privilege is access that remains enabled all the time rather than being issued only when needed. In cloud environments, it expands the blast radius of a compromised account or secret because the attacker inherits ongoing administrative reach instead of a narrow, task-scoped window.
• Identity Evidence Debt: Identity evidence debt is the operational cost created when teams cannot quickly prove who had access, why they had it, and whether controls were working. It usually appears when IAM, cloud, and audit data are fragmented, forcing manual reconstruction during reviews or incidents.
• Workload Identity: Workload identity is the identity assigned to software, services, or machine processes rather than people. It includes service accounts, keys, and tokens that let workloads authenticate and act, which means lifecycle, rotation, and ownership have to be governed like any other privileged identity.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The per-sector breakdown of cloud identity control failures across finance, healthcare, manufacturing, and SaaS
• The exact IAM gap families behind the 70% of high-severity findings
• The article's audit and insurance observations tied to unresolved access gaps
• The practical remediation checklist for privileged MFA, role removal, and key rotation

👉 Unosecur's full blog includes the benchmark findings, audit impact, and identity remediation priorities.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.