How should teams decide when to keep a static secret versus migrate to federation?

Why This Matters for Security Teams

The decision is not really about “static versus dynamic” in the abstract. It is about whether the workload can be trusted to use identity safely over time. static secret are operationally easy, but they expand blast radius when leaked, copied, or left in code. That is why NHIMG research keeps finding secret where teams least expect them, including in pipelines and source control, as shown in the Guide to the Secret Sprawl Challenge. The practical risk is amplified by the fact that 96% of organisations store secrets outside of secrets managers in vulnerable locations, including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs — Static vs Dynamic Secrets.

Current guidance suggests treating federation as the default when the target can validate a trusted issuer and the dependency chain is understood. That aligns with the direction of the OWASP Non-Human Identity Top 10, which emphasises reducing standing credentials and tightening identity controls around machine access. In practice, many security teams encounter secret sprawl only after a build system, integration token, or service account has already been reused outside its intended boundary.

How It Works in Practice

Start with a simple test: can the workload authenticate to a trusted issuer, receive a short-lived token, and complete the task without a long-term secret? If yes, migrate. Federation works best when identity is anchored in the workload itself, not in a reusable password, API key, or certificate that must be distributed and protected everywhere. For that reason, teams should pair federation with workload identity and runtime policy checks rather than rely on broad RBAC rules alone. The question is not only “who is calling,” but also “what is this workload allowed to do right now?”

Operationally, the strongest pattern is to issue JIT credentials per task, scope them to the minimum audience, and revoke them automatically after completion. That reduces exposure if a token is intercepted or an integration is repurposed. NHIMG incident research shows why this matters: in the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign, exposed secrets became reusable footholds rather than one-time failures.

• Keep a static secret only for systems that cannot consume federated identity or short-lived tokens.
• Prefer a trusted issuer, such as OIDC-based federation, where the platform can validate workload identity at request time.
• Use policy-as-code for intent-based authorisation so access reflects the task, context, and risk level.
• Rotate and retire any remaining static secret on a scheduled path, with ownership and offboarding documented.

These controls tend to break down when legacy systems require embedded credentials and cannot tolerate token exchange or frequent reauthentication because the integration was never designed for short-lived access.

Common Variations and Edge Cases

Tighter control often increases integration effort, so organisations have to balance resilience against downtime risk and engineering cost. There is no universal standard for exactly when a static secret is “acceptable,” and current guidance suggests using business criticality, system capability, and revocation speed as the decision criteria. In practice, that means some low-risk batch jobs may temporarily retain a secret while the team builds the federation path, but the exception should be time-boxed and reviewed.

The hardest cases are stateful legacy applications, vendor-managed services, and tools that cache credentials longer than the security team expects. In those environments, moving to federation may require a wrapper service, a credential broker, or a phased cutover with parallel validation. Where agents or autonomous workflows are involved, the bar should be higher still: their behaviour is harder to predict, so long-lived credentials create an outsized risk. For that reason, the control model should lean toward short-lived secrets, real-time policy evaluation, and workload identity primitives rather than static RBAC assumptions. NHIMG’s analysis of the 230M AWS environment compromise and the CI/CD pipeline exploitation case study both show how quickly a single overprivileged secret can turn into broad lateral movement.

The practical rule is simple: keep the static secret only until the system can be made identity-aware, then migrate decisively instead of leaving the exception in place.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams replace static secrets in Databricks pipelines?
• How should teams secure non-human identities across cloud and SaaS?
• What is the difference between privilege reduction and secret rotation?