Cyber Resilience Act: frequently asked questions

The Regulation covers products with digital elements: software or hardware products and their remote data processing solutions. A service that runs entirely on the provider’s own infrastructure is not supplied as such a product, so pure SaaS generally stays outside the CRA; the Cybiq engine reports it as probably out of scope with checks worth running. The Regulation does not settle this boundary with an explicit services provision: if customers install or run anything on their side, such as an app, agent, connector or browser extension, or if the service is sold together with hardware, that element can be in scope.

“a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately”

“This Regulation applies to products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network.”

Not to everyone who touches it, and not only when money changes hands. The Regulation does not apply to people who contribute source code to free and open-source products that are not under their responsibility, and software whose source is openly shared under a licence granting rights to use, modify and redistribute it freely falls within the Regulation’s own definition of free and open-source software. The exclusion ends once the software is supplied in the course of a commercial activity. Recital 15 lists five circumstances that can characterise a commercial activity, and Commission guidance C(2026) 5252 (non-binding) paragraph 41 recalls them. The guidance narrows two of them: paid support around software that stays freely available is not enough on its own, since what decides it is whether access to the software itself is conditioned on payment (paragraphs 55 to 56), and donations, even where they exceed costs, count only when they gate access to the software, its functions or its updates (paragraphs 61 to 62). A free community edition that sits next to a paid edition of the same codebase is not placed on the market on its own terms: only the paid edition is placed on the market, and a legal person publishing the free one is also subject to the obligations on stewards (section 3.2.1, paragraphs 52 to 53).

“does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility”

“software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable”

“open-source software supplied for distribution or use in the course of a commercial activity”

The test is whether the supply happens in the course of a commercial activity, not whether it is paid. Making available on the market is the supply of a product for distribution or use on the Union market in the course of a commercial activity, and the Regulation says explicitly that this counts whether the supply is paid or free of charge; the manufacturer definition names payment, monetisation and free distribution side by side, not one at the expense of the others. A free app, a free tier or a giveaway installer from a business is therefore treated exactly like a paid one once it is supplied in the course of a commercial activity. For free and open-source software specifically, the five circumstances named in “Does the CRA apply to free and open-source software?” decide whether that supply counts as commercial.

“the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”

“a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge”

Usually not. Commission guidance treats a donation link as no evidence of an intention to make a profit, even where donations exceed costs, so long as access to the software, its source code and its updates is not conditioned on donating (section 3.2.4, paragraph 61, example 20). Donations become a price where they are, in practice, that condition: releases or security updates provided to donors only amount to charging for access to the product, and guidance treats a project run that way as placed on the market (paragraph 62, examples 21 and 22).

“the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”

No. The CRA regulates placing on the market and making available on the Union market, both of which involve supplying the product beyond your own organisation. Software that never leaves it triggers neither concept, so the engine returns out of scope for internal-only tools.

“the first making available of a product with digital elements on the Union market”

“the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”

Yes. The definition of a product with digital elements explicitly covers a software or hardware product, and it includes software or hardware components placed on the market separately. Hardware can be in scope even when you ship it without any software of your own, provided its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Art. 2(1)).

“a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately”

Spare parts are excluded where they are made available on the market to replace identical components and are manufactured to the same specifications as the parts they replace. The carve-out is narrow: components placed on the market separately otherwise fall inside the product definition, and if you change a placed product in a way that affects its compliance with the essential requirements, that can be a substantial modification with fresh obligations attached.

“This Regulation does not apply to spare parts that are made available on the market to replace identical components in products with digital elements and that are manufactured according to the same specifications as the components that they are intended to replace.”

“a change to the product with digital elements following its placing on the market, which affects the compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I or which results in a modification to the intended purpose for which the product with digital elements has been assessed”

Products placed on the market before 11 December 2027 stay outside the main requirements unless they undergo a substantial modification from that date. One duty reaches back regardless: the Article 14 reporting obligations apply to all in-scope products, including those placed on the market before the full application date.

“Products with digital elements that have been placed on the market before 11 December 2027 shall be subject to the requirements set out in this Regulation only if, from that date, those products are subject to a substantial modification.”

“By way of derogation from paragraph 2 of this Article, the obligations laid down in Article 14 shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027.”

It means the first making available of a product with digital elements on the Union market. It is a one-off trigger per product: everything that happens afterwards, such as further supplies, updates and vulnerability handling, rests on other concepts like making available and the support-period duties.

