Fulcio is the piece of Sigstore that makes keyless signing possible. It is also the piece that enterprise architects worry about most when they first look at the stack. A certificate authority that issues certificates valid for ten minutes, based on OIDC tokens, with no subscriber identity ceremony, feels alien to anyone who has operated a traditional PKI. Once you understand the lifecycle, the worry becomes specific rather than general, and the specific worries have specific answers.
This post is an enterprise view of the Fulcio certificate lifecycle. It covers how certificates are issued, what the OIDC identity binding actually guarantees, how long-term trust works when individual certificates are ephemeral, the decision points for running a private Fulcio, and the operational practices that make keyless signing defensible under audit.
How are Fulcio certificates actually issued?
A Fulcio certificate request starts with an OIDC ID token. The signer (a CI workflow, a developer, a release script) obtains an ID token from an OIDC issuer it trusts (GitHub Actions, Google, an internal SSO), generates a short-term key pair, and signs a challenge containing the key fingerprint with the private key. The signed challenge, the ID token, and the public key are sent to Fulcio.
Fulcio validates the ID token against the issuer's JWKS, extracts the identity claims, and issues an X.509 certificate binding the public key to those claims. The certificate's subject alternative name (SAN) is the primary identity (typically an email or a workflow URI). Additional OIDC claims are encoded as certificate extensions, using the OID namespace 1.3.6.1.4.1.57264.1.x defined by the Sigstore project. The certificate's notBefore/notAfter are set such that validity spans roughly ten minutes.
The certificate is signed by Fulcio's intermediate CA, which in turn is signed by the Fulcio root. The root is published as part of the Sigstore TUF metadata and is what consumers anchor trust to. The ten-minute validity window is a policy choice, not a technical limit; the underlying CA can issue longer certificates, but short lifetimes are what eliminate the need for revocation.
What does the OIDC identity binding guarantee?
The identity binding is where enterprise concerns tend to focus. A Fulcio certificate says "this key pair is bound to identity X, issued by OIDC provider Y, at time Z." It does not say that identity X is the real person claimed by the email address, nor that the key was used responsibly. All the trust in the binding comes from the OIDC provider's validation of the identity.
For GitHub Actions OIDC, the identity in the certificate encodes the organisation, repository, workflow file, event trigger, and ref. The claim "this signature was made by the release.yml workflow in myorg/myrepo triggered by tag vX.Y.Z" is as strong as GitHub's control of the workflow identity. An attacker that compromises a workflow's secrets can forge signatures for that workflow's identity, which is why production policies verify not just the workflow identity but the event trigger (workflow_dispatch, push, pull_request) and the ref type (tag vs branch).
For human identities (developer signing a commit), the OIDC issuer is typically Google, Microsoft, or GitHub's login endpoint. The identity is an email address, and the guarantee is as strong as the provider's account security. Enterprise deployments generally do not allow signing from consumer OIDC providers; they require internal SSO that enforces MFA, device posture, and session duration policies.
The certificate extensions record rich provenance about the issuance. Extension 1.3.6.1.4.1.57264.1.8 is the OIDC issuer. Extensions in the 1.3.6.1.4.1.57264.1.1x range encode GitHub workflow details. A verifier that parses these extensions can enforce policy that goes beyond just the SAN.
How does long-term trust work?
The central question every enterprise asks: how do you verify a signature produced six months ago with a certificate that is long expired?
The answer is the Rekor transparency log. When Fulcio issues a certificate and the signer uses it, the signature (plus the certificate, plus the signed payload's hash) is recorded in Rekor. Rekor provides a timestamp, called integratedTime, asserting when the entry was added to the log. A verifier checks that the integrated time falls within the certificate's validity window; if it does, the signature is valid even though the certificate itself expired long ago.
This is the mental model shift. Traditional PKI treats expiry as "signature no longer usable." Sigstore treats expiry as "no new signatures with this certificate, but historical signatures remain verifiable." The Rekor log is the long-term trust anchor; the certificate is a short-term binding.
For this to work, the Rekor log itself must be trustworthy over the long term. The log is append-only, its root hash is periodically signed and published as a "checkpoint," and the checkpoints form a chain that consumers can audit. If Rekor were to lose integrity, the entire long-term trust story collapses, which is why the public Rekor instance is operated with careful attention to operational security and why regulated enterprises sometimes run their own.
When does a private Fulcio make sense?
The public Fulcio instance at fulcio.sigstore.dev is operated by the OpenSSF as public good infrastructure. For most teams it is the right default. Private Fulcio deployments make sense in three scenarios.
First, when OIDC providers cannot be public. If your signing identity provider is an internal SSO that cannot be reached from Fulcio's servers, a private Fulcio instance in the same network boundary is required. This is common in air-gapped deployments.
Second, when certificate identity policy needs to be organisation-specific. Public Fulcio accepts a fixed set of OIDC providers and encodes their claims in a standard way. If your organisation wants custom identity encoding (internal employee IDs in certificate extensions, organisation-specific OID allocations), a private Fulcio lets you control the certificate template.
Third, when audit requirements demand that issuance records stay inside the organisation's control. Public Fulcio's issuance records go to public Rekor. A private deployment keeps both the CA and the transparency log internal.
Running private Fulcio is non-trivial. The Helm chart at sigstore/helm-charts provides the starting point. The root CA needs to be generated in a ceremony with proper key custody (HSM, offline signing machine, documented procedure). The intermediate CA needs its own HSM and rotation plan. The OIDC validation configuration must be maintained as the organisation's SSO evolves.
What are the enterprise operational practices?
Three practices are worth copying from teams that run Fulcio well. First, explicit trust scoping. Every verifier in the organisation declares which OIDC issuers it trusts and, within each issuer, which identities. A GitHub Actions OIDC trust that accepts any workflow from any repository is too broad; the policy should list acceptable repositories and workflow patterns.
Second, routine certificate audit. On a regular cadence, pull a sample of recent certificates from Rekor, parse the extensions, and verify that the identity claims make operational sense. This catches anomalies: workflows signing unexpectedly, certificates issued to unknown repositories, claims that should not have been accepted.
Third, disciplined trust root rotation. Sigstore periodically rotates the Fulcio root certificate. Enterprises that have cached trust material need to handle the rotation gracefully. The TUF client in cosign v2.2+ does this automatically for online verifiers; offline verifiers need a scheduled sync of the TUF repository.
The long-term view is that keyless signing does not remove PKI operational concerns; it moves them. Instead of managing individual certificates and their revocation, you manage the trust in issuers, the policy against identities, and the integrity of transparency logs. Done well, this is less operational burden than traditional PKI. Done poorly, it is the same amount of burden in a less familiar shape.
How Safeguard Helps
Safeguard parses Fulcio certificate extensions into structured metadata so your policy can enforce fine-grained rules about which identities are acceptable for which artifacts, rather than just matching the certificate SAN. We track the OIDC provider, workflow, repository, event trigger, and ref for every keyless signature we verify, and surface anomalies when a new identity signs an artifact that was previously signed by a known one. Customers running private Fulcio deployments configure their trust root once and Safeguard uses it for all verifications without requiring changes at each consumer. For audit-heavy environments we retain the full certificate chain and Rekor entry alongside the artifact, so historical verifications remain reconstructable years after the certificates themselves expired.