Key takeaways

• September 11, 2026 opened the CRA’s reporting obligations, a narrower and more urgent target than full compliance, which arrives December 11, 2027.
• A working 24/72-hour reporting workflow, with a named owner and a documented moment of becoming aware, matters more in the first 30 days than closing every compliance item at once.
• Minimum viable CRA posture means knowing your in-scope products, your reporting owner, and your evidence trail. The rest of the program can follow on a roadmap.
• Fines reach EUR 15 million or 2.5% of global annual turnover, whichever is higher, and regulators are expected to weigh intent, pattern, and impact alongside the specifics of each case.

Manufacturers with connected products crossed a real deadline on September 11, 2026, and most of them are still working out what actually changed. The Cyber Resilience Act’s reporting obligations went live that day, years before the regulation’s full requirements take effect in December 2027. The distance between those two dates causes more confusion in CRA planning than almost any other aspect of the regulation, and it is worth resolving first: September 2026 is the day a manufacturer became legally required to report actively exploited vulnerabilities and severe incidents within fixed deadlines, regardless of where the rest of the compliance program stands.

For organizations still building their reporting process, the instinct after the deadline is to sprint toward full CRA compliance. That instinct produces partial progress on everything and a working process on none of the areas that matter most. The better target is narrower: build a reporting mechanism solid enough that no statutory deadline gets missed while the rest of the program catches up on a longer timeline.

What the First 30 Days Should Actually Cover

Six areas carry the reporting obligation, and they need to be resolved before anything else.

The first is ownership. Someone has to be able to say, before any meeting is called, which products count as manufacturer scope, who decides whether an event qualifies as an actively exploited vulnerability (AEV) or a severe incident, and who has the authority to send a report. An incident where CISO, product security, legal, and product management are still debating ownership while the clock runs is the exact failure mode the CRA reporting timeline was built to expose.

The second is the 24/72-hour workflow itself, documented end to end: detection, triage, CRA determination, escalation, report preparation, sign-off, submission through the Single Reporting Platform (SRP), and evidence capture. The CRA requires an early warning, submitted promptly and within 24 hours, followed by a fuller notification within 72 hours.

Third, every organization needs a primary and backup reporting officer. ENISA’s registration and authentication model for Assigned Representatives runs through EU Login, and prior validation by the relevant CSIRT is a separate process that leaves the reporting obligation in place. Waiting for that validation before naming a backup is a planning error, not a compliance requirement.

Fourth is the data itself: product identity, affected versions, countries of distribution, the vulnerability or incident description, any known exploit activity, impact, and remediation status, whether already applied or planned. Assembling this after an incident has started consumes hours the 24-hour window has no room to recover.

Fifth, CRA reporting should plug into existing vulnerability management and incident response ahead of building a parallel process. Adding fields like CRA in scope, AEV suspected, severe incident suspected, time of awareness, 24h deadline, 72h deadline, and SRP notification ID to the existing ticketing system does more for reporting reliability than a standalone CRA tracker built separately.

Sixth, run a tabletop exercise. One actively-exploited-vulnerability scenario, walked through from detection to a hypothetical submission, tests something documentation leaves unresolved: whether the organization can establish the moment of becoming aware, gather the required data, and reach a legal and business decision inside 24 hours.

A practical way to sequence this across 30 days: days 1-5 for scope, ownership, and CSIRT mapping; days 6-10 for the 24/72-hour procedure, RACI, and backup personnel; days 11-15 for SRP and EU Login setup and ticketing integration; days 16-20 for reviewing vulnerability disclosure, incident response, and SBOM data; days 21-25 for the tabletop exercise; and days 26-30 for addressing the issues it surfaces and getting formal sign-off from CISO, Legal, and the product owner.

This structure aligns with how ENISA designed the SRP itself: a single point of submission, with the manufacturer’s report routed to the relevant CSIRT and shared with ENISA at the same time.

Minimum Viable CRA Compliance, Defined

Reporting readiness and full CRA compliance operate on two different clocks, and treating them as the same target is where most readiness assessments lose focus. Full compliance, covering documented risk assessment, systematic vulnerability management, complete SBOMs, and conformity assessment, applies from December 11, 2027.

