A compromised OIDC provider or Fulcio could issue certificates for identities that never asked for them. Sigstore's design answers with a public log: certificates must be published to be trusted, so misuse is detectable, provided someone is watching the log.
The trust chain in one line
Per Sigstore's security documentation, Fulcio treats a valid OIDC token from a trusted provider as proof of identity, and then issues a short lived certificate. Rekor records signatures in an append only log. A TUF trust root distributes the keys clients need to verify both.
Failure scenarios
| What fails | Possible effect | What limits it |
|---|---|---|
| An OIDC provider is compromised | Fulcio may issue certificates to the wrong party | Certificates must be logged, so abuse leaves a trace |
| Fulcio is compromised | It might issue unauthorised certificates | Clients should not trust certificates missing from the log |
| Rekor misbehaves | Entries or timestamps could be wrong | Entries can be verified cryptographically, and signed tree heads are kept as evidence |
| A signer's own account is taken over | Legitimate looking signatures from your identity | Detection depends on watching for unexpected signing |
The docs put it directly: such certificates are useless unless they are published to the certificate transparency log, so the compromise can be detected. They also state that Fulcio does not monitor that log itself, and users are responsible for monitoring.
The part that depends on you
A transparency log only helps if someone reads it. The documentation says that without third party monitoring, misbehaviour by Rekor or Fulcio could go unnoticed. That points to a practical task:
- Decide which identities should ever sign your artifacts.
- Watch the log for entries under your identities that you did not make.
- Alert and investigate quickly, since certificates are short lived and the window is short.
- Pin your verifiers to exact identity and issuer, so a stray valid certificate for another identity does not pass.
On timing, the docs note that log timestamps are hard to forge over the long term, but short windows are more exposed to a dishonest log operator.
What verifiers can do today
- Require both certificate identity and issuer.
- Refuse certificates not backed by a log entry.
- Keep trust roots current through TUF updates.
- Use narrow identities, such as one workflow path in one repository, rather than a whole organisation.
What this does not cover
If an attacker controls your build workflow, they can legitimately obtain a certificate for it. Keyless signing proves which workflow signed, not that the workflow did only what you intended. That is a source and pipeline security problem.
Where Safeguard fits
Safeguard's asset discovery helps you know which pipelines and repositories exist, and policy gates help constrain what they can release.
Quick check
Does keyless signing remove the need for monitoring?
No. It shifts the risk from stolen keys to stolen identities and makes monitoring of the log the key control.
Who monitors the log?
The Sigstore docs say users are responsible for it, since Fulcio does not monitor the certificate log itself.
Sources
Last reviewed: 19 October 2026.
