They should treat account growth as a control-design problem, not a provisioning problem. Standardise inventory, require every material change to flow through code, and make exceptions visible and reviewable. If teams cannot prove where changes came from, governance is already failing across access, compliance, and recovery.
Why This Matters for Security Teams
When cloud estates grow faster than the control plane, governance stops being about adding more accounts and becomes about proving who can change what, when, and why. The failure mode is usually not a single bad account; it is the accumulation of unmanaged exceptions, inconsistent tagging, and hidden privilege paths that bypass review. Current guidance suggests treating cloud account sprawl as an identity, change-control, and recovery problem together, not as separate operational chores.
The scale of the gap is visible in NHIMG research: The 2024 Non-Human Identity Security Report found that 88.5% of organisations acknowledge their non-human IAM practices lag behind or merely match human IAM. That matters because every new cloud account adds more workload identities, more secrets, and more policy drift. The control objective is not to stop growth, but to make growth observable, reversible, and enforceable through standardised processes aligned to the NIST Cybersecurity Framework 2.0.
In practice, many security teams encounter account sprawl only after an audit failure, a recovery test, or a breach exposes how many accounts were created outside the normal path.
How It Works in Practice
Effective governance starts with a single inventory model that covers cloud accounts, subscriptions, projects, and the identities attached to them. Every material change should be emitted from code, recorded as an auditable event, and mapped to an accountable owner. That includes account creation, policy attachment, trust relationships, secret issuance, and cross-account permissions. For most environments, the practical pattern is a combination of infrastructure as code, policy-as-code, and approval gates that validate the change before it reaches production.
Security teams should also separate the lifecycle of the account from the lifecycle of the access inside it. An account may remain persistent for operational reasons, but the credentials and privileged grants inside it should not. Where possible, use short-lived access, role assumption, and just-in-time elevation so the account does not accumulate standing privilege. This is especially important for service and automation identities, which often outlive the application they were created for. The NHIMG Top 10 NHI Issues and Lifecycle Processes for Managing NHIs both reinforce that unmanaged identity lifecycle is a primary source of exposure.
- Require every account to have an owner, purpose, environment label, and expiry or review date.
- Route changes through code repositories and change pipelines instead of consoles and one-off tickets.
- Enforce deny-by-default guardrails for external sharing, privilege escalation, and secret creation.
- Reconcile cloud inventory against billing, logging, and identity sources to catch orphaned accounts.
- Trigger periodic access recertification for accounts with elevated or cross-environment trust.
For auditability, retention matters as much as prevention. Teams should be able to reconstruct who approved a change, what policy allowed it, and which workloads inherited access. These controls tend to break down when organisations run multiple cloud tenants with different operating models because ownership metadata, approval workflows, and logging formats no longer line up.
Common Variations and Edge Cases
Tighter account governance often increases delivery friction, requiring organisations to balance speed against control precision. That tradeoff is real, especially when platform teams support many business units, acquisitions, or regulated workloads. Current guidance suggests using exception handling rather than bypasses: time-box the exception, document the compensating control, and schedule a review that cannot be ignored.
Not every account should be governed identically. Development sandboxes can tolerate lighter access if they are isolated and disposable, while production and shared services need stricter controls, immutable logging, and stronger segregation of duties. Hybrid estates also complicate the model because some changes happen in cloud consoles, some in identity providers, and some in infrastructure pipelines. That is where account growth becomes dangerous: the estate appears larger, but the real issue is that authority becomes fragmented across systems.
NHIMG case research such as the 230M AWS environment compromise and the Snowflake breach show how quickly hidden trust paths and stale access can turn account sprawl into incident scope. For teams maturing their control set, the practical priority is not perfect centralisation, but consistent evidence that every account can be explained, reviewed, and retired. Where rapid M&A integration or emergency recovery accounts are common, those controls tend to break down because temporary exceptions become permanent operating practice.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Cloud account sprawl is fundamentally an access governance problem. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Account growth often hides unmanaged non-human credentials and privilege drift. |
| NIST AI RMF | Growth control needs governance, accountability, and traceable decision-making. |
Define ownership, oversight, and audit evidence for every automated or semi-automated cloud change.
