Mandating signing and binding would end relay, but scanners on your segment cannot do it. How do you decide?

## The decision is not the one you were handed The question arrives as *devices versus security*, and answering it in those terms loses. Reframe it first. The property that ends relay is a destination property: the service that accepts the identity must refuse an authentication that does not state which channel and which service it was for. Nothing about that requires every device in the estate to be capable. It requires every *destination that matters* to be enforcing. Most of the fleet that cannot comply - scanners, cameras, old appliances - are clients. A non-compliant client does not weaken an enforcing destination; it just fails to authenticate to it. So the cost of enforcement is not a security risk at all, it is a list of broken workflows, and broken workflows have owners, values and alternatives. That is a conversation you can actually run. ## Enumerate destinations, not devices The useful inventory is short and nobody has it: which services in this estate accept these identities and grant something worth having. File services holding data. The directory, where a write can change who is privileged. Certificate enrolment endpoints, where an accepted identity can be turned into a durable one. Administrative interfaces. Each entry gets one column - does it refuse an unbound authentication today - and that table is the programme. The inversion matters for prioritisation. Enforcing on the destination that holds nothing buys nothing, however easy it is. Enforcing on the one where an accepted identity becomes a lasting one buys the most, however painful. Estate coverage percentages are the wrong metric here; the metric is whether any destination that matters is still open, because one is enough. ## Handling the device that genuinely cannot comply Sometimes the device is not just a client - it also needs to write somewhere that is on your enforcement list, and it cannot do the binding. Three levers, in order of preference. Shrink the principal. The scan account should have write to one location and nothing else: no group membership, no rights on any other service, no interactive sign-in. Then a successful coercion buys the operator write to that one location. This is the single most under-used control on this class, because the value of a relay is entirely the coerced principal's authorisation, and that is something you set. Shrink the reach. If the device is only ever meant to talk to one destination, it does not need to be able to reach the directory or the enrolment endpoints at all. This is somebody else's discipline to design, but naming it as a requirement is yours. Shrink the time. An exception with no end date is a permanent decision made quietly. Tie the enforcement date to the fleet's replacement cycle - which exists, and has a budget line - so the exception is a bridge rather than a state. ## Getting the decision owned The part that is genuinely principal work is making the refusal explicit and priced. The owner of the scanning function may quite reasonably decide that scan-to-share is worth more than an open destination for eleven months. That is a legitimate call, and it is not yours to make alone. What is yours is stating the price in the terms the technique actually has: while this destination does not enforce, any host on the estate that can be provoked into authenticating outward becomes that host's rights on this destination, at no cost to the operator and with no dependence on a weak password. Written down that way, decisions go the other way more often than they do when the ask is phrased as a hardening standard. Be prepared for the counter-offer of compensating controls. Rotating the device account's password is not one; the password is never in play. Restricting the device's own signing behaviour is not one; the coerced leg is disposable. A permissive binding mode is not one; if a missing value is accepted, the property is absent. Saying clearly which proposals are not compensating controls is more valuable than accepting a weak one to close the item. ## What good looks like A year later, the answer you want to be able to give is not *the estate is compliant*. It is: every destination on the short list refuses an unbound authentication; the two exceptions are named, each has an owner who signed it, each has a date tied to a replacement already in a budget, and each exception's blast radius is one account with rights to one place. That is a defensible position under organisational constraint, which is what this question is really testing.