An OIDC replaceable secret is a static credential that can be eliminated by using OpenID Connect federation instead. OIDC lets a workflow obtain short-lived tokens at run time, reducing the need to store long-lived secrets. This is especially useful for cloud access and trusted publishing workflows.
Expanded Definition
An OIDC replaceable secret is a static credential that should be removed once an application, CI/CD job, or cloud workload can authenticate through OpenID Connect federation and exchange that trust for a short-lived token. In NHI security, the term matters because the goal is not merely stronger authentication, but eliminating durable secrets from the workflow entirely.
OIDC is a standards-based federation pattern, so the practical question is whether a workload can prove its identity without storing an API key, password, or long-lived token. Where that is possible, the secret becomes replaceable by ephemeral credentials issued at runtime. Guidance varies across vendors on how broadly this pattern applies, but the security intent is consistent: reduce secret persistence, shrink blast radius, and improve offboarding. The OWASP Non-Human Identity Top 10 treats secret handling as a core NHI risk area, and NIST SP 800-53 Rev. 5 Security and Privacy Controls reinforces the need for strong credential lifecycle controls.
The most common misapplication is treating a replaceable secret as “temporary” while still hardcoding it into pipelines or retaining it after federation is available.
Examples and Use Cases
Implementing OIDC replaceable secrets rigorously often introduces migration overhead, requiring organisations to weigh short-term pipeline changes against the long-term reduction in secret exposure.
- A GitHub Actions workflow uses OIDC to assume a cloud role at run time, removing the need for a stored cloud access key.
- A trusted publishing job signs releases through federation instead of holding a long-lived npm or package registry token.
- A deployment system exchanges an OIDC assertion for a short-lived token before accessing storage, secrets, or database APIs.
- A build pipeline replaces environment-stored credentials with workload identity, so the secret no longer needs rotation or manual revocation.
- Security teams use the pattern to harden CI/CD after incidents like the Reviewdog GitHub Action supply chain attack, where exposed secrets amplified downstream risk.
The same pattern is described in the Ultimate Guide to NHIs — Static vs Dynamic Secrets, which distinguishes durable credentials from runtime-issued tokens. OIDC federation aligns most cleanly with OpenID Connect Core 1.0, while SPIFFE workload identity concepts are often used in adjacent workload-authentication designs.
Why It Matters in NHI Security
OIDC replaceable secrets matter because static credentials are easy to copy, difficult to inventory, and often remain valid long after the workload that used them has changed. That creates a persistence problem: once a secret escapes code, logs, or a compromised runner, it can be reused until someone finds and revokes it. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes this term operational rather than theoretical.
This is also where governance gets sharper. Replacing a secret with federation reduces rotation burden, strengthens zero standing privilege, and improves offboarding speed when an application, publisher, or automation identity is retired. The risk is especially visible in the kinds of incidents covered in Guide to the Secret Sprawl Challenge and the Shai Hulud npm malware campaign, where exposed credentials turned routine automation into a broader compromise path.
Organisations typically encounter the full impact only after a pipeline compromise, at which point OIDC replaceable secrets become operationally unavoidable to address.
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, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers improper secret management and replacing static secrets with federated identity. |
| NIST CSF 2.0 | PR.AA-01 | Supports identity proofing and authentication for non-human workloads. |
| NIST SP 800-63 | Provides digital identity assurance concepts that inform federated authentication strength. | |
| NIST Zero Trust (SP 800-207) | 2.1 | Zero Trust requires dynamic, continuously evaluated access rather than durable credentials. |
| CSA MAESTRO | ID-01 | Agentic and automated workloads need strong identity and short-lived authorization to limit blast radius. |
Prefer ephemeral, context-bound access tokens over long-lived secrets wherever federation is available.
