Your team replaced a long-lived signing key with keyless signing — what did that move custody to?

## The move is real, and so is the bill Dropping a long-lived signing key is usually the right call. The thing you were failing to guard — a secret with an indefinite lifetime, an unclear list of holders, and a rotation date nobody hit — is genuinely gone. But signing is an assertion of identity, and identity has to come from somewhere. When it stops coming from possession of a key, it starts coming from an identity system. That system is now the custodian. ## The three new custodians **1. Whoever can cause an identity to be minted for your workload.** This is the big one, and it is much wider than people expect. In a CI setting the identity token asserts machine facts: this issuer, this repository, this workflow, this branch or environment. Everyone who can influence those facts can influence who gets to sign: - an administrator of the CI provider's organisation or tenant, who can change org-level settings, add repositories, or alter which identities are permitted; - anyone able to merge a change to a workflow that runs with the release identity; - anyone who can modify the mapping between a repository or environment and a release identity; - the managed CI provider's own operators, since the token is minted by their service. That last one deserves saying out loud. A fintech that moves to keyless signing has, in effect, decided that the administrators of its CI provider's organisation — and the provider's own operators — are trusted to produce release signatures. Sometimes that is an entirely reasonable trade, because the same people already controlled the build. But it must be a decision, not a surprise, and the compromised-operator case is a genuine threat model: a compromised managed-CI operator does not need to steal anything from you, because they can mint the credential. **2. The certificate authority.** Verifiers are configured to trust the CA's root. That root is now the anchor of your whole scheme, and its compromise is broader than the compromise of any one signing key: it does not just forge your signatures, it forges everyone's. **3. The transparency log.** The log is what lets a certificate that lived for minutes still support verification a year later, so it sits in the verification path. It is also the only place a bogus issuance under your identity becomes visible. Note the direction carefully: **the log is detective, not preventive.** It does not stop a certificate being issued; it makes issuance discoverable to someone who looks. If nobody monitors entries for your identity, the log is only useful after an incident, as evidence. ## What this changes operationally | Old custody problem | New custody problem | | --- | --- | | Who holds a copy of the key? | Who can get a token minted as us? | | When was it last rotated? | Who has admin on the CI org and the issuer configuration? | | Is it on an HSM? | Is anything watching the log for certificates under our identity? | Concretely: - **Treat CI organisation admin membership as key custody.** Changes to it deserve the scrutiny a key ceremony would get: named holders, review, an audit trail. - **Protect the path to the release identity.** Which workflows can assume it, and what review a change to those workflows requires, is the equivalent of who can open the safe. - **Monitor the log for your own identity.** This is the step almost nobody does by default, and it is the only detection available. Without it, the answer to "has anyone ever signed as us?" is "we have no idea, but the evidence exists if we ever go looking." - **Record the trust decision.** Write down that the identity provider and CA are now in your trust boundary, and who accepted that risk. ## The honest interview answer Candidates who say keyless "removes the key management problem" and stop there have read a landing page. The strong answer is: it removes *storage* custody and replaces it with *issuance* custody, which is generally a better trade because issuance is short-lived, logged, and tied to identities you already administer — but only if you actually administer them, watch the log, and know that the CA and issuer are now inside your trust boundary. The question an interviewer is really asking is whether you can name the new asset. It is the ability to obtain a credential in your name, and it usually lives in an access-control group, not a vault.