Updates for early draft

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

CYBER; CRA;<br />

Title;<br />

Part #: Part element of title;<br />

Sub-part #: Sub-part element of title<br />

Release #

Essential cybersecurity requirements for boot managers<br />

</div>

In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use of or inability to use the software.

<br />

No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI yyyy.

© ETSI 2025.

All rights reserved.<br />

**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™**, **LTE™** and **5G™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM®** and the GSM logo are trademarks registered and owned by the GSM Association.

# Foreword

This Group Report (GR) has been produced by ETSI Industry Specification Group <long ISGname> (<short ISGname>).

> DRAFT FOREWORD - DO NOT CONSIDER THE CONTENT

This draft Harmonised European Standard (EN) has been produced by ETSI Technical Committee Cyber Working Group for EUSR (CYBER-EUSR), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI Standardisation Request deliverable Approval Procedure (SRdAP).

```

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 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).

```

Once the present document is cited in the Official Journal of the European Union under that Regulation, compliance with the normative clauses of the present document given in table A.1 confers, within the limits of the scope of the present document, a presumption of conformity with the corresponding requirements of that Regulation and associated EFTA regulations.

Transposition table

The Harmonised Standard shall have appropriate transposition periods specified. A Harmonised Standard confers presumption of conformity when it has been published in the Official Journal of the European Union (OJEU) and transposed by a member state.

The Technical Body may propose different dates to the default ones (3, 6, 18). Technical Bodies who wish to propose different dates are advised to indicate this clearly in the approved committee draft.

| Proposed national transposition dates                          |                                 |

|----------------------------------------------------------------|---------------------------------|

| Date of latest announcement of this EN (doa):                  | 3 months after ETSI publication |

| Date of latest publication of new National Standard            |                                 |

| or endorsement of this EN (dop/e):                             | 6 months after doa              |

| Date of withdrawal of any conflicting National Standard (dow): | 18 months after doa             |

The Technical Body should advise the ETSI Secretariat if the above default national transposition dates are inappropriate for the particular standard.

# Modal verbs terminology

In the present document "**should** ", "**should not** ", "**may** ", "**need not** ", "**will** ", "**will not** ", "**can** " and "**cannot** " are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules) (Verbal forms for the expression of provisions).

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

<br />

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.

# 1 Scope

## 1.1 General 

NOTE: This includes updatable platform initialization components that participate in the boot chain of trust, even if they execute before traditional boot managers.

<mark>FIXME: Anything still missing?</mark>

<mark>FIXME Is the scope sufficient?</mark>

<mark>FIXME Add boot sequence diagrams from power-on to handover by the operating system.</mark>

## 1.3 Out-of-scope products

This standard does not cover products in use in contexts other than those identified in Annex <L>.

This standard does not cover products in use in contexts other than those identified in Annex A.

This standard does not cover:

	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 Kernels with boot manager functionality?</mark>

<mark>FIXME relationship with other verticals as graphics</mark>

Example single-stage boot sequence from power-on to hardware access by the operating system. 

<mark>FIXME relationship with other verticals as diagram?</mark>

## 1.4 Composite products

Products integrating boot manager functionality may:

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 and how this work. Maybe move into an Annex or extra guidance document.</mark>

# 2 References

## 2.1 Normative references

Normative references are not applicable in the present document.

## 2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

**Boot component**: Any code or data loaded during the boot process.

<mark>FIXME Terms</mark>

## 3.2 Abbreviations

For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:

- TPM: Trusted Platform Module

- UEFI: Unified Extensible Firmware Interface

<mark>FIXME Abbreviations</mark>

# 4 Product context

## 4.1 General

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

## 4.3  Essential functions

Boot manager may provide the following functions:

### 4.3.1 Core functions 

- Loading and execution of target OS kernel/next stage

- Loading and execution of target OS kernel or next stage

- Transfer control to loaded software  

- Select boot target/configurations

- Pass boot parameters

- Chain of trust establishment

- Secure update mechanisms

- Measure components

- Disk encryption support

- Boot policy enforcement

- Manage keys/certificates

- Network boot protocols (PXE, HTTPS Boot)

- Remote attestation capabilities

<mark>FIXME: Minimum cryptographic algorithms and key lengths </mark>

<mark>FIXME Add relevant 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 Requirement applicability model

### 4.4.1 Functional categories

Requirements in Section 5 are organized as:

- Fundamental requirements: All boot managers

- Function-specific requirements: Only when function is implemented

- Platform-dependent requirements: Only when specific hardware capabilities are available

### 4.4.2 Applicable requirements

To determine which requirements apply:

1. Fundamental requirements (applies to all)

2. If implementing functions, corresponding requirements in apply

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

<mark>FIXME: Test procedures for component-level verification</mark>

