Fulcio certificates expire in about ten minutes — what does that window protect, and what does it not?

## Two different security properties, routinely conflated When people first meet short-lived signing certificates, they read the tiny validity window as a containment measure — as if a compromised signer were somehow limited to ten minutes of damage. That reading is wrong and it is worth dismantling carefully, because the correct reading changes where you spend your defensive effort. The window is about **custody of the signing key**. It is not about **who is allowed to sign**. ## What the window genuinely gives you **No stored key.** The private key is generated in memory for a single operation and discarded. There is no key file on a build machine, no key in a secret store that a pipeline can read, and no key in a backup. An attacker who lands on the build host after the fact finds nothing worth taking. **No rotation programme.** Long-lived signing keys need scheduled rotation, and rotation is where organisations quietly fail: the calendar entry slips, the key outlives the team that owned it, or rotation is skipped because it would break consumers. A key that lives for seconds rotates by construction. **No revocation infrastructure.** This is the underrated one. Revocation for long-lived certificates is a genuinely hard distributed-systems problem: publishing revocation state, getting verifiers to check it, deciding what to do when the check fails. Certificates that expire before anyone could plausibly act on a revocation make the entire question moot. "Revoke it" is replaced by "it already expired." **A tightly bounded window of key misuse.** If an ephemeral key somehow leaked mid-operation, it is useless once the certificate expires. That is real, but it is also the least valuable of the four, because it is not the attack anyone actually runs. ## What the window does not give you **It does not stop impersonation.** Consider a build job's OIDC token exfiltrated by a malicious dependency executing during that build. The attacker does not need to steal a signing key — they need the *identity*, and they now have it. Every time they want to sign something, they present the token, receive a fresh certificate, and sign. Ten minutes later they do it again. Expiry imposes a round trip, not a limit. **It does not shorten your exposure window.** Exposure lasts as long as the attacker can obtain tokens for that identity, which is a property of the identity provider and the environment, not of the certificate. A leaked token might be valid for minutes; a compromised human account might be usable for weeks. **It does not give you a revocation lever during an incident.** This is the operational sting. When you learn a signer was compromised, there is no certificate to revoke — the ones they used are long expired and the ones they will use next do not exist yet. Your only real levers are at the **identity layer** (disable the account, invalidate sessions, cut the pipeline's access to tokens, remove the trust in that issuer) and at the **verification layer** (stop accepting that identity). Anyone who plans incident response around revoking a certificate will find themselves with nothing to pull. **It does not invalidate what was already signed.** Expiry is not repudiation. A signature made while the certificate was valid remains verifiable indefinitely, because the signing event was recorded in the transparency log when it happened; the log, rather than the certificate, is what establishes that the signature predates expiry. Conversely, that means a compromise does not automatically un-sign the attacker's artifacts either — you have to decide, artifact by artifact, what was produced during the compromised period. ## Where this lands your defences Because the certificate lifetime is doing custody work rather than authorisation work, everything that would once have been "protect the signing key" becomes: - **Protect the identity.** Strong authentication on human signing accounts; a build environment where a malicious step cannot read the job's identity token; least privilege on which jobs can request tokens at all. - **Constrain what an identity can prove.** The narrower the identity a token asserts, the less an attacker who steals one can pass themselves off as. - **Detect after the fact.** Since prevention now rests entirely on the identity layer, the ability to notice a signature made under an identity that should not have signed becomes the safety net. ## The one-line version Short-lived certificates eliminate the key-management problem and replace it with an identity-management problem. That is a very good trade — key management fails silently and identity compromise at least has a detection story — but it is a trade, and calling the ten-minute window a containment control misrepresents which half of it you now own.