What needs to be operational now is narrower. An organization should be able to demonstrate that it knows which products with digital elements fall within CRA scope, has a named party responsible for reporting, can identify actively exploited vulnerabilities and severe incidents, records the exact moment it became aware of an event, can produce an early warning inside 24 hours and a fuller notification inside 72, has a final-report mechanism (14 days from remediation availability for an AEV, one month from initial notification for a severe incident), knows its relevant CSIRT, and retains evidence of every decision, submission, deadline, and remediation step.

Everything past that point, full technical documentation, systematic cyber-risk assessments, a mature secure-by-design process, complete SBOMs, formal secure-update procedures, defined support periods, coordinated vulnerability disclosure, and CE conformity preparation, belongs on a roadmap running through the December 2027 deadline. For a CISO or CTO working with limited budget and time, the sequencing rule is straightforward: build the capability to detect, classify, report, and document first. Optimize the surrounding architecture afterward.

Running a Rapid CRA Readiness Assessment

A useful readiness assessment is evidentiary in approach. Asking a team whether vulnerability management is in place produces an affirmative almost every time. Asking them to walk through the last three cases they handled, and show exactly how, produces something closer to the truth.

Start with product scope: the catalog of products with digital elements, the legal manufacturer and the brand under which each is sold, product versions, EU distribution, third-party and open-source components, software dependencies, and any SBOMs already in place. Move next to vulnerability management: the disclosure policy, PSIRT procedure, triage process, SLAs for critical vulnerabilities, vulnerability history, patching process, active-exploit intelligence, and how the moment of awareness gets documented. The CRA requires manufacturers to maintain policies and procedures for handling potential vulnerabilities, document them systematically, and manage them effectively across the support period.

Then check incident response specifically: who can declare an incident, who holds escalation authority to Legal, whether 24/7 escalation exists, whether the process records the precise time of detection and awareness, and whether a procedure exists for incidents affecting the product itself, ahead of general company infrastructure. That last distinction carries real weight: CRA Article 14 governs the security of the product with digital elements, and its reporting scope is narrower than a general IT incident response process.

Documentation review comes next, covering the cybersecurity risk assessment, technical documentation, SBOM, vulnerability records, security update records, product support period, conformity assessment status, and EU Declaration of Conformity where one already exists. Risk assessment has to be documented and reflected in the product’s technical file.

The most revealing part of any readiness assessment is a live simulation: on a Friday at 10:00, credible evidence arrives that a vulnerability in a shipped product is being actively exploited. What happens, in concrete terms, by Saturday at 10:00? If the answer requires several meetings and a debate over who owns the decision, that is an operational readiness problem, regardless of how complete the compliance documentation looks on paper.

How ENISA Vulnerability Reporting Works in Practice

One clarification resolves most confusion here: manufacturers submit through ENISA’s Single Reporting Platform, naming the relevant CSIRT, and the system routes the information to both that CSIRT and ENISA simultaneously. The SRP handles routing to member states automatically.

Ownership inside the company usually sits with PSIRT, Product Security, or Security Operations, formally backed by Legal and Compliance. A functional RACI model looks like this: SOC or Threat Intelligence detects or surfaces exploit evidence; PSIRT or Product Security runs triage and qualifies the vulnerability; Engineering confirms impact and prepares remediation; Legal and Compliance interpret the reporting obligation and legal exposure; the product owner confirms product and version scope; the Assigned Representative performs the formal SRP submission; and the CISO owns oversight and escalation. ENISA generally determines the relevant CSIRT by the manufacturer’s main place of business, or, for manufacturers outside the EU, by the rules governing their authorized representative.

The timeline runs on fixed clocks. From the moment the organization becomes aware, the process starts. An early warning is due within 24 hours, a fuller vulnerability or incident notification within 72 hours, a final report within 14 days of a remediation becoming available for an actively exploited vulnerability, and a final report within one month of the initial notification for a severe incident. The SRP has been operational since September 11, 2026, and ENISA publishes its own guidance on user registration and how to submit and update notifications.

One point worth stressing: the 24-hour clock starts from awareness, not from confirmation. The first submission can carry a limited set of information that gets supplemented as more facts become available. Waiting for full confirmation before submitting is the most common timing error in CRA reporting.

Communicating CRA Status, and What Enforcement Actually Looks Like

The single biggest communication error is telling a customer the organization is CRA compliant before evidence exists to support that claim. An evidence-based statement holds up better and survives scrutiny.

