How should security teams reduce cloud identity risk when passwords and credentials are still widely shared?

Why This Matters for Security Teams

Shared passwords and ad hoc credential exchange create invisible access paths that bypass every inventory, review, and revocation process built around named owners. Once a secret appears in email, chat, or a spreadsheet, the organisation loses reliable control over who has it, where it copied, and whether it still works. That is why current guidance treats credential sharing as an access-governance problem, not just a hygiene issue, as reflected in the Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10.

NHIMG research shows the scale of the problem: 23.7% of organisations still share secrets through insecure methods such as email or messaging applications, while 88.5% say their non-human IAM practices lag behind or merely match human IAM maturity, according to The 2024 Non-Human Identity Security Report by Aembit. That gap matters because cloud identities are often service accounts, automation tokens, and API keys that can be reused at machine speed. The control objective is to make access observable, attributable, and revocable before a shared credential becomes durable persistence. In practice, many security teams discover the breach path only after a secret has already been forwarded, pasted, or embedded into automation.

How It Works in Practice

Reducing cloud identity risk starts by replacing informal distribution with managed issuance. For human users, that means password vaulting, approval workflows, and enforced ownership. For workloads, it means moving toward short-lived secrets, workload identity, and runtime authorisation so access is granted for a task rather than stored for convenience. The NIST Cybersecurity Framework 2.0 remains useful for organising ownership, access review, and recovery, but the implementation detail must shift from static accounts to ephemeral credential flows.

Practitioners should prioritise four operational moves:

• Inventory every shared cloud credential and assign a named owner, system owner, and rotation path.
• Move secrets into a managed secret store with automatic expiry, logging, and revocation triggers.
• Use workload identity, not embedded passwords, for cloud automation and service-to-service calls.
• Require break-glass and emergency access procedures that are time-bound and auditable.

Where possible, align access with the NIST SP 800-63 Digital Identity Guidelines for identity assurance, then adapt that model for machine identities using the patterns described in Ultimate Guide to NHIs — Static vs Dynamic Secrets. Where teams still rely on shared credentials, the immediate win is not perfect zero trust, but removing uncontrolled distribution and ensuring every secret can be rotated without manual recall. These controls tend to break down in legacy admin consoles and unmanaged automation scripts because embedded credentials cannot be rotated cleanly without service interruption.

Common Variations and Edge Cases

Tighter secret control often increases operational overhead, so organisations have to balance stronger governance against deployment speed and on-call friction. That tradeoff is real in hybrid estates, where some platforms support ephemeral tokens and others still require long-lived static credentials. Best practice is evolving, not settled: there is no universal standard for every cloud and legacy mix, which is why many teams treat secret modernisation as a phased programme rather than a single cutover.

Edge cases usually appear in three places. First, vendor integrations may force the use of shared API keys until a modern auth option exists. Second, disaster recovery accounts often resist full automation because they are intentionally rare and tightly guarded. Third, CI/CD and infrastructure-as-code systems may need credentials that live only long enough to bootstrap trust, then hand off to federated identity. The right response is to narrow scope, reduce TTL, and document compensating controls rather than accept permanent sharing as normal.

NHIMG data also shows why urgency matters: 59.8% of organisations see value in dynamic ephemeral credentials, but only 19.6% express strong confidence in their ability to manage workload identities securely, according to The 2024 Non-Human Identity Security Report. For teams still early in the journey, the most practical starting point is to map every shared secret to a replacement path and retire the highest-risk ones first. In environments with heavily scripted admin access and fragmented ownership, the guidance breaks down when no single team can rotate or revoke a credential without breaking production.

Related resources from NHI Mgmt Group

• How should security teams reduce cloud identity risk when credentials are stored in shared infrastructure?
• How should security teams evaluate shared cloud risk for identity credentials?
• How should security teams use ISPM to reduce identity risk?
• How should security teams reduce help desk hijack risk in identity programmes?