init EN-304-623.md

<div align="center">

**ETSI EN LLL-LLL DDD Vm.t.e (yyyy-mm)**

![~~CAPTION~~](media/etsi-coverpage-logo.png)

**ETSI EN-304-623 0.0.0 (2025-08)**

![](media/etsi-coverpage-logo.png)

# 1 Scope

The present document ...

## 1.1 General 

The present document specifies cybersecurity requirements for boot managers as products with digital elements under Regulation (EU) 2024/2847 (Cyber Resilience Act). It addresses boot managers identified in Annex III, Point 8 as Important Products with Digital Elements (Class I) and as specified in Standardisation Request C(2025) 618, line item 23. 

## 1.2 In-scope products

Products in scope include boot management software that may be integrated into firmware, or provided as components for integration into other products, regardless of their distribution model. This category includes but is not limited to:

- Universal bootloaders for multiple hardware platforms

- Multi-boot managers supporting operating system selection

- Network-capable boot loaders with remote boot functionality

- Embedded bootloaders distributed as standalone software components

- Firmware-independent boot management software

NOTE: Boot managers may be implemented as single-stage bootloaders (direct loading) or multi-stage bootloaders (staged verification and loading processes).

NOTE: This includes updatable platform initialization components that participate in the boot chain of trust, even if they execute before traditional boot managers.

<mark>FIXME: Anything still missing?</mark>

## 1.3 Out-of-scope products

This standard does not cover products in use in contexts other than those identified in Annex <L>.

This standard does not cover:

- Operating systems

- Hypervisors

- Immutable boot code embedded in silicon

Operating systems may provide some or all of functions of boot managers, but its primary purpose is to provide services through which applications interact with system resources and peripherals while the system is running, not just during initialization. 

Boot functionality tightly integrated into operating system kernels may provide some or all of the functions of boot managers, but where such functionality cannot be independently updated, configured, or replaced separately from the operating system kernel.

While type I hypervisors may contain boot management functionality, they are designed primarily for virtualization rather than general-purpose boot management. However, boot management components within hypervisors that meet the technical boundaries defined in this standard may fall under scope.

Immutable boot code embedded in silicon and hardware-specific boot ROMs are implementations where the boot code is fixed and cannot be independently updated, modified, or configured after manufacturing. While they may perform boot functions, they are part of the hardware product itself rather than a separate software product with digital elements.

<mark>FIXME Kernels with boot manager functionality?</mark>

<mark>FIXME relationship with other verticals as graphics</mark>

Example single-stage boot sequence from power-on to hardware access by the operating system. 

## 1.4 Composite products

Products integrating boot manager functionality may:

- Apply this standard to boot manager components only

- Demonstrate conformance through composite evaluation

- Reference relevant requirements without claiming full conformance

# 2 References

The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding but are not required for conformance to the present document.

- <a name="_ref_i.1">[i.1]</a>

- [i.x] Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)

- [i.x] Commission Implementing Regulation (Draft): "Technical description of the categories of important and critical products with digital elements"

- [i.x] C(2025) 618: "Commission Implementing Decision on a standardisation request as regards cybersecurity of products with digital elements in support of Regulation (EU) 2024/2847"

- [i.x] ETSI EN 303 645: "Cyber Security for Consumer Internet of Things: Baseline Requirements"

- [i.x] ETSI TS 103 732-5: "CMD Protection Profiles - Part 5: Bootloader & Root of Trust Protection Profile Module"

# 3 Definition of terms, symbols and abbreviations

For the purposes of the present document, the [following] terms [given in ... and the following] apply:

**Boot managers**: Software or firmware component that controls the boot process and allow to manage multiple operating systems or boot configurations, for the use in the document it also serves as a catch-all term.

**Boot sequence**: Ordered series of operations performed during system startup.

**Chain of Trust**: Sequential verification where each boot component validates the next, establishing security from hardware root to operating system.

**Verified boot**: Cryptographic verification of boot components before execution to ensure only authorized code runs during system initialization.

