reorgaanzied threats, added risks section

<div align="center">

**ETSI EN-304-623 0.0.4a (2025-09)**

**ETSI EN-304-623 0.0.4b (2025-09)**

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

CYBER; CRA;<br />

The following use cases provide 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.

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

#### 4.5.2.1 UC-HOME-1: Embedded IoT device (smart speaker, sensor)

- Device has no user interface for boot configuration

- Cannot be updated independently from main firmware

- May be purchased second-hand without factory reset

- Firmware may outlive vendor support by years

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

#### 4.5.2.2 UC-HOME-2: Consumer home entertainment device (ie. smart TV)

- No keyboard, remote control interface only

- Accepts USB media

- Service technicians may need diagnostic boot modes

- Integrated cameras/microphones with storage of private media

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

#### 4.5.2.3 UC-HOME-3: Consumer home router

- Exposed to untrusted network

- Device stores credentials (ISP, WiFi)

- Can influence all connected devices

- Can access private data on the internal network

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

#### 4.5.2.4 UC-STAT-1: Personal desktop computer

- Allows user to select boot device

- Permits disabling verified boot for compatibility

- Enthusiasts may overclock requiring custom settings

- Dual-boot configurations complicate secure boot

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

#### 4.5.2.5 UC-STAT-2: Enterprise-managed workstation

- Device owned by organization, not user

- Stores configured boot policies

- Must survive employee termination procedures

- Regulatory compliance may require specific configurations

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

#### 4.5.2.6 UC-STAT-3: Thin client terminal

- Stores only network boot configuration

- Downloads OS image from server

- Network outage leaves device unusable

- Server compromise affects all terminals connected

**UC-MOB-1** Smartphone

#### 4.5.2.7 UC-MOB-1: Smartphone

- Stores device-unique cryptographic keys in hardware

- Collects personal data including biometrics for unlock

- Usually receives over the air updates on a regular basis

- Effort by user to keep updated is lower compared to servers or workstations (can be done by children)

**UC-MOB-2** Tablet

#### 4.5.2.8 UC-MOB-2: Tablet

- Similar to UC-MOB-1

- May be shared in the household or with guests

- May be shared with children

- Used for point-of-sale in businesses

**UC-MOB-3** Personal laptop

#### 4.5.2.9 UC-MOB-3: Personal laptop

- Similar to UC-STAT-1

- Target of theft, carried through borders

- Customs/border inspection scenarios

- Coffee shop shoulder-surfing during boot

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

#### 4.5.2.10 UC-MOB-4: Enterprise-managed corporate laptop

- Similar to UC-STAT-2

- Travels with employee

- Temporary contractor access requirements

- Devices by employees may be targeted specifically due to corporate function

**UC-INFRA-1** Datacenter server

#### 4.5.2.11 UC-INFRA-1: Datacenter server

- Physical access to systems restricted

- Configured via remote management interface

- Must boot headless without user intervention

- Decommissioning requires verifiable secure wipe

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

#### 4.5.2.12 UC-INFRA-2: Cloud service machine

- Loads hypervisor instead of OS

- Stores VM boot configurations

- Multiple different users at a time

- No control of the type of user (normal user, enterprise user, state actor)

**UC-INFRA-3** Edge computing device

#### 4.5.2.13 UC-INFRA-3: Edge computing device

- Deployed in remote locations

- Limited physical security compared to UC-INFRA-1 and UC-INFRA-2

- Maintenance visits expensive/rare

- Cellular backup connectivity for recovery

**UC-INFRA-4** Network infrastructure device

#### 4.5.2.14 UC-INFRA-4: Network infrastructure device

- Router, switch, firewall

- Always-on operation

- Backdoor concerns from manufacturer

- Operates 24/7 with rare reboots

**UC-IND-1** Industrial control system

#### 4.5.2.15 UC-IND-1: Industrial control system

- Critical infrastructure

- Controls physical processes

- May be air-gapped but USB can be used

- May require support for legacy protocols

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

