Why is holding an identity-signing key different from stealing a password?

## The two halves of an identity system Every federated or domain identity system splits into an **issuer** and a set of **verifiers**. The issuer is the component trusted to say who somebody is: a domain controller in Kerberos, an identity provider issuing SAML assertions, an authorisation server issuing OpenID Connect ID tokens. A verifier is anything that consumes the result: a file server, a partner's SaaS tenant, an internal application. The verifier does not know your password and never sees it. What it knows is a key, and its rule is simple: *anything signed by that key is a true statement about identity*. That rule is the whole point of the design, and it is also the whole exposure. ## The password path A stolen password is a secret **about one principal**. To use it you must present it to the issuer, and the issuer then does work on your behalf: it compares the secret, checks whether the account exists and is enabled, applies whatever second factor and sign-in conditions are configured, and only then produces a ticket, assertion or token. Every one of those steps is a place the attempt can fail. Crucially, an authentication **happened** — someone tried, and something decided. ## The key path A signing key is not a secret about a principal. It is the instrument of issuance. Holding it, the forger produces the artefact directly and hands it to a verifier. The issuer is never contacted, so: - there is no secret to compare, and none is required; - the second factor and sign-in conditions live at the issuer, so they never engage; - account state — disabled, expired, deleted — is usually never consulted, because the verifier trusts the assertion rather than querying the directory; - there is no failed attempt, no lockout and no rate limit, because there is no attempt. The forger also chooses more than *who*. Group and role claims travel inside the signed artefact, and most verifiers consume them as asserted. So the forger writes both the identity and the entitlements that come with it. They also choose the validity window, which is why "we use short lifetimes" is not a defence against someone who can sign at will — they simply write another one. ## Nothing was proven, so nothing was checked This is the sentence to carry into an interview. A forged identity is not an authentication that slipped past a control. It is the **absence** of an authentication: no principal proved anything anywhere, and the first thing that happens in the whole exchange is a verifier accepting a well-formed, correctly signed identity. Everything an organisation built to make authentication hard sits at the issuer, and the issuer was skipped. ## The remedies are not comparable Changing a password is a one-account change that takes seconds and is entirely within your control. Replacing a signing key requires every verifier that trusts it to accept new key material. Some fetch it automatically, some have a certificate uploaded by hand, and some belong to other organisations. Until they all move, the old key is still accepted — which is why key replacement is a programme with a schedule, not a change window. A related trap: resetting the impersonated user's password does nothing at all. The forged artefact never referred to that secret, so changing it changes nothing about whether the artefact validates. ## The width question sits on top of this Once you accept that holding a signing key means authoring identity rather than proving it, the only remaining question is *who accepts what this key signs* — one service, every service in a realm, or every organisation federated to the issuer. That is a question about the key's position in the trust graph, not about the privileges of any account.