OIDC trusted publishing uses a short-lived federated assertion from the CI system to prove a workflow is current and authorised. The registry exchanges that proof for ephemeral publish access, which removes the need to store a durable package token.
Expanded Definition
OIDC trusted publishing is a federated publishing pattern in which a CI workflow presents a signed OpenID Connect assertion to a registry or package service, proving the job is current, approved, and running in the expected automation context. The registry then issues short-lived publish permission instead of relying on a stored package token. In NHI terms, the workflow becomes a transient publishing identity with narrowly scoped authority, which reduces the durability of secrets and the blast radius of compromise.
Definitions vary across vendors on how much trust should be placed in workflow metadata, branch protections, runner provenance, and environment claims. That means implementation quality depends on strict claim validation, audience binding, and policy controls at the receiving service, not merely on “using OIDC.” For governance context, NIST Cybersecurity Framework 2.0 frames this as an access and assurance problem, while NHI management treats it as a secret-elimination and lifecycle-control pattern. The most common misapplication is replacing a long-lived token with OIDC while failing to restrict the trusted claims, which occurs when any workflow in the repository can still obtain publish access.
Examples and Use Cases
Implementing OIDC trusted publishing rigorously often introduces policy complexity, requiring organisations to weigh secret removal and faster rotation against stricter workflow controls and registry-side validation.
- A package build in GitHub Actions exchanges an OIDC assertion for ephemeral release access, eliminating a stored publish token on the runner.
- A hardened CI pipeline allows publishing only from a protected branch and only when the workflow identity matches the expected repository and environment claims.
- A software vendor moves from static registry credentials to federation after reviewing the attack path described in OneLogin API Key Vulnerability, which shows how durable secrets can be abused once exposed.
- An open-source maintainer uses federated publishing to reduce secret sprawl and align release automation with the least-privilege guidance in NIST Cybersecurity Framework 2.0.
- A compliance team requires every publishing workflow to be traceable to a specific repository, ref, and job so that provenance can be audited after release.
Why It Matters in NHI Security
OIDC trusted publishing matters because it removes a high-value class of standing secrets from CI/CD, but only if the federation policy is strict enough to prevent unauthorized workflows from minting publish access. 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 durable package tokens a predictable exposure point. In that environment, trusted publishing is not just a convenience feature; it is a direct control for reducing secret persistence, revocation burden, and supply-chain blast radius. It also supports Zero Trust principles by making each publish action depend on current context rather than on a reusable credential. For operational teams, the term becomes relevant when release automation is reviewed after a leak, a suspicious package upload, or a CI compromise, because the old token-based model is then clearly the weak link.
For broader identity governance, the pattern aligns with the NHI lifecycle concerns described in Ultimate Guide to NHIs, and the same trust-boundary logic should be evaluated alongside NIST Cybersecurity Framework 2.0 when organisations define access review, monitoring, and incident response expectations.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secretless federation and the risks of exposed CI/CD credentials. |
| NIST CSF 2.0 | PR.AC-4 | Trusted publishing is an access-control pattern for machine identities. |
| NIST Zero Trust (SP 800-207) | OIDC trusted publishing fits Zero Trust by avoiding implicit standing trust. | |
| NIST SP 800-63 | Federation | OIDC is a federated identity mechanism defined under digital identity guidance. |
| OWASP Agentic AI Top 10 | CI agents and automation need constrained tool access and provenance checks. |
Replace durable publish tokens with short-lived federated assertions and validate claim scope.
