Secret manager based authentication depends on a persistent credential that the pipeline retrieves and reuses. OIDC-based authentication does not store a long-lived cloud key in the pipeline at all. Instead, the workflow requests a signed identity token at runtime, and the cloud provider exchanges it for short-lived credentials based on predefined trust rules.
Runtime trust versus stored credential reuse
OIDC-based cloud authentication and CI secret manager storage solve the same access problem in different ways. The first shifts trust to a runtime-issued token and a cloud-side trust policy, which means the pipeline never carries a reusable long-lived cloud key. The second keeps a persistent secret in the CI environment and depends on careful storage, retrieval, and rotation discipline.
The practical difference is not just where the value lives. With OIDC, the workflow proves it is the right workload at the moment of execution, then receives short-lived cloud credentials. With a secret manager, the pipeline already has a reusable credential path, so compromise of the pipeline, runner, or retrieval logic can expose something that remains valid until it is rotated or revoked.
For a broader reference on the underlying identity and secret-handling problem, NHI Mgmt Group’s Ultimate Guide to NHIs explains why long-lived machine credentials and secrets sprawl create durable risk.
Security trade-offs in CI/CD and cloud access
OIDC reduces secret persistence, but it raises the importance of trust configuration. You must define which workflow, repository, branch, environment, or deployment context is allowed to exchange a token for cloud access. If that trust rule is too broad, the control becomes permissive even though no static cloud key is stored.
Secret manager based authentication shifts the burden to secret hygiene. You need strong vault access control, retrieval logging, rotation, and scoping, because the pipeline will still depend on a credential that can be reused if leaked. This is why secret manager designs often work best when the secret is tightly scoped, short-lived, and isolated from broad pipeline reuse.
For practitioners dealing with secret sprawl specifically, NHI Mgmt Group’s Guide to the Secret Sprawl Challenge is a useful companion, and the OWASP Non-Human Identity Top 10 captures the risks around static credentials, overprivilege, and rotation gaps.
A useful data point here is that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That does not make secret managers ineffective, it shows how often the operational model fails when secrets are treated as convenient plumbing rather than controlled access material.
What practitioners should verify before choosing one model
The right choice depends on what you need to control most tightly: credential persistence, trust granularity, or operational simplicity. OIDC is usually the stronger option when your cloud provider and CI platform support fine-grained workload trust and you want to eliminate stored cloud keys. A secret manager is still reasonable when the target system cannot federate cleanly, or when a controlled stored secret is unavoidable and can be tightly governed.
What to verify: confirm the token audience, issuer, subject claims, and branch or environment restrictions for OIDC, because those fields determine whether the exchanged credential is truly bound to the intended workflow. For secret managers, verify who can read the secret, how long the secret stays valid, and whether rotation is actually enforced rather than merely documented.
Decision rule: if the pipeline can authenticate through short-lived federation without storing a cloud key, prefer OIDC; if you must store a reusable secret, treat the vault path, access policy, and rotation cadence as first-class security controls rather than implementation details.
Practitioner takeaway: OIDC lowers blast radius by removing durable credentials, while a secret manager lowers exposure only if the stored secret is tightly governed, short-lived, and demonstrably rotated.
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 address the attack and risk surface, while CIS Controls v8, NIST Zero Trust (SP 800-207), NIST AI RMF and 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-01 — Secret Sprawl and Credential Leakage | OIDC vs stored secrets is fundamentally about durable credential exposure. |
| NHI-03 — Overprivileged Non-Human Identities | Cloud trust rules and vault scopes determine how much access a pipeline can misuse. | |
| NHI-06 — Secrets Rotation and Expiration | Secret-manager models depend on rotation and expiration to limit reuse after exposure. | |
| Recommendation — Eliminate long-lived pipeline secrets wherever federation can issue short-lived access. Scope workload access to the minimum cloud permissions needed for each workflow. Set short secret lifetimes and enforce rotation on a fixed, auditable cadence. | ||
| CIS Controls v8 | 6.3 — Access Granting and Revocation | Both approaches depend on tightly controlled issuance and revocation of access material. |
| 8.2 — Audit Log Management | CI secret retrieval and token exchange both require traceable authentication events. | |
| Recommendation — Revoke unused pipeline access paths and remove standing credentials promptly. Log secret reads and federation exchanges with enough detail to support investigation. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Continuous Verification | OIDC implements runtime trust by verifying the caller at the moment of access. |
| Recommendation — Bind cloud access to runtime assertions instead of reusable static credentials. | ||
| NIST AI RMF | GV.2 — Govern AI Risk Management | The core choice is a governance decision about trust, persistence, and blast radius. |
| Recommendation — Define when federated runtime access is mandatory and when stored secrets are acceptable. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The comparison centers on how cloud access is authenticated and authorized for pipelines. |
| PR.DS — Data Security | Secrets stored in CI systems are sensitive data that require protection and lifecycle control. | |
| Recommendation — Apply strong authentication and least-privilege access rules to CI workloads. Protect stored credentials with vault controls, segmentation, and minimised retention. | ||
Related resources from NHI Mgmt Group
- What is the difference between storing CI/CD secrets in pipeline variables and retrieving them from a central secrets manager at runtime?
- What is the difference between OIDC-based workload identity and shared secrets in CI access control?
- What is the difference between passwordless authentication and password-based MFA in ransomware defense?
- What is the difference between bound service account tokens and secret based service account tokens?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