“the first making available of a product with digital elements on the Union market”

It means supplying a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge. Supplying something for free therefore counts exactly like selling it, so long as the supply happens in the course of a commercial activity.

“the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”

Yes. The trigger is supply on the Union market in the course of a commercial activity, and nothing in either definition turns on where the seller is established. In practice a seller without an EU establishment reaches the EU market through an importer, which the Regulation defines as a person established in the Union who places on the market a product bearing the name or trademark of a person established outside the Union.

“the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”

“a natural or legal person established in the Union who places on the market a product with digital elements that bears the name or trademark of a natural or legal person established outside the Union”

Where one of the listed Union acts governs the product, that act takes precedence and the CRA does not apply: the list covers medical devices, in-vitro diagnostics and road vehicles, with further exclusions for aviation-certified products and marine equipment. High-risk AI systems are treated differently: they are not excluded from the CRA, and a high-risk AI system that meets the CRA essential cybersecurity requirements is deemed to comply with the AI Act’s cybersecurity requirements, with the two conformity assessments coordinated.

“This Regulation does not apply to products with digital elements to which the following Union legal acts apply:”

“shall be deemed to comply with the cybersecurity requirements set out in Article 15 of that Regulation”

“Regulation (EU) 2024/1689”

It can be. The definition of a product with digital elements includes its remote data processing solutions, and the Regulation defines remote data processing by three elements: it happens at a distance, the product could not perform one of its functions without it, and its software is designed and developed by the manufacturer or under the manufacturer’s responsibility. Commission guidance, which is non-binding, reads the definition the same way: a service you integrate as a fully developed third-party application, with only user-level configuration, is not your remote data processing (guidance section 8.1, paragraphs 184 and 200). A web application used only through a browser is not a product on that basis alone, while the remote processing a locally installed client needs for a function is part of the product (guidance section 2.2, example 5).

The free Is my cloud backend part of the product? Remote data processing check asks these three questions and returns a result with the reasons and sources. Orientation, not legal advice.

“data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions”

“a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately”

A product is important when its core functionality corresponds to a category listed in Annex III; integrating such a product does not by itself bring the host product into that category (Art. 7(1)). The list spans password managers, standalone and embedded browsers, operating systems, network equipment, security tooling such as anti-malware and SIEM systems, smart home locks and cameras, internet-connected toys and health wearables.

“IMPORTANT PRODUCTS WITH DIGITAL ELEMENTS”

“Password managers”

“Standalone and embedded browsers”

“Operating systems”

Both classes sit inside the Annex III list of important products; they differ in how conformity is demonstrated. Class I products keep internal-control self-assessment only while harmonised standards, common specifications or certification schemes are applied in full, otherwise third-party procedures apply. Class II products, such as firewalls, intrusion detection and prevention systems, hypervisors and container runtimes, demonstrate conformity through those third-party procedures, unless the manufacturer qualifies for the Article 32(5) exception: free and open-source software falling under Annex III may instead use the Article 32(1) procedures, provided its Article 31 technical documentation is public at the time of placing on the market.

“Manufacturers of products with digital elements qualifying as free and open-source software, which fall under the categories set out in Annex III, shall be able to demonstrate conformity with the essential cybersecurity requirements set out in Annex I by using one of the procedures referred to in paragraph 1 of this Article, provided that the technical documentation referred to in Article 31 is made available to the public at the time of the placing on the market of those products.”

“the manufacturer has not applied or has applied only in part harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least ‘substantial’ as referred to in Article 27, or where such harmonised standards, common specifications or European cybersecurity certification schemes do not exist, the product with digital elements concerned and the processes put in place by the manufacturer shall be submitted with regard to those essential cybersecurity requirements to either of the following procedures”

“(a) the EU-type examination procedure (based on module B) set out in Annex VIII followed by conformity to EU-type based on internal production control (based on module C) set out in Annex VIII; or (b) a conformity assessment based on full quality assurance (based on module H)”

“Where the product is an important product with digital elements that falls under class II as set out in Annex III, the manufacturer shall demonstrate conformity with the essential cybersecurity requirements set out in Annex I by using any of the following procedures”

“Firewalls, intrusion detection and prevention systems”

