Yes, where the underlying service supports it and the workload can present a trustworthy runtime identity. Workload-attested access is better suited to ephemeral machine use because it removes the durable artifact attackers want. Rotation remains a backstop, but it should not be the primary control for high-volume NHI access.
Why This Matters for Security Teams
Secret rotation is still useful, but it is a blunt control for workloads that authenticate constantly, change context quickly, and may never need a durable credential at all. Workload-attested access shifts the trust decision from “does this secret still work?” to “is this workload the one that should be here right now?” That matters because the attack surface is often the secret itself, not just the system using it.
NHIMG research shows how quickly machine identity sprawl becomes operational risk: the 2025 State of NHIs and Secrets in Cybersecurity found that 44% of NHI tokens are exposed in the wild. When secrets are copied into tickets, repos, chat, or build logs, rotation can reduce exposure time, but it does not remove the pattern of overexposed, reusable credentials. That is why guidance is moving toward workload identity, short-lived proof, and policy-based issuance rather than long-lived shared artifacts.
Current guidance also aligns with the OWASP Non-Human Identity Top 10, which treats secret misuse, over-privilege, and weak lifecycle control as core machine-identity risks. In practice, many security teams discover the real failure only after a secret has already been copied into multiple systems and one of them is compromised.
How It Works in Practice
Workload-attested access typically relies on cryptographic proof of runtime identity, not a standing secret that must be manually refreshed. In mature implementations, the workload presents an attestation signal from its platform, environment, or identity agent, and the access layer issues a short-lived credential only when policy allows it. That can be an OIDC token, a SPIFFE ID, or another workload identity primitive depending on the stack. The important point is that the credential is bound to the workload instance and the request context, not just to a name in a vault.
This is where the SPIFFE workload identity specification is especially relevant: it formalises how workloads can prove who they are without relying on reusable shared secrets. For teams comparing patterns, NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets and Guide to SPIFFE and SPIRE explain why dynamic issuance is often safer than maintaining a pool of long-lived secrets.
- Use attestation for issuance, then make the credential short-lived and auto-revoked.
- Bind access to workload identity, environment, and purpose, not just service name.
- Apply policy at request time, so a compromised workload cannot keep broad access indefinitely.
- Keep rotation only as a fallback for legacy dependencies that cannot yet attest.
This guidance breaks down in legacy environments where services cannot present verifiable runtime identity and still depend on shared secrets across multiple nodes or jobs.
Common Variations and Edge Cases
Tighter attested access often increases integration overhead, requiring organisations to balance stronger control against platform maturity and service compatibility. That tradeoff is real, especially where applications are container-agnostic, vendor-managed, or tied to fixed credentials that cannot yet be replaced.
Best practice is evolving rather than settled in every environment. For high-volume machine traffic, most teams should treat rotation as a backstop and not the primary mechanism. For low-frequency or third-party integrations, rotation may still be the most practical control until the service can support workload identity. The right decision depends on whether the workload can prove itself at runtime, whether secrets are duplicated across systems, and whether policy can be evaluated fast enough to support the business flow.
NHIMG’s Guide to NHI Rotation Challenges is useful when teams need to understand why rotation alone often fails to keep pace with sprawl, while the Guide to the Secret Sprawl Challenge shows how duplication makes every extra secret a future cleanup task. For policy and governance context, the OWASP Non-Human Identity Top 10 supports moving away from standing secrets wherever workload attestation is available. When workloads are ephemeral, distributed, and tool-chained, rotation tends to lag behind reality because the access pattern changes faster than the credential lifecycle can keep up.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret lifecycle weaknesses that rotation is meant to reduce. |
| OWASP Agentic AI Top 10 | Runtime identity and tool access are central when workloads act autonomously. | |
| NIST AI RMF | Supports governance for dynamic AI or workload behaviour requiring context-aware controls. |
Prefer short-lived, workload-bound credentials and keep rotation only as a fallback.
