Article 14 reporting under the Cyber Resilience Act applies from 11 September 2026 to products placed on the market before 11 December 2027. Article 69(2) keeps those products outside the Annex I requirements unless substantially modified from that date.
A vendor statement that current versions are outside the CRA, because they were placed on the market before 11 December 2027, is correct about the product requirements. It leaves out Article 14, which is the CRA duty that applies to the installed base today. This article covers both paragraphs of Article 69, the per-unit rule, the substantial modification test, and what an OEM should ask its suppliers for and give its own customers.
Key takeaways
- Article 69(3) of the Cyber Resilience Act applies Article 14 reporting to products placed on the market before 11 December 2027, so actively exploited vulnerabilities in the installed base are reportable from 11 September 2026.
- Commission guidance C(2026) 5252 states that the Article 14 reporting obligations continue after a product is no longer supported.
- The Commission FAQs read the CRA per unit, so a product type on sale across 11 December 2027 has units on both sides of the date.
- An OEM that integrates third-party software or a third-party component must notify a vulnerability in that component when the vulnerability is actively exploited in the OEM's own product.
- On 26 October 2026 no harmonised standard under the CRA was cited in the Official Journal, so an IEC 62443-4-1 certificate is due diligence evidence and gives no presumption of conformity.
What does Article 69 say about products already on the market?
Article 69 has two paragraphs on the installed base, and the second one limits the first.
Article 69(2) reads: "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."
Article 69(3) reads: "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."
Article 71(2) applies Article 14 from 11 September 2026. The result for one unit of a product in scope is this.
| Obligation | Unit placed before 11 December 2027, not substantially modified | Unit placed from 11 December 2027 |
|---|---|---|
| Annex I essential requirements | No | Yes |
| Conformity assessment, EU declaration of conformity and CE marking | No | Yes |
| Article 13 manufacturer obligations, including the support period | No | Yes |
| Article 14 reporting of actively exploited vulnerabilities and severe incidents | Yes, from 11 September 2026 | Yes |
| Article 14(8) information to impacted users | Yes, from 11 September 2026 | Yes |
Does Article 14 reporting stop when the support period ends?
No. Commission guidance C(2026) 5252 states that the reporting obligations continue after a product is no longer supported (points 210, 217 and 218). The vulnerability handling requirements in Annex I Part II stop with the support period. Reporting does not.
The same points add two limits. Exploitation that the manufacturer knew about before 11 September 2026 is not reportable, but a known vulnerability whose exploitation begins or comes to light after that date is. A vulnerability in an integrated third-party component is reportable only where it is actively exploited in the manufacturer's own product.
The Commission FAQs add that for a legacy product where investigation is impractical, for example because the build environment is gone, the manufacturer must still notify. The deadlines are the same as for a new product.
| Report | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of awareness | Within 24 hours of awareness |
| Notification | Within 72 hours of awareness | Within 72 hours of awareness |
| Final report | Within 14 days after a corrective or mitigating measure is available | Within one month after the 72-hour notification |
Article 14(8) also applies to the installed base. After it becomes aware of an actively exploited vulnerability or a severe incident, the manufacturer must inform the impacted users and, where necessary, tell them about risk mitigation and corrective measures. An operator that runs an old version should know where those notices will arrive.
How does the per-unit rule work for a product type on sale across the date?
The CRA dates apply to each unit. The Commission FAQs give the example of a manufacturer that placed 10,000 non-compliant routers on the market before 11 December 2027. It need not fix them, but it may not place 5,000 more identical units afterwards.
For software sold by licence, the safe reading is that each licence sold for EU use from 11 December 2027 is a new unit. A vendor that plans to sell only a conformant version for EU use from that date follows this reading. A vendor that keeps selling an old version in the EU after the date places non-compliant units on the market.
A product type therefore falls into one of three cases.
| Case | Units placed before 11 December 2027 | Units placed from 11 December 2027 |
|---|---|---|
| Every unit placed before the date, because EU sales stop | Article 14 only, unless substantially modified | None |
| Units placed before and from the date | Article 14 only, unless substantially modified | Full CRA |
| Every unit placed from the date | None | Full CRA |
A product type on sale today that stays on sale after 11 December 2027 is in the second case. The units already in the field need Article 14 readiness now. The units sold from 11 December 2027 need the full conformity file by that date.
When does a unit placed before 11 December 2027 come into full scope?
A unit placed before the date comes into full scope when it is substantially modified from that date. Article 3(30) defines a substantial modification as a change after placing on the market that affects compliance with the essential requirements in Annex I Part I, or that changes the intended purpose for which the product was assessed.
Point 110 of C(2026) 5252 turns that definition into four questions.
- Does the change introduce new threat vectors, such as interfaces, communication channels, execution environments or external dependencies?
- Does it enable new attack scenarios?
- Does it change the likelihood of attack scenarios that are already identified?
- Does it change the potential impact of those scenarios?
Security updates that only reduce risk are generally not substantial modifications. A feature release of an old version after 11 December 2027 that adds a new interface, protocol or module needs the four-question test before release. A major-version upgrade of a system already in the field needs the same test. Record each result, because a market surveillance authority can ask the manufacturer to show why an update was not substantial.
Who carries CRA duties when a product contains third-party software?
Duties follow the role, and one company can hold more than one role.
| Party | CRA role | Duty from 11 September 2026 | Duty from 11 December 2027 |
|---|---|---|---|
| Vendor of a software platform or component sold separately | Manufacturer of the platform or component | Article 14 for all versions in scope | Full CRA for each unit or licence placed from that date |
| OEM that ships the platform or component inside its own product | Manufacturer of its own product | Article 14 where a component vulnerability is actively exploited in its product | Full CRA for units placed from that date, including Article 13(5) due diligence |
| Developer that sells modules or plug-ins for a platform | Manufacturer of each module | Article 14 for its modules | Full CRA for module licences placed from that date |
| System integrator that delivers an application built for one customer | Possibly the manufacturer of a tailor-made product | Article 14, if it is a manufacturer | Full CRA, with two permitted deviations agreed with the customer |
| Operator that runs the product for its own use | No CRA role | None under the CRA | None under the CRA. NIS2 supply chain measures where it is an essential or important entity |
OEMs
Article 3(13) defines a manufacturer as a person who develops or manufactures products with digital elements, or has them developed, "and markets them under its name or trademark". A machine, controller or gateway sold under the OEM's name is the OEM's product, whatever software runs inside it.
The Commission FAQs answer the component question directly. If an actively exploited vulnerability originates in an integrated component, the manufacturer of the product must notify it, and the component's own manufacturer must notify too if the component was placed on the market. Where the vulnerable code cannot be exploited in the product, the OEM has no mandatory report. This applies today to products already shipped.
From 11 December 2027, Article 13(5) requires the OEM to "exercise due diligence when integrating components sourced from third parties". Article 13(6) requires it to report a vulnerability it finds in a component to the person or entity that manufactures or maintains the component. Article 13(8) sets a support period of at least five years and lets the OEM take into account the support periods of integrated components that provide core functions. A product designed for 15 years of use needs the support end date of each core component before the OEM can set its own.
Module and plug-in developers
Point 145 of C(2026) 5252 covers modular products. Where modules are available separately for purchase, licensing or subscription, each module is a standalone product classified on its own core functionality. A developer that sells a module in the course of a commercial activity is the manufacturer of that module, and its Article 14 duty for modules already sold started on 11 September 2026.
System integrators
The answer depends on what the integrator supplies. The Commission FAQs say that products manufactured for own use are not placed on the market, and that tailor-made products stay in scope. For a tailor-made product, the manufacturer and the business user may agree to deviate from two essential requirements, the secure by default configuration in Annex I Part I point 2(b) and free security updates in Annex I Part II point 8.
Configuring a product for its intended purpose is use of the product. Article 22 makes a person a manufacturer only where it carries out a substantial modification and makes the product available on the market. An integrator that delivers an application built for one customer should record in writing whether it treats that application as a tailor-made product, and agree any deviation with the customer.
Operators
The CRA places no duty on an operator that uses a product for its own purposes. NIS2 can. Article 21(2)(d) of Directive (EU) 2022/2555 requires essential and important entities to manage supply chain security. Article 21(3) requires them to take into account the vulnerabilities specific to each direct supplier and the secure development procedures of their suppliers. Energy, drinking water, food production and machinery manufacturing are all NIS2 sectors, and the supplier questions of those operators reach the OEM and the integrator first.
What does a vendor hardening checklist mean for conformity?
The answer depends on what the checklist asks the customer to do. Annex I Part I point 2(b) requires a product to be "made available on the market with a secure by default configuration", with an exception only for a tailor-made product by agreement with a business user.
Annex II point 8(a) requires instructions on "the necessary measures during initial commissioning and throughout the lifetime" of the product. A commissioning checklist fits there.
| Checklist content | CRA fit |
|---|---|
| Site-specific steps, such as certificates, identity provider connection, network zones and user accounts | Annex II point 8(a), commissioning information |
| Security settings that are off at delivery and that the customer must turn on | Conflicts with Annex I Part I point 2(b), secure by default configuration |
Ask the vendor which security settings are on at delivery. For an OEM, the configuration of a third-party platform that it ships inside its product is part of its own product. From 11 December 2027, record the completed checklist in the Annex VII technical documentation of that product.
Does an IEC 62443-4-1 certificate give a presumption of conformity?
No. Article 27(1) gives a presumption of conformity only for harmonised standards "the references of which have been published in the Official Journal of the European Union". On 26 October 2026 no harmonised standard under the CRA was cited there. That includes the horizontal EN 40000 series from CEN-CENELEC JTC 13 and the vertical EN 304 6xx series from ETSI TC CYBER.
The certificate is still useful. IEC 62443-4-1 covers secure development, defect management, security update management and security guidelines, which are themes of Annex I Part II and Annex II. For an OEM, a supplier's certificate is evidence for its Article 13(5) due diligence. Ask for the certificate number, the issuing body, the scope of products and sites, and the expiry date. A certificate without a scope does not tell you whether it covers the version and modules you ship.
What should an OEM ask its platform and component vendors for?
Eight answers cover what a vendor statement usually leaves out.
- The product class and conformity route of the version that will be sold from 11 December 2027, and of each module sold separately.
- The support end date of that version, at least month and year, for the OEM's own Article 13(8) support period.
- The vulnerability contact and coordinated vulnerability disclosure policy, under Annex I Part II points 5 and 6.
- Security advisories in CSAF and VEX statements per version and module.
- Whether a software bill of materials is available and where, under Annex II point 9.
- The hardening checklist, and the list of security settings that are on at delivery.
- Each security certificate with its number, issuing body, scope and expiry date.
- How users of versions placed before 11 December 2027 will receive Article 14(8) information about an actively exploited vulnerability.
Store each answer with its date. An answer without a date cannot go into a technical file.
What should an OEM give its own customers?
An OEM should give its customers the same set of answers for its own product. Operators that are NIS2 entities ask machine builders and integrators for a scope statement, a support end date, a vulnerability contact, advisories and VEX, and a software bill of materials.
For a product with third-party software inside, three details need care.
- Scope and placement. A product in scope with units placed before 11 December 2027 is in scope of the CRA. Article 69(2) removes the requirements from those units, and Article 69(3) keeps Article 14. Say both, and say whether units will also be placed from that date.
- VEX for component vulnerabilities. A CSAF VEX statement per product lets the customer see fast whether a component advisory affects it. Where the affected module is not installed, the CSAF flag
component_not_presentfits. Where the module is installed but the vulnerable function cannot be reached,vulnerable_code_not_in_execute_pathfits. - Software bill of materials. List the platform version and each installed module as separate components, because advisories name modules.
CVD Portal's trust portal shares these records with customers that a manufacturer approves. Each product page shows the CRA scope statement and its basis, and for a product in scope, when its units are placed on the EU market. For units placed before 11 December 2027, the page quotes Article 69(2) and 69(3), and a product with every unit placed before that date shows no empty declaration of conformity. The page also shows the software content statement, the support end date, the vulnerability contact, the CSAF VEX, SBOM and HBOM files, and certificates with their expiry dates. A component or module supplier can publish an integrator security guide built on Annex II points 4, 5, 8(d) and 8(f). The manufacturer can make viewers accept an NDA first, a download log records each download, and a signed evidence pack records what was published and when. The trust portal documentation lists each record. CVD Portal also prepares the Article 14 reports, and an authorised person at the manufacturer files them on the ENISA single reporting platform. To check whether a product is in scope first, start with the free CRA product classifier.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the European Union, L series, 20 November 2024. ELI, CELEX 32024R2847. Articles 3(13), 3(30), 13(5), 13(6), 13(8), 14, 22, 27(1), 69(2), 69(3) and 71(2), Annex I Part I point 2(b), Annex I Part II, and Annex II points 8 and 9.
- European Commission, Commission guidance on the application of Regulation (EU) 2024/2847, annexed to C(2026) 5252 final of 27 July 2026. Points 110, 145, 210, 217 and 218.
- European Commission services, Cyber Resilience Act implementation, frequently asked questions, version 1.4 of 4 September 2026. The FAQs are not binding.
- Directive (EU) 2022/2555 (NIS2), Official Journal of the European Union, L 333, 27 December 2022. ELI, CELEX 32022L2555. Article 21(2)(d) and 21(3).
Frequently asked questions
Do products placed on the market before 11 December 2027 have to meet the CRA requirements?
Only if they are substantially modified from that date. Article 69(2) of the Cyber Resilience Act keeps such products outside the requirements of the Regulation otherwise. Article 69(3) still applies Article 14 reporting to them from 11 September 2026.
Does Article 14 reporting stop when the support period of a product ends?
No. Commission guidance C(2026) 5252 states that Article 14 reporting obligations continue after a product is no longer supported. The vulnerability handling requirements in Annex I Part II stop with the support period. Reporting of actively exploited vulnerabilities and severe incidents does not.
Must an OEM report an actively exploited vulnerability in a third-party component?
Yes, where the vulnerability is actively exploited in the OEM's own product. The Commission FAQs say that the manufacturer of the product must notify it, and the manufacturer of the component must notify too if the component was placed on the market. Where the vulnerable code cannot be exploited in the product, no mandatory report arises.
Does IEC 62443-4-1 certification give a presumption of conformity with the CRA?
No. Article 27(1) of the Cyber Resilience Act gives a presumption of conformity only for harmonised standards whose references are published in the Official Journal. On 26 October 2026 no harmonised standard under the CRA was cited there. An IEC 62443-4-1 certificate is still useful due diligence evidence.