Annex IV lists the critical categories: hardware devices with security boxes, smart meter gateways within smart metering systems and other devices for advanced security purposes, including for secure cryptoprocessing, and smartcards or similar devices including secure elements. These face the strictest route: a European cybersecurity certification scheme where one is required under Article 8(1), otherwise the Class II procedures of Article 32(3), which involve a notified body.

“CRITICAL PRODUCTS WITH DIGITAL ELEMENTS”

“Hardware Devices with Security Boxes”

“Smart meter gateways within smart metering systems as defined in Article 2, point (23) of Directive (EU) 2019/944 of the European Parliament and of the Council (¹) and other devices for advanced security purposes, including for secure cryptoprocessing”

“Smartcards or similar devices, including secure elements”

The Regulation does not appoint a classifier: it publishes the Annex III and Annex IV lists, and the manufacturer performs the conformity assessment, which includes working out which listed category fits the product. For Class II and critical products, that choice is then checked by a third party during assessment, a notified body or a certification body under a European cybersecurity certification scheme, rather than taken on trust, unless the manufacturer instead qualifies for the Article 32(5) exception for free and open-source Annex III products with public Article 31 technical documentation, which uses the Article 32(1) procedures with no notified body at all.

“The manufacturer shall perform a conformity assessment of the product with digital elements and the processes put in place by the manufacturer to determine whether the essential cybersecurity requirements set out in Annex I are met.”

“Manufacturers of products with digital elements qualifying as free and open-source software, which fall under the categories set out in Annex III, shall be able to demonstrate conformity with the essential cybersecurity requirements set out in Annex I by using one of the procedures referred to in paragraph 1 of this Article, provided that the technical documentation referred to in Article 31 is made available to the public at the time of the placing on the market of those products.”

“IMPORTANT PRODUCTS WITH DIGITAL ELEMENTS”

“CRITICAL PRODUCTS WITH DIGITAL ELEMENTS”

The Regulation does not settle how to rank overlapping categories: there is no explicit priority rule between annex items. Work conservatively. Identify every category the product matches and follow the route of the most demanding one, because a Class II or critical category requires a third-party procedure, subject to the Article 32(5) exception for free and open-source software, and an overlapping Class I category does not lift that requirement.

“Where the product is an important product with digital elements that falls under class II as set out in Annex III, the manufacturer shall demonstrate conformity with the essential cybersecurity requirements set out in Annex I by using any of the following procedures”

“(a) the EU-type examination procedure (based on module B) set out in Annex VIII followed by conformity to EU-type based on internal production control (based on module C) set out in Annex VIII; or (b) a conformity assessment based on full quality assurance (based on module H)”

Not unconditionally. For Class I products, internal-control self-assessment stays available only where harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least ‘substantial’ are applied in full. If you apply them only partly, or they do not exist for your product, EU-type examination followed by production control (module B+C) or full quality assurance (module H) applies instead.

“the manufacturer has not applied or has applied only in part harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least ‘substantial’ as referred to in Article 27, or where such harmonised standards, common specifications or European cybersecurity certification schemes do not exist, the product with digital elements concerned and the processes put in place by the manufacturer shall be submitted with regard to those essential cybersecurity requirements to either of the following procedures”

“(a) the EU-type examination procedure (based on module B) set out in Annex VIII followed by conformity to EU-type based on internal production control (based on module C) set out in Annex VIII; or (b) a conformity assessment based on full quality assurance (based on module H)”

Yes. The definition covers a person who develops or manufactures products with digital elements or has them designed, developed or manufactured by others, and markets them under its name or trademark, whether for payment, monetisation or free of charge. Resellers who rebrand a product are treated as manufacturers outright: an importer or distributor that places a product on the market under its own name or trademark, or carries out a substantial modification of an already placed product, is considered to be a manufacturer subject to Articles 13 and 14.

“a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge”

“An importer or distributor shall be considered to be a manufacturer for the purposes of this Regulation and shall be subject to Articles 13 and 14, where that importer or distributor places a product with digital elements on the market under its name or trademark or carries out a substantial modification of a product with digital elements already placed on the market.”

Importers place on the market only products that comply with the essential cybersecurity requirements, and they indicate their name, registered trade name or registered trademark on the product. On vulnerabilities they have a pass-through duty: upon becoming aware of one, they inform the manufacturer without undue delay, and where the product presents a significant cybersecurity risk they immediately inform the market surveillance authorities of the Member States where they made it available.

