The Cyber Resilience Act's vulnerability reporting obligations apply from 11 September 2026. Meeting the 24-hour early warning and 72-hour notification timelines requires a functioning product security incident response process — not a policy document, but a working capability with named owners, documented procedures, and at least one dry run. Small product teams that have not started building this can still get there before September. Teams that wait until August cannot.
A Product Security Incident Response Team (PSIRT) is the function responsible for receiving, triaging, and coordinating the response to security vulnerabilities in your products. It does not need to be a separate team or a dedicated headcount. It needs to be a defined capability: someone receives vulnerability reports, someone triages them, someone coordinates the fix, and someone handles the regulatory reporting when the threshold is met. Those four roles can be held by two or three people in a small organisation — but they need to be assigned, documented, and reachable.
THE_FOUR_CAPABILITIES_YOU_NEED
The CRA reporting timeline requires four capabilities that most small product teams do not have explicitly defined even when they have the underlying knowledge to perform them. First, a vulnerability intake path: a way for external researchers, customers, and internal teams to report potential security issues that routes reliably to someone who acts on it, not to a generic support inbox that may or may not be reviewed by someone with security context. Second, a triage and classification process: a documented set of criteria that determines whether a reported issue constitutes an actively exploited vulnerability, a severe incident, or something below the reporting threshold. Third, a response coordination process: who does what when a significant vulnerability is confirmed. Fourth, the regulatory reporting capability: who files the ENISA report, in what system, with what content, within what deadline.
The triage and classification process is the capability most teams underestimate. Under the CRA, the 24-hour early warning clock starts when the team knows a vulnerability is being actively exploited — not when an investigation is complete. That means the classification decision is made under time pressure, with incomplete information, by whoever is handling the report when it comes in. If the classification criteria are not documented and the decision authority is not assigned in advance, the 24-hour window closes before anyone can agree on what the situation requires.
"A PSIRT is not a team. It is a process with named owners."
SETTING_UP_VULNERABILITY_INTAKE
The minimum viable vulnerability intake path is a dedicated security email address (conventionally security@yourdomain.com), a published security.txt file at the well-known URI, and a process that ensures reports sent to that address reach someone who can act on them within hours, not days. The security.txt standard (RFC 9116) specifies the format and fields for publishing security contact information in a machine-readable way that security researchers and automated tools can find reliably.
Security email addresses fail in practice when they route to shared inboxes with no clear owner, when they are monitored only during business hours, or when they route to a customer support team without security context. A researcher who reports a critical vulnerability on a Friday evening and receives no response for 72 hours will typically assume the report was not received and escalate — either publicly or to a regulatory body. Setting up the intake correctly prevents those scenarios without requiring 24/7 security staffing.
- Publish a
security.txtfile athttps://yourdomain.com/.well-known/security.txtwith your contact address, PGP key if available, and preferred language. - Ensure the security email address routes to someone with authority to act — not to a shared support inbox. The routing should be tested before it is published.
- Set up an auto-acknowledgement for security reports with an expected response timeline. Researchers filing valid reports deserve to know their report was received.
- Define what information you need in a vulnerability report to begin triage, and include that in your security.txt or linked policy page.
TRIAGE_AND_CLASSIFICATION_CRITERIA
The classification decision for CRA reporting purposes has two thresholds. An actively exploited vulnerability that meets the significance criteria triggers the 24-hour early warning and 72-hour notification. A severe incident affecting the security of the product triggers the same timeline. Both require a judgment call made quickly — and the quality of that judgment depends on having documented criteria before the event, not improvising them during it.
The criteria document should specify: what "actively exploited" means in operational terms for your product context (typically: evidence of exploitation in the wild, confirmed or reasonably suspected from threat intelligence, security research disclosure, or observed attack patterns); what severity thresholds trigger the reporting obligation (typically mapped to CVSS scores and the specific Annex I Part I properties affected); and what evidence standard is required to confirm exploitation before the 24-hour window expires.
The evidence standard question is where teams most frequently struggle. Waiting for absolute confirmation before filing the early warning is a risk — the 24-hour window can pass while the investigation is still in progress. The CRA allows for initial reports to be updated as more information becomes available. The safe approach is to file the early warning as soon as active exploitation is reasonably suspected, with a note that the investigation is ongoing, and update the notification as the picture becomes clearer.
- Write the classification criteria document before the first real event. Include worked examples for borderline cases — they make faster decisions under pressure.
- Assign decision authority explicitly: who can authorize filing an early warning, and who covers that role when the primary owner is unavailable.
- Map your CVSS scoring practice to the CRA severity thresholds so that severity assessments feed directly into reporting decisions without additional translation.
- Define the escalation path when classification is uncertain: who resolves the uncertainty, in how long, and what happens if the person responsible is unreachable.
COORDINATING_THE_FIX
Vulnerability response coordination for small teams can be a simple linear process: confirmed significant vulnerability goes to the engineer who owns the affected component, fix is developed and reviewed under a confidential branch or in a private fork, a patch release is prepared and tested, and the release is coordinated with the regulatory notification timeline if applicable. The key constraint is confidentiality before the fix is available: a publicly disclosed vulnerability in a product without an available patch creates immediate risk for users.
The coordination with the reporter matters more than most product teams expect. Security researchers who have found and reported a valid vulnerability have an implicit expectation of coordinated disclosure: they will not publish their findings while you are working on a fix, within a reasonable timeframe, and you will acknowledge their contribution in the release notes or advisory. Research community norms around coordinated disclosure are well established. Teams that ignore them — either by failing to respond or by releasing a fix without any acknowledgement — damage their ability to receive future responsible disclosures.
For teams receiving their first significant vulnerability report, the practical process is: acknowledge within 24 hours, provide an initial assessment and expected fix timeline within 72 hours, keep the reporter updated at each significant development, coordinate the disclosure date, and publish a security advisory with the fix that credits the reporter. Most researchers are cooperative with that process.
THE_ENISA_REPORTING_PROCESS
ENISA is establishing the single reporting point for CRA Article 14 notifications. The reporting format will include: product identification, vulnerability description, affected versions, exploitation status and evidence, initial severity assessment, available mitigations, and the steps taken or planned for remediation. Teams that have not yet identified where and how to file the report should monitor ENISA's CRA implementation guidance, which is being updated ahead of the September 2026 application date.
The final report is the document that closes the event from a regulatory perspective. For actively exploited vulnerabilities, it is due no later than 14 days after a corrective or mitigating measure is available; for severe incidents, it is due within one month. It needs to include the complete timeline from discovery to remediation, the root cause analysis, the full scope of impact, and the specific technical and process changes made to prevent recurrence. For small teams, the most important thing about the final report is writing it while the event is still fresh — not reconstructing it from partial records after the engineering team has moved on to the next sprint.