Not everywhere. Dynamic credentials are the better default where applications and platforms can handle short-lived issuance and renewal, but some legacy systems still require static secrets. The right decision is to prioritise dynamic access for high-risk paths first, then reduce static exceptions through migration and tighter ownership.
Why This Matters for Security Teams
Choosing dynamic credentials over static secrets is not a cosmetic architecture preference. Static secrets expand blast radius, stay valid long after they should, and are easy to copy into code, tickets, chat, and build logs. That is exactly why secrets sprawl remains persistent, and why NHIMG’s The State of Secrets Sprawl 2026 highlights 64% of valid secrets leaked in 2022 still being exploitable today. For teams trying to reduce NHI risk, the issue is not whether dynamic credentials are ideal in theory, but where they can be operationalised without breaking delivery.
Current guidance from OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is consistent: dynamic credentials should be the default for systems that can support short-lived issuance, but static exceptions still exist in legacy, embedded, or vendor-managed environments. The real security mistake is treating every exception as temporary without ownership, expiry, and migration pressure.
In practice, many security teams discover the cost of long-lived credentials only after a pipeline, integration, or third-party account has already been reused far beyond its intended scope.
How It Works in Practice
Dynamic credentials replace a reusable secret with a time-bound credential issued for a specific workload, task, or session. The operational goal is simple: prove the workload, authorize the request, issue the minimum usable credential, and revoke it automatically when the task ends. In mature environments, that credential is backed by workload identity rather than a shared password or API key, which means the system is authenticating what the service is, not relying on a static string that can be copied and reused.
That model usually works best when paired with short TTLs, automated renewal, and policy checks at issuance time. It also fits modern trust boundaries better than static secrets because access can be narrowed to the exact environment, job, or runtime context. NHIMG’s Guide to the Secret Sprawl Challenge shows why this matters: secrets frequently escape into code, collaboration tools, and infrastructure artefacts, where they become hard to inventory and harder to revoke. A dynamic model reduces the value of any one leak because the credential should expire before an attacker can reliably reuse it.
Implementation usually includes:
- Workload identity for the calling service or agent, often through OIDC, SPIFFE, or a cloud-native identity provider.
- Just-in-time issuance of credentials for the specific API, database, or broker session.
- Policy-as-code to decide whether the request is allowed at runtime.
- Automated revocation and rotation logic tied to job completion or anomaly detection.
- Exception handling for legacy systems that cannot yet accept ephemeral access.
Where teams need a baseline for identity assurance, NIST SP 800-63 Digital Identity Guidelines helps frame assurance and authentication strength, while NHIMG’s CI/CD pipeline exploitation case study illustrates how quickly static pipeline secrets become a supply-chain problem. These controls tend to break down when a legacy product requires a shared credential that cannot be scoped per session because the vendor has no runtime identity or token exchange support.
Common Variations and Edge Cases
Tighter credential controls often increase integration effort, so organisations have to balance security gain against migration cost and system fragility. That tradeoff is real, especially in long-lived estates where embedded devices, older databases, batch jobs, and third-party platforms cannot consume short-lived tokens without redesign.
Best practice is evolving, but current guidance suggests using dynamic credentials everywhere they are technically and operationally feasible, then managing static secrets as controlled exceptions rather than default practice. The exception list should be explicit, time-bound, and owned. A static secret that cannot yet be eliminated still needs rotation, scope limitation, detection, and a retirement plan. Otherwise, the exception becomes a permanent backdoor.
There is also a practical difference between “dynamic” and “fully automated.” Some environments can issue ephemeral access but still require manual approval for sensitive systems. That is acceptable if the control is documented and consistently applied. The risk increases when teams assume dynamic access is universal and leave service accounts, CI variables, mobile app keys, or partner integrations untouched. NHIMG’s Guide to the Secret Sprawl Challenge and The State of Secrets Sprawl 2026 both point to the same operational truth: detection without revocation, and exceptions without expiry, do not meaningfully reduce exposure.
For teams with strict compliance or vendor lock-in constraints, the right answer is usually phased adoption, not an all-or-nothing rewrite.
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 CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Static secrets and rotation are core NHI risks in this question. |
| NIST CSF 2.0 | PR.AC-1 | Access control must distinguish workload identity from reusable secrets. |
| CSA MAESTRO | IAM-03 | MAESTRO covers ephemeral identity and runtime authorization for autonomous systems. |
Replace shared secrets with short-lived credentials and enforce rotation on every remaining exception.