“place on the market only products with digital elements that comply with the essential cybersecurity requirements”

“Importers shall indicate their name, registered trade name or registered trademark”

“Upon becoming aware of a vulnerability in the product with digital elements, importers shall inform the manufacturer without undue delay about that vulnerability”

“where the product with digital elements presents a significant cybersecurity risk, importers shall immediately inform the market surveillance authorities of the Member States in which they have made the product with digital elements available on the market”

Distributors act with due care in relation to the Regulation’s requirements, which includes verifying before making a product available that it bears CE marking and is accompanied by the required documentation. They mirror the importer pass-through duties: informing the manufacturer about vulnerabilities without undue delay, and immediately informing market surveillance authorities where the product presents a significant cybersecurity risk.

“act with due care in relation to the requirements set out in this Regulation”

“Upon becoming aware of a vulnerability in the product with digital elements, distributors shall inform the manufacturer without undue delay about that vulnerability”

“where the product with digital elements presents a significant cybersecurity risk, distributors shall immediately inform the market surveillance authorities of the Member States”

The CRA attaches at the Union border rather than at the company’s registered office. Its definition of importer covers precisely the case of a Union-established person placing on the market a product bearing the name or trademark of a person established outside the Union, and importers may only place compliant products there. A non-EU maker should therefore expect its EU importer to demand conformity evidence before taking stock, because the importer carries its own liability for what it lets through.

“a natural or legal person established in the Union who places on the market a product with digital elements that bears the name or trademark of a natural or legal person established outside the Union”

“place on the market only products with digital elements that comply with the essential cybersecurity requirements”

An open-source software steward is a legal person, other than a manufacturer, that systematically supports the development of specific free and open-source products intended for commercial activities and ensures their viability. Stewards must put in place and document, in a verifiable manner, a cybersecurity policy fostering secure development and effective vulnerability handling, and parts of the Article 14 reporting regime can reach them to the extent they are involved in development.

“a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products”

“Open-source software stewards shall put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product.”

An SBOM (software bill of materials) is a formal record containing details and supply-chain relationships of the components included in the software elements of a product. The required depth is a floor, not a ceiling: it must cover at the very least the top-level dependencies of the product, in a commonly used and machine-readable format. The Regulation names no format; CycloneDX and SPDX are widely used examples.

“a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements”

“software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”

The support period is the period during which a manufacturer must ensure that vulnerabilities are handled effectively and in accordance with the essential cybersecurity requirements. It runs for at least five years. Where the product is expected to be in use for less than five years, the support period corresponds to that expected use time instead.

“the period during which a manufacturer is required to ensure that vulnerabilities of a product with digital elements are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I”

“the support period shall be at least five years”

“Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time.”

Manufacturers must ensure that vulnerabilities of the product are handled effectively and in accordance with the essential cybersecurity requirements: in practice a documented process to receive, triage, fix and publish fixes, with a contact channel for reporters. Products must be made available with a secure by default configuration, unless the manufacturer and a business user agree otherwise for a tailor-made product.

“vulnerabilities of a product with digital elements are handled effectively and in accordance with the essential cybersecurity requirements”

“secure by default configuration, unless otherwise agreed between manufacturer and business user”

Article 14 is addressed to manufacturers, as its own heading states; under Article 24(3), parts of it also apply to open-source software stewards. A manufacturer notifies actively exploited vulnerabilities and severe incidents simultaneously to the CSIRT designated as coordinator and to ENISA via the single reporting platform. The clocks run from awareness: an early warning within 24 hours, a vulnerability notification within 72 hours, a final report for an actively exploited vulnerability no later than 14 days after a corrective or mitigating measure is available, and a final incident report within one month after submitting the incident notification.

“Reporting obligations of manufacturers”

“A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.”

“an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it”

“a vulnerability notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability”

“an early warning notification of a severe incident having an impact on the security of the product with digital elements, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it”

“an incident notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the incident”

“a final report, no later than 14 days after a corrective or mitigating measure is available”

“a final report, within one month after the submission of the incident notification under point (b)”

Article 14 covers an actively exploited vulnerability contained in the product, and a severe incident, not every catalogued vulnerability. The Regulation defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it. Whether that evidence exists is a question of fact about your case: where the only facts are a CVE record, a severity score or a proof of concept, that evidence is absent on those facts. Vulnerability handling under Annex I, Part II, point (2) applies separately.

