Risk factors, comosite products

<div align="center">

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

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

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

CYBER; CRA;<br />

## 1.4 Composite products

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

When boot manager functionality is integrated into larger products (such as operating systems, hypervisors, or embedded devices), the product manufacturer demonstrates conformance through evaluation of the complete product, with boot manager requirements assessed as part of the whole.

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

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

# 2 References

## 2.1 Normative references

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

# 3 Definition of terms and abbreviations

## 3.1 Terms

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

## 4.3  Essential functions

## 4.3 Architecture

<mark>FIXME Architecture</mark>

### 4.3.1 Core functions

## 4.4  Essential functions

### 4.4.1 Core functions

- Loading and execution of target OS kernel or next stage

- Transfer control to loaded software

- Error handling

- Recovery

### 4.3.2. Security functions

### 4.4.2. Security functions

- Chain of trust establishment

- Secure update mechanisms

<mark>FIXME Description of core security functions</mark>

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

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

## 4.4 Architecture

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

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

Users with direct interaction

Legitimate actors with direct interaction

- Manufacturers for initial provisioning during production

- System integrators for customization or deployment

- Forensic analysts

- Security researchers

<mark>FIXME Automated tools?</mark>

Actions being performed

- During configuration through setup utilities or OS-based tools

## 4.6.2 Use case examples

The following use cases is a high-level overview how boot managers operate within various device types. Each use case reflects the boot manager's roles as component that must balance device-specific requirements with security enforcement.

<mark>FIXME Mapping</mark>

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

- device has no user interface for boot configuration

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

- exposed to untrusted network

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

- device stores credentials (ISP, WiFi)

- provides factory reset via physical button

- may automatically download firmware from vendor servers

- always-on device, rarely rebooted

- target of theft, carried through borders

- integrates with payment and banking systems via apps

- enforces manufacturer boot policy by default

- user may wipe data on the device remotely

**UC-MOB-2** Tablet

- same as UC-MOB-1

- often shared in the household or with guests

- similar to UC-MOB-1

- may shared in the household or with guests

- may shared with a child

**UC-MOB-3** Personal laptop

- all of UC-STAT-1

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

- similar to UC-STAT-2

- travels with employee

- may be remotely wiped or bricked if reported stolen

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

- development and testing

- edge devices

- industrial control systems

- medical devices

- voting machines

- gambling terminals

## 4.6.2 Risk factors

### 4.6.3 Risk factors

The manufacturer of a boot manager placed on the market shall develop a threat model and risk profile based on intented use, foreseeable misuse, and deployment environment. 

The following risk factors shall be taken into account when developing the risk profile and determining applicable security requirements.

#### 4.6.3.x Environmental exposure

RF-ENV: Manufacturers shall account for the physical security of the deployment location of the intented use and implement appropriate protective measures where feasible.

- ENV-0: Physically secured location

- ENV-1: Controlled environment  

- ENV-2: Uncontrolled private space

- ENV-3: Public/hostile environment

#### 4.6.3.x Update capability

RF-UPD: Manufacturers shall provide secure update mechanisms appropriate to the deployment model, or shall document why updates are not possible. For immutable boot managers (UPD-0), the manufacturer shall ensure no known exploitable vulnerabilities exist at time of production.

- UPD-0: Immutable

- UPD-1: Physical access required

- UPD-2: Local update possible

- UPD-3: Remote/automatic update

#### 4.6.3.x Configuration access

RF-CFG: Manufacturers shall implement access controls appropriate to the configuration risk level. Default configurations shall be secure.

- CFG-0: No configuration possible

- CFG-1: Physical presence required

- CFG-2: OS admin can modify

- CFG-3: Remote configuration possible

#### 4.6.3.x Rollback protection

RF-ROLL: Manufacturers shall implement anti-rollback mechanisms appropriate to the security risk. For ROLL-0, manufacturers shall document why rollback protection is not implemented and the associated risks.

- configuration access

- boot recovery mechanisms

- rollback protection

- update capability

- verification capability

- ROLL-0: No rollback protection

- ROLL-1: Warning only on rollback

- ROLL-2: Software-enforced anti-rollback

- ROLL-3: Hardware fuse anti-rollback

#### 4.6.3.x Verification capability

RF-VRFY: Manufacturers shall implement integrity verification appropriate to the threat model. For VRFY-0, manufacturers shall document the rationale and compensating controls.

- VRFY-0: No verification

- VRFY-1: Checksum/CRC only

- VRFY-2: Software-based signatures

- VRFY-3: Hardware-rooted chain of trust

<mark>FIXME Review risk factors and add more</mark>

## 4.7 Threat considerations

- Keys get compromised over time

- Hardware is aging and cause faults

## 4.8 Implementation considerations

### 4.8.1 Component testing

- integrated into larger systems

- using manufacturer's reference implementation

- using documented test interfaces

<mark>FIXME What constitute a "documented test interface"?</mark>

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

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

<mark>FIXME Legacy implementations for existing boot managers as part of a composite product</mark>

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

# 5 Requirements

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

## 5.1 Applicable requirements

- Basic requirements (applies to all boot managers)

- If implementing functions, corresponding requirements apply

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

<mark>FIXME Criteria for when a function is implemented? How does a lab verify presence/absence?</mark>

<mark>FIXME Acceptable simulation/emulation environments</mark>

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

## 5.2 Technical requirements

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

### 5.2.6 Data minimization

### 5.2.7 Availability protection

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

# 6 Security profiles

<mark>FIXME Security profiles</mark>

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

  - Manufacturing backdoor

  - Compromised updates

<mark>FIXME Implementation guidance</mark>

# History

| Document History |        |                   |