What is secure boot and why does a security sensor need it?

Secure boot is a hardware-enforced check that the device only executes firmware signed by a trusted key, so a compromised or tampered image cannot run even if an attacker gains write access to flash. For a security sensor this matters because the device is a trust anchor in the home; if its firmware can be swapped, its alarms and its attestation are both meaningless.

How is secure boot different from Matter device attestation?

Matter device attestation — the DAC, PAI and PAA chain recorded in the DCL — proves a device's identity: that this physical unit is a genuine, CSA-certified product from a known manufacturer. Secure boot proves the firmware's integrity: that the code running is the code the manufacturer authorized. Identity and integrity are complementary, and one without the other leaves a gap, which is why a factory handles both.

What do signed firmware and OTA mean in practice?

Every firmware image the factory ships — including over-the-air updates — is cryptographically signed with a protected private key, and the device verifies the signature and the version before applying it, rejecting unsigned or downgrade images. This is what lets a brand push a fix to a fielded sensor without opening it, while preventing an attacker from pushing a malicious one.

Where do the keys live and who controls them?

The verification keys are burned into the device's secure storage at manufacturing; the signing keys are held by the manufacturer under access control and used only in the build and release pipeline. Because Shenan Yangguang builds and certifies the Matter security hardware we produce, we own that key hierarchy and the line discipline that provisions it — a brand relabelling finished goods does not.

How does this relate to cybersecurity law, such as PSTI, ETSI EN 303 645 and the EU CRA?

Secure boot and signed firmware are the technical backbone behind the software-update and no-default-credential duties those laws impose; a product that cannot verify its own firmware cannot meet a secure-update requirement. The legal marks — the UK PSTI Act, ETSI EN 303 645 and the EU Cyber Resilience Act — describe the duty; secure boot and signing are how a factory discharges it. The specific law timestamps and transition periods should be confirmed against the current regulation.

Secure Boot and Signed Firmware for Matter Security Devices: The Factory's Cryptographic Duty

What secure boot actually is

Secure boot is a hardware-enforced check that a device executes only firmware signed by a trusted key, so a compromised or tampered image cannot run even when an attacker gains write access to the device's flash memory. It is the floor under everything else: without it, every other security claim — the alarm logic, the network key, the attestation — sits on code that an attacker could quietly replace. For a security sensor the stakes are direct, because the device is a trust anchor inside the home; if its firmware can be swapped, its alerts and its identity are both hollow.

The check happens before any application code runs: the bootloader verifies a cryptographic signature against a key burned into the device's secure storage, and refuses to execute anything that does not match, which is why "secure" describes the enforcement and not merely the intention. A product that signs images but does not verify them at boot has theatre, not security, and that distinction is exactly what a factory that owns the silicon integration controls and a relabeller does not.

Secure boot is not the same as attestation

Matter device attestation — the chain of a Device Attestation Certificate, a Product Attestation Intermediate and a Product Attestation Authority, recorded in the Distributed Compliance Ledger — proves a device's identity: that this physical unit is a genuine, CSA-certified product from a known manufacturer. It answers "who made this." Secure boot answers a different question: "is the code running the code the manufacturer authorized." The two are complementary, and a product strong on one but weak on the other has an exploitable seam.

A sensor can attest beautifully to a counterfeit firmware image, and a sensor can boot a verified image that claims the wrong identity — so a factory that takes security seriously handles both, with attestation proving the unit and secure boot protecting the code that the unit runs. We treat them as one programme because they are: the DAC anchors trust in the hardware root, and secure boot keeps that trusted hardware from being silently reprogrammed.

Signed firmware and the OTA promise

When firmware is signed, every image the factory ships — including over-the-air updates — carries a cryptographic signature, and the device verifies both the signature and the version number before applying it, rejecting unsigned images and blocking downgrade attacks that would roll a device back to a vulnerable build. This is the mechanism that makes a fielded sensor patchable without a recall: a brand can push a fix to thousands of homes, and an attacker cannot push a malicious build in its place.

The signing step lives in the manufacturer's build and release pipeline, under access control, because the moment a signing key is exposed the entire product line's integrity collapses, which is why key custody is a factory discipline and not a setting a brand toggles. A brand that relabels finished goods inherits our signing posture or someone else's; it cannot establish its own, because it does not hold the keys or run the line.

Where the keys live, and who controls them

The verification keys are fused into the device's secure storage during manufacturing, while the signing keys are held by the manufacturer under strict access control and used only inside the build and release pipeline, so the trust relationship is anchored in hardware at the factory and never leaves it in a usable form. Because Shenan Yangguang builds and certifies the Matter security hardware we produce, we own that key hierarchy and the line discipline that provisions and audits it — the provisioning of the verification key is a manufacturing step we control, not a black box we buy.

A brand evaluating a factory should ask directly how the keys are generated, where they are stored, who can sign, and how a compromised key would be revoked, because the answers reveal whether the secure boot is real or decorative, and a relabeller will be unable to answer in its own name. The honest position is that key custody is the manufacturer's non-transferable duty; we state ours plainly and document it per programme.

How this backs the cybersecurity laws

Secure boot and signed firmware are the technical backbone behind the software-update and no-default-credential duties that modern connected-device law imposes, because a product that cannot verify its own firmware cannot meet a "secure update" requirement no matter how polished its app is. The legal marks describe the duty in plain language; the factory discharges it in silicon and in the release pipeline. Without the factory's work, the brand's compliance paperwork is unsupported.

The UK Product Security and Telecommunications Infrastructure Act, the ETSI EN 303 645 baseline, and the EU Cyber Resilience Act each frame the obligation from a different jurisdiction, and the specific effective dates and transition periods shift, so they are confirmed against the current regulation rather than quoted as fixed — but the underlying technical requirement they point at is the same one secure boot satisfies. A brand serving the EU and UK should treat signed, verifiable firmware as a baseline expectation from design, not a last-minute patch before a listing.

What a brand should require

A brand should require, in writing, that firmware is signed and version-verified at boot, that OTA updates are authenticated and downgrade-protected, and that the key custody and revocation story is documented — and it should ask the factory to demonstrate the boot-time rejection of an unsigned image rather than accept the claim on faith. These are the questions that separate a manufacturer that owns security from one that relabels it, and they are answerable only by the party that runs the line.

Specific key-storage and signing-pipeline details are confirmed per project under appropriate confidentiality, but the principle is constant: the factory that builds the hardware owns the cryptographic duty of proving the firmware is the firmware it authorized. If you are building a Matter security line where trust is the product, send us your threat model and update policy; we will show you the boot, the signing and the key story that back it.