Three months from now, on September 11, 2026, Article 14 of the EU Cyber Resilience Act enters into force. From that date, manufacturers of connected products sold in the EU have a legal obligation to report actively exploited vulnerabilities to EU authorities within 24 hours of becoming aware of them.

This is not a preparation deadline for December 2027. This is an operational requirement that applies right now - to products already on the EU market, not just products launched after the compliance date.

Most of the manufacturers I speak with are focused on December 2027. Very few have a functioning vulnerability reporting process. This article explains what Article 14 specifically requires, who it applies to, and what needs to be in place before September.

If you are new to CRA, our complete guide to the EU Cyber Resilience Act covers the full regulation, deadlines, and technical requirements in detail.

What Article 14 actually is - and what it is not

Article 14 is the vulnerability and incident reporting obligation within CRA. It is distinct from the broader product security requirements in Annex I - those apply from December 2027. Article 14 applies from September 11, 2026, specifically because the EU determined that active threat response cannot wait for the full compliance timeline.

The obligation covers two categories:

Actively exploited vulnerabilities - a vulnerability in your product for which there is evidence of real-world exploitation in active attacks. Not theoretical risk. Not a published CVE with no observed exploitation. Evidence that attackers are using it against deployed products.

Severe security incidents - incidents that significantly impact the security of your product in a way that affects users. An active compromise with measurable user impact, not a routine bug or minor security finding.

This distinction matters because it defines what triggers your reporting clock - and what does not. Routine vulnerability management, patch releases, and minor security fixes do not trigger Article 14 reporting. But the moment you have evidence of active exploitation, the 24-hour clock starts.

Who this applies to

The scope is broader than many manufacturers realize.

Article 14 applies to any manufacturer of a product with digital elements that is placed on the EU market - regardless of where the manufacturer is based, and regardless of when the product was launched.

A device sold in the EU today is covered. A product that shipped two years ago and is still in active use is covered. The obligation is not conditional on the product being "CRA-compliant" - it applies to the entire installed base of connected devices currently on the EU market.

This is the part of Article 14 that catches manufacturers by surprise. Many assume CRA obligations only apply to new products released after December 2027. For Article 14, that assumption is wrong. The reporting obligation starts September 11 for everything currently on the market.

The reporting timeline

Article 14 establishes a three-stage reporting structure with specific deadlines:

Within 24 hours of becoming aware: An early warning notification. You report that an actively exploited vulnerability exists in your product. A full analysis is not required at this stage - you report what you know, confirm the vulnerability is being actively exploited, identify the affected products, and note that investigation is ongoing. The notification goes through ENISA's Single Reporting Platform (SRP), which routes simultaneously to your national CSIRT and to ENISA. You submit once.

Within 72 hours of becoming aware: A complete notification. This requires more detail: the nature of the vulnerability, potential impact, affected product versions, preliminary measures taken or underway to address it. If your investigation is not complete within 72 hours, you report what is known and indicate that a final report is forthcoming.

Within 14 days of a fix being available: A final report. Root cause analysis, CVE assignment status if applicable, the patch details, and recommendations for users on how to protect themselves.

For severe security incidents - active compromises rather than specific vulnerabilities - the structure is the same: 24-hour early warning, 72-hour full notification, final report within one month.

The 24-hour clock starts when you become aware of active exploitation - not when you begin your investigation, not when you have confirmed the scope, not when your security team has completed their analysis. Awareness triggers the obligation.

What manufacturers need to have in place

Meeting Article 14 in practice requires three operational capabilities that take months to build. None of them can be assembled on short notice after an incident has already occurred.

1. Vulnerability monitoring

You need to know about actively exploited vulnerabilities in your product before you receive a report from a customer, a security researcher, or a news article. That means active post-release monitoring of your component stack against vulnerability databases and threat intelligence sources.

The foundation of this is an accurate, current SBOM - a complete inventory of every software component and version in your shipping firmware. Without a live SBOM, you cannot run systematic CVE checks against your product. Without CVE monitoring, you cannot become aware of active exploitation in a timeframe that makes the 24-hour window achievable.

Useful sources for monitoring include the NIST National Vulnerability Database, vendor security advisories, and CISA's Known Exploited Vulnerabilities catalogue - which tracks vulnerabilities with confirmed real-world exploitation and is directly relevant to the Article 14 trigger condition.

2. Internal escalation process

When a potential Article 14 event is identified, someone needs to make a reporting decision quickly. Who in your organization has the authority to determine that a vulnerability qualifies for mandatory government notification? Who is responsible for preparing and submitting the report? Who communicates with the reporter if the vulnerability was disclosed externally?

If the answer to any of these questions is "we would figure it out when it happens," you will miss the 24-hour window. The decision process, the authorization chain, and the submission workflow need to be documented and understood before an incident occurs - not drafted during one.

For a small team, this does not require a formal ISMS or a dedicated security operations function. It requires a written process with clear ownership. One page is better than nothing.

3. Coordinated Vulnerability Disclosure contact

