The EU Cyber Resilience Act — Regulation (EU) 2024/2847 — entered into force in December 2024 with most of its substantive obligations deferred to 11 December 2027. One block of obligations was not deferred that far.

Article 14 applies from 11 September 2026. That is three weeks and two days from the date of this article.

From that date, manufacturers of products with digital elements placed on the EU market must report actively exploited vulnerabilities and severe incidents having an impact on the security of the product to their national CSIRT and to ENISA, through the CRA Single Reporting Platform, on a fixed escalating cascade.

This site published an overview of the June and September 2026 CRA reporting deadlines in February and an implementation guide last October. This piece is narrower: with three weeks left, what has to be operationally true on 11 September, and what is realistically achievable if it is not true today.

The cascade, precisely

For an actively exploited vulnerability in a product with digital elements:

  • Within 24 hours of becoming aware: an early warning to the CSIRT designated as coordinator and to ENISA, indicating whether the exploitation is believed to be carried out by a malicious actor and in which member states the product is made available.
  • Within 72 hours of becoming aware: a vulnerability notification providing general information about the product, the general nature of the exploit and the vulnerability, and any corrective or mitigating measures taken or that users can take.
  • Within 14 days of a corrective or mitigating measure becoming available: a final report including a description of the vulnerability, its severity and impact, and — where available — information about the actor exploiting it, plus details of the security update or corrective measure.

For a severe incident having an impact on the security of the product:

  • Within 24 hours: an early warning, indicating whether the incident is suspected to be caused by unlawful or malicious acts.
  • Within 72 hours: an incident notification with general information about the nature of the incident, an initial assessment, and any corrective or mitigating measures.
  • Within one month of the 72-hour notification: a final report, including a detailed description, severity and impact, the type of threat or root cause where available, and applied and ongoing mitigation measures.

Manufacturers must also, without undue delay and after becoming aware, inform the impacted users of the product about the vulnerability or incident and, where necessary, about corrective measures and risk mitigation actions the user can take.

Open-source software stewards carry a modified version of these obligations under Article 15.

The word that decides everything: “aware”

Every clock in Article 14 runs from becoming aware. There is no definition that makes “aware” a formal internal determination, and no grace period between technical detection and the start of the 24-hour window.

This produces the single most consequential operational question of the whole regime: who, inside your organisation, can become aware, and how fast does that awareness reach the person who can file?

In most manufacturers, the answer today is that awareness can arrive through at least six channels, most of which are not wired to anything:

  • The PSIRT mailbox or security@ address — usually monitored, but often only in business hours
  • A CVE or GHSA advisory against a component in your product — arriving through a scanner, or through nobody
  • Threat intelligence reporting exploitation of a vulnerability you already knew about but had triaged as low priority
  • A customer support ticket describing behaviour that a support engineer does not recognise as exploitation
  • A CISA KEV addition naming a component you ship
  • A researcher on social media publishing a proof of concept

The 24-hour clock does not wait for that signal to travel through three queues and a weekly triage meeting. If a support engineer received credible information on Friday evening and the PSIRT read it on Monday, the regulator’s view of “aware” is unlikely to be Monday.

A vulnerability you already know about becomes reportable the moment it becomes actively exploited. This is the trap in the regime. The trigger is not disclosure and not severity — it is exploitation. A medium-severity issue in a shipped product, triaged months ago and scheduled for a future release, converts into a 24-hour reporting obligation the day a KEV entry or a threat intelligence report says it is being exploited in the wild. That requires continuous monitoring of exploitation status against your entire shipped component inventory, not periodic vulnerability scanning.

The legacy inventory problem

The provision that catches most manufacturers by surprise: Article 14’s reporting obligations apply to products with digital elements placed on the market before 11 December 2027.

The CRA’s design requirements — secure by default, vulnerability handling processes, SBOM, security updates — apply to products placed on the market from December 2027. But the reporting obligation is not limited to CRA-conformant products. From 11 September 2026, if a product with digital elements is on the EU market and an actively exploited vulnerability in it comes to your attention, you report.

For a manufacturer with a decade of shipped hardware and software in the field, that means the reporting perimeter is everything currently available on the EU market, not the next product generation. Which in turn means:

  • You need to know what you have on the EU market. For many manufacturers, particularly those selling through distribution, this is genuinely uncertain at the edges.
  • You need to know which member states each product is made available in, because the early warning asks for it.
  • You need to know what components are inside those products — including end-of-life dependencies you no longer track, which is exactly where actively exploited vulnerabilities concentrate.