A useful structure covers four layers. First, scope: which products fall under CRA and who owns that responsibility internally. Second, reporting readiness: confirmation that, since September 11, 2026, a process exists to meet Article 14 obligations, including the 24/72-hour workflow. Third, evidence available on request, subject to confidentiality, which can include the vulnerability management policy, PSIRT policy, incident response overview, RACI structure, a sample workflow, SBOM status, secure-update process details, risk assessment status, and conformity assessment status. Fourth, an honest roadmap where full implementation is still in progress, stating plainly that reporting obligations effective from September 2026 are covered by a dedicated operational process, with the remaining requirements following a roadmap toward full CRA application from December 11, 2027.

For OEM customers especially, the strongest signal is traceability: the ability to follow a vulnerability from component to product to version to customer to patch to report. The CRA’s documentation requirements around cybersecurity and vulnerability handling exist to make that traceability possible.

Enforcement carries real financial weight. Violations of Article 13 and 14 obligations, and of the essential cybersecurity requirements in Annex I, can draw administrative fines up to EUR 15 million or 2.5% of the company’s total worldwide annual turnover for the previous year, whichever is higher, with member states setting the detailed enforcement rules. The maximum fine applies in the most serious cases: the CRA requires regulators to weigh the nature, severity, and duration of the violation, its consequences, and the size of the company. Micro and small enterprises are exempt from an administrative penalty for missing the 24-hour early warning deadline specifically, though that exemption covers only that one obligation and leaves the broader set of CRA requirements in place.

Predicting exactly how regulators will rank enforcement priorities falls outside what the CRA text supports, since that would be forecasting. From a risk-management standpoint, the pattern most likely to draw scrutiny involves an organization that learns of active exploitation and lets the reporting deadline pass, misses deadlines repeatedly, lacks a credible detection and classification process, submits incomplete or misleading information, ignores remediation, submits reports with an undocumented awareness timeline, or has a violation with broad market or user impact.

For a CISO, the most valuable asset is the audit trail, not the SRP submission form: when the organization learned of the issue, who classified it and on what basis, when the 24/72-hour clock started, what information was available at each stage, who approved the report, and when it was sent.

The core message for CISOs, CTOs, and Legal: September 11, 2026 is a hard operational deadline for one specific capability, reporting actively exploited vulnerabilities and severe incidents correctly and on time. An organization at roughly 70% CRA readiness should secure that capability first and run the remainder of the program as a controlled roadmap toward December 11, 2027.

FAQ

What is the difference between the CRA reporting deadline and full CRA compliance?

The September 11, 2026 deadline covers a specific obligation: reporting actively exploited vulnerabilities and severe incidents within 24 and 72 hours. Full CRA compliance, including documented risk assessment, SBOMs, and conformity assessment, applies from December 11, 2027. Organizations need working reporting processes now and can build the rest of the program on a longer timeline.

Who is responsible for CRA vulnerability reporting inside an organization?

Ownership typically sits with PSIRT, Product Security, or Security Operations, supported formally by Legal and Compliance. A working model assigns detection to SOC, triage to PSIRT, impact confirmation to Engineering, legal interpretation to Compliance, scope confirmation to the product owner, formal submission to an Assigned Representative, and oversight to the CISO.

How does reporting through the CRA Single Reporting Platform work?

Manufacturers submit through ENISA’s Single Reporting Platform, naming the relevant CSIRT, and the SRP routes the submission to that CSIRT and to ENISA simultaneously. The SRP handles routing simultaneously to the relevant CSIRT and to ENISA. The relevant CSIRT is generally determined by the manufacturer’s main place of business.

What counts as the start of the CRA reporting clock?

The 24-hour early warning and 72-hour notification deadlines start from the moment the organization becomes aware of an actively exploited vulnerability or a severe incident, not from the point of full confirmation. The first submission can include a limited set of information that gets supplemented as more facts become available.

What are the penalties for missing CRA reporting deadlines?

Violations of Article 13 and 14 reporting obligations, and of the Annex I security requirements, can draw fines up to EUR 15 million or 2.5% of global annual turnover, whichever is higher. Regulators are required to weigh the violation’s nature, severity, duration, and impact, along with company size, and apply penalties proportionate to the specific case.

Are small manufacturers exempt from CRA reporting penalties?

Micro and small enterprises are exempt from an administrative fine specifically for missing the 24-hour early warning deadline under Article 14. This exemption covers that one obligation only. The broader set of CRA requirements applies in full.