Skip to content

The Boot Manager Standard (ETSI EN 304 623)

Draft — tracking an in-progress standard

ETSI EN 304 623 is under development. Details here reflect the direction of the draft and the CRA standardization mandate, and will change as the standard is finalized. Do not treat specifics as final requirements. Verify against the published standard when it is available.

The CRA sets essential requirements but generally not the concrete technical means of meeting them — that's the job of harmonised standards developed by the European standards organisations (CEN, CENELEC, ETSI) under a Commission standardisation request. When a harmonised standard is published and cited in the Official Journal, conforming to it gives a presumption of conformity with the corresponding CRA requirements — which, for certain product classes, is what lets you self-assess rather than engage a notified body.

ETSI EN 304 623 is the emerging standard addressing the boot manager — the component that governs how a device's firmware is selected, verified, and started. It's directly relevant to LAAVAT customers because the boot manager is where secure boot verification actually happens.

What the standard addresses

A boot manager, in this context, is the trusted component responsible for deciding what firmware runs and verifying it's authorized before it does. The draft standard is expected to formalize requirements around:

  • Firmware verification before execution — the boot manager must cryptographically verify each firmware/boot stage against a trusted key before handing control to it. This is the secure-boot property, made into a stated requirement.
  • Root of trust — anchoring verification keys in a way that can't be trivially bypassed or replaced by an attacker (hardware-backed where the platform supports it).
  • Update handling and anti-rollback — accepting genuine updates while rejecting tampered ones, and preventing an attacker from forcing a downgrade to a known-vulnerable version.
  • Failure and recovery behaviour — what the device does when verification fails (refuse to boot, fall back to a known-good image, enter recovery) rather than executing unverified code.
  • Key and signature handling — supported algorithms, signature formats, and how trust is managed over the device lifecycle.

The common thread is exactly what secure boot provides: the device runs only firmware whose signature verifies against a trusted key.

How LAAVAT aligns

A boot-manager standard defines what the device must do at verification time; it presumes the firmware it verifies was signed correctly in the first place. LAAVAT is the signing side of that relationship:

  • Signatures the boot manager will accept. LAAVAT signs firmware and update artifacts in the formats each platform's boot manager expects (RAUC, MCUboot, FIT, Xilinx, NXP HAB/AHAB), so the artifacts a compliant boot manager verifies are ones it can actually validate.
  • A real root of trust. The keys the boot manager checks against correspond to keys LAAVAT holds in AWS CloudHSM, owned by and access-controlled to your own crypto user. The "trusted key" side of the standard's root-of-trust requirement is backed by infrastructure an attacker can't extract keys from.
  • Update integrity and anti-rollback support. Signed updates are the precondition for a boot manager to safely accept updates while rejecting tampered or downgraded ones.

In short, when the standard says "the boot manager verifies a valid signature," LAAVAT is what produces the valid signature — securely, at scale, with keys you control.

Why track it now

The standard isn't final, and you can't conform to an unpublished document. But two things make it worth watching before it lands:

  1. It may gate self-assessment. For "Important" product classes, a published harmonised standard is what allows self-assessment instead of third-party conformity assessment. If your product's route depends on EN 304 623, its timeline affects yours.
  2. Building on signed secure boot now is the no-regret move. Whatever the final text says, it will require verified boot against a trusted key. A product already doing HSM-backed signed secure boot is positioned to conform; one that isn't will be retrofitting the hardest part under deadline. LAAVAT's signing platform is that foundation regardless of the standard's final wording.