Why do organisations struggle to keep secrets management and non-human identity governance under control as environments expand?

Why This Matters for Security Teams

Secrets management stops being a tool problem once environments expand. It becomes an identity problem, because every API key, token, certificate, and workload credential is a path into production. As organisations add cloud services, CI/CD automation, partner integrations, and AI-driven tooling, the number of non-human identities grows faster than owners can govern them. NHIMG research on Guide to the Secret Sprawl Challenge and 52 NHI Breaches Analysis shows how quickly sprawl turns into exposure when lifecycle control is weak.

The operational failure mode is predictable: teams focus on discovery, but not on assignment, rotation, revocation, and attestations. That leaves secrets sitting in source control, CI jobs, container images, and service configs long after the system that created them has changed. NIST’s Cybersecurity Framework 2.0 frames this as a governance and control issue, not just a storage issue. In practice, many security teams encounter credential leakage only after a pipeline or workload has already been reused in ways nobody documented.

How It Works in Practice

Organisations regain control by treating secrets and NHI governance as a single lifecycle, not separate admin tasks. That means inventorying every machine credential, assigning an owner, setting rotation and expiration rules, and revoking access automatically when the workload, service, or deployment is retired. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce the same point: static credentials age badly in dynamic environments.

In mature environments, this usually includes three layers:

• Discovery and classification of secrets across code, pipelines, images, vaults, and runtime environments.
• Workload identity for services and agents, so access is tied to what the workload is, not where a secret was copied.
• Policy enforcement at request time, so rotation, TTL, and revocation are validated continuously rather than during periodic audits.

That approach aligns with the OWASP Non-Human Identity Top 10, which highlights weak lifecycle governance, overprivileged machine accounts, and poor visibility as recurring risks. It also matches what security teams see in incidents like the Shai Hulud npm malware campaign, where exposed secrets become a fast path to lateral movement. These controls tend to break down when thousands of ephemeral workloads are created by automation because ownership, expiry, and revocation metadata does not keep pace with deployment speed.

Common Variations and Edge Cases

Tighter secret controls often increase operational overhead, requiring organisations to balance stronger revocation discipline against developer friction and release velocity. That tradeoff becomes sharper in multi-cloud, hybrid, and CI/CD-heavy environments, where manual exception handling quickly creates shadow processes. The most reliable pattern is usually not a single vault, but a governed system of record for ownership, rotation, and policy enforcement that spans teams and platforms.

There is no universal standard for every environment yet, but current guidance suggests short-lived credentials should replace long-lived static secrets wherever workloads can authenticate with workload identity, federation, or ephemeral token exchange. For organisations trying to reduce blast radius, the question is not only whether a secret can be stored securely, but whether it can be issued just in time, scoped narrowly, and revoked without human intervention. NHIMG’s The State of Secrets in AppSec and Top 10 NHI Issues both point to the same operational reality: fragmentation is the enemy of lifecycle control.

The exception cases are legacy applications, vendor-managed services, and long-lived integrations that cannot yet support dynamic credentials. In those environments, teams usually need compensating controls such as tighter vault access, more frequent rotation, scoped distribution, and stronger detection for credential reuse. The guidance breaks down when secrets are embedded in third-party systems that cannot be refactored, because governance then depends on outside release cycles rather than internal policy.

Related resources from NHI Mgmt Group

• Why do organisations struggle to keep secrets and privileged access under control in fast-moving environments?
• How should security teams secure non-human identities and secrets in Google Workspace environments?
• When should organisations prioritise secrets management over other identity controls?
• Why do long-lived OAuth client secrets create more risk as organisations scale non-human identities?