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, which 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, meaning 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.

Who receives the reports and how to reach them

There are two recipients for every Article 14 report: ENISA and your national CSIRT.

ENISA maintains the European Vulnerability Database (EUVDB) and operates the Single Reporting Platform (SRP), the central submission channel for CRA notifications. When you submit through the SRP, the report is routed automatically to both ENISA and the relevant national CSIRT. You do not need to contact them separately.

The national CSIRT is determined by the country where your company is legally established, not where your customers are located. For companies with operations across multiple EU member states, the CSIRT of the country where your registered office is located receives the report.

CSIRT contacts by country:

For companies registered in Poland: CERT Polska (CSIRT NASK) at cert.pl. CERT Polska is the national CSIRT under the Polish Cybersecurity Act and the designated recipient for CRA notifications for Polish-registered entities.

For companies registered in Germany: BSI (Bundesamt für Sicherheit in der Informationstechnik) at bsi.bund.de. The BSI operates a dedicated incident reporting portal for regulated entities.

For companies registered in the Netherlands: NCSC-NL (Nationaal Cyber Security Centrum) at ncsc.nl.

For companies registered in Finland: TRAFICOM / CERT-FI at traficom.fi/en/communications/cyber-security.

For companies registered outside the EU that sell into the EU market: you are required to designate an authorised representative established in the EU. That representative's member state determines which national CSIRT receives your reports.

Regardless of country, the ENISA SRP submission handles the routing. Direct CSIRT contact is relevant when you need to communicate outside the SRP — for example to request guidance before an incident occurs, or to follow up on a submitted report.

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 internal document you need to write

The minimum viable version of your Article 14 process is a single internal document. It does not need to be long. It needs to exist, be understood by the people who will use it, and be findable in the first minutes of an incident.

Here is what it should contain:

Security contact and intake. The published email address (security@yourdomain.com). Who monitors it and how often. Who is subscribed to component supplier security advisories (Espressif, Nordic, Zephyr, your BLE module vendor). What the process is when a report arrives outside business hours.

Triage criteria. The definition of an Article 14 event: active exploitation confirmed in a product your company places on the EU market. Who makes the triage decision. What information is needed to make it. The escalation path if the primary person is unavailable.

Notification contacts. The ENISA SRP submission URL. The email or portal for your national CSIRT as a direct backup. The names and contact details of the two or three people in your organisation authorised to submit Article 14 reports.

Notification templates. A draft 24-hour early warning with fields to fill in: company name and contact, product name and affected versions, brief vulnerability description, evidence of active exploitation, current severity assessment, whether a fix or workaround exists. A draft 72-hour notification with expanded fields. Both should be ready to send with 30 minutes of editing, not written from scratch during an incident.

Patch timeline commitments. By severity level, what is your internal target from confirmed vulnerability to patch available. These do not need to be contractual obligations. They need to be realistic and documented so that everyone involved understands the expectation before an incident happens.

Customer notification procedure. How affected customers are informed about a security update. Who drafts the message. Who approves it. What channel it goes through.

Review this document once a year and after any incident. Make sure new team members are aware it exists.

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.

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.

What happens if you do not report

For manufacturers that do not qualify for the SME exemption, the penalty framework under CRA Article 64(2) applies directly to Article 14 violations. Failure to meet vulnerability reporting obligations can result in fines up to €15 million or 2.5% of global annual turnover, whichever is higher. Article 14 sits in the highest penalty tier of the regulation alongside the core Annex I security requirements.

Beyond the financial penalty, non-compliance with reporting obligations can trigger product withdrawal orders. Authorities can require you to take a product off the market until compliance is demonstrated. For manufacturers with a small customer base and a limited public profile, the reputational impact of a disclosed non-compliance is often the larger practical risk.

A security incident handled transparently, with timely notification to authorities and customers, is recoverable. An incident where the manufacturer failed to report and customers found out through other channels is a different situation.

The practical implication of the SME exemption: 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.
  • Confirm the CSIRT contact details for your country and include them in your internal process document.

In the next 60 days:

  • Write the internal process document described in this article. Assign ownership to a named person.
  • Run a tabletop exercise. Describe a scenario: a CVE drops for a library you ship, and proof-of-concept exploit code appears on GitHub the next morning. Walk through the process from the moment your team sees it to the moment the early warning is submitted. Time it. You will find where it breaks down, and it is much better to find that now than during a real incident.
  • Assess your firmware version tracking. Can you determine within an hour which deployed units are running a vulnerable firmware version? If not, that is a gap to address before September.

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.

What is the fine for not reporting under Article 14? Article 14 violations fall under the highest penalty tier in CRA Article 64(2). For companies that do not qualify for the SME exemption, fines can reach €15 million or 2.5% of global annual turnover, whichever is higher. Market surveillance authorities can also order product withdrawals independently of any financial penalty.

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.