A reviewer says the estate is fully patched, so NTLM relay is fixed. Why is that wrong?

## Separating a defect from a property The useful distinction to draw for the reviewer is between a vulnerability and a design property. A vulnerability is behaviour the designers did not intend: a boundary that can be crossed, a value that is not checked, memory that is written past its end. A patch is the right instrument, because there is a correct behaviour to restore. Relay is not that. A challenge-response exchange is designed to convince a challenger that the answering party holds a key, and designed not to reveal the key. It succeeds at both. The property it lacks - a statement of intended audience that the far end verifies - was never in it. Restoring nothing restores that. This is why relay has been continuously exploitable for decades across estates that were entirely current on updates. ## What the patches did do, and why it looked like progress Two genuinely useful things have arrived as updates over the years, and both are narrower than the reviewer thinks. The first was removing a specific variant: reflecting an authentication straight back at the host that produced it, so a host would authenticate to itself and grant the operator its own privileges. That is a special case of the class, it was closed, and it stayed closed. The second is the ongoing removal or gating of individual features that can be used to make a host authenticate outward on demand. Each of those is a real reduction. But they are individually enumerated fixes against an open-ended input: the trigger is a feature that takes a location and then goes and fetches it, and that description covers document processing, print and scan destinations, remote administration calls, indexing, previewing and more. New triggers keep being found because the design pattern keeps recurring, so a fully patched estate is a snapshot of the triggers known so far, not a state of immunity. ## The second failure in the claim Even granting all of that, the sentence has a practical hole. The properties that actually end the technique - enforced session signing at the destination, channel binding, service binding - are configuration, not code. They exist in a patched estate; they are frequently off, or set to a permissive mode that accepts a missing binding value, because turning them on breaks something old. So the accurate rendering of *we are fully patched* is *we hold the capability to end this and have not enabled it*. Those are very different positions, and the second one is the one to say out loud in a review. ## How to make the point land Asking for the trigger inventory is a fast way to show the shape of the problem: which hosts in the estate can be made to authenticate outward, and to what. Nobody has that list, and the reason nobody has it is that it is not a list of bugs. Then reframe the question the reviewer should be asking: not *are we patched* but *which services that accept these identities will accept an authentication that names no audience, and what would it cost to make each of them refuse*. That also disposes of the neighbouring bad answers. Rotating the coerced account's password does nothing, because the password was never in play. Strengthening interactive sign-in does nothing, because the coerced principal is often a device or machine account that never signs in interactively. Encrypting the path does nothing, because the operator terminates the transport on both sides. The only levers are refusing at the destination and removing the protocol from the estate. ## The honest end state The class is retired in one of two ways: every service that accepts these identities refuses an authentication that is not bound to a channel and a service, or the protocol is no longer accepted anywhere. Both are programmes of work with a compatibility bill, and both are decisions somebody has to own. Neither of them arrives on patch day, and saying so clearly is the whole value of answering this question well.