Article 14 also requires manufacturers to maintain a publicly accessible contact point through which vulnerabilities can be reported to them. In practice this is a security@yourdomain.com address and a published vulnerability disclosure policy - a short document explaining that you accept reports, what information you need, what reporters can expect in terms of response time, and your commitment to addressing genuine findings.

This is one of the simplest Article 14 requirements to implement and one of the most frequently outstanding. Setting up a dedicated email address and a basic disclosure policy takes an hour. There is no reason to have this pending.

The SME exemption - what it covers and what it does not

Article 64 of the CRA contains a specific provision for microenterprises and small enterprises: companies with fewer than 50 employees and annual turnover under 10 million euros.

For these companies, financial penalties for missing the 24-hour early warning notification are capped or limited compared to the general penalty framework.

This exemption is narrower than it sounds and is frequently misunderstood.

The exemption covers the financial penalty exposure for the 24-hour early warning specifically. It does not exempt small enterprises from the reporting obligation itself - the requirement to notify still applies. It does not cover the 72-hour full notification or the final report. And it does not protect against non-financial enforcement actions: market surveillance authorities can still require corrective measures, order product withdrawals, or issue public notices regardless of company size.

The practical implication: if you are a small manufacturer, the financial risk from missing the 24-hour window is reduced. The operational and reputational risk from an unmanaged incident - and the legal requirement to have a reporting process - remains fully in force.

The connection to product architecture

There is a direct relationship between your product's technical architecture and your ability to meet Article 14 obligations that does not get enough attention in compliance discussions.

If your devices have no mechanism for you to identify which firmware version is running in the field - if every unit in a production batch is architecturally identical with no unique device identity - you cannot accurately scope an incident. Your 72-hour report will contain incomplete information about affected products and versions.

If you have no functioning OTA update mechanism, you cannot verify that a patch was successfully deployed after a vulnerability is addressed. Your final report cannot confirm remediation.

These architectural gaps do not make Article 14 compliance impossible. They make it slower, less complete, and more exposed to scrutiny from market surveillance authorities assessing whether your incident response was adequate.

The manufacturers who handle the September 2026 obligations well are the ones who have already invested in the foundational architecture: unique device identity, firmware version tracking, a functioning update channel, and an SBOM-backed monitoring process. These are not separate compliance projects - they are the same technical investment that enables everything else.

To understand how product classification affects your compliance path, see our guide on CRA product categories: Default, Important Class I, and Class II.

A preparation checklist for September 11

This week:

  • Set up security@yourdomain.com and publish a basic vulnerability disclosure policy. One hour.
  • Generate or update your SBOM. If you do not have a current component inventory, start here - everything else depends on it.

In the next 30 days:

  • Subscribe to vulnerability monitoring for your component stack: NVD feeds, vendor advisories, CISA KEV.
  • Document your internal escalation process. Who receives reports, who makes the reporting decision, who submits to ENISA via the SRP. Write it down.
  • Review ENISA's Single Reporting Platform so the submission interface is not unfamiliar when you need it.

In the next 60 days:

  • Run a tabletop exercise. Simulate discovering a critical CVE on a Monday morning and walk through the 24-hour process end to end. Find the gaps before they appear in a real incident.
  • Assess your firmware version tracking. Can you determine within an hour which deployed units are running a vulnerable version? If not, that is a gap to address.

FAQ

Does Article 14 apply to my product if it was released before CRA passed? Yes. Article 14 applies to products currently on the EU market, regardless of when they were placed there. The September 2026 deadline is not contingent on your product being "CRA-compliant" in the broader sense.

What is the difference between Article 14 and the December 2027 requirements? Article 14 covers ongoing vulnerability and incident reporting obligations - an operational process requirement. The December 2027 deadline covers product security requirements: the technical architecture your product must have before it can be placed on the EU market. Both apply to manufacturers, but on different timelines.

What if we discover a vulnerability is being exploited but our investigation is not complete within 24 hours? The 24-hour early warning is designed for this situation. You report that an actively exploited vulnerability exists, identify the affected products, and note that investigation is ongoing. You do not need a complete analysis to file the early warning - you need to notify. The full analysis follows in the 72-hour notification.

We have no security team. Is Article 14 compliance realistic for a small manufacturer? Yes - with the right preparation. The process does not need to be complex. A written escalation process, an accurate SBOM, active CVE monitoring, and a published disclosure contact are achievable for any size organization. The critical factor is having them in place before an incident occurs, not during one.

What counts as "becoming aware" for the 24-hour clock? Awareness in this context means having information indicating that an actively exploited vulnerability exists in your product. If a security researcher reports an active exploit to your security contact, the clock starts. If your monitoring identifies a CVE in your component stack with confirmed active exploitation in the wild, the clock starts. If a customer reports signs of a compromised device, an investigation confirming active exploitation starts the clock.

Sources: EU Cyber Resilience Act - Regulation (EU) 2024/2847, Article 14 and Article 64; European Commission CRA overview; CISA Known Exploited Vulnerabilities Catalogue

Valentyna Shulga is the CEO of Platanor Technologies. Platanor works with IoT and hardware manufacturers on the embedded security architecture and CRA compliance documentation required to meet both the September 2026 and December 2027 obligations. Reach our team at platanor.com/contact.