Added terms and definitions, new security profiles for immutable components,...

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

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

**Verified boot**: Generic term for 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, it refers to the UEFI Secure Boot feature.

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

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

**Hardware security component**: Generic term for hardware-based security modules that provide cryptographic services and secure storage (includes but not limited to TPM, HSM, TEE, Secure Element)

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

**Boot target**: Software component to which the boot manager transfers control upon successful completion of its designated function, such as an operating system kernel, hypervisor, another boot loader, or an embedded application.

**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).

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

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

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

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

**Factory reset**: Process of restoring boot manager to its original manufactured state, removing all user configuration and enrolled credentials.

<mark>FIXME Terms</mark>

## 3.2 Abbreviations

- PXE: Preboot Execution Environment

- ROM: Read-Only Memory

- SBOM: Software Bill of Materials

- TEE: Trusted Execution Environment 

- TPM: Trusted Platform Module

- UEFI: Unified Extensible Firmware Interface

NOTE: TPM and HSM are examples of hardware security components. The generic term 'hardware security component' is used throughout this document unless referring to specific implementation examples.

<mark>FIXME Abbreviations</mark>

# 4 Product context

## 4.3 Architecture

<mark>FIXME Architecture</mark>

### 4.3.1  Functional architecture

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. 

- Configuration: User-modifiable settings or fixed configuration

- Recovery mechanisms: Recovery mode available or not

- Boot target selection: Multiple boot targets or single target

- Update granularity: None / Config-only / Partial / Full

The presence or absence of these capabilities determines which requirement profiles apply as defined in Section 6.

- Storage boundary: Components requiring verification before use, including all data read from storage media, configuration data, and boot components that may have been tampered with or corrupted.

- Network boundary: Untrusted input requiring complete verification, including all network-sourced boot components, protocol data, and remote configuration.

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

- Physical access boundary: Environmental threats from authorized or unauthorized physical access that can compromise the security.

- 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.6 Interfaces

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

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

- Storage interfaces: SPI flash, 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

- 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

<mark>FIXME Interfaces</mark>

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

## 4.4 Users

# 5 Requirements

<mark>FIXME Formal requirement with SHALL statements, requirement identifiers, tests</mark>

<mark>FIXME Change requirements to include unique identifiers (REQ-BM-xxx) and test methods, current lists only indicate requirement areas to be addressed.</mark>

## 5.1 Applicable requirements

- Detect and respond to component substitution

- Update integrity verification

- Protection against TOCTOU attacks

- Requirements when no TPM/HSM available

- Requirements when no hardware security component available

- Minimum key sizes

- Approved cryptographic algorithms

- Post-quantum cryptography considerations

- Provisions for immutable components

- Network boot security requirements

For boot managers with expected operational lifetime exceeding 5 years:

- Cryptographic resilience

- Key management for extended lifecycle

- Hardware aging considerations  

- Time-based vulnerabilities

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

- Provide method to cryptographically erase sensitive data

- Clear all cryptographic keys from hardware security components

- Enable verification that secure erasure completed successfully

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

- Device resale or transfer

- Employee termination (enterprise devices)

- End-of-life disposal

- Return for service/warranty

NOTE: Configuration systems shall distinguish between user data and system configuration, allowing selective erasure of user data while maintaining device function.

<mark>FIXME Owner control? User-enrollable keys, alternative boot paths, support for multiple certificate authorities</mark>

# 6 Security Profiles

# 6 Security profiles

## 6.1 SP-BASE: Base Security Profile

## 6.1 SP-BASE: Base security profile

- Applies to all boot managers

- Requirement categories: Security by design, secure defaults, vulnerability

management

- Requirement categories: Security by design, secure defaults, vulnerability management

## 6.2 SP-VERIFIED: Verified Boot Profile

## 6.2 SP-VERIFIED: Verified boot profile

- Applies to verified boot architecture

- Categories: SP-BASE + verification-specific integrity, access control, and availability

requirements

- Categories: SP-BASE + verification-specific integrity, access control, and availability requirements

When configuration is supported, it needs:

- certificate update mechanisms

- key enrollment procedures

- signature database management

## 6.3 SP-MEASURED: Measured Boot Profile

## 6.3 SP-MEASURED: Measured boot profile

- Applies to measured boot architecture

- Categories: SP-BASE + measurement-specific integrity and logging requirements

## 6.4 SP-UPDATE: Updatable Systems Profile

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

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

Update capability levels:

### 6.4.1 Fully updatable

- All boot components can be updated 

- Requirements: Full update authentication, recovery partition, rollback protection

### 6.4.2 Partially updatable

- Only certain components can be updated

- Requirements: Document immutable components, protect update boundaries

### 6.4.3. Configuration-only updates

- Applies when update capability present

- Categories: Update integrity, recovery mechanisms, enhanced vulnerability

management

- Only settings/keys can be updated

- Requirements: Configuration signing, default restoration capability

## 6.4 SP-NETWORK: Network Boot Profile

## 6.5 SP-IMMUTABLE: Non-updatable system profile

- Applies to boot managers that cannot be updated

- Categories: Long-term cryptographic resilience, algorithm selection for 15+ year lifecycles, hardware write-protection

Requirements 

<mark>FIXME Move into Section 5</mark>

- documentation what remains configurable vs truly immutable

- hardware write-protection for code regions

- cryptographic algorithms for full device lifecycle

NOTE: Updates of Configuration data may still be possible.

## 6.6 SP-NETWORK: Network boot profile

- Applies when network boot capability present

- Categories: Boot image verification, attack surface limits

## 6.5 SP-HARDWARE: Hardware Security Profile

When configuration is supported:

- boot server configuration may be considered RDPS

- boot order preferences may b ea security concern

## 6.7 SP-PORTABLE: Portable media boot profile

- Applies when boot from user-provided media is supported (USB, SD card, optical disc, external drives)

- Categories: Media authentication, physical port control, user presence verification

## 6.8 SP-HARDWARE: Hardware security profile

- Applies when hardware security features present

- Categories: Hardware key storage, attestation support

- Categories: Hardware key storage, measured boot support, attestation

## 6.6 SP-CONFIG: Configuration Management Profile

## 6.9 SP-CONFIG: Configuration management profile

- Applies when configuration capability present

- Categories: Access control, secure defaults for configuration

## 6.7 Profile Application

## 6.10 SP-RECOVERY: Recovery boot profile

- Applies when recovery or failover boot modes present

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

## 6.11 Profile application

Boot managers implement all applicable profiles based on their capabilities. Specific requirements within each profile will be defined as Section 5 is developed.

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.

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

- **Requirements of Regulation**: Identification of article(s) defining the requirement in the Regulation.

- **Clause(s) of the present document**: Identification of clause(s) defining the requirement in the present document unless another document is referenced explicitly.

**Requirement Conditionality:**

**Requirement conditionality:**

- **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".

- Boot order and parameters

- Network boot settings

- Boot event log

- PCR values (when TPM present)

- Security register values (when hardware security component present)

- NVRAM/variable storage

- Boot cache

- Hardware security module state