added use cases, changed requirements to fit pt1

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 managers**: Software or firmware component that controls the boot process and allow to manage multiple operating systems or boot configurations after power-on or reset. For the use in the document it also serves as a catch-all term.

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

- Network boot protocols (PXE, HTTPS Boot)

- Remote attestation capabilities

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

<mark>FIXME Description of core security functions</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>

## 4.4 Architecture

## 4.4.1 Overview

## 4.4.2 Deployment context

Boot managers face different security risks based on whether physical access is controlled. While physical access is the primary concern for local boot, network boot shifts the trust boundary to network infrastructure.

In a protected environment physical access requires some form of authorization, either specific permission or organizational membership. Includes some levels of monitoring to minimal oversight. Examples: datacenter servers, network infrastructure, office workstations, corporate laptops, retail POS systems.

Unprotected environments don't offer reliable physical access control, anyone can reach and tamper with the device. No monitoring or detection of physical access. Examples: personal devices, ATMs, IoT devices, smart meters, vehicles, public kiosks.

<mark>FIXME overhaul this section and or integrate with use cases</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.5 Users

Boot managers operate in many cases without traditional user interaction during normal operation. Security decisions are predetermined by configuration, not made by users at runtime.

- End users for selection of boot options when permitted

- Service technicians for maintenance and repair

- Testing labs

- Forensic analysts and security researchers

- Forensic analysts

- Security researchers

<mark>FIXME Automated tools?</mark>

## 4.6 Use cases

<mark>FIXME use cases</mark>

## 4.6.1 Deployment context

<mark>FIXME Controlled/managed/uncontrolled vs protected/unprotected?</mark>

Boot managers face different security risks based on whether physical access is controlled. While physical access is the primary concern for local boot, network boot shifts the trust boundary to network infrastructure.

In protected environments physical access requires some form of authorization, either specific permission or organizational membership. Includes some levels of monitoring to minimal oversight. Examples: datacenter servers, network infrastructure, office workstations, corporate laptops, retail POS systems.

Unprotected environments don't offer reliable physical access control, anyone can reach and tamper with the device. No monitoring or detection of physical access. Examples: personal devices, ATMs, IoT devices, smart meters, vehicles, public kiosks.

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.2 Use case examples

**UC-HOME-1** Embedded IoT device (smart speaker, sensor)

- device has no user interface for boot configuration

- cannot be updated independently from main firmware

- operates on battery or low power

- no network connectivity during boot

- if compromised, entire device must be replaced

**UC-HOME-2** Consumer home entertainment device (ie. smart TV)

- no keyboard, remote control interface only

- accepts USB media

- may access online content

- may automatically download updates from vendor servers

**UC-HOME-3** Consumer home router

- exposed to untrusted network

- device stores credentials (ISP, WiFi, cloud service authentication)

- provides factory reset via physical button

- may automatically download firmware from vendor servers

- always-on device, rarely rebooted

- maybe accessible to guests and visitors in physical space

- may have vendor backdoor for ISP support

**UC-MOB-1** Smartphone

- stores device-unique cryptographic keys in hardware

- collects personal data including biometrics for unlock

- frequently travels through untrusted environments

- target of theft, carried through borders

- integrates with payment and banking systems via apps

- enforces manufacturer boot policy by default

**UC-MOB-2** Tablet

- same as UC-MOB-1

- often shared in the household or with guests

**UC-MOB-3** Personal laptop

- all of UC-STAT-1

- target of theft, carried through borders

- exposed to untrusted network

**UC-MOB-4** Enterprise-managed corporate laptop

- all of UC-STAT-2

- travels with employee

- may be remotely wiped or bricked if reported stolen

**UC-STAT-1** Personal desktop computer

- allows user to select boot device

- permits disabling verified boot for compatibility

- stores arbitrary personal files and credentials

- may store multiple OS entries

- may be modified with hardware additions

**UC-STAT-2** Enterprise-managed workstation

- device owned by organization, not user

- stores configured boot policies

- enforces secure boot without override

- measured boot state for disk encryption

- requires admin credentials for changes

- reports attestation to corporate network

**UC-STAT-3** Thin client terminal

- stores only network boot configuration

- downloads OS image from server

- has no local OS storage

- resets to clean state on reboot

**UC-INFRA-1** Datacenter server

- physical access to systems restricted

- configured via remote management interface

- stores network boot parameters

- not accessible to end users

**UC-INFRA-2** Cloud service machine

- loads hypervisor instead of OS

- stores VM boot configurations

- validates hypervisor integrity

- manages nested boot processes

- virtual machine boot images

- no physical security boundary

**UC-REG-1** Payment terminal or ATM

- public physical exposure

- stores tamper detection state

- halts boot if security check fails

- regulatory compliance

<mark>FIXME Add more use cases from below</mark>

- edge devices

- industrial control systems

- medical devices

- healthcare devices

- voting machines

- gambling terminals

## 4.6.2 Risk factors

- configuration access

- boot recovery mechanisms

- rollback protection

- update capability

- verification capability

## 4.7 Threat considerations

For devices with a long lifetime, the following considerations should been taken into account:

- Cryptographic algorithm deprecation

- Key compromise over time

- Hardware aging and faults

- Cryptographic algorithms deprecate

- Keys get compromised over time

- Hardware is aging and cause faults

## 4.8 Implementation considerations

<mark>FIXME Specify test methods for each requirement</mark>

## 5.1 Basic security requirements

## 5.2 Technical requirements

Applies to all boot managers

### 5.2.1 Security by design

- Protect boot code against unauthorized modification

- Prevent bypass of boot sequence

- No default passwords or backdoors

- Fail securely on error conditions

- Support for multiple certificate authorities

## 5.2 Integrity and verification

### 5.2.2 Secure by default configuration

- Verify component signatures before execution

- Verify entire boot chain

- Security functions enabled by default

- No default passwords or backdoors

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

## 5.3 Access control

### 5.2.3 Authentication and access control mechanisms

- Restrict configuration changes

- Authenticate administrative access

## 5.4 Update security

### 5.2.4 Confidentiality protection

- Authenticated updates only over secured update channel

- Secure key storage

- Clear sensitive data after use

### 5.2.5 Integrity protection

- Verify component signatures before execution

- Verify entire boot chain

- Anti-rollback protection mechanisms

- Detect and respond to component substitution

- Update integrity verification

- Recovery if update fails

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

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

## 5.5 Attack resilience

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

- Clear sensitive data after use

- Protect against fault injection where feasible

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

### 5.2.6 Data minimization

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

### 5.2.7 Availability protection

<mark>FIXME Physical attack countermeasures</mark>

- Recovery if update fails

- Prevent bypass of boot sequence

## 5.6 Operational security

### 5.2.8 Impact minimization

- Security functions enabled by default

- Secure key storage

### 5.2.9 Limit attack surface

- Protect against fault injection where feasible

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

### 5.2.10 Logging and monitoring mechanisms

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

### 5.2.11 Vulnerability management

## 5.6 Owner control

- Authenticated updates only over secured update channel

- Backup/recovery of trust settings and keys

- User-enrollable keys

- Alternative boot paths

- Support for multiple certificate authorities

### 5.2.12 Security testing and review

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

<mark>FIXME Feature?</mark>

<mark>FIXME Owner control: User-enrollable keys, alternative boot paths, support for multiple certificate authorities</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).