Before withdrawing a broker's old credential, what evidence shows nothing still presents it, and what will that evidence miss?

## What the cluster itself can tell you The withdrawal step is the only part of a swap that can break traffic, so it is decided on evidence. On a broker that evidence is close at hand, because the cluster authenticates every connection and writes down what it decided: - **Connection records** — who attached, when, from where, and with which mechanism. - **Authorization-decision records** — the principal the broker saw and what it was allowed or refused. - **The list of current connections** — who is attached right now, and on some platforms how long they have been. Read together over a window, these answer one question precisely: *what has authenticated recently, and as whom.* That is a narrower question than the one you actually want answered, and the gap between them is the whole subject. ## The distinguishability decision comes first If the replacement credential authenticates as the same principal as the old one, the records show a familiar name connecting and cannot say which of the two credentials produced it. The swap then has no readable finish line. So decide before issuing the replacement how the two will be told apart. Either the new credential yields a distinct principal that the records already name, or the cluster records something that separates them — which credential, or which issuer, was presented. What you cannot do is retrofit it: once both are in circulation under one name, the history you need was never written. ## Sizing the observation window The observation window has to be longer than the longest interval at which anything in the estate reconnects. That number is almost never set by a service: | Holder | Natural reconnect interval | In a one-week window? | |---|---|---| | A fleet redeployed by a pipeline | hours to days | yes | | A long-running writer restarted only for patching | weeks | sometimes | | A report or reconciliation job | monthly or quarterly | no | | A standby that starts on failover | never, until it is needed | no | Taking the deploy cadence as the window is the usual mistake, because it is the number everyone knows. ## What the evidence cannot show Records capture **presentations**, not **possession**. Every holder below owns a working copy of the old credential and contributes nothing to the records: - a scheduled job whose interval is longer than the window; - a standby or disaster-recovery deployment that is idle by design; - a machine image or template with a copy baked in, used only when a pool scales out; - a process that has been connected since before the swap began and has therefore not authenticated during the window at all — the most counter-intuitive one, because it is actively using the old credential while looking completely silent. That last case is worth saying out loud in an interview. On a broker, being in constant use and being invisible in the recent records are perfectly compatible, because the credential was checked once at connect and the connection has not ended since. ## Making the withdrawal survivable rather than certain Because the census can never be complete, the withdrawal is designed so that an unknown holder is an inconvenience: 1. **Withdraw during working hours**, deliberately, as its own change — never as the tail end of something else. 2. **Watch refusal records as the first signal.** After the withdrawal, a refused authentication naming a principal is exactly the holder the census missed, and it is far better information than a downstream timeout. 3. **Keep the reversal cheap.** Restoring acceptance of the old credential should be one action, not a re-issue. The unknown holder is expected; being unable to put the old credential back is what turns it into an incident. 4. **Force what you can.** Deliberately reconnecting the fleet inside the overlap window converts a large part of the unknown into evidence before you rely on it. ## Why this is a broker question and not a general one On a service where every request carries the credential, recent traffic is a near-complete census. A broker has the opposite shape: long-lived connections that authenticate once, a cluster shared across many teams so the holder list is not one team's to know, and batch or standby holders that are legitimately silent for weeks. The evidence is genuinely good and genuinely incomplete, and the senior answer is to say both — here is what the records prove, here is the class of holder they structurally cannot see, and here is why the withdrawal is designed to be undone.