Cyber Resilience Act Reporting: What Software Teams Need to Know
Cyber Resilience Act reporting obligations begin on September 11, 2026, for manufacturers subject to Article 14. The change concerns actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. It does not mean every requirement of the regulation takes effect on the same day.
The European Commission's Cyber Resilience Act legislative summary distinguishes this reporting milestone from the main provisions applying on December 11, 2027. For software businesses, the immediate challenge is connecting product ownership, security investigation and reporting responsibility before an urgent event occurs.
The practical priority: determine which products and responsibilities are in scope, establish an escalation route and rehearse the reporting workflow. This article provides technical and operational preparation guidance, not legal advice or a determination that a particular business must report.
Start With Product Scope, Not Company Location
The CRA addresses products with digital elements made available on the EU market, subject to its scope and exclusions. A US headquarters is not enough to conclude that a business has no exposure. Equally, having European website visitors does not establish that every service is a covered product.
Build an inventory that connects each product to its legal entity, distribution model, versions and responsible team. Ask qualified counsel to assess the product and the organization's role. Avoid treating software manufacturers, distributors and open-source contributors as interchangeable categories.
Existing products should not be ignored simply because the main provisions apply later. The Commission explains that reporting obligations also cover relevant products already placed on the market before December 11, 2027. The assessment therefore needs more than a list of planned launches.
For an engineering team, the useful deliverable is a reviewed scope register. It should show the decision, its owner and unresolved questions. That register lets responders find the responsible people without improvising a jurisdictional assessment during an incident.
Which Events Trigger CRA Reporting?
Mandatory reporting distinguishes actively exploited vulnerabilities from severe incidents affecting product security. ENISA describes active exploitation in terms of reliable evidence of malicious exploitation, rather than the mere existence of a weakness. A vulnerability scan result alone is not equivalent to that evidence.
That distinction should shape triage. Record what was observed, which product versions may be affected and whether the evidence supports exploitation or a severe incident. Keep confirmed facts separate from hypotheses while security and legal owners assess the applicable criteria.
Do not use an internal ticket priority as a substitute for that assessment. A critical severity label may justify urgent remediation without independently establishing the reporting trigger. Conversely, an incident can deserve escalation before the team understands its full root cause.
Teams already using AI in delivery should apply the same evidence discipline to automated findings. Our guide to AI risk management in software development discusses controls around generated code and development workflows. An automated summary can support triage; it should not silently make the reporting decision.
Cyber Resilience Act Reporting Deadlines
The ENISA reporting FAQ sets out the staged deadlines below. Early warnings and notifications are required without undue delay; the hour limits are outer deadlines, not recommended waiting periods.
| Stage | Deadline | Time reference |
|---|---|---|
| Early warning | Within 24 hours | Awareness of the reportable vulnerability or severe incident |
| Vulnerability or incident notification | Within 72 hours | The same awareness point, not the early warning |
| Final vulnerability report | No later than 14 days | After a corrective measure becomes available |
| Final severe incident report | Within one month | After the 72-hour notification |
Record timestamps consistently, including the timezone and supporting evidence. An internal acknowledgment, investigation update and notification submission are different events. Preserve the sequence so reviewers can understand both what the team knew and when it knew it.
The operational danger is waiting for a complete investigation before escalating. Build a process that can communicate available facts and update them as evidence develops. Confirm the required fields and any applicable exceptions against current official guidance rather than relying solely on this summary.
Prepare the Single Reporting Platform Workflow
ENISA's Single Reporting Platform guidance provides the official starting point for manufacturer notifications. The platform coordinates communication with the relevant authorities. It does not remove the manufacturer's need to identify its reporting responsibilities and coordinate internally.
Assign a primary reporting owner and a backup. Confirm who can submit, who supplies technical evidence and who approves the organization's assessment. Review access arrangements in advance rather than discovering during an event that the only prepared person is unavailable.
Separate this responsibility map from a broad mailing list. A notification copied to ten managers is not a reliable handoff unless one person has accepted the next action. Use an escalation record with a named owner, deadline and current status.
Also distinguish regulatory reporting from customer communications, vulnerability disclosure and obligations under other regimes. A single CRA submission should not be interpreted as proof that every notification duty has been satisfied. Coordinate those decisions with the appropriate legal and communications teams.
Connect Vulnerability Handling to Release Evidence
Cognativ's implementation recommendation: connect the incident record to the engineering work that reduces the exposure. Responders should be able to identify affected releases, the corrective change, test results and the person who approved distribution.
Useful evidence includes a product identifier, affected versions, the observed behavior, investigation notes and remediation status. Preserve original evidence with appropriate access restrictions. Avoid copying unnecessary credentials, customer records or exploitable details into general-purpose project updates.
These practices belong within secure software development and release controls, not in a disconnected compliance folder. A patch that cannot be traced to the relevant product version makes both engineering follow-up and reporting harder.
A corrective measure becoming available and customers installing it are separate milestones. Track both where relevant. Do not close the operational work merely because a release artifact exists; confirm the distribution plan, support responsibilities and any remaining exposure.
Build a Reporting-Ready Evidence Packet
A compact evidence packet helps different teams work from the same facts. The following structure is a proposed internal tool, not a replacement for the platform's required notification fields:
- Identity: product, version, responsible entity and incident reference.
- Timeline: observations, awareness assessment, escalations and submissions.
- Assessment: confirmed impact, exploitation evidence and unresolved questions.
- Response: mitigation, corrective measure, testing and distribution status.
- Ownership: technical lead, reporting owner, reviewer and backup.
Our discussion of secure custom software development and audit evidence explains why traceable development records matter. Reuse existing evidence where it is reliable rather than creating conflicting copies for each reporting audience.
Rehearse Before the First Urgent Event
Run a tabletop exercise using fictional product data. Introduce an exploitation report, an unavailable owner and an incomplete version inventory. Ask the team to locate evidence, establish responsibilities and prepare a draft notification without submitting a fictitious incident to the live platform.
Measure handoff delays and missing information. The exercise succeeds when it exposes gaps that can be corrected, not when every participant agrees the process looks complete. Assign each improvement to an owner and repeat the scenario after meaningful changes.
Where the gaps involve architecture, maintenance ownership or delivery processes, software development consulting for technical delivery decisions can help turn findings into a practical engineering plan. Legal interpretation and regulatory decisions still require the appropriate qualified owners.
Turn the Reporting Date Into Operational Readiness
Cyber Resilience Act reporting makes timely coordination a concrete priority. Start with scope, distinguish reportable events, preserve the different deadline triggers and connect reporting to remediation evidence. Do not confuse a completed checklist with a verified capability to respond.
To review the technical gaps in your product and incident workflows, discuss secure software delivery with Cognativ. Bring the product inventory, escalation process and current release evidence so the next steps address real operating constraints.