The end-of-life dependency point deserves emphasis. A product shipped in 2021 running an unsupported runtime version does not stop generating reporting obligations because the runtime is unsupported. It generates more of them, because unsupported components accumulate exploited vulnerabilities and receive no fixes. And the 14-day final report clock runs from when a corrective or mitigating measure becomes available — so a manufacturer with no path to a fix must produce a mitigation, and tell users about it.

The Single Reporting Platform

ENISA is responsible for establishing and operating the CRA Single Reporting Platform (SRP) — a centralised electronic system acting as a single entry point for reports from manufacturers and open-source stewards. It is to be operational by 11 September 2026, with testing before that date.

Reports are submitted once through the SRP and routed to the CSIRT designated as coordinator in the member state where the manufacturer has its main establishment, and simultaneously to ENISA except in exceptional circumstances.

Three practical points:

Register and test before you need it. The worst possible time to discover that nobody at your company has SRP credentials is hour one of a 24-hour clock. Onboarding, account provisioning and role assignment should be complete before 11 September, with at least two named individuals holding access and a documented process for after-hours use.

Determine your main establishment now, and write it down. The routing of your reports depends on it. For a group with entities in multiple member states, this is a legal determination, not an IT one, and it should be made in advance rather than argued about during an incident.

The single-entry-point design does not discharge other regimes. A severe incident at an entity in scope of NIS2 may generate an Article 23 notification and a CRA Article 14 report. A financial-sector manufacturer may face DORA obligations in parallel. A personal-data breach triggers GDPR Article 33 within 72 hours. The SRP consolidates CRA reporting; it does not consolidate European incident reporting generally. Organisations that have built a single 72-hour muscle around GDPR will find the CRA’s 24-hour front end is a materially different capability.

Penalties

Infringement of the Article 14 reporting obligations is subject to administrative fines of up to EUR 15,000,000 or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.

That is the same tier as breaches of the essential cybersecurity requirements in Annex I. The regulation does not treat late reporting as a lesser offence than shipping an insecure product.

Three weeks: what is achievable

If your Article 14 readiness is incomplete, the following is a realistic sequence for the remaining time. It is deliberately ordered by what fails first if omitted.

Week 1 — establish the intake and the clock.

  • Designate a single reporting decision-maker and a named deputy, with 24/7 reachability. One person owns the “does this start a clock” call.
  • Consolidate every awareness channel into one intake: security@, PSIRT mailbox, support escalation path, scanner alerts, KEV feed, threat intel feed. Route them to one queue with a documented response-time expectation measured in hours, not days.
  • Write the awareness-to-decision procedure: on receipt of credible information about possible exploitation, the decision-maker is engaged within a stated number of hours, and the 24-hour clock is presumed to have started at the time of first credible receipt unless documented otherwise. Presuming the earlier start is the safe posture.
  • Register for the SRP and provision at least two accounts.

Week 2 — establish the perimeter.

  • Produce a list of products with digital elements currently available on the EU market, with member-state availability per product. Imperfect is acceptable; absent is not.
  • Map each to its component inventory / SBOM. Where no SBOM exists for a legacy product, record that gap explicitly with an owner — it will be needed for the December 2027 obligations regardless.
  • Cross-reference the component inventory against CISA KEV and your threat intel sources. Anything already flagged as actively exploited in a shipped product is a report you may owe on day one.

Week 3 — rehearse.

  • Draft report templates for both scenarios, pre-populated with everything that does not vary: legal entity, main establishment, contact details, product identifiers, member-state availability.
  • Run a timed tabletop. Inject a credible exploitation report at an inconvenient hour. Measure the elapsed time from injection to a submitted early warning. If it exceeds 24 hours in the exercise, it will exceed 24 hours in reality.
  • Agree the user notification path in parallel — Article 14(8) requires informing impacted users without undue delay, and that is a separate workflow involving product, support and communications.
  • Brief executive leadership on the trigger, the timeline and the penalty exposure, so that the first time they hear about a 24-hour EU reporting obligation is not during one.

The honest assessment

Three weeks is not enough time to build a mature product security incident response function. It is enough time to build the two things that determine whether you fail visibly: a single intake that cannot lose a signal, and a named person who can file within 24 hours.

Manufacturers that have those on 11 September will report imperfectly and improve. Manufacturers that do not will discover the obligation retrospectively, when a researcher publishes, a customer asks, or a regulator writes — and the record will show a clock that started days before anyone inside the company noticed.

This article is provided for informational purposes only and does not constitute legal advice.