Bump version, minor changes terms, fix tzpos

<div align="center">

**ETSI EN-304-623 0.0.2 (2025-09)**

**ETSI EN-304-623 0.0.3 (2025-09)**

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

CYBER; CRA;<br />

## 1.3 Out-of-scope products

This standard does not cover products in use in contexts other than those identified in Annex A.

This standard does not cover:

This standard does not cover products in use in contexts other than those identified in Annex A. It does not cover:

- Operating systems

- Hypervisors

**Boot device**: Any storage medium or interface from which boot code can be loaded and executed, including internal storage, removable media, or network sources.

**Firmware**: Low-level software stored in non-volatile memory that provides hardware initialization and runtime services, including boot managers.

**Platform initialization firmware**: Code that typically executes from power-on until the actual boot management takes place (includes but not limited to UEFI PI, or coreboot romstage).

**Firmware**: Low-level software stored in non-volatile memory on the device/product that provides hardware initialization and runtime services, including boot managers.

**Update**: Modification of boot manager code, data, or configuration after initial deployment. Updates in this documents may be complete (entire firmware), partial (specific components), or configuration-only.

**Platform initialization firmware**: Code that typically executes from power-on until the actual boot management takes place.

**Physical presence**: Requirement for a user to be physically at the device location to perform certain security-sensitive operations, typically verified through local keyboard input, or button presses.

**Physical presence**: Requirement for a user to be physically at the device location with unrestricted access to the device to perform certain security-sensitive operations, typically verified through local keyboard input, or button presses.

**Air-gapped**: System or network physically isolated from unsecured networks, particularly the internet, with no network connectivity for data transfer.

**Immutable**: Components that cannot be modified after manufacture or initial programming. 

**Immutable components**: Components that cannot be modified after manufacture or initial programming. 

**Rollback protection**: Security mechanism preventing installation of older firmware versions that may contain known vulnerabilities.

- Network-enabled: Loading from network sources

- Platform initialization: Pre-boot firmware that establishes initial trust before main boot

Security approaches may include but is not limited to:

- Verified boot: Cryptographic validation preventing unauthorized code execution

- Secure boot: Specific implementation of verified boot (typically UEFI)

- Measured boot: Recording cryptographic measurements for attestation

Boot managers may operate with or without cryptographic verification mechanisms, as detailed in the architectural descriptions in Section 4.3.1.

Boot managers typically reside in non-volatile storage (SPI flash, eMMC boot partitions, QSPI) and are loaded into memory for execution. The boot target may be an operating system, hypervisor, another bootloader, embedded application, or recovery environment, and may reside in the same or different storage media.

For the purposes of this standard, the choice of boot architecture represents the fundamental security capability of a boot manager. This architectural choice determines the boot manager's core baseline security requirements. 

Basic Boot: Provides no cryptographic verification, focusing solely on loading and executing boot components. This represents the minimum viable boot capability.

Basic Boot provides no cryptographic verification, focusing solely on loading and executing boot components. This represents the minimum viable boot capability.

Verified Boot: Implements cryptographic verification with enforcement, preventing execution of unauthorized code. 

Verified Boot implements cryptographic verification with enforcement, preventing execution of unauthorized code. 

Measured Boot: Adds cryptographic measurement and recording without enforcement, provides auditability without blocking execution.

Measured Boot adds cryptographic measurement and recording without enforcement, provides auditability without blocking execution.

The architectural pattern chosen is not merely a design decision but the primary capability that defines which security requirements apply. A boot manager's architecture cannot be changed post-deployment, it is an intrinsic property. Additional capabilities augment but do not replace the security properties provided by the chosen architecture.

Verified boot implements cryptographic verification with enforcement throughout the boot process. Components are cryptographically verified before execution, creating a verification chain from power-on through boot target execution.

Components are verified against stored cryptographic signatures or hashes and if verification fails the system halts the boot process and potentially triggering recovery mode. Initial verification material (keys or hashes) may be stored in hardware-protected memory, fuses, or one-time programmable storage.

Components are verified against stored cryptographic signatures or hashes and if verification fails the system halts the boot process and potentially triggers recovery mode. Initial verification material (keys or hashes) may be stored in hardware-protected memory, fuses, or one-time programmable storage.

Systems implementing verified boot require cryptographic verification capabilities and secure storage for verification material.  

### 4.3.3 Boot manager capabilities

The architectural choices and functional extensions described above result in specific capabilities that a boot manager may possess. These capabilities determine which security requirements apply to the product:

The architectural choices and functional extensions described in the previous sections result in specific capabilities that determine which security profiles apply:

- Boot verification approach: Basic, Verified or Measured

- Update support: Can be updated or immutable

- Boot architecture: As defined in Section 4.3.1 (Basic, Verified, or Measured)

- Update capability: Updatable or immutable

- Network boot: Supported or not supported

- Hardware security features: TPM/HSM integration present or absent

- Portable media boot: Supported or not supported

- Hardware security features: Hardware security component integration present or absent

