OIDC in CI means your pipeline proves its identity to your cloud provider and receives a short lived access token, so you do not store a permanent cloud key as a pipeline secret. To a buyer, the message is simple: there is no standing key to steal, and access is tied to a specific workflow.
The old way and the new way
The old pattern: create a cloud access key, paste it into the CI system as a secret, and let every workflow use it. The key lives for months or years. If it leaks through a log, a compromised dependency or a departing employee, the attacker holds standing access.
The newer pattern: the CI system issues a signed identity token for each run. The cloud provider has a trust rule that says "accept tokens from this repository and branch." The workflow swaps the token for a short lived credential. GitHub's documentation on OpenID Connect lists these benefits, including no need to duplicate cloud credentials as long lived secrets, finer control through the cloud provider's own authorization, and no manual credential rotation.
A script for the questionnaire
Reviewers like short, checkable statements.
"Our pipeline authenticates to the cloud using OpenID Connect. Each run receives a short lived credential scoped to a role. We do not store long lived cloud access keys in CI. The trust rule limits tokens to our production repository and protected branch."
If you still have some stored keys, say which, why, and when you plan to remove them. Do not claim "none" without checking every pipeline and every third party integration.
What the trust rule should say
A trust rule that accepts any repository in your organization is weaker than one that names the repository, the branch or environment, and the role. When you configure it, check:
- The audience and subject conditions are set, not left open.
- Production roles are reachable only from protected branches or approved environments.
- Roles have least privilege, such as permission to deploy one service.
- Forked pull requests cannot assume production roles.
What OIDC does not solve
It does not stop a malicious change that is merged and deployed through the legitimate path. That is why code review, required checks and scanning still matter. It also does not cover secrets for third party services that do not support federation, such as some package registries or SaaS APIs. Inventory those and rotate them on a schedule.
Evidence to offer
| Evidence | Example |
|---|---|
| Trust policy export | The role trust document with conditions visible |
| Pipeline snippet | The step that requests the token |
| Secret inventory | Remaining stored secrets, with owner and rotation date |
| Cloud audit log sample | A deploy showing the assumed role session |
Redact account identifiers before sharing.
Rolling it out
Start with one non critical pipeline, confirm the role works, then move production. Remove the old key only after you have verified nothing else uses it, and record the removal date. For more on pipeline access questions, read who can deploy to production.
Safeguard can help by scanning your dependencies and pipeline definitions for risky patterns through policies and gates. Try a free scan.
Quick check
Is OIDC only for GitHub?
No. Several CI platforms support issuing identity tokens, and major cloud providers accept them. Check your platform's documentation.
Does OIDC remove the need to rotate secrets?
It removes rotation for the cloud keys it replaces. Other secrets still need an owner and a schedule.
Sources
Last reviewed: 19 October 2026.
