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

Is a browser an important product under the EU CRA?

Verified against the Official Journal text on

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

Yes, most likely. The CRA names "standalone and embedded browsers" as a category of important products with digital elements (Annex III, Class I, item 2). A product whose core functionality is that of a browser carries the full manufacturer obligations and a restricted conformity route: self-assessment stays available only where harmonised standards, common specifications, or an eligible European cybersecurity certification scheme are applied in full. Embedding a browser engine or a WebView inside a wider app does not, on its own, make that app a browser or an important product.

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

Judgment call: Whether an app "has the core functionality of" a browser, as opposed to embedding one, is a classification judgment. The technical descriptions in Implementing Regulation (EU) 2025/2392 control.

Where the CRA puts browsers Annex III Class I (2), Art. 7(1), Art. 7(4)

Annex III lists the product categories the CRA treats as "important products with digital elements", split into Class I and Class II. Item 2 of Class I reads "standalone and embedded browsers". A product with digital elements that has the core functionality of that category is an important product and becomes subject to the stricter conformity assessment procedures of Article 32(2).

The wording is deliberately broad. It reaches a desktop or mobile browser you ship as a product, and it reaches a browser embedded as the visible, primary way a device or kiosk lets users reach the web. The plain-language label is only the starting point: the binding definition lives in the implementing act.

Embedded browser versus an app that embeds a WebView Art. 7(1), Art. 7(4)

The sharp question for software teams is the WebView. Almost every mobile and desktop app can embed a web rendering component to show help pages, a login flow, or in-app content. That embedding does not turn the host app into a browser. Article 7(1) is explicit that integrating a component with the core functionality of a listed category does not, in itself, make the surrounding product one of those categories.

The line to watch is whether browsing the open web is the point of your product. A hardened kiosk shell whose sole job is to render arbitrary web destinations looks like an embedded browser; a banking app that opens a WebView for one payment step does not. Resolve close calls against the technical description in Implementing Regulation (EU) 2025/2392 and record your reasoning.

Judgment call: The CRA gives no bright-line test for "embedded browser" versus "app with a WebView". The implementing act controls the match, so resolve close calls against it and document your reasoning. Until you have done that, the prudent working assumption is that the stricter Class I route applies.

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 for a requirement, the browser must go through EU-type examination plus conformity to type (modules B and C) or full quality assurance (module H). Both bring in a notified body, so factor lead time and cost into your plan 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 all apply to a browser as they do to any product in scope. For a browser, secure default settings and a working update mechanism carry particular weight.

What you must do

  • Design, develop, and produce the browser 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

My app embeds a WebView. Is it a browser under the CRA?

Not on its own. Integrating a web rendering component does not make the host app a browser, because Article 7(1) says integration of a listed component does not, in itself, make the surrounding product an important one. It becomes a browser only if browsing the open web is its core functionality. (Art. 7(1), Art. 7(4))

Does a browser extension count as a browser?

No. An extension is its own product with digital elements, not a browser, so it does not inherit the Class I browser listing. It still needs its own scope assessment as software placed on the market. (Annex III Class I (2), Art. 3(1))

Can I still self-assess my browser?

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.