Two details from Commission guidance, which is non-binding: a vulnerability in a third-party component is reportable only where it is exploited in your own product (paragraph 218; the definition itself speaks of exploitation “in a system”, so where a component flaw is exploited in other systems and not known to be exploited in your product, the check returns “Needs review”), and the clocks start when, after an immediate initial assessment, you have a reasonable degree of certainty about the exploitation or the incident (paragraph 213). The free Is this vulnerability or incident reportable? Article 14 check walks one event through these questions and reports whether your answers describe an actively exploited vulnerability (Article 14(1)) or a severe incident (Article 14(3)). The blog post When does a vulnerability have to be reported under Article 14? sets out the test in the text. Orientation, not legal advice. Cybiq never files or transmits anything on your behalf.

“a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”

“A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.”

“address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates”

Yes. The four notification templates in the EUR 199 pack print the field list and the character limits from ENISA’s CRA Single Reporting Platform glossary, version 1.5 (ENISA’s last update 15 October 2026, read by Cybiq on 19 October 2026), next to the content that Article 14 of Regulation (EU) 2024/2847 requires. The platform column is a specification, not law: the Regulation sets what a notification must contain, and the glossary sets how the platform asks for it.

ENISA changes its glossary, so Cybiq watches it and names the version each document used. Two fields carry a platform note: one arrives in a later release of the platform, and one is labelled “detected” today. Cybiq never files or transmits anything on your behalf.

“Reporting obligations of manufacturers”

“A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of simultaneously to the CSIRT designated as coordinator, in accordance with paragraph 7 of this Article, and to ENISA.”

Yes, for agents and scripts. The MCP tool compute_reporting_deadlines and POST /api/deadlines, both documented on /for-agents.html, take the moment you became aware, which you supply, and return the 24-hour and 72-hour outer limits on their earliest reading, together with a calendar file. Give the date a corrective measure became available, for a vulnerability, or the date you submitted the incident notification, and it also returns the 14-day or one-month final-report limit. Hours are added to the exact moment of awareness, and a month ends on the same calendar day of the next month, clamped to that month’s last day. Each notification is due without undue delay before those limits in any event.

There is no browser calculator by design, because the clock starts from a fact only you know. Cybiq never files or transmits anything on your behalf.

“an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it”

“a vulnerability notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the actively exploited vulnerability”

CE marking is how the manufacturer indicates that the product and the processes put in place conform with the essential cybersecurity requirements. It must be affixed visibly, legibly and indelibly. For products that are software, the marking instead goes on the EU declaration of conformity or on the website accompanying the software product.

“a marking by which a manufacturer indicates that a product with digital elements and the processes put in place by the manufacturer are in conformity with the essential cybersecurity requirements set out in Annex I and other applicable Union harmonisation legislation providing for its affixing”

“visibly, legibly and indelibly indicate their conformity”

“For products with digital elements which are in the form of software, the CE marking shall be affixed either to the EU declaration of conformity referred to in Article 28 or on the website accompanying the software product.”

The technical documentation must be drawn up before the product is placed on the market and continuously updated, where appropriate, at least during the support period. Its content is set out in Annex VII. Watch the numbering: Annex V holds the EU declaration of conformity template, not the technical documentation.

“The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.”

“CONTENT OF THE TECHNICAL DOCUMENTATION”

“EU DECLARATION OF CONFORMITY”

The full compliance pack includes the cybersecurity risk assessment worksheet, section 13. It is an empty structure for you to complete: a table for the context of your product and a risk register with blank numbered rows. Likelihood and impact scales are yours to define and record. The worksheet contains no pre-filled threats and no scoring method, because Cybiq does not perform your assessment and a canned threat list would suggest that it does.

It is not a completed assessment and it is not a certification of compliance. The document is generated in your browser and we don't keep what you enter in it. Cybiq never files or transmits anything on your behalf. Your finished assessment belongs in your technical documentation, which the Regulation requires to be drawn up before the product is placed on the market and continuously updated, where appropriate, at least during the support period. Annex VII sets its content.

“The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.”

“CONTENT OF THE TECHNICAL DOCUMENTATION”

Chapter IV, the notification of conformity assessment bodies (Articles 35 to 51), has applied since 11 June 2026. Article 14 reporting has applied since 11 September 2026. Everything else applies from 11 December 2027.

