A device you can update is a device an attacker can too.
The ability to update a device in the field is also the attacker's way in. A firmware root of trust ensures only authentic code runs, that an update cannot be forged or silently rolled back to a vulnerable version, and that the whole chain begins in silicon an attacker cannot rewrite.
DomainSecure systems, device integrity
PlatformsFaststream Secure
ScopeImmutable root to verified update
Binding constraintOnly authentic firmware runs — from an unwritable root
DisclosureRepresentative programme; customer not named
CONTEXT
Where this started.
A connected device that accepts firmware updates has, by definition, a path to change the code it runs. That path is exactly what an attacker wants: forge an update, downgrade to a version with a known flaw, or replace the firmware outright, and the device is theirs. Field-updatability and security are the same door.
Closing it means a chain of trust that starts from something immutable. An unwritable root in silicon verifies the first code it loads; each stage verifies the next; updates are cryptographically signed and checked before they run; and anti-rollback stops a signed-but-old, vulnerable image from being reinstalled. Break any link and the chain is decorative.
So the system is built as that chain: an immutable hardware root, verified boot stages, signed updates with rollback protection, and key handling that assumes the device itself may fall into hostile hands.
CHALLENGES
4 problems, named.
Stated before any of them had an answer.
01
Update is attack surface
The mechanism that lets you fix a device lets an attacker change it; the update path has to be authenticated, or it is a back door.
02
Rollback is a real attack
A properly signed but old firmware with a known vulnerability can be reinstalled unless anti-rollback forbids it; signing alone is not enough.
03
The root must be immutable
A chain of trust anchored in writable memory can be rewritten; the root has to live in silicon an attacker cannot change.
04
Keys in hostile hands
The device may be physically captured; key storage and handling have to assume the attacker holds the hardware.
ARCHITECTURE
How it was built.
Signing the firmware is one link. The chain holds only if the root is immutable, every stage verifies the next, and a signed-but-old image cannot be rolled back in.
CONTRIBUTION
What Faststream did.
The scope of the work, rather than a capability list.
Immutable hardware root — anchoring the chain in silicon an attacker cannot rewrite, not in writable memory.
Verified boot chain — each stage cryptographically checking the next before handing over control.
Signed updates — firmware images authenticated before they are allowed to run, closing the forge path.
Anti-rollback — refusing a signed but outdated image so a known-vulnerable version cannot be reinstalled.
Key handling — storage and use that assume the device may be physically captured.
Recovery path — a way to recover a device safely without opening a hole or bricking it.
WHAT WAS HARD
The parts that consumed the schedule.
Rarely the subsystem that sounds difficult.
01
Anchoring in immutability
The chain is only as strong as its root; getting a genuinely immutable, silicon-anchored root right is the foundation everything else depends on.
02
Closing rollback
Anti-rollback is the link teams most often miss; a correctly signed old image is a valid attack, and forbidding it without bricking legitimate downgrades takes care.
03
Keys under capture
Designing key storage and use on the assumption that the attacker holds the hardware is a stricter, harder discipline than trusting the device.
04
Recovery without a hole
A recovery mechanism has to save a bricked device without becoming the very bypass an attacker uses; that balance is delicate.
OUTCOME
What resulted.
Only authentic code runs
A boot chain that refuses any image it cannot verify, from an immutable root.
Updates that can't be forged
Signed firmware checked before execution, closing the update as an attack path.
No silent rollback
Anti-rollback preventing reinstatement of known-vulnerable versions.
Secure under capture
Key handling that holds even if the device is physically in an attacker's hands.
Confidentiality
Customer projects are presented at property, capability, outcome and integration level. Customer names, internal architecture, confidential deliverables and commercial terms are not disclosed. Where a detail would identify a customer it is omitted rather than approximated. More is available under a non-disclosure agreement, within the limits the customer has agreed.
Why does field-updatability create a security problem?
Because the mechanism that lets you update a device is a mechanism to change the code it runs, and that is exactly what an attacker wants. If updates are not authenticated, an attacker can forge one; if old versions can be reinstalled, they can downgrade the device to a version with a known vulnerability. Being able to fix a device in the field and being able to compromise it are the same capability, so the update path has to be secured or it becomes a back door.
02
What is a root of trust and why must it be immutable?
A root of trust is the starting point of a chain in which each stage verifies the authenticity of the next before running it. It must be immutable — anchored in silicon that cannot be rewritten — because if the root itself can be changed, an attacker simply replaces it and the entire chain built on top verifies their code instead of yours. The strength of the whole system rests on that first link being unwritable.
03
Isn't signing the firmware enough?
No — signing is necessary but not sufficient. A signed image proves authenticity, but a correctly signed old image with a known flaw is still a valid attack if the device will accept it, which is why anti-rollback is essential. And signing means nothing if the root that checks the signature is not immutable, or if the signing keys can be extracted from a captured device. The security is the whole chain — immutable root, verified stages, signed updates, rollback protection and protected keys — not any single link.