Annex III, Class I ยท Regulation (EU) 2024/2847

Is a boot manager an important product under the CRA?

Verified against the Official Journal text on

Important product, Class I (Annex III Class I (8), Art. 7(1))

Yes, most likely. The CRA lists "boot managers" as important products (Annex III, Class I, item 8). A product whose core functionality is selecting and launching an operating system or firmware at start-up carries the full manufacturer obligations and a restricted conformity route: self-assessment stays available only where harmonised standards, common specifications, or eligible certification are applied in full. Bootloaders and boot managers sit at the root of the trust chain, which is why they are treated as important.

Basis: Annex III Class I (8), Art. 7(1), Art. 32(1)-(2)

Judgment call: Whether a given piece of early-boot software "has the core functionality of" a boot manager is a classification judgment the technical descriptions in Implementing Regulation (EU) 2025/2392 control.

What a boot manager is, for CRA purposes Annex III Class I (8), Art. 7(1), Art. 7(2), Art. 7(4)

Item 8 of Class I names "boot managers" plainly. In practice this reaches the software that runs very early in a device start-up to select, verify, and hand control to an operating system or further firmware. Both a bootloader and a boot manager that presents a choice of boot targets are the kind of software the category is about.

It is in Class I because it performs a function critical to the security of everything above it, in the sense of Article 7(2): whatever runs before the operating system anchors the chain of trust, and a compromise there undermines every later defence. The binding scope is the technical description in the implementing act, not the label.

When a boot manager is a product placed on the market Art. 7(1), Art. 3(1)

A boot manager is often shipped inside a larger product: it is embedded in device firmware, in an operating system image, or on a hardware board. Where you place a boot manager on the market as a product with digital elements in its own right, item 8 applies to it directly.

Where a boot manager is a component integrated into a wider product, Article 7(1) is explicit that integrating a listed component does not, in itself, make the surrounding product an important product. The surrounding operating system or device is assessed on its own listing. Confirm which case you are in and record the reasoning.

Judgment call: Whether early-boot code is placed on the market as its own product or only integrated into another product turns on how you actually supply it; the implementing act settles the category match.

What Class I changes: your conformity route Art. 32(1), Art. 32(2), Annex VIII

For a default-category product a manufacturer may self-assess under internal control (module A). For a Class I important product that choice narrows: internal control remains available only where you apply harmonised standards, common specifications, or a European cybersecurity certification scheme at assurance level at least "substantial", in full, to the relevant essential requirements.

Where you do not, or where no such standard yet exists, the product must go through EU-type examination plus conformity to type (modules B and C) or full quality assurance (module H), both involving a notified body. Plan for that lead time well before 11 December 2027.

Everything else is the ordinary manufacturer programme Art. 13, Art. 14, Annex I

Class I status changes the conformity route, not the substance. The essential cybersecurity requirements, vulnerability handling including a coordinated vulnerability disclosure policy, technical documentation, CE marking, and the reporting duties for actively exploited vulnerabilities and severe incidents apply to a boot manager as they do to any product in scope. Integrity of updates to early-boot code deserves particular care.

What you must do

  • Design, develop, and produce the product in line with the essential cybersecurity requirements. (Art. 13(1), Annex I Part I)
  • Handle vulnerabilities during the support period, including putting in place and enforcing a coordinated vulnerability disclosure policy. (Art. 13(8), Annex I Part II (5))
  • Draw up technical documentation and carry out the Class I conformity assessment: internal control only with harmonised standards, common specifications, or eligible certification applied in full, otherwise modules B and C or module H via a notified body. Then affix the CE marking. (Art. 13(12), Art. 32(2), Annex VIII)
  • Report actively exploited vulnerabilities and severe incidents once reporting duties start. (Art. 14)

The dates that decide your planning

11 September 2026
Reporting duties start. Actively exploited vulnerabilities and severe incidents must be reported via the single reporting platform: early warning within 24 hours, notification within 72 hours, then a final report (within 14 days after a corrective measure is available for vulnerabilities, within one month after the notification for severe incidents). (Art. 14, Art. 16, Art. 71(2))
11 December 2027
The full obligations apply: essential cybersecurity requirements, technical documentation, conformity assessment, and CE marking. (Art. 71(2))

Frequently asked

Our boot manager is embedded in our own firmware. Is it separately in scope?

Where it is only a component of a wider product you place on the market, Article 7(1) says integrating a listed component does not, on its own, make the surrounding product important. The device or operating system is assessed on its own listing; the boot manager is in scope in its own right where you supply it as a product. (Art. 7(1), Art. 3(1))

Why is a boot manager treated as high-risk?

Because it runs before the operating system and anchors the chain of trust, a compromise there undermines everything that loads afterwards. That is the kind of critical function Article 7(2) uses to justify Class I placement. (Art. 7(2))

Can I still self-assess as a Class I product?

Only where you apply harmonised standards, common specifications, or an eligible European cybersecurity certification scheme at assurance level at least "substantial" in full. Otherwise a notified body route applies (modules B and C, or module H). (Art. 32(2))

When does this start applying?

Reporting duties start 11 September 2026. The full obligations, including the Class I conformity route, apply from 11 December 2027. (Art. 71(2))

Check where your product lands, free

The Vexwatch Scope Checker walks the same cited decision tree in about three minutes: whether you are in scope, in which role, in which category, and which obligations hit on which date.

Check your scope, free See the Blueprint

This page is general information about Regulation (EU) 2024/2847, the EU Cyber Resilience Act. It is compliance tooling, not legal advice, and creates no client relationship. It may not reflect your specific circumstances or the most recent regulatory guidance. Verify conclusions against the regulation or qualified counsel before relying on them.