Which is wider: a stolen service key, a realm ticket-granting key, or a federation signing key?

## Rank by acceptors, not by privilege The instinct is to rank key losses by how powerful the account sounds. The right axis is different: **who has been configured to accept what this key signs**. That set is the blast radius, and it is a property of the trust graph rather than of any account's permissions. | Key held | Identity can be forged to | Bounded by | |---|---|---| | One service's own key | That single service | The service itself; the domain never participates | | The realm's ticket-granting key | Every service in the realm | The realm edge | | The federation signing key | Every relying party that trusts the issuer | Nothing you administer | ## One service's key When an adversary holds the key belonging to a single service, they can present that service with a credential it validates using its own key. The consequence people miss is that the domain's issuing infrastructure is not involved at all: there is no exchange with a domain controller to be seen anywhere, and no domain-side decision to be made. The reach, though, is exactly one service. If that service is a print queue, this is a small problem. If it is the finance database, it is a large one with a small radius, which is a different shape of problem from a wide one. ## The realm's ticket-granting key The key that signs the credential every service in a realm accepts sits one level up. Holding it, an adversary can be any principal to any service in that realm, with any group membership, for as long as they like. This is the loss people usually mean by `domain compromise`, and its remedy is famously awkward: the key is embedded in a running directory service, so replacing it is disruptive and has to be done carefully. But note the bound: it is the realm. Services that federate to a separate issuer, and other organisations, are not in scope simply because this key was lost. ## The federation signing key The widest loss is the key an issuer uses to sign identity for parties **outside** the estate. Every relying party configured to trust that issuer will accept identity signed with it: your own SaaS tenants, your customers' tenants where you are the identity source, partner applications, and integrations added over the years by teams that have since dissolved. Three properties make this qualitatively different from the realm case: 1. **It crosses an administrative boundary.** You cannot patch, rebuild, isolate or re-image the far side. You can only ask, and sometimes you can only ask nicely. 2. **The acceptor set is often unknown.** Few organisations hold a complete list of who trusts their issuer, so the blast radius cannot be stated precisely, let alone bounded. 3. **Replacement requires cooperation.** New key material has to reach every relying party, some of which fetch it automatically and some of which need a human to upload a certificate during a change window they control. ## Why the single label is wrong An adversary who has been in the estate for a year and holds all three keys is described identically by the label `domain compromise`, and that label is what gets carried into a briefing. It hides the only question that matters for scope: does the reach stop at one service, at the realm edge, or on the far side of a trust boundary? Being able to say *which* key was held, and therefore *who* accepts what it signs, is what separates a candidate who has thought about this from one who has memorised a term. ## A caveat worth stating Width is not the same as value. A single service key that reaches the crown-jewel system may matter more than a federation key trusted by a handful of low-value applications. Rank by acceptors first because that is the part people get wrong, then weigh what those acceptors hold.