Edge Security and Attestation

Definition

Attestation is a device proving what it is running. It matters because edge and IoT devices are physically accessible to people who may not be trustworthy.

The threat that distinguishes this domain

Physical access. An attacker can hold the device, open it, read its storage, attach a debugger and extract keys. Every assumption that holds in a data centre — that the hardware is trusted, that memory is private, that storage cannot be read — fails.

The mechanisms

Secure boot. Each stage of the boot chain verifies the signature of the next, rooted in immutable hardware. Prevents modified firmware from running, and is the foundation everything else rests on.

Hardware-backed key storage. Keys generated inside a secure element and never extractable. Without this, a key on a device is a key in the attacker's hands.

Remote attestation. The device proves to a server, cryptographically, what software it is running. The server can then decline to serve, restrict permissions, or trigger remediation.

Signed, verified updates, with rollback protection so an attacker cannot force a downgrade to a version with a known vulnerability.

Encrypted storage, tied to the hardware, so removing the storage yields nothing.

The architectural consequence

Never trust the device. Even with attestation, treat device-supplied data as untrusted input and enforce authorisation server-side. Attestation raises the cost of compromise; it does not eliminate it, and a design that treats an attested device as trusted has a single failure away from a fleet-wide problem.

Practically: least privilege per device, server-side validation of everything, anomaly detection on device behaviour, and a revocation path that works.

The update problem

Updates are simultaneously the primary security control and the largest operational risk. A bad update to a fleet you cannot physically reach is unrecoverable. So:

• Staged rollout with verification at each stage.
• A/B partitions so a failed update reverts automatically.
• A recovery path that survives a failed update.
• Rollback protection, so reverting cannot be weaponised.

Failure scenarios

• Keys extractable from storage.
• Unsigned updates, allowing arbitrary code.
• No rollback protection, permitting a forced downgrade.
• Device assertions trusted by the server.
• A bad update with no recovery, bricking a fleet.

Interview question

"An attacker has physical possession of one of your devices. What should they be able to obtain, and what protects the rest of the fleet?"