“This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026.”

“NOTIFICATION OF CONFORMITY ASSESSMENT BODIES”

Member States lay down the rules on penalties and must ensure they are implemented; the Regulation sets the ceilings. Under Article 64(2), non-compliance with the essential cybersecurity requirements and Articles 13 and 14 carries administrative fines of up to EUR 15 000 000 or, for an undertaking, up to 2.5 % of total worldwide annual turnover, whichever is higher. Under Article 64(3), breaches of other operator obligations carry administrative fines of up to EUR 10 000 000 or 2 %, whichever is higher.

“Member States shall lay down the rules on penalties applicable to infringements of this Regulation and shall take all measures necessary to ensure that they are implemented.”

“administrative fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 2,5 % of the its total worldwide annual turnover for the preceding financial year, whichever is higher.”

“administrative fines of up to EUR 10 000 000 or, if the offender is an undertaking, up to 2 % of its total worldwide annual turnover for the preceding financial year, whichever is higher.”

The immediate legal exposure is the penalty regime just described: Member States enforce through nationally laid-down penalties, capped by Article 64’s ceilings. How enforcement proceeds in detail varies by Member State, so treat those ceilings as the outer bound rather than a prediction. Article 14 has applied since 11 September 2026; the other obligations apply from 11 December 2027.

“Member States shall lay down the rules on penalties applicable to infringements of this Regulation and shall take all measures necessary to ensure that they are implemented.”

“administrative fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 2,5 % of the its total worldwide annual turnover for the preceding financial year, whichever is higher.”

Yes, provided the supply happens in the course of a commercial activity. Making available covers supply whether in return for payment or free of charge, so free tiers, giveaways and free downloads from a business count like sales.

“the supply of a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge”

No. The Regulation does not apply to natural or legal persons who contribute source code to free and open-source products that are not under their responsibility. That protection belongs to contributors; running or monetising the project is different, and can put you in scope as a steward or as a manufacturer marketing the software under your name.

“does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility”

Three situations pull third-party assessment in. Annex III Class II products demonstrate conformity through EU-type examination with production control, through full quality assurance, or, where one is available and applicable, through a European cybersecurity certification scheme at assurance level at least ‘substantial’. Annex III Class I products lose internal-control self-assessment when harmonised standards, common specifications or certification schemes are not applied in full. Annex IV critical products face the strictest route throughout. The Article 32(5) exception applies across Annex III: free and open-source software falling under either class may use the Article 32(1) procedures instead, provided its Article 31 technical documentation is public at the time of placing on the market.

“The manufacturer shall perform a conformity assessment of the product with digital elements and the processes put in place by the manufacturer to determine whether the essential cybersecurity requirements set out in Annex I are met.”

“Where the product is an important product with digital elements that falls under class II as set out in Annex III, the manufacturer shall demonstrate conformity with the essential cybersecurity requirements set out in Annex I by using any of the following procedures”

“where available and applicable, a European cybersecurity certification scheme pursuant to Article 27(9) of this Regulation at assurance level at least ‘substantial’ pursuant to Regulation (EU) 2019/881”

“(a) the EU-type examination procedure (based on module B) set out in Annex VIII followed by conformity to EU-type based on internal production control (based on module C) set out in Annex VIII; or (b) a conformity assessment based on full quality assurance (based on module H)”

“CRITICAL PRODUCTS WITH DIGITAL ELEMENTS”

“Manufacturers of products with digital elements qualifying as free and open-source software, which fall under the categories set out in Annex III, shall be able to demonstrate conformity with the essential cybersecurity requirements set out in Annex I by using one of the procedures referred to in paragraph 1 of this Article, provided that the technical documentation referred to in Article 31 is made available to the public at the time of the placing on the market of those products.”

A significant cybersecurity risk is one which, based on its technical characteristics, can be assumed to have a high likelihood of an incident leading to severe negative impact, including considerable material or non-material loss or disruption. This threshold is what obliges importers and distributors to inform market surveillance authorities immediately.

“a cybersecurity risk which, based on its technical characteristics, can be assumed to have a high likelihood of an incident that could lead to a severe negative impact, including by causing considerable material or non-material loss or disruption”

“where the product with digital elements presents a significant cybersecurity risk, importers shall immediately inform the market surveillance authorities of the Member States in which they have made the product with digital elements available on the market”