**Secure boot**: A specific UEFI implementation of verified boot that uses certificates and signature databases to verify boot components. When capitalized, refers to the UEFI Secure Boot feature.

**Measured boot**: Recording cryptographic measurements of boot components for attestation without blocking execution.

## 3.2 Symbols

For the purposes of the present document, the [following] symbols [given in ... and the following] apply:

**Network boot**: Loading boot components from network sources using protocols such as PXE or HTTPS Boot.

**Recovery boot**: Specialized boot process designed to restore system functionality after failures.

**Root of Trust**: The foundation of the boot security chain, typically implemented in immutable code or hardware.

## 3.3 Abbreviations

**Attestation**: Process of providing cryptographic evidence about boot state to a verifier.

**Boot component**: Any code or data loaded during the boot process.

## 3.2 Abbreviations

For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:

- BIOS: Basic Input/Output System

- HSM: Hardware Security Module

- NVRAM: Non-Volatile Random Access Memory

- OS: Operating System

- PCR: Platform Configuration Register

- PXE: Preboot Execution Environment

- ROM: Read-Only Memory

- SBOM: Software Bill of Materials

- TPM: Trusted Platform Module

- UEFI: Unified Extensible Firmware Interface

# 4 Product context

# 4 User defined clause(s) from here onwards

## 4.1 General

The product context identifies the operational characteristics, deployment environments, and functional boundaries that determine applicable security requirements.

## 4.1 User defined subdivisions of clause(s) from here onwards

## 4.2 Product overview

Boot managers implement various architectural patterns based on platform requirements:

<br />

- Single-stage: Direct loading of operating system

- Multi-stage: Sequential loading through intermediate stages

- Network-enabled: Loading from network sources (PXE, HTTP)

- Verified boot: Cryptographic validation chain

Integration occurs through firmware, storage interfaces, and hardware security modules.

# Annex A: <br>Title of annex

## 4.3  Essential functions

Boot manager may provide the following functions:

### 4.3.1 Core functions 

<br />

- Loading and execution of target OS kernel/next stage

- Transfer control to loaded software  

- Select boot target/configurations

- Pass boot parameters

- Configuration management and storage

- Error handling

- Recovery

### 4.3.2. Security functions

# Annex B: <br>Title of annex

## B.1 First clause of the annex

## B.1.1 First subdivided clause of the annex

- Chain of trust establishment

- Secure update mechanisms

- Measure components

- Disk encryption support

- Boot policy enforcement

- Manage keys/certificates

- Component measurement and recording (requires TPM/HSM)

- Network boot protocols (PXE, HTTPS Boot)

- Remote attestation capabilities

<mark>FIXME: Minimum cryptographic algorithms and key lengths </mark>

<br />

## 4.4 Requirement applicability model

### 4.4.1 Functional categories

Requirements in Section 5 are organized as:

- Fundamental requirements: All boot managers

- Function-specific requirements: Only when function is implemented

- Platform-dependent requirements: Only when specific hardware capabilities are available

### 4.4.2 Applicable requirements

To determine which requirements apply:

1. Fundamental requirements (applies to all)

2. If implementing functions, corresponding requirements in apply

3. Platform capabilities (TPM, secure storage) trigger additional requirements where specified

# Annex: Bibliography

<mark>FIXME: Test procedures for component-level verification</mark>

## 4.5 Deployment context

<br />

- Consumer devices (laptops, desktops)

- Enterprise laptops

- Datacenter systems

- Industrial/automotive systems

- IoT and embedded devices

- Development/test environments

## 4.6 Users and their interactions

Boot managers operate in many cases without traditional user interaction during normal operation.

# Annex : Change history

Users with direct interaction

- Manufacturers for initial provisioning during production

- System integrators for customization or deployment

- System administrators for configuration in enterprise context

- End users to selection boot options when permitted

Actions being performed

- During configuration through setup utilities or OS-based tools

- Key press for boot menu during boot time