- Configuration: User-modifiable settings or fixed configuration

- Recovery mechanisms: Recovery mode available or not

- Boot target selection: Multiple boot targets or single target

- Operating system boundary: Components to which the boot manager transfers control, including operating systems, hypervisors, and runtime services. This boundary is bidirectional when the operating system performs updates to the boot manager.

- Control authority boundary: Delineation of ultimate authority over boot manager configuration and debug access, which shall reside with device owners or administrators, not manufacturers or vendors.

Interface lockdown hierarchy:

- Owner/administrator has ultimate control

- Manufacturer access only with owner consent

- No hidden or undocumented access methods

These boundaries define where boot managers can enforce security properties versus where they must rely on trust assumptions or external security mechanisms.

### 4.3.5 Resource constraints

- Time: Boot performance requirements limiting security operations

- Power: Energy constraints in battery-powered and embedded devices

- Environment: Temperature, vibration, and reliability requirements in industrial deployments

- Aging: Flash wear, bit rot, component degradation over lifecycle

These constraints influence architectural decisions and security vs. performance trade-offs.

Boot managers receive inputs, for example hardware reset signals, configuration data, boot media, network packets, or user input, and produce outputs, like the system state, measurement logs, or error codes. Boot managers interact through various technical interfaces:

- Storage interfaces: SPI flash, eMMC, NVMe, SATA with different protection mechanisms

- Storage interfaces: SPI flash, USB, eMMC, NVMe, SATA with different protection mechanisms

- Network interfaces: Ethernet, WiFi supporting PXE, HTTP Boot, iSCSI protocols

- Debug interfaces: JTAG, SWD, UART, SPI programmers requiring access control

- Debug interfaces: JTAG, SWD, UART, USB, SPI programmers requiring access control

- User interfaces: Serial console, display output, keyboard, remote management (IPMI/BMC)

- Hardware security interfaces: Hardware security component connections (SPI/I2C or other protocols)

- Runtime interfaces: UEFI runtime services, ACPI tables, SMM/SMI interfaces

Interface lockdown hierarchy:

- Owner/administrator has ultimate control

- Manufacturer access only with owner consent

- No hidden or undocumented access methods

The control interfaces of boot managers include configuration utilities, update mechanisms, recovery modes, or remote management protocols.

## 4.4 Users

- safety-critical operation

- 15-20 year lifecycle

- may be air-gapped but USB can be used

- may be support for legacy protocols needed

- may require support for legacy protocols

**UC-IND-2** Building automation controller

For secure lifecycle:

- Provide mechanism to restore boot manager to default state

- Clear all user-configured credentials and keys

- Remove user-enrolled certificates

- Documentation what data persists after factory reset

- Require physical presence OR strong authentication for reset

- Clear all user-configured credentials and keys

- Provide method to cryptographically erase sensitive data

- Clear all cryptographic keys from hardware security components

- Remove user-enrolled certificates

- Enable verification that secure erasure completed successfully

- Overwrite key material when deleted, including but not limited to passwords in hardware security components

- Require physical presence OR strong authentication for reset

- Support transfer of ownership scenarios

- Clear sensitive data from memory after use

- Overwrite key material when deleted

- Document any data that cannot be erased

Use cases requiring special attention:

## 6.4 SP-UPDATE: Updatable system profile

NOTE: SP-UPDATE and SP-IMMUTABLE are mutually exclusive profiles. A boot manager implements either SP-UPDATE (if any components can be updated) or SP-IMMUTABLE (if no code updates are possible).

NOTE: SP-UPDATE and SP-IMMUTABLE are mutually exclusive profiles. A boot manager implements either SP-UPDATE (if any components can be updated) or SP-IMMUTABLE (if no updates are possible).

Applies when any boot manager component can be updated post-manufacture

- hardware write-protection for code regions

- cryptographic algorithms for full device lifecycle

NOTE: Updates of Configuration data may still be possible.

NOTE: Updates of configuration data may still be possible.

## 6.6 SP-NETWORK: Network boot profile

When configuration is supported:

- boot server configuration may be considered RDPS

- boot server configuration may be considered remote data processing solutions (RPDS)

- boot order preferences may be a security concern

## 6.7 SP-PORTABLE: Portable media boot profile

- Applies when recovery or failover boot modes present

- Categories: Recovery authentication, failsafe mechanisms, factory reset security

<mark>FIXME Recovery path may be misused to bypass a rollback-protection</mark>

## 6.11 Profile application

Boot managers implement all applicable profiles based on their capabilities. A boot manager must implement SP-BASE plus all profiles matching its implemented capabilities Specific requirements within each profile will be defined in Section 5.

A boot manager must at least implement SP-BASE and in addition all profiles matching its implemented capabilities' specific requirements within each profile as defined in section 5.

<mark>FIXME Include boot taget selection</mark>

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

  - Boot image tampering

- Physical attacks

  - DMA attacks

  - TPM reset attacks

  - Reset attacks against hardware security components

  - Fault injection

  - Flash chip replacement

- Supply chain attacks