When would you run a private Fulcio bound to your corporate IdP instead of the public instance?

## The decision, stated honestly Both options give you the same cryptographic story: a short-lived certificate binding an ephemeral key to an identity asserted by an OIDC issuer. What differs is **who operates the authority, which issuers it trusts, and who can see the result**. This is an operating-model decision, not a security-strength decision, and it should be argued that way. ## Reasons that genuinely justify going private **Signer identities are sensitive.** Certificate issuance on the public instance is itself published to a public log. That means the signer's email address, or the path to an internal repository and its release pipeline, becomes world-readable. For many organisations that is fine and even desirable. For others — a small maintainer team whose personal addresses would be exposed, or a company whose internal project names leak roadmap information — it is disqualifying. This is usually the deciding factor. **Isolation.** A build environment with no route to the public internet cannot reach a public authority at signing time. A private instance inside the boundary is the only option. **Identities only your directory can assert.** If the identities you want in certificates are internal principals that no public issuer knows about, the authority has to trust your issuer, and that means running it. **Regulatory constraints** on where trust roots and identity data live can force the same conclusion. ## What you are signing up to own **A certificate authority root.** Its private key needs real protection — hardware custody, split control, an audited ceremony — and it is now among the most consequential keys in the company. The irony of adopting keyless signing to eliminate key custody and then owning a CA root should be stated out loud in the decision document, not discovered later. **Availability at exactly the wrong moments.** Issuance sits on the critical path of every release. If the authority is down, nobody ships. That means an on-call rotation, a target availability, and a break-glass story that does not amount to "disable signing." **Trust root distribution.** Every verifier must be configured to trust your root. Inside your estate that is a fleet-management problem. If anyone outside your organisation consumes your artifacts, it is a customer-onboarding problem — and it is the reason many organisations that could run a private instance choose not to. ## The organisational cost people miss Binding the authority to your corporate identity provider makes **identity lifecycle management a release-integrity control**. That sounds abstract until you work an example. A contractor leaves. Their directory account is scheduled for removal, but the offboarding ticket sits for three weeks — a completely ordinary latency in a large organisation. For those three weeks their account still authenticates, still yields a valid token, and therefore still yields valid signing certificates. If they sign a release in that window, the certificate is legitimate in every respect: correct issuer, correct identity, correctly issued. Nothing in it is anomalous, because nothing about it *is* anomalous. The failure happened in a human process weeks earlier. With long-lived signing keys the equivalent risk was "did they copy the key before they left?" — bad, but bounded by whether the key changed afterwards. Here the risk is continuous for exactly as long as the account survives. The controls that address it are not cryptographic: - an offboarding SLA that is measured and reported, with signing-capable identities on the fast path; - narrowing the set of identities that can sign at all, so most departures are irrelevant; - preferring workload identities for anything routine, so human signing is a rare exception rather than the norm; - reviewing the record of what was signed and by whom, so an unexpected signer is noticed rather than merely possible. That last point matters because there is no revocation to fall back on. Certificates expire on their own, and there is nothing to pull after the fact. ## How to argue it Write down which of the four triggers actually applies. If the answer is only "it feels safer to run our own," that is not a trigger — it is a preference that buys you a CA root, an availability commitment and a trust-distribution programme in exchange for nothing you did not already have. If the answer is "we cannot publish signer identities" or "our release builds have no internet route," the case makes itself, and the work then is to name an owner for identity lifecycle who understands that their ticket queue is now part of the release pipeline.