added controlled/uncontrolled environment to deployment context, threats

# Executive summary

# Introduction

The present document is a European harmonised standard that defines cybersecurity requirements for products whose primary purpose is providing a boot manager. Demonstrating compliance with this standard is not necessary, but doing so provides a presumption of conformity with Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA).

This standard does not apply to products that contain a boot managers but whose primary purpose is something else. But this standard may be useful as part of the process of demonstrating compliance for a product containing a boot manager as component.

<!-- 01-scope.md -->

# 1 Scope

## 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

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 relationship with other verticals as diagram?</mark>

## 1.4 Composite products

This standard only applies to boot managers as products put on the market. Products integrating boot manager functionality may:

- apply this standard to boot manager components only

- Apply this standard to boot manager components only

- Demonstrate conformance through composite evaluation

- Reference relevant requirements without claiming full conformance

<mark>FIXME add examples of composite products including boot manager. Maybe move into Annex or extra guidance document.</mark>

<!-- 02-03-refs-terms.md -->

# 2 References

## 2.1 Normative references

- 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

<mark>FIXME Abbreviations</mark>

<!-- 04-context.md -->

# 4 Product context

## 4.1 General

- Chain of trust establishment

- Secure update mechanisms

- Disk encryption support

- Boot-time integrity checking

- Boot policy enforcement

- Manage keys/certificates

- Component measurement and recording (requires TPM/HSM)

<mark>FIXME Add relevant security functions</mark>

<mark>FIXME Netboot as core function? Different grouping </mark>

<mark>FIXME Netboot as core function? Different grouping?</mark>

<mark>FIXME Minimum key sizes and approved cryptographic algorithms; post-quantum cryptography considerations</mark>

<mark>FIXME Interaction with OS after handover</mark>

<mark>FIXME How are these functions reflected in security profiles?</mark>

## 4.4 Requirement applicability model

### 4.4.1 Functional categories

Requirements in Section 5 are organized as:

<mark>FIXME Add when functionasl categories defined.</mark>

<mark>FIXME Add when functional categories defined.</mark>

### 4.4.2 Applicable requirements

## 4.5 Deployment context

- Consumer devices (laptops, desktops)

- Enterprise laptops

- Datacenter systems

- Industrial/automotive systems

- IoT and embedded devices

- Development/test environments

Boot managers are a core component of hardware and software products. The difference is how the product is exposed to physical access by by authorized and unauthorized third-parties. While physical access is the primary concern for devices with local boot storage, network boot scenarios shift the trust boundary to network controls and boot image integrity.

Controlled environments restrict physical access to specifically authorized personnel through multiple security layers. Threat actors must either be authorized insiders or successfully bypass physical security controls. Examples include datacenter servers, HSMs, and critical infrastructure where access is logged and monitored.

Semi-controlled environments allow any organizationally authorized person to physically access the device without specific permission or detection. Threat actors with basic organizational access (employees, contractors or visitors) may modify boot configuration without raising alerts. Examples include office workstations, corporate laptops, and shared printers.

Uncontrolled environments expose devices to physical access by anyone. Threat actors have unlimited time and opportunity for tampering without detection. Examples include personal devices, ATMs, IoT devices, and other systems deployed outside organizational physical control.

<mark>FIXME add use cases</mark>

<mark>FIXME Other deployment contexts?</mark>

NOTE: Individual hardware components and software that contain or manage boot processes inherit security requirements from the complete system they're deployed in. 

## 4.6 Users and their interactions

Users with direct interaction

- Manufacturers for initial provisioning during production

- System integrators for customization or deployment, including OEMs

- System integrators for customization or deployment

- System administrators for configuration in enterprise context

- End users to selection boot options when permitted

- End users for selection of boot options when permitted

- Service technicians for maintenance and repair

- Forensic analysts and security researchers

<mark>FIXME Automated tools?</mark>

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

- Factory reset or emergency recovery

- Firmware updates and rollback

- Bootloader unlocking for development or research

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>

<mark>FIXME GDPR: Boot managers collect hardware identifiers (MAC addresses, TPM IDs) that may be PII when correlated by third parties, especially for remote attestation.</mark>

<mark>FIXME Boot managers collect hardware identifiers (MAC addresses, TPM IDs) that may be considered personal information when correlated by third parties, especially for remote attestation.</mark>

## 4.7 Threat considerations

<mark>FIXME Threats and mitigations to Annex C?</mark>

### 4.7.1 Supply chain threats

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

<mark>FIXME Detailed description and mitigations into Annex C</mark>

### 4.7.2 Runtime manipulation

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

- Bootloader bypass attacks

- Configuration tampering

- Debug interface exploitation

- Supply chain threats: Boot manager code injection during development or distribution, affecting integrity before deployment.

- Runtime manipulation: Attempts to bypass or replace boot manager during operation, including configuration tampering, or debug interface exploitation.

- Physical access attacks: Exploitation through direct hardware access, for example evil maid or cold boot attacks, boot media substitution or hardware modifications.

- Persistent firmware threats: Malicious code surviving system reinstallation, like bootkits or firmware implants.

- Network boot attacks: Threats specific to network-based booting.

- Rollback and downgrade attacks: Attempts to revert to vulnerable versions.

## 4.8 Implementation considerations

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

<mark>FIXME Minimum acceptable test environment specifications</mark>

### 4.8.2 Composite products

<mark>FIXME Add infos here or move to Annex for guidance/examples</mark>

<!-- 05-requirements.md -->

# 5 Requirements

<mark>FIXME Proper grouping, formal requirement with SHALL statements;  add requirement identifiers </mark>

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

<mark>FIXME Proper engagement with community-maintained projects when using open source software</mark>

## 5.5 Attack resilience

- Debug interface exploitation

<mark>FIXME Define fault injection attacks to test (clock glitch, voltage, EM)</mark>

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

<mark>FIXME What constitutes feasible fault injection protection? Needs decision criteria</mark>

<mark>FIXME Physical attack countermeasures</mark>

- Security functions enabled by default

- Secure key storage

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

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

<mark>FIXME How to verify "secure key storage" without access to internals?</mark>

## 5.6 Neutrality

## 5.6 Vendor neutrality

<mark>FIXME Better term for "n"eutrality"</mark>

<mark>FIXME Better term for "vendor neutrality"</mark>

- Support for multiple certificate authorities

- User-enrollable keys

<mark>FIXME Develop requirements ensuring boot managers don't create vendor lock-in</mark>

<!-- annex-a-cra.md -->

<mark>FIXME Feature?</mark>

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

- **U/C**: Indicates whether the requirement is unconditionally applicable (U) or is conditional upon the manufacturer's claimed functionality of the equipment (C).

- **Condition**: Explains the conditions when the requirement is or is not applicable for a requirement which is classified "conditional".

<!-- annex-b-relationships.md -->

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

## B.1 Relationship to ETSI standards

<mark>FIXME Table relationship to ETSI Standards </mark>

<!-- annex-c-risk.md -->

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

<mark>FIXME Annex C Risks</mark>

- NVRAM/variable storage

- Hardware security module state

<mark>FIXME what are typical assets? starting with OSS, moving then to more sophisticated BMs</mark>

## C.2 Threat actors

- Physical attacker