Fulcio is used to issue short-lived signing certificates after verifying an identity claim for a build or release process. A practitioner can use it so signatures are tied to a trusted workload identity rather than a long-lived private key. Defenders should ensure certificate issuance is limited to approved identities and expected workflows.
Fulcio as a certificate issuer in a build pipeline
In practice, Fulcio sits in the signing path for software build and release systems: a builder proves who it is, Fulcio issues a short-lived signing certificate, and that certificate is then used to sign the artifact or attestation. The practical value is that trust follows the workload identity at issuance time, not a static private key sitting on disk.
This changes how teams think about signing. The control point is no longer “whoever has the key,” but “who can successfully present an approved identity claim from the expected workflow.” That makes Fulcio useful for CI/CD systems, ephemeral builders, and other automation that should sign on behalf of a trusted process rather than a long-lived human-controlled credential.
What a Fulcio-based workflow usually looks like
A typical pattern is: the build system authenticates with an identity provider or workload attestation, requests a certificate, signs the release artifact, and then discards the certificate when the job ends. The certificate is short-lived by design, so compromise windows are narrower than with reusable signing keys.
For defenders and platform owners, the important operational detail is that Fulcio only helps if the identity assertion is trustworthy and tightly scoped. If an attacker can impersonate the approved workflow, steal the upstream token, or trigger issuance from an untrusted job, they may obtain a valid signing certificate for malicious output.
In a supply chain program, Fulcio is usually paired with provenance and verification controls, so downstream consumers can check that the signature came from the expected identity and that the artifact was built under the expected conditions. For a broader view of the provenance and signing context around this pattern, see the Software Supply Chain Security Guide.
What practitioners should validate before relying on it
Before adopting Fulcio for production signing, validate three things: the identity source is strong enough to prove the build origin, certificate issuance is limited to the correct jobs or repositories, and consumers actually verify the resulting signatures and attestations. If any of those pieces is loose, the certificate becomes a high-trust token for the wrong actor.
Also check the failure mode when the issuer is unavailable. Teams sometimes discover that signing is tied too tightly to a live dependency, which can stall releases unless there is a clearly governed fallback. That fallback should be more restrictive, not more permissive, than the normal path.
If you want the surrounding control set for access, authentication, and secure release handling, NIST SP 800-53 Rev 5 Security and Privacy Controls is the broad control catalog most teams map this workflow to, while SLSA is the more specific supply-chain integrity model for build provenance and release trust.
Risk and Threat Considerations
The main risk is not Fulcio itself, but misuse of the identity path that leads to certificate issuance. If an attacker reaches the approved build identity, they can potentially sign malicious artifacts with a certificate that downstream systems treat as trusted.
Failure mechanism: A weakly protected build token, overly broad workload trust relationship, or poor workflow scoping can let an unauthorized job obtain a valid signing certificate and produce trusted-looking output.
Impact: The result can be release compromise, malicious artifact distribution, and a loss of confidence in signature-based verification across the software supply chain.
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 addresses the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | SLSA — Supply-chain Levels for Software Artifacts | Fulcio supports build provenance and trusted release signing. |
| Recommendation — Use SLSA to require verifiable provenance for signed build artifacts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Fulcio issuance depends on tightly governed short-lived credentials and lifecycle controls. |
| IA-9 — Service Identification and Authentication | Fulcio issues certificates to workloads and build services, not just people. | |
| AC-6 — Least Privilege | Certificate issuance should be restricted to approved release workflows and identities. | |
| Recommendation — Manage build credentials as short-lived authenticators with strict lifecycle limits. Authenticate build services with workload-bound identities before issuing signing certificates. Limit certificate issuance to the minimum set of approved build identities. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Fulcio relies on trustworthy identity claims from non-human build workflows. |
| NHI-07 — Long-Lived Secrets | Fulcio is used to replace reusable signing keys with short-lived certificates. | |
| Recommendation — Harden the identity assertion path that authorizes certificate issuance. Replace durable signing secrets with short-lived, workflow-bound credentials. | ||
Practitioner Guidance
What to verify: Treat certificate issuance as a privileged action. Verify which workloads, branches, repositories, and runners are allowed to mint certificates, and confirm that the identity claim being asserted is the one you actually intend to trust.
Common mistake: Teams often secure the private key path but under-secure the identity proofing path. With Fulcio, the upstream claim is the control surface, so a strong certificate policy is only as good as the workflow identity behind it.
What good looks like: Short-lived certificates are issued only from expected automation, signatures are verifiable by downstream consumers, and no release path depends on a reusable signing secret that can be copied and reused later.
Practitioner takeaway: Fulcio is most valuable when you treat signing as an identity-verified, ephemeral workflow rather than a key management problem alone.