CRA Article 14 reporting is the manufacturer’s duty to notify actively exploited vulnerabilities and severe security incidents affecting products with digital elements. Notifications use ENISA’s Single Reporting Platform and the designated coordinator CSIRT, on staged deadlines that apply since 11 September 2026.
Two event types, two final-report clocks
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | Within 24 hours of awareness | Within 24 hours of awareness |
| Notification | Within 72 hours of awareness | Within 72 hours of awareness |
| Final report | Within 14 days after a corrective or mitigating measure is available | Within one month after notification |
Do not treat every CVE match as an Article 14 event. The actively exploited vulnerability and severe incident triggers need a factual assessment. Equally, do not wait until a root-cause investigation is complete before escalating a potentially qualifying event. Record what was known, when it became known and why the team chose the reporting path. If uncertain, seek timely qualified guidance without allowing an internal approval queue to consume the deadline.
Start with an awareness record
The incident owner should record the earliest relevant awareness time, source of the information, affected product, versions and initial assessment. Preserve the original disclosure or alert with access restricted to those who need it. Establish a shared working timeline in UTC, while displaying operational deadlines in the responders’ local time zones. A shift change should not change the time at which the clock started.
The reporting deadline calculator adds 24 and 72 elapsed hours from the selected instant. It rejects ambiguous and nonexistent daylight-saving timestamps. The incident final report uses a calendar month, which must not be replaced by an assumed thirty days. Enter the actual notification time when calculating that final deadline. For vulnerabilities, use the availability of the corrective or mitigating measure as the anchor.
Prepare an early warning with available facts
An early warning is a first notice, not a finished forensic report. Prepare the required information about the affected product and the known event. Distinguish confirmed facts from estimates and identify material uncertainties. Keep the manufacturer contact and technical contact accurate, and arrange an authorised reviewer who can decide quickly. The team should understand who submits if the primary contact is unavailable.
By the notification stage, update the assessment with the information required by the regulation and the SRP workflow. Record impact, affected versions, available mitigations and relevant indicators as appropriate to the event. Keep the submission acknowledgment and a versioned copy of the information sent. Avoid uncontrolled copies of exploit details in broad internal mailing lists.
Use the Single Reporting Platform
ENISA describes the SRP as a single electronic submission route. Manufacturers select the relevant CSIRT designated as coordinator, according to the applicable establishment rules. The information is made available to ENISA through the platform. Non-EU manufacturers should check which coordinator applies to their situation before an incident, rather than improvising the route during the first twenty-four hours.
Set up access and review ENISA’s current registration and submission guidance. A saved draft in an internal portal is not proof of a completed submission. Roja prepares copy-ready drafts and helps track the reporting clock; the customer reviews and submits. That boundary should be explicit in the contract, the incident runbook and the reporting drill.
Close the loop with users and remediation
The authority notification is one part of the response. Assess and meet the duty to inform affected users, distribute mitigation and security updates safely, and document the final technical conclusions. Connect the incident record to the release-specific SBOM and any VEX statements so later reviewers can see which versions were affected and how the issue was resolved.
Practise with an illustrative scenario before a real event. Test receipt of an external report, ownership during a weekend, SRP access, review authority and preparation of the two initial stages. Capture what took too long and fix it. A reporting drill is successful when it exposes and resolves operational gaps, not when every participant silently assumes someone else will submit.
Build evidence that survives a release
Begin with a named product and a reproducible release reference. A marketing model number is not enough when several firmware branches, mobile applications and remote services jointly implement its functions. Record the hardware revision, firmware version, build identifier and necessary remote processing. Decide which older versions remain supported. The CRA work should refer to this boundary consistently, so a reviewer can understand which product a statement describes.
Assign responsibilities before collecting documents. Engineering should own technical facts and remediation. A product owner should agree the intended use, support commitment and customer information. An incident contact should receive vulnerability disclosures and have the authority to escalate them. The manufacturer remains accountable for conformity and reporting even when an external team prepares evidence or drafts. Outsourcing a task does not transfer the underlying obligation.
Retain both the conclusion and the evidence that supports it. An applicability decision without a release reference becomes difficult to defend after a dependency upgrade. A technical file without its underlying test results becomes difficult to update. A useful record links the requirement, the artifact, the reviewer, the decision and its date. Keep open questions visible instead of marking an item complete because a template exists.
Common mistakes to avoid
Do not use a scan score as a compliance decision. Vulnerability matches can be incomplete or inaccurate, and a component version alone does not establish exploitability in the product. Equally, a finding that appears irrelevant needs a documented technical rationale. The evidence should explain whether the affected code is present, reachable and exposed through the supported configuration, and who reviewed that conclusion.
Do not confuse a project completion date with a continuing duty. New releases, new public vulnerabilities and changes to the intended use can change the evidence. Plan how the inventory, risk assessment and customer information will be updated. Check that the incident contact still works and that an on-call substitute can make decisions when the primary owner is unavailable.
Do not assume that company size or a non-EU address removes the obligations. The relevant questions include the product, the economic-operator role and how it reaches the EU market. A distributor, importer, authorised representative and manufacturer can have different responsibilities. Borderline interpretations need qualified review. This guide explains the engineering workflow and does not provide legal advice.
A practical review meeting
Bring the product owner, release engineer and security contact together with the current evidence. Walk through a single supported version rather than discussing a hypothetical future product. Ask which assumptions can be checked immediately, which require a build or test, and which require an external conformity or legal specialist. Finish with a short list of actions, owners and dates. A small, reviewed evidence set is more useful than a large unmaintained folder.
Use the CRA guide to connect this topic to the complete lifecycle. Review the product classes before choosing a conformity route, and connect the release SBOM to the Article 14 reporting workflow. If you need a starting inventory, the free Snapshot is a bounded first step.
Preserve the submission record
Keep the approved draft, actual submission time and platform acknowledgment together. An internal approval timestamp is different from a submitted notice. Identify who reviews whether new facts require a follow-up. The final-report anchor should refer to the actual notification or measure availability, rather than the date somebody planned to send it.
Frequently asked questions
Is this a substitute for a product-specific assessment?
No. Use the guide to organise the engineering work. The product boundary, applicable legal interpretation and conformity route need a documented review.
Does a small team still need a process?
Yes. Assign a product owner, incident contact and substitute. The micro and small enterprise fine exception for 24-hour early warnings does not remove the duties.
Can Roja help with the practical work?
Yes. Our engineers validate inventory, triage findings, prepare reporting drafts and help build the technical evidence. The manufacturer reviews and remains accountable.
Where should we check the requirements?
Start with Regulation (EU) 2024/2847 on EUR-Lex and ENISA guidance for the Single Reporting Platform. Check the current text and your product facts before making a decision.
Sources
General engineering information, reviewed on the date above. Product-specific interpretations and current standards should be checked before a conformity decision. Roja helps manufacturers prepare for the Cyber Resilience Act. We do not certify products or provide legal advice.