On September 11, 2026, the Cyber Resilience Act's reporting requirements began applying to covered manufacturers. An actively exploited vulnerability or severe product-security incident now requires an early warning without undue delay, within 24 hours of awareness, followed by a notification within 72 hours. The European Commission's reporting guidance, updated September 11, confirms those deadlines.
For a small software company, the difficult part is getting a reliable account of an incident out of the people investigating it before they have finished. The engineer working on containment may also be the person who knows which releases are affected. Someone else has to turn that knowledge into a report without making the engineer stop responding or pretending the investigation is complete.
The reporting policy needs to connect those responsibilities: who gathers the evidence, who can approve the account, and how corrections reach the person preparing the submission.
Scope starts with the product you supply
Having European customers does not, by itself, settle CRA applicability. The regulation covers products with digital elements and certain supporting remote processing. Recitals 11 and 12 distinguish services needed for a product's functions from unrelated websites or cloud services. A backend developed under a manufacturer's responsibility can be included when the product depends on it. The SaaS label alone doesn't answer that question (CRA text, published November 20, 2024).
For the applicability assessment, draw the boundary around what the customer receives and the hosted functions it requires. Include installed applications and their backends. A discussion framed entirely around the company's website can miss the software it actually distributes.
The dates also differ by obligation and role. Most CRA requirements apply from December 11, 2027, according to the Commission's July 27, 2026 guidance announcement. The current reporting requirement can reach covered products already on the market, under Article 69(3) of the regulation. Open-source software stewards have a separate reporting start date of December 11, 2027 (Commission reporting guidance, September 11, 2026).
Document which role the company occupies before choosing a deadline. Publishing source code alone doesn't settle that assessment.
Record the evidence that starts the clock
An actively exploited vulnerability requires reliable evidence of malicious exploitation without the system owner's permission. A scanner finding alone does not establish that. Severe incidents are a separate trigger, with criteria concerning sensitive or important data or functions, or malicious-code introduction or execution (CRA Articles 3 and 14, November 20, 2024).
Your incident record should preserve the original signal and the evidence behind the assessment. If an allegation remains uncorroborated, say so. Pasting a customer report into the incident channel shouldn't strip away the uncertainty attached to it.
Consider a hypothetical customer report containing logs that appear to show unauthorized activity through your application. An engineer begins checking the affected version while support asks the customer for more detail. The reporting owner should be assessing the trigger alongside that investigation, with access to the evidence and someone qualified to resolve the legal question. Waiting for a polished root-cause document makes the reporting process dependent on the slowest part of the response.
The record should distinguish when the event happened, when the evidence arrived, and when the team made its assessment. Those timestamps answer different questions. Collapsing them into the time someone opened a ticket leaves you reconstructing the sequence later.
The reporting stages need different evidence
The deadlines are not sequential extensions. Both the early warning and the subsequent notification run from awareness. Final reports use different anchors: for exploited vulnerabilities, no later than 14 days after a corrective or mitigating measure becomes available; for severe incidents, within one month after the incident notification (Commission reporting guidance, September 11, 2026).
Build an internal worksheet around the actual submission fields. Give each entry a source and an owner. Separate what is confirmed from what remains under investigation, and retain the submitted version when an answer changes. That makes it possible to explain a correction without rewriting the history of the response.
For example, engineering may initially identify an affected release without knowing whether earlier releases share the defect. Record the supported finding and the outstanding investigation separately. Do not expand the affected range merely to sound cautious, or narrow it because nobody has checked the older code yet.
We recommend giving the incident lead responsibility for containment and investigation, with a reporting owner maintaining the submission and its deadlines. Existing staff can take those roles, provided someone covers their absence. The person preparing the report should already know who can approve it.
The portal does not replace your deadline record
ENISA's September 12, 2026 FAQ says the initial platform has no submission API. Reports go through its interface. Representatives use personal EU Login accounts with MFA. ENISA recommends preparing that login in advance, while registering the manufacturer association when a notification is needed.
The same FAQ documents a counter discrepancy: the initial 72-hour reminder is calculated as 48 hours after the early-warning submission, rather than from awareness. ENISA says the counter will change and does not replace the legal deadline. Keep your own timestamp-based record and recheck this behavior before relying on it.
We have not submitted a report through the platform; this is ENISA's description of its current behavior. Our recommendation is to identify the person responsible for completing the submission and document the handoff, even if internal automation prepares the report. Make that responsibility explicit before the response depends on it.
Keep reporting work out of the containment team's way
Reporting consumes time that a small team could otherwise spend containing the incident. That cost is real. If an engineer has to stop disabling an exposed function to attend a meeting about wording, assigning a reporting owner hasn't solved the problem. Give that owner access to the investigation record so they can prepare the account and bring back specific questions.
The staged approach also allows the account to develop. ENISA's September 12 FAQ explains that field requirements differ by stage. Your internal review should check the information required for that stage rather than demand a finished postmortem before any submission can leave.
Keep user communication in the response plan as well. Article 14(8) requires manufacturers to inform impacted users and, where appropriate, other users, including relevant corrective or mitigation measures (CRA, November 20, 2024). A regulator-facing submission and customer instructions have different audiences; prepare each for the decision its reader needs to make.
Before the next real incident, run a tabletop with a covered product and a hypothetical customer report. Ask the team to find the affected release, preserve the evidence, identify the reporting owner, and prepare a reviewable submission. Note where they need an answer from someone who isn't in the exercise.
If the exercise stalls because the authorized submitter is absent or an affected release cannot be identified, assign that gap to someone before closing the exercise. A policy marked reviewed won't answer either question when a customer sends the next report.