#### 4.5.2.16 UC-IND-2: Building automation controller

- HVAC, lighting, access control

- Integration with legacy systems

- Energy efficiency monitoring

- Fire/safety system integration

**UC-MED-1** Diagnostic equipment

#### 4.5.2.17 UC-MED-1: Diagnostic equipment

- MRI, CT scanner, X-ray

- Patient data protection

- Scheduled maintenance windows

**UC-MED-2** Patient monitoring device

#### 4.5.2.18 UC-MED-2: Patient monitoring device

- Continuous operation required

- Patient safety critical

- Visitor tampering

- Fluid ingress risks

**UC-MED-3** Medical IT infrastructure

#### 4.5.2.19 UC-MED-3: Medical IT infrastructure

- Hospital information systems

- Electronic health records

- Ransomware recovery critical

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

#### 4.5.2.20 UC-REG-1: Payment terminal or ATM

- Public physical exposure

- Stores tamper detection state

- Surveillance camera present

- Transaction during network outages

**UC-REG-2** Voting machine

#### 4.5.2.21 UC-REG-2: Voting machine

- Public verifiability required

- Sealed between elections

- Comprehensive audit trail

- Storage between elections in uncontrolled environments

**UC-REG-3** Gaming/gambling terminal

#### 4.5.2.22 UC-REG-3: Gaming/gambling terminal

- Anti-tampering required

- Detailed logging for disputes

- Surveillance systems

- Tournament mode configurations

**UC-REG-4** Government/military system

#### 4.5.2.23 UC-REG-4: Government/military system

- Classified information processing

- Strict access controls

- Hardware supply chain verification

- Electromagnetic emanation controls

**UC-DEV-1** Development board

#### 4.5.2.24 UC-DEV-1: Development board

- Frequent reflashing

- Debug access

- Experimental code execution

- Power supply instabilities

**UC-DEV-2** Continuous integration system

#### 4.5.2.25 UC-DEV-2: Continuous integration system

- Automated testing

- Frequent boot cycles

- Malware in test suites

- Container/VM hybrid environments

**UC-DEV-3** Security research platform

#### 4.5.2.28 UC-DEV-3: Security research platform

- Intentional vulnerability testing

- Forensic analysis capability

## 4.6 Threat considerations

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

### 4.6.1 General

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

Boot managers face unique threats due to their position as the first code  executed and their role in establishing platform trust. These threats differ from OS-level threats in persistence, detectability, and impact.

### 4.6.2 Threat actors

- Nation state actors (sophisticated persistent threats)

- Organized crime (ransomware, cryptominers)

- Insider threats (supply chain, malicious admins)

- Researchers/hackers (proof of concept, discovery)

- Opportunistic attackers (automated tools)

### 4.6.3 Threat categories

- Pre-boot compromise

- Boot-time attacks

- Persistence mechanisms

- Trust chain attacks

- Configuration attacks

- Update attacks

- Physical access attacks

- Network boot specific

- Attack progression

- Threat evolution

## 4.7 Risk analysis

### 4.7.1 General

This section analyzes risks associated with boot manager compromise and the role of boot managers in system risk mitigation.

### 4.7.2 Risk model for boot managers

Boot manager specific risk factors:

- Privileged position (highest privilege level)

- Persistence (survives OS reinstall)

- Invisibility (below OS visibility)

- Trust establishment (foundation for all security)

### 4.7.3 Risks posed by compromised boot managers

- Immediate risks

- Persistent risks

- Propagation risks

- Lateral movement to other systems

### 4.7.4 Risks mitigated by secure boot managers

- Unauthorized code prevention

- System integrity protection

- Attack surface reduction

### 4.7.5 Deployment context risk factors

- Physical security

- Network exposure

- Update constraints

- Impact factors

### 4.7.6 Risk assessment methodology

- Component level assessment

- Integration level assessment

#### 4.7.6 Risk treatment options

- Avoid, reduce, transfer, accept

### 4.7.7 Risk-based requirement selection

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