DEADLINE · 11 SEPTEMBER 2026
CRA Reporting Ready
From no process to a tested, operational reporting system, in three weeks.
CLOSED SCOPE · DECLARED OUTPUT · AVAILABILITY JULY–AUGUST 2026
THE PROBLEM
The obligation applies to products already on the market too
From 11 September 2026, every manufacturer of products with digital elements sold in the European market is obliged to report actively exploited vulnerabilities and severe incidents that impact the security of their products. Reporting goes through ENISA's Single Reporting Platform, addressed to the national CSIRT, on tight timelines.
The obligation applies to products already on the market, not just new ones. The timelines aren't compatible with improvisation: those who discover on 11 September that they have no process discover it at the worst moment — during a real incident.
The point isn't the sanction. It's that a company able to handle a report in 24 hours has already built half the vulnerability management system the CRA will require in full from December 2027. Arriving ready by September is the first step — the lowest-cost one — toward full compliance.
WHO IT'S FOR
Manufacturers with connected products sold in Europe
This package is for manufacturers of machinery, embedded systems or connected components sold in the European market. Audience: CTO, R&D manager, CEO. It doesn't require an internal security team — the process is sized to the company's real resources.
Are my products in scope?
If the product has software and is connected — or connectable — almost certainly yes. The precise check is part of Phase 1. Better to find out during the briefing than during an inspection.
We've never had incidents. Does it still count?
The obligation doesn't kick in when the incident happens: the process must exist beforehand. Knowledge of an exploited vulnerability can come from a customer or a researcher at any time — often without warning.
Does our system integrator or software vendor handle it?
The obligated party is the manufacturer, not the supplier. The responsibility to notify within 24 hours cannot be delegated by contract.
HOW IT WORKS
Three phases in three weeks
A closed-scope engagement: defined scope, declared output, fixed timeline. Not "by the day, then we'll see".
PHASE 1 — SNAPSHOT · half day on-site or remote · Week 1
Census of products in CRA scope and verification of what already exists in the company.
- Inventory of products with connected or connectable digital elements
- Mapping of the channels through which the company currently learns of vulnerabilities and incidents (customer reports, vendors, researchers)
- Identification of the people involved in the handling chain
- Verification of reusable existing processes: ticket management, quality processes, software vendor contracts
Intermediate output: map of in-scope products and gaps against CRA obligations.
PHASE 2 — PROCESS BUILD · remote work · Weeks 1–2
Design and documentation of the process calibrated to the company's real resources.
- Vulnerability handling and incident reporting process: who receives the report, who assesses, who decides, who notifies — within CRA timelines
- Roles and responsibilities matrix
- Ready-to-use operational templates (early warning, full notification, final report, user communication)
- Publishable coordinated vulnerability disclosure policy (contact channel for researchers and customers)
- Vulnerability and incident register — ready-to-use structure
PHASE 3 — TEST AND HANDOVER · 1 day on-site · Week 3
Tabletop simulation and final handover.
- Tabletop simulation: an exploited vulnerability reported by a customer, handled by the team with the new process, against the 24/72-hour clock
- Identification and correction of the points that don't work under pressure
- Final handover session with CEO/CTO: complete review of the material produced and the next steps
DELIVERED OUTPUT
What stays in the company at the end
Vulnerability handling and incident reporting procedure compliant with CRA requirements
Roles and responsibilities matrix: who does what in the first 24 hours, in the 72, up to the final report
Ready operational templates: early warning, full notification, final report, user communication
Coordinated vulnerability disclosure policy publishable on the company website
Vulnerability and incident register — ready-to-use structure, to populate right away
Documented outcome of the tabletop simulation with the residual points of attention
SCOPE
What this package doesn't cover
CRA Reporting Ready solves a specific obligation with a date: the reporting process, operational from 11 September 2026. It doesn't include:
- Full CRA compliance (essential requirements, technical file, conformity assessment) — deadline December 2027
- Continuous monitoring of vulnerabilities over time
- Management of real incidents in progress at the time of the engagement
These elements are covered by subsequent paths — the CRA Compliance Manager for annual oversight, the OT Compass for the full snapshot of exposure.
IN THE CRA PATH
The first step, the lowest-cost one
Those who complete CRA Reporting Ready have already experienced first-hand that the CRA obligations are continuous: CVE monitoring, SBOM updates, technical documentation don't stop after September. The natural next step is the CRA Compliance Manager — and onboarding is already done: knowledge of the company is included in the package.
The useful window to start is now
The engagement lasts three calendar weeks. Those who want to be ready by 11 September must start by July. To check whether your products fall under the reporting obligations, the Regulatory Spark is the starting point: 45 free minutes to map your exposure and confirm whether this package is the right one.
Book the Regulatory Spark — free