Re-publishing under a new signing identity breaks every consumer's pinned trust — when is that worth it?

## The decision, stated properly After a publishing identity is compromised you choose between two paths, and the difference is who pays. - **Keep the identity, replace what is underneath it.** The name, namespace and trust anchor consumers configured stay valid; you replace the credential or key material and re-establish control of the account. Consumers do nothing. This is by far the cheaper outcome downstream. - **Move to a fresh identity.** A new key, a new certificate subject, sometimes a new namespace. Every consumer with an explicit trust configuration must be told, must understand, and must act. You cannot check whether they did. The technical question that decides it is narrow: **can the old identity be reclaimed, and can you prove it?** If the account is recovered, every credential in scope is cut, the access path is closed, and you can bound when the compromise began, keeping the identity is defensible. If the attacker retains something you cannot revoke where it matters — key material held by consumers as a pinned anchor, with no revocation channel those consumers actually consult — then the identity is permanently poisoned no matter what you do at the registry, and moving is forced. ## Why unverifiable adoption is the real cost Rotation is easy to announce and impossible to confirm. Downstream you have a long tail: consumers who pinned once and never revisited, vendored copies, internal mirrors that re-sign, air-gapped installations, and platform teams whose verification policy is a config file nobody has opened in a year. The typical failure is not that they trust the wrong key — it is that verification starts failing and someone quietly turns it off to unblock a release. A rotation that converts strict verifiers into non-verifiers has made the ecosystem less safe than leaving the old identity in place would have. This is why trust models that anticipate rotation matter: where the anchor a consumer pins is something that can delegate to new signing material, rotation is a routine signed update rather than a manual migration. Where the anchor is the signing key itself, it is not. Which model you are in is decided long before the incident, and it is the single biggest determinant of how expensive this decision is. ## Managing the cutover you chose If you move, run it as a migration rather than a switch: - **Dual-publish for a stated window.** New releases under the new identity; keep the old artifacts served, unchanged and verifiable, so history remains auditable and nobody's forensic work is destroyed. - **Publish a firm end date** for the old identity, and hold it. An open-ended transition never completes. - **Track adoption by proxy.** You cannot enumerate consumers, but you can watch pulls of old versus new artifacts and lean on repackagers and distributions, each of which converts many consumers at once. - **Name the large consumers you can reach** and give them a contact. A regulated consumer that cannot move for six months needs a plan, not a deadline: an explicit extension, a named owner on both sides, and agreement on what they do in the interim. ## When the artifact is data, not code Some artifacts have no patch semantics. Model weights pushed with a stolen registry credential are the clean example: there is no fix to backport into the file, consumers pull by digest, and inference clusters may have the weights cached locally and loaded in memory. The remediation is therefore expressed entirely in digests — an explicit list of digests to refuse and the replacement set to accept — plus instructions to purge local caches, because a running cluster will not re-fetch on its own. The asset at stake is also different from the usual one: the loss is integrity of a model your customers make decisions with, and trade-secret value if the attacker also pulled what they overwrote. Frame the notice accordingly, and expect downstream consumers to ask you to prove the provenance of the replacement weights, which means the replacement must be produced under the new identity with a build record you can show. ## What a lead is being tested on The interviewer is not looking for "rotate everything immediately". They are looking for someone who can say who bears each cost, who can name the condition that forces the expensive path, who plans for consumers who cannot follow, and who understands that a control everyone disables under pressure is not a control. The good answer also closes the loop back to design: after this incident, is the trust anchor consumers hold still the raw signing key, or have you moved to something that lets you rotate without asking thousands of strangers to edit a config file?