A camera firmware change cut a physical evasion finding's success rate to near zero — do you close it?

## What actually changed A physical artefact is fitted to a distribution of capture conditions: angles, lighting, reproduction, the resize to the model's input, the encode in between. When a camera vendor ships a new resolution default, a different encoder or a changed auto-exposure curve, they move that distribution. The artefact was an optimum for the old one, so its rate collapses. Nothing about the model changed. Its weights, its decision surface and its sensitivity along chosen input directions are identical. What changed is the mapping from a physical surface to the tensor the model receives. That distinction is the whole judgment, and getting it backwards — booking the firmware update as a remediation — is the failure mode this question exists to catch. ## Why it is not a control A control, for the purposes of a risk decision, has properties that this does not have: - **Chosen for a reason.** The vendor changed a default for image quality, bandwidth or storage. Security was not the objective, so no one weighed the security consequence of changing it back. - **Owned and monitored.** Nobody in your organisation watches the capture settings for drift. The next firmware update can revert them silently, and the first signal would be the attack working again. - **Uniform.** Camera fleets are not uniform. Older units, units on a deferred update ring, and units from a second supplier plausibly still present the old capture distribution, and the old rate with it. - **Costly to the adversary in a durable way.** Re-fitting an artefact to a new capture distribution costs the attacker printing and presentations — cheap, repeatable and unattributed. Their skill and their tooling carry over completely; only the artefact is thrown away. So the correct entry is: exploitability observed to have dropped on the updated units, cause identified as a capture-chain change outside our control, finding remains open, retest scheduled across the fleet and after firmware updates. ## The claim you can honestly make The direction of the evidence is narrow. "The attack no longer succeeds" establishes that **this artefact**, fitted against **the old capture distribution**, fails against **these updated units**, over however many presentations you ran. It does not establish that the model resists the attack class, that a re-fitted artefact would fail, or that the rest of the fleet is safe. Writing the smaller claim in the report is the professional move, and it is also what protects you when the number comes back next quarter. ## Where the decision actually is The organisational question is not whether to close the ticket; it is what to fund now that you know a physical evasion path exists against this reader. The options divide by who owns them: - **Controls that depend on the capture chain** — pinning capture settings, standardising the fleet, blocking vendor updates. These are brittle, they fight the vendor's roadmap, and pinning an old codec or resolution has its own security and quality costs. - **Controls you own that do not depend on it** — alerting on repeated failed reads from one lane in a short window (the low per-presentation rate forces the attacker to retry, which is the signal), a second independent check at the barrier, or human review of anomalous reads. These survive a firmware change because they do not reference one. - **Model-side hardening** — slower, measured against one condition set that the next capture change invalidates, and it costs clean read accuracy. That cost is not evenly spread: the reads it degrades are the marginal ones — dirty, damaged, unusual or poorly lit markings — so the people who absorb the false rejections are legitimate users with the worst-conditioned inputs. Somebody has to decide that trade explicitly rather than discover it in a support queue. A lead is expected to say which of these they are buying and why, and to be able to defend not buying the first category despite it appearing free. ## The organisational habit underneath This is a specific instance of a general rule worth stating in an interview: **a drop in a measured attack success rate is evidence about the measurement, not automatically about the system.** The same reasoning applies when a scanner update makes a finding stop reproducing, when a retrained model happens to break an artefact, or when a proxy change alters an input pipeline. Ask what moved: the adversary's cost, or your visibility into it. Only the first is a remediation.