TL;DR: Static secrets still dominate non-human identity access patterns, but they leave a bootstrap trust gap, create multicloud policy drift, and keep revoked credentials alive far too long, according to Aembit and GitGuardian research. Layered identity controls that remove standing credential exposure matter more than vault centralisation alone.
At a glance
What this is: Aembit argues that secrets managers solve storage and rotation, but not the deeper problem of how non-human identities authenticate and get authorised across multicloud environments.
Why it matters: IAM, PAM, and NHI teams need to distinguish between storing credentials and governing runtime access, because bootstrap trust gaps and policy fragmentation keep standing credential risk alive.
By the numbers:
- 64% of secrets confirmed as valid in 2022 remained unrevoked heading into 2026.
- Credentials for AI services surged 81% as agentic workflows introduced new categories of machine credentials into production stacks.
Context
Secrets manager alternatives for non-human identities in multicloud is a governance problem, not just a tooling problem. Storing credentials centrally does not answer who can present them, where they can be used, or how access should change across cloud boundaries.
The article separates storage from runtime authorisation and shows why that split matters in multicloud. It also frames workload IAM, federation, service meshes, PKI, and cloud-native IAM as complementary controls that reduce standing credential dependence rather than replacing every existing control overnight.
For NHI programmes, the core question is whether a vault remains the primary control or becomes only one layer in a broader access model. The answer depends on whether workloads need secretless authentication, cross-cloud policy consistency, and context-aware issuance.
Key questions
Q: What breaks when secrets managers are the only control for non-human identities?
A: Secret storage remains intact, but trust governance does not. A vault can centralise credentials and still leave a bootstrap secret, inconsistent cross-cloud policy, and standing access to downstream services. The failure mode is treating custody as authorisation. Teams need to distinguish between holding a secret and deciding whether a workload should use one in the current context.
Q: Why do cloud environments increase non-human identity risk?
A: Cloud environments increase non-human identity risk because automation, APIs, and service accounts multiply faster than manual review can keep up. Those identities often carry persistent credentials and broad permissions, which makes them difficult to track and easy to over-extend. If they are not inventoried and rotated, they become durable access paths for attackers.
A: Warning signs include keys appearing in crash dumps, secrets being moved outside their original secure boundary, and access paths that give engineers or systems broader reach than intended. Another indicator is when sensitive data sits in a datastore with permissive access or plaintext exposure. These patterns show that automation, redaction, or environment separation is not working as designed.
Q: What is the difference between workload IAM and secrets management?
A: Secrets management stores and rotates credentials, while workload IAM governs whether a workload should receive access in the first place. Both are needed, but they solve different problems. Without workload IAM, secrets can still be overprivileged or reused too broadly; without secrets management, credentials are still exposed and difficult to revoke.
Technical breakdown
Why vaults do not solve the secret zero problem
A secrets manager stores and rotates credentials, but the workload still needs something to present before it can retrieve the secret. That bootstrap dependency is the secret zero problem. In multicloud environments, the issue gets worse because access models differ by provider, so the same workload may need separate bootstrap paths and policy settings in each cloud. The operational result is not just more secrets, but more places where control can drift away from governance.
Practical implication: treat vault storage as downstream control and map every bootstrap path that still depends on a standing credential.
How federation changes non-human identity trust across clouds
OpenID Connect federation replaces cross-cloud static secrets with token-based trust. A workload proves identity with a signed token, the target system validates that trust relationship, and then it issues a short-lived credential for the specific request. This removes the need to copy a long-lived secret into each environment. The important architectural point is that the trust relationship is now policy-bound and portable, which makes it easier to avoid the configuration sprawl that often appears when each cloud is managed separately.
Practical implication: use federation where the main problem is cross-cloud credential reuse rather than local workload-to-workload authentication.
Why workload IAM shifts control from storage to issuance
Workload IAM verifies identity at runtime and brokers access through policy, rather than waiting for a stored credential to be retrieved from a vault. That changes the security boundary from secret storage to credential issuance. Access can be conditioned on environment, time, and posture, which matters when workloads, CI/CD systems, and AI services request access autonomously. In practice, this is the point where standing credentials stop being the default mechanism and become the exception for legacy integrations.
Practical implication: prioritise runtime issuance controls for workloads that already have stable identity context and predictable access paths.
Threat narrative
Attacker objective: The attacker wants persistent, reusable access to workloads and downstream services by exploiting secrets that outlive the trust they were meant to represent.
- Entry begins when a workload uses a bootstrap credential to reach a vault or when a hardcoded secret is embedded in code, configuration, or a CI/CD path.
- Credential access follows when the stored secret is reused across clouds, integrations, or services that were never meant to share the same trust boundary.
- Escalation happens when the compromised credential exposes multiple downstream workloads, APIs, or SaaS connections because the vault centralised storage but not use authority.
- Impact is broad access to the secret estate, with revoked or stale credentials still usable long after the original trust decision should have expired.
Breaches seen in the wild
- 12,000 secrets in LLM training data: Truffle Security found 11,908 live API keys and passwords hard-coded in web pages captured by Common Crawl, a dataset used to train LLMs.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Vault centralisation is not identity governance. A secrets manager can store credentials securely, but it cannot by itself decide when a workload should authenticate, where a secret may be used, or whether trust should persist across clouds. That is why the security problem in multicloud is not storage density but issuance control. Practitioners should stop treating vault coverage as a proxy for governance maturity.
The secret zero assumption breaks at runtime, not at rest. The model assumes a workload can fetch a credential before it needs to act, but that assumption creates a bootstrap credential that becomes the real high-value target. Once that bootstrap credential exists, the vault inherits the same standing-access problem it was meant to reduce. The implication is that issuance-time trust, not vault hygiene, is the decisive control boundary.
Multicloud makes policy drift the default unless identity is portable. Each cloud brings different trust semantics, configuration models, and access boundaries, so a credential strategy built around separate vaults quickly fragments. That fragmentation is a governance failure because revocation, rotation, and scope no longer behave consistently across environments. The practical conclusion is that cross-cloud workload identity needs one policy layer, not a stack of isolated secret stores.
Secretless access changes the control objective from possession to proof. When workloads authenticate with tokens, attestation, or mTLS-backed identity instead of copied credentials, the security question shifts to whether the runtime proof is valid for this request. That is a different governance model from storing and rotating secrets, and it is far more suitable for AI services, CI/CD systems, and distributed application stacks. Teams should reframe NHI risk around who can prove identity at runtime, not just where secrets live.
Runtime access controls should be the new baseline for machine identity. The article’s real message is that vaults remain useful, but only as one layer in a broader trust architecture. Mature NHI governance now means combining federation, workload IAM, PKI, and transport identity so no single control carries the full burden. Security teams should design for ephemeral issuance first and legacy secret handling second.
From our research library:
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to the State of Secrets Sprawl 2026.
- 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
- Read next: Ultimate Guide to NHIs
What this signals
Secret zero is now a governance issue, not an implementation nuisance. If a workload must present a bootstrap credential before it can reach the control plane, that credential becomes the real trust anchor. Teams should inventory those bootstrap paths first, because that is where vault-centric programmes silently preserve standing privilege.
Multi-cloud policy drift is the hidden failure mode. When each cloud provider maintains its own identity model and access syntax, rotation and revocation stop being uniform controls. The result is a fragmented NHI estate in which the same access rule behaves differently depending on where the workload runs.
Secretless access should be treated as the target architecture for high-value paths. Workloads that access production data, third-party APIs, and CI/CD systems are the clearest candidates for runtime issuance rather than reusable credentials. That shift reduces the blast radius of compromise and makes governance measurable at the point of issuance.
For practitioners
- Map bootstrap credentials for every workload Inventory the credential or token each workload uses before it can reach a vault, broker, or cloud-native identity service. Flag any path that still depends on a reusable standing secret as a governance gap.
- Prioritise secretless access for cross-cloud workloads Move database, API, and SaaS connections that span clouds toward token-based federation or workload IAM so the secret never crosses the trust boundary in the first place.
- Separate storage control from use control Document which controls only store or rotate credentials and which controls decide whether a workload may use them in the current context. Use that distinction to identify overreliance on vaults.
- Apply contextual issuance policies Require environment, time, and posture checks before a workload receives a short-lived credential. Reserve static secrets for legacy dependencies that cannot yet be converted.
Key takeaways
- Secrets managers reduce storage risk, but they do not eliminate the bootstrap trust problem that governs non-human identity access.
- Multicloud environments amplify policy drift because each provider handles trust, rotation, and revocation differently.
- Runtime identity and short-lived issuance matter more than vault centralisation when workloads need consistent access across clouds.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Hardcoded and embedded secrets are the article's core risk signal. |
| NHI-07 — Long-Lived Secrets | The article contrasts static secrets with short-lived identity and token-based access. | |
| NHI-04 — Insecure Authentication | Bootstrap credentials and reuse across clouds expose weak authentication patterns for NHIs. | |
| Recommendation — Eliminate exposed machine secrets and scan code, CI, and integrations for leaked credentials. Reduce dependence on long-lived machine secrets and replace them with short-lived credentials where possible. Harden machine authentication paths so workloads prove identity without reusable bootstrap secrets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centers on who can use credentials once issued, not just where they are stored. |
| Recommendation — Apply PR.AA-05 to enforce consistent authorisation and entitlement checks for NHI access across environments. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle, rotation, and revocation are central to the article's comparison of control models. |
| Recommendation — Use IA-5 to govern authenticator issuance, rotation, revocation, and replacement for workload credentials. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article describes compromise paths that lead from secret access to broader credential exposure. |
| Recommendation — Map leaked secret paths to TA0006 and TA0010 to prioritise detection around credential harvesting and spillover. | ||
Key terms
- Bootstrap Credential: A bootstrap credential is a temporary secret used to get a new identity into its first trusted session when normal access paths are not yet ready. In identity governance, it should be time-bound, single-use, and auditable so it does not become a permanent side channel.
- Secret Zero Problem: The secret zero problem is the bootstrap challenge of needing a credential to obtain another credential or reach a vault. It exposes a fundamental weakness in static-secret architectures because the first credential still has to be protected before any downstream rotation or governance can begin.
- Workload IAM: Workload IAM is the practice of applying identity and access management controls to software workloads instead of relying on static secrets. It uses platform-native identity, policy, and short-lived credentials so access can be verified, scoped, and audited without embedding long-term secrets in applications.
- Policy Drift Detection: Policy drift detection is the process of identifying when an access policy no longer matches the intended rule or the current business context. It helps teams catch unauthorized changes, stale permissions, and exceptions that have quietly become the new normal, so governance stays aligned with actual identity and app usage.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org