- Fundamental 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 Test procedures for component-level verification</mark>

## 4.5 Deployment context

- IoT and embedded devices

- Development/test environments

<mark>FIXME Other deployment contexts; add details</mark>

## 4.6 Users and their interactions

Boot managers operate in many cases without traditional user interaction during normal operation.

<mark>FIXME Repair shops with the need to support end users or small businesses?</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. 

- Configuration tampering

- Debug interface exploitation

<mark>FIXME Mitigations in Annex</mark>

## 4.8 Implementation considerations

Component testing

### 4.8.1 Component testing

- integrated into larger systems

- using manufacturer's reference implementation

- using documented test interfaces

<mark>FIXME What constitutes "documented test interfaces"?</mark>

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

<mark>FIXME: Legacy implementations for existing boot managers</mark>

<mark>FIXME Legacy implementations for existing boot managers</mark>

<mark>FIXME Define minimum acceptable test environment specifications</mark>

### 4.8.2 Composite products

Composite products

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

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

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

# 5 Requirements 

<mark>FIXME Formal requirement with SHALL statements;  add requirement identifiers </mark>

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

<mark>FIXME Specify observable failure behaviors</mark>

<mark>FIXME Map threats to mitigation requirements (here or  Annex C)</mark>

Basic security requirements (all boot managers)

- Protect boot code against unauthorized modification 

- Anti-rollback protection mechanisms

- Detect and respond to component substitution

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

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

Access control

- Update integrity verification

- Recovery if update fails

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

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

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

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

<mark>FIXME How to properly engage with community-maintained projects</mark>

Attack resistance

- Clear sensitive data after use

- Protect against fault injection where feasible

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

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

<mark>FIXME: Physical attack countermeasures</mark>

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

<mark>FIXME Physical attack countermeasures</mark>

Operational security:

- Security functions enabled by default

- Secure key storage

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

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

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

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

| X                                                |             | Annex I, Part I(1)         | X                                 | X   |           |

| **Part II: Vulnerability Handling Requirements** |             |                            |                                   |     |           |

| X                                                |             | Annex I, Part II(2)        | X                                 | X   |           |

: Relationship between the present document and the requirements of the CRA

Table: Relationship between the present document and the requirements of EU Regulation 2024/2847

<mark>FIXME Table relationship to CRA </mark>

**Table columns:**

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

**Requirement:**

- **No**: A unique identifier for one row of the table which may be used to identify a requirement.

- **Description**: A textual reference to the requirement.

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

<br />

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

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

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

- Threat actors (nation-state, criminal, insider)

- Attack vectors mapped to mitigations in Section 5

- Risk matrix showing likelihood vs impact

- Deployment-specific risks (IoT/enterprise/consumer)

## B.1 Relationship to ETSI standards

| Standard          | Title               | Relationship to this document                                              |

| ----------------- | ------------------- | -------------------------------------------------------------------------- |

| **CRA Verticals** |                     |                                                                            |

| EN 304 626        | Operating Systems   | Boot managers transfer control to OS; boundary at kernel initialization    |

| EN 304 635        | Hypervisors and CRS | Hypervisors may include boot functionality; boot managers load hypervisors |

| XXX               | XXX                 | XXX                                                                        |

: Relationship between the present document and related ETSI standards

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

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

<mark>FIXME Annex C Risks</mark>

## C.1 Assets

- Root of trust keys (vendor certificates)

- User-enrolled keys (enterprise certificates)  

- Recovery keys

- Boot order and parameters

- Network boot settings

- Boot event log

- PCR values (when TPM present)

- NVRAM/variable storage

- Hardware security module state

## C.2 Threat actors

- Physical attacker

- OS-level malware

- Network attacker

- Supply chain

- Insider threat

- Nation state actor

## C.3 Boot-specific threats

- Pre-boot attacks

	- Boot code modification

	- Configuration manipulation

	- Key injection/replacement

- Persistence attacks

	- Bootkit installation

	- Recovery mechanism compromise

	- Boot server impersonation

	- Boot image tampering

- Physical attacks

	- DMA attacks

	- Fault injection

	- Flash chip replacement

- Supply chain attacks

	- Manufacturing backdoor

	- Compromised updates

# Anne

# History

+-------------------------------------------------+

|Document History                                 |

+:==============+:==============+:================+

| Document History |        |                   |

| ---------------- | ------ | ----------------- |

| Version          | Date   | Milestone         |

+---------------+---------------+-----------------+

|<Month year>   | <#>           |<Changes made>   |

+---------------+---------------+-----------------+

|               |               |                 |

+---------------+---------------+-----------------+

|               |               |                 |

+---------------+---------------+-----------------+

| <Month year>  | <#> | <Changes made> |