CRA Vulnerability Reporting Is Live: A Practical Readiness Guide for Machine Builders

Nederlands: Lees dit artikel in het Nederlands.

As of 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents affecting products with digital elements under the EU Cyber Resilience Act (CRA). For machine builders, this is no longer a future compliance project. The immediate task is to make sure that product, service and security teams can recognise a reportable event, collect reliable information and submit it through ENISA’s Single Reporting Platform within the required stages.

The difficult part is rarely opening the reporting portal. It is knowing which machines and software releases are affected, who owns the decision, what evidence can be trusted and how a security update can be delivered without creating a safety or availability problem at a customer site.

What changed on 11 September 2026?

The CRA’s reporting duties now apply to manufacturers of products with digital elements made available in the EU. ENISA has launched the Single Reporting Platform for notifications concerning actively exploited vulnerabilities and severe incidents that affect product security. The broader CRA cybersecurity requirements apply from 11 December 2027, but reporting cannot wait until then.

The legal basis is Regulation (EU) 2024/2847. Article 14 sets staged notification duties. In practice, manufacturers need a process that supports an early warning, a fuller notification and a final report as the investigation develops. ENISA’s current CRA reporting FAQ and platform guidance should be treated as operational reference material.

Why machine builders have a harder reporting problem

A machine is not just a single software package. It may contain a PLC, HMI, industrial PC, remote-service component, embedded libraries, drives, safety interfaces and third-party applications. The same machine family may have been delivered in different configurations over many years. Customer modifications and site-specific integrations add further variation.

When a vulnerability is discovered, the first questions are therefore operational:

• Which product versions and customer installations contain the affected component?
• Is the vulnerable function enabled and reachable in the delivered configuration?
• Is there evidence of active exploitation?
• Could exploitation affect the security of the product or contribute to a severe incident?
• Can a patch be tested and deployed safely, and what compensating measure is available until then?

If sales records, software bills of materials, engineering baselines and service histories cannot answer these questions, the reporting team will lose time reconstructing the installed base during an incident.

Build a reporting process that works under pressure

1. Define the product and installed-base record

Start with product families, supported versions, embedded components, support periods and customer installations. Do not wait for a perfect company-wide asset database. Establish the minimum record needed to determine exposure and contact affected customers. For each released configuration, identify the responsible product owner and the location of the approved software and firmware baseline.

2. Create one intake route for vulnerabilities

Customers, researchers, suppliers and service engineers need a visible way to report a possible product vulnerability. The CRA requires manufacturers to designate a single point of contact. Make sure messages reach people who can assess product impact; a general sales inbox is not a vulnerability-handling process.

Record receipt time, reporter contact details, affected product and version, technical evidence, exploitation indicators and any safety or operational consequence. Restrict access to sensitive details, but do not make the intake route so complicated that reporters avoid it.

3. Agree the reporting decision before an incident

Write down who decides whether an event meets the CRA threshold and who is authorised to submit. The decision usually needs product security, engineering, legal or compliance and management input. For industrial products, functional safety and service teams may also be required.

Use a short decision record. It should state what is known, what remains uncertain, which product releases are potentially affected and why the event is or is not considered reportable. This is more useful than a long policy that nobody consults during the first hours.

4. Prepare the information for staged notifications

The first notification will not contain a completed root-cause analysis. Teams need to submit reliable information at the appropriate stage and update it as facts develop. ENISA’s SRP glossary shows the fields used for early warnings, later notifications and final reports.

Prepare an internal worksheet that mirrors the platform fields. Include product identification, versions, exploitation status, incident impact, affected Member States, mitigation, communication status and investigation ownership. Test who can access the SRP and who acts as backup when the primary reporter is unavailable.

5. Connect reporting to remediation and customer communication

Regulatory reporting does not replace technical response. The same workflow must drive containment, patch development, validation, release notes and customer communication. For machinery, patch testing should consider production behaviour, communications, recipes, safety functions and recovery. Where immediate patching is unsafe or impractical, document temporary controls such as access restrictions, segmentation or disabling an exposed service.

A 30-day readiness plan

1. Week 1: appoint a reporting owner and deputy; register or verify access to the ENISA platform; identify the coordinating CSIRT.
2. Week 2: map product families, supported versions, critical software components and available installed-base records.
3. Week 3: document intake, triage, decision, notification, remediation and customer-communication steps. Assign names rather than departments.
4. Week 4: run a tabletop exercise using a realistic vulnerable component in a delivered machine. Time the first two hours and record every missing fact, access problem and unclear decision.

The outcome should be a tested working process, not simply a CRA policy. The exercise will often expose practical gaps in product ownership, version records, supplier escalation, platform access and approval authority.

Frequently asked questions

Do the reporting duties apply only to products placed on the market after 2027?

No. The European Commission’s CRA summary explains that the Article 14 reporting obligations also apply to products with digital elements already made available on the EU market. Manufacturers should confirm the exact scope for their own portfolio and circumstances.

Is a software bill of materials enough?

No. An SBOM can help identify components, but the manufacturer still needs product-version mapping, reachability and configuration context, an installed-base view, decision ownership, a tested reporting route and a safe remediation process.

Does reporting through the SRP complete the incident response?

No. Reporting is one part of vulnerability and incident handling. Investigation, containment, customer communication, corrective action and documented closure still need owners and evidence.

Prepare the process before the next vulnerability arrives

Machine builders do not need to solve every 2027 CRA requirement in one project to improve reporting readiness now. They do need named owners, usable product records, platform access and a rehearsed path from technical signal to reporting decision.

OT-Guard helps machine builders assess their current product-security process, identify practical gaps and translate CRA duties into engineering and service workflows. Read more about our CRA and OT compliance support or discuss a focused readiness review.

Sources: Regulation (EU) 2024/2847; European Commission CRA guidance for manufacturers; ENISA Single Reporting Platform documentation and FAQ. Reviewed 12 September 2026. This article provides practical cybersecurity guidance and is not legal advice.