Introduction
Draft ETSI EN 304 623 defines CRA cybersecurity requirements for boot managers. Its scope is broad: it covers bootloaders and boot managers, including low-level hardware initialization and services used during the boot phase. Bootloaders implemented in hardware are covered by hardware-specific standards instead.
The standard defines a capabilities model, for example whether a bootloader supports updates, and three cumulative security profiles depending partly on available hardware security mechanisms. The highest profile does not imply protection against physical attacks such as fault injection or side-channel attacks.
Several assumptions are particularly relevant for implementers. Secure Boot refers to the UEFI Secure Boot model (and only to this one). Verified Boot requires cryptographic verification, while Measured Boot records measurements without preventing execution. Anti-bricking is a requirement, debug tools are explicitly excluded from released bootloaders, and network boot requires authentication of the server.
One area that remains unclear is the SBOM. The standard requires one, but does not define normative requirements for its content or format. Its definition appears in informative Annex C.2 and refers to another informative reference, making it unclear which SBOM provisions are actually required for conformity.
As in the other CRA standard we reviewed, the ENISA “European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms” report (version 2, April 2025) is a normative reference.
Below are our comments on the draft, reproduced as submitted.
This review was made possible thanks to a grant from the CYBERSTAND programme.
Draft ETSI EN 304 623
Cyber Security (CYBER); CRA; Cybersecurity requirements for boot managers
- Comment 1 – Clause 5.4.0 – Security requirement without a separate identifier
Clause 5.4.0 states that “Boot managers shall be put on the market with security features enabled, no default credentials, and protection matching available hardware and software.” This is a normative requirement but has no separate requirement identifier or assessment criteria.
The issue is particularly important for default credentials. Clause 5.4.2 partially addresses authorization, but a documented or hardcoded default password could still satisfy an authorization requirement.
=> Proposed change:
Add a separate requirement:
“The boot manager shall be put on the market with no default credentials.”
- Comment 2 – Clause 5.4.1 – REQ-BM-SBD-001 does not specify what is validated
REQ-BM-SBD-001 does not clearly specify what the boot manager is required to validate.
=> Proposed replacement:
“The boot manager shall enable by default cryptographic validation of the code it loads and boots.”
- Comment 3 – Clause 5.4.2 – REQ-BM-SBD-002 allows default passwords
REQ-BM-SBD-002 requires authorization but does not prevent the use of a default password. A documented or hardcoded default password could therefore satisfy the requirement while still creating a security risk.
=> Proposed change:
Add the separate prohibition of default credentials proposed for clause 5.4.0.
- Comment 4 – Clause 5.6.2 – Meaning of “configured” is unclear
It is unclear whether “configured” means that the boot manager provides an option to protect the configuration, or that configuration settings themselves must be protected.
=> Proposed replacement:
“The boot manager shall allow protection of configuration settings related to the boot process against unauthorised modification.”
- Comment 5 – Clause 5.6.4 – REQ-BM-AC-004 – Editorial
The wording “or using cryptographic methods designed to be slow key derivation functions that are deliberately slow” is redundant.
=> Proposed replacement:
“or using cryptographic methods that are deliberately slow”
- Comment 6 – Clause 5.6.8 – REQ-BM-AC-008 is unclear
REQ-BM-AC-008 is not sufficiently clear to determine what implementation behaviour is required or how conformity should be assessed.
=> Proposed change:
Clarify the expected behaviour and the conditions under which REQ-BM-AC-008 is satisfied (also in 6.6.8)
- Comment 7 – Clauses 5.6.8 and 5.6.9 – “Authority transfer” is not defined
The term “authority transfer” is used but not defined. The related term “authority model”, used earlier in the document, is also not defined. This makes the corresponding requirements difficult to interpret consistently.
=> Proposed change:
Define “authority transfer” and “authority model” in the terms and definitions section.
- Comment 8 – Clause 5.7 – Storage of symmetric keys in the manufacturer’s production environment
The requirements do not prevent a manufacturer from retaining copies of all product symmetric keys in its production environment. Compromise of this environment could therefore compromise all products sharing or having recoverable symmetric key material.
=> Proposed addition:
“The manufacturer shall not retain product-specific symmetric secret keys in the production environment after provisioning, unless their retention is necessary for the operation or maintenance of the product and the associated risk is addressed by appropriate key management controls.”
- Comment 9 – Clause 6.3.1 – “Component inventory” and SBOM
Clause 6.3.1 mentions a “component inventory” separately from the SBOM, but does not define the component inventory or explain the difference between the two. It is therefore unclear why both are required.
All components should already be included in the SBOM.
=> Proposed change:
Remove the separate “component inventory” requirement and use the SBOM as the inventory of components.
- Comment 10 – General / SBOM requirements – No normative requirements for SBOM content or format
The standard requires an SBOM but does not define normative requirements for its minimum content or format. It is therefore unclear what information an SBOM needs to contain to satisfy the standard or what machine-readable formats are acceptable.
=> Proposed change:
Add normative requirements defining the minimum content of the SBOM and requiring a machine-readable, interoperable format based on a recognized SBOM standard, such as SPDX or CycloneDX.
- Comment 11 – Annex C.2 / reference [i.4] – Normative status of the SBOM definition is unclear
The SBOM definition is provided in informative Annex C.2 and refers to informative reference [i.4]. It is therefore unclear whether this definition and the referenced SBOM specifications are requirements for conformity or only informative guidance.
=> Proposed change:
If the SBOM definition or requirements from [i.4] are necessary for conformity, move the relevant provisions into the normative part of the standard and make the necessary references normative. Otherwise, clarify that Annex C.2 and [i.4] provide informative guidance only.
