Who signs for a MAC bypass list of spoofable hospital devices when the team that owns them refuses the risk and the vendor forbids changes?

## Why the attestation is not being signed Three separate refusals hide behind an unsigned bypass list, and they need different answers. 1. **It is unreadable.** A list of addresses, ports and profile names is not a risk statement. Nobody signs what they cannot evaluate, and signing it anyway would be worse. 2. **It is somebody else's calendar.** An annual attestation invented by the security team competes with clinical work that has its own priorities. It loses. 3. **The device genuinely cannot change.** A vendor support contract that forbids modification, or a regulatory clearance tied to a validated configuration, means the imaging console will never run a supplicant no matter who signs. That is not obstruction; it is the actual constraint. ## Make the entry signable Rewrite every entry as one sentence about consequence, in the owner's language: > *The ceiling camera in Ward 3 is admitted by an address printed on its chassis. Anyone who reads that label and plugs a laptop into a ward socket reaches the video archive on one port, and nothing else. We are asking you to confirm the device is still yours, still there, and that this reach is what it needs.* That sentence is signable because it names an owner-visible fact, a concrete adversary action, and a bounded consequence. It also quietly reveals whether the authorisation is defensible — if you cannot finish the sentence with `and nothing else`, the entry is not ready to be attested, and the fix is yours, not theirs. ## Put renewal on their calendar, not yours A device team already touches every device on a cycle: preventive maintenance, calibration, contract renewal, inventory audit. Attach the confirmation to that event. The marginal cost is a field on a form they already complete, and the data is fresher than an annual sweep because it happens when someone is standing in front of the device. Where nothing exists to attach to, negotiate the smallest possible recurring artefact — a per-department list, reviewed at a meeting that already happens. ## Design the default, because most entries will never be actively signed The honest planning assumption is that a fraction of the list will be attested and the rest will be ignored. So decide in advance what silence means, and get that decision approved before you need it: - entries carry an expiry from the day they are created; - an unattested entry does not disappear, it **narrows** on a published schedule — first losing reach it has not used, and only much later losing admission; - every narrowing lands in an agreed window with the department reachable; - nothing is removed silently to make a point. This matters because the deadline exists to force a conversation, not to break a pump. A network team that causes a clinical outage to prove a governance point loses the programme and deserves to. ## Escalating what cannot be fixed For the imaging console under a contract that forbids modification, there is no technical answer available to you. The correct move is to stop pretending it is a network decision: - state the residual risk in the consequence sentence above; - name the compensating controls you have applied and what they cost; - name the ones you have not applied and what they would cost, in money and in whose time; - take it to a risk owner senior to both the network and the device team, with an expiry date so the acceptance is revisited rather than permanent; - record who accepted it. An unowned risk is the thing you are actually trying to eliminate; a *signed* risk with a bad answer is progress. ## Where the permanent fix lives, and it is not on the network The list grows because devices arrive with no admission story and the network team is told after purchase. The lever is procurement: a requirement that any device entering the estate either carries a credential or arrives with a named owner, a declared minimum reach, and an expiry on its exception. That is a contract and budget change, which is why it needs the same senior owner as the accepted risks — and why it is the argument worth spending your political capital on, rather than on the four thousandth attestation email. ## What a strong answer avoids Do not claim the device team must sign or be denied; you do not own clinical risk and that threat is not credible. Do not delete to force action. Do not treat a purchased tool as an ownership record — an inventory is not an accountability. And do not accept `it is on the list` as a substitute for a person.