- Physical presence for recovery operations

NOTE: Security decisions are predetermined by configuration, not made by users at runtime.

<mark>FIXME Repair shops with the need to support end users or small businesses?</mark>

## 4.7 Threat considerations

### 4.7.1 Supply chain threats

Boot manager code injection during development or distribution, affecting integrity before deployment. 

### 4.7.2 Runtime manipulation

Attempts to bypass or replace boot manager during operation, including:

- Bootloader bypass attacks

- Configuration tampering

- Debug interface exploitation

<mark>FIXME Mitigations in Annex</mark>

## 4.8 Implementation considerations

Component testing

- integrated into larger systems

- using manufacturer's reference implementation

- using documented test interfaces

Requirements apply based on implemented functions. If a function is not implemented, associated requirements do not apply.

<mark>FIXME: Legacy implementations for existing boot managers</mark>

Composite products

When boot manager functionality is part of a larger product (chip, OS, hypervisor, device), conformance is demonstrated as part of the composite product evaluation.

# 5 Requirements 

Basic security requirements (all boot managers)

- Protect boot code against unauthorized modification 

- Prevent bypass of boot sequence

- No default passwords or backdoors

- Fail securely on error conditions

Integrity and verification

- Verify component signatures before execution

- Verify entire boot chain

- No execution of unsigned code (if verification enabled)

- Anti-rollback protection mechanisms

- Detect and respond to component substitution

<mark>FIXME: Requirements when TPM/HSM available</mark>

Access control

- Restrict configuration changes

- Authenticate administrative access

Update security

- Authenticated updates only over secured update channel

- Update integrity verification

- Recovery if update fails

<mark>FIXME: How to handle devices that cannot be updated?</mark>

<mark>FIXME: Update mechanisms for constrained devices</mark>

Attack resistance

- Resist debug interface exploitation

- Time-bounded operations to prevent delays

- Clear sensitive data after use

- Protect against fault injection where feasible

<mark>FIXME What constitutes "feasible" fault injection protection?</mark>

<mark>FIXME: Physical attack countermeasures</mark>

Operational security:

- Security functions enabled by default

- Secure key storage

<mark>FIXME: How to handle key without secure storage?</mark>

# Annex A (normative): Relationship between the present document and the essential requirements of EU Regulation 2024/2847

The present document has been prepared under the Commission's standardisation request C(2025) 618 final to provide one voluntary means of conforming to the requirements of Regulation (EU) No 2024/2847 (Cyber Resilience Act).

Once the present document is cited in the Official Journal of the European Union under that Regulation, compliance with the normative clauses of the present document given in Table A.1 confers, within the limits of the scope of the present document, a presumption of conformity with the corresponding requirements of that Regulation and associated EFTA regulations.

| No                                               | Description | Requirements of Regulation | Clause(s) of the present document | U/C | Condition |

| ------------------------------------------------ | ----------- | -------------------------- | --------------------------------- | --- | --------- |

| **Part I: Product Requirements**                 |             |                            |                                   |     |           |

| X                                                |             | Annex I, Part I(1)         | X                                 | X   |           |

| **Part II: Vulnerability Handling Requirements** |             |                            |                                   |     |           |

| X                                                |             | Annex I, Part II(2)        | X                                 | X   |           |

Table: Relationship between the present document and the requirements of EU Regulation 2024/2847

# Annex B (informative): Relationship between the present document and any related ETSI standards

| Date       | Version | Information about changes |

|------------|---------|---------------------------|

|&lt;Month year>|   <#>   | &lt;Changes made are listed in this cell> |

|            |         |                           |

|            |         |                           |

|            |         |                           |

<br />

# Annex C (informative): Risk identification and assessment methodology

- Threat actors (nation-state, criminal, insider)

- Attack vectors mapped to mitigations in Section 5

- Risk matrix showing likelihood vs impact

- Deployment-specific risks (IoT/enterprise/consumer)

# Anne

# History

+-------------------------------------------------+