Image verification on in-store appliances with no cluster control plane — where does the check run?

## When there is no seat, you do not get to choose one The usual discussion assumes an orchestrator whose creation path you can hook. Retail appliances, kiosks, industrial gateways and similar fleets frequently have no control plane in the path at all: an update mechanism pushes images, a local runtime pulls and starts them, and the device may be offline for hours or days. That removes two of the three seats. A pipeline gate still exists upstream and still catches mistakes, but it is far from execution and covers only what your pipeline shipped. The only enforcement point between a bad image and a running process is the **runtime's own pull-time policy on the device**. ## What that seat genuinely gives you It is worth having, and it is worth being exact about the threat it closes: - **A tampered or substituted image** served by a compromised registry, a mirror, or an on-path attacker on the store network is refused, because the content will not match a signature made by an accepted identity. - **Operational mistakes** — an unsigned build, an image from an unexpected source, a stale artifact promoted by accident — are refused close to the point of harm. - It works **offline**, which matters here, provided the material it needs is local. ## What it cannot give you, and why An enforcement point is only a boundary against parties who cannot modify it. On a device somebody can open, that condition fails for the person holding it: they can edit the policy file, install their own trust root, downgrade the runtime configuration, or bypass the runtime and start a process directly. Nothing cryptographic repairs this, because the cryptography is being evaluated by software the adversary controls. This is the single most important thing to say in an interview about edge enforcement, and the most common thing to get wrong. Local verification protects the device's owner from a **remote** attacker. It does not protect the owner from the **holder** of the device. ## Where the real boundary goes instead Since a local check cannot constrain a local adversary, move the consequential decision to something the adversary does not control — a service: - **Attestation-gated credentials.** The device proves its state (measured boot, expected runtime configuration, expected image identity) to a remote service, and the service issues short-lived credentials or unlocks a sensitive scope only if that proof holds. Now the refusal happens somewhere the holder cannot edit, and the local check becomes an input to it rather than the boundary itself. - **Anchoring the root in hardware.** A trust root in hardware-backed or verified-boot-protected storage raises the effort of tampering from editing a file to defeating the platform's boot chain. It does not make the device tamper-proof; it makes tampering expensive and, ideally, detectable. - **Blast-radius reduction.** Device-scoped credentials, no shared keys across the fleet, no ability for one appliance to affect another, and sensitive functions kept behind the service rather than on the box. A compromised appliance should cost you that appliance. - **Detection.** Fleet inventory of what image digest each device is actually running, reported centrally, so a device that quietly stopped matching the fleet is visible. This is detective, not preventive, and here it does much of the useful work. ## The failure mode you own On this fleet, refusal has a business cost that outweighs the theoretical one. A payment terminal that will not start because a check could not be satisfied is an outage in a store with customers in it, caused by you rather than by an attacker. Two design choices follow: - **Refuse updates, not startups.** Enforce hard on *installing* a new image, where a refusal means the device keeps running the last good version. Be far more conservative about a check that blocks starting software that is already installed and previously verified. - **Plan for long-lived material.** Devices that are offline for days cannot fetch fresh revocation or identity data, so the material must be long-lived — and long-lived material is exactly what makes revocation slow. That tension is real and does not have a clean answer: you buy back some of it with an update channel that can be reached reliably and with attestation-gated access on the service side, so that a device you can no longer trust loses its ability to do anything valuable even if it keeps running. ## What a good answer sounds like Name the seat (runtime, at pull), name the threat it closes (remote and registry-side tampering), name the one it does not (the holder), then move the consequential boundary to a service via attestation, and finish with the availability decision about what the device does when verification cannot be satisfied. That sequence shows you understand that a choke point is only as strong as the party who controls it.