The essentials in 60 seconds / tl;dr
- From 11 September 2026, a must report actively exploited vulnerabilities and severe security incidents affecting covered digital products.
- An early warning is generally due within 24 hours and a fuller notification within 72 hours of awareness.
- Not every vulnerability or outage is reportable. Active exploitation or the statutory severity criteria are decisive.
- The Single Reporting Platform is due to be operational by the deadline. An EU Login can be created in advance, but ENISA advises starting SRP registration only when a specific notification is needed.
- The broader product and conformity duties mainly apply from 11 December 2027, but 2026 reporting already needs a product inventory, ownership and technical evidence.
Sources: Regulation (EU) 2024/2847 (Cyber Resilience Act) · European Commission: CRA reporting obligations · European Commission: CRA implementation timeline
01
The deadline starts reporting duties, not the whole CRA
The Cyber Resilience Act has been in force since December 2024. Most principal obligations apply from 11 December 2027, but Article 14 reporting for actively exploited vulnerabilities and severe security incidents applies from 11 September 2026.
That distinction matters operationally. An organisation may still be planning later conformity work while the clock is already running on a concrete security event in 2026. Reporting readiness cannot wait for the next major product release.
11 June 2026
Rules on notified conformity assessment bodies apply.
11 September 2026
Article 14 reporting duties begin.
11 December 2027
The CRA’s main obligations apply in full.
Older and unsupported products may also be covered
Article 14 applies from 11 September 2026 to every product with digital elements within the CRA scope, including products placed on the market before 11 December 2027 and products whose support period has ended. Active exploitation already known to the before the deadline does not have to be reported retroactively. If active exploitation only becomes known afterwards, the reporting duty may apply.
02
Which software is actually in scope?
The CRA covers products with digital elements made available on the EU market that have a direct or indirect logical or physical data connection. It includes software products and separately marketed components, not only devices.
Typically in scope
Desktop and mobile software, operating systems, network products, software libraries sold as products, IoT devices and digital components made available separately.
Remote functions may be included
A remote data processing solution may form part of the product when the develops or is responsible for it and a product function depends on it.
Pure SaaS is not automatically a CRA product
A standalone cloud service is not covered merely because it is software. Other frameworks, including NIS2, may still apply.
Roles matter
The , importer and distributor hold different duties. Offering a product under your own name or materially modifying it may transfer the legal manufacturer role.
Free and open source does not always mean outside the CRA
Free open-source software supplied outside a commercial activity receives special treatment. Software supplied in the course of commercial activity needs closer assessment, and open-source stewards have distinct proportionate duties.
03
Who holds which role under the CRA?
The person who writes the code is not automatically the . The key question is usually who develops or commissions the product and offers it on the EU market under its own name or trademark.
Own product under own brand
The company offering the product generally holds the legal manufacturer role, even where an external supplier developed it.
Client product under the client’s brand
The client may be the . The commissioned developer generally remains a technical service provider.
Third-party product in operation
The customer is typically the operator or user. The original supplier generally retains the manufacturer role.
Substantially modified and offered again
A party that substantially modifies a product and makes it available on the market again may itself assume manufacturer obligations.
Separate legal responsibility from technical work
The may commission development, hosting, monitoring and maintenance. Operators and technical suppliers must reliably provide the necessary information and actions, but commissioning them does not automatically change the statutory allocation of roles.
04
What must be reported, and what does not?
The duty focuses on two event types. A normal bug, a merely theoretical vulnerability or a brief operational interruption is not automatically a CRA notification.
Actively exploited vulnerability
Reliable evidence shows that a malicious actor exploited the vulnerability without the system owner’s permission.
Severe security incident
The incident impairs or threatens the protection of the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Alternatively, it has introduced malicious code into the product or a user’s systems, or is capable of doing so.
Not automatically reportable
- A vulnerability is known but there is no reliable evidence of active exploitation.
- An ordinary functional defect has no relevant product-security impact.
- An isolated infrastructure incident does not affect the digital product in the legally described way.
- A researcher report alone does not prove active exploitation, but it may require immediate investigation.
A decision that an event is not reportable should not exist only in a chat or one person’s memory. A short recorded rationale with the evidence and date is much more defensible.
05
24 hours, 72 hours and the final report
Deadlines run from the point at which the becomes aware. That moment must therefore be technically and organisationally identifiable.
Who actually receives the notification
The notification is submitted through the electronic endpoint of the coordinating CSIRT in the Member State where the has its main establishment in the Union. It is simultaneously accessible to ENISA. Article 14(7) provides a cascading rule for s without a main establishment in the Union.
Within 24 hours
Submit an early warning through the Single Reporting Platform. For incidents, indicate suspected unlawful or malicious acts where that information is available.
Within 72 hours
Submit a fuller notification using the general information available at that point. Depending on the case, this includes the product and nature of the vulnerability or exploitation, or the nature and initial assessment of the incident, together with mitigation already taken or available to users.
Vulnerability: final report
No later than 14 days after a corrective or mitigating measure becomes available, submit the analysis and details of that measure.
Severe incident: final report
Submit the final report generally within one month of the 72-hour notification.
Practical example: from vulnerability alert to CRA notification
A fictional timeline shows when a technical alert can become a reportable case and when the statutory deadlines begin.
Show example
Tuesday, 09:10: alert received
An automated scan identifies a new in a login library used by the product. The team checks which product versions contain the library and whether the affected code is actually used and reachable. The match alone does not trigger a CRA notification.
Tuesday, 11:40: active exploitation confirmed
Logs show targeted exploitation attempts against an affected customer installation. The initial technical assessment provides a reasonable degree of certainty that the vulnerability is being actively exploited in the product. This time is recorded as the point of awareness.
By Wednesday, 11:40: early warning
Within 24 hours, the CRA manufacturer submits the available information through the Single Reporting Platform. The investigation continues in parallel.
By Friday, 11:40: fuller notification
Within 72 hours, information follows on the product, affected versions, vulnerability, impact identified so far and protective measures already taken.
In parallel: protect customers
At-risk functions are restricted, affected customers are informed and a security update is prepared. Release, rollout and effectiveness checks are documented.
After remediation becomes available: final report
No later than 14 days after the corrective or mitigating measure becomes available, the final report provides the technical analysis and describes the measures implemented.
The first alert is not the decisive point. What matters is the documented time at which the initial assessment provides a reasonable degree of certainty that the vulnerability is being actively exploited in the product.
Reporting to authorities is not the only communication path
After becoming aware of an actively exploited vulnerability or severe incident, the must inform affected users and, where appropriate, all users. The content, audience and timing should be risk-based and proportionate. This does not require indiscriminate public disclosure of technical details that could facilitate further attacks.
06
A dependable reporting process in seven hand-offs
A PDF emergency plan is not enough. The process must begin wherever signals actually arrive: support, monitoring, email, issue trackers, dependency alerts or external researchers.
Secure intake
Define a central security contact and escalation path; preserve an immutable receipt time.
Map the product
Identify product, version, tenants, regions, components and owners from a maintained inventory.
Separate facts
Record confirmed observations, assumptions, open questions and third-party claims separately.
Classify the event
Assess active exploitation and severity criteria in a structured way; involve legal and security owners for borderline cases.
Set deadline and owner
Make the awareness time, 24/72-hour deadline, accountable owner and deputy visible.
Notify while investigating
Send the early warning with the information available; uncertainty is not a reason to delay all work until the deadline.
Connect mitigation and closure
Link patch, customer communication, rollout, effectiveness checks and final report to the same case.
A small vendor does not necessarily need its own SOC. It does need unambiguous intake, an empowered call tree, access to product knowledge and a practised deputy.
07
Technical evidence that saves time during an incident
The early notification does not demand perfect forensics. Without prepared product and operational data, even the first assessment becomes unnecessarily vague.
Product and version inventory
Which versions are deployed, for which customers and under which support periods?
Components and dependencies
Which builds contain the affected library or component? An SBOM helps but does not replace maintained mapping.
Security and operations logs
Time-consistent, access-controlled records of relevant authentication, administration and update activity.
Update path
How is a fix built, tested, distributed, monitored and rolled back?
Decision record
Who knew what and when, which classification was made and which questions remained open?
Contact and deputy matrix
Product, security, management, privacy, legal, support and suppliers with real deputies.
Credentials for the reporting platform do not belong in a shared incident document or ticket. An EU Login can be set up securely in advance and internal authority can be clarified. ENISA nevertheless advises starting SRP registration and validation by the competent CSIRT only when a specific notification must be submitted.
08
What I upgrade in existing systems
For my clients, I implement a compact CRA readiness update with four technical foundations. I also offer continuous monitoring of the open-source packages in use:
Record security events
Suspicious sign-ins, unauthorised access and critical changes are logged in a traceable way.
Technical example
Structured, access-controlled logs with timestamps, product version and correlation ID.
Document the software inventory
A machine-readable component list is generated automatically for every product version.
Technical example
An SBOM in CycloneDX or SPDX format, generated automatically during the build.
Provide a safe vulnerability channel
Security researchers receive a clear contact and a defined reporting path.
Technical example
A dedicated security address, CVD policy and /.well-known/security.txt.
Deliver updates securely
Every released version is uniquely documented, tested and distributed in a controlled way. This makes it possible to identify affected installations and verify whether a security update was rolled out successfully.
Technical example
Versioned releases, automated tests, release notes, checksums or signatures, staged rollout and a prepared rollback.
SBOM security monitoring (optional)
The component inventory is regularly matched against new entries in the catalogue. Matches involving open-source packages in use are mapped to affected product versions and assessed by a specialist.
Technical example
Automated dependency scanning with package and version matching, alerts for new findings, and assessment of supplier advisories, actual applicability, code reachability and available remediation.
These measures support the detection, assessment and reporting of security issues. A match in the catalogue does not by itself prove that the product is vulnerable or that a CRA notification is required. Reporting duties start on 11 September 2026. The broader technical product obligations generally follow on 11 December 2027.
09
Reporting is only the early part of the CRA work
Much broader lifecycle requirements follow by December 2027. A well-designed reporting process creates foundations that can be reused.
Cybersecurity risk assessment
Assess risks systematically across planning, design, development, production, delivery and maintenance.
Secure by design and default
Ship without known exploitable vulnerabilities, reduce attack surface and choose secure defaults.
Vulnerability handling
Receive, investigate and remediate vulnerabilities, distribute updates securely and provide information.
Support period
Determine and document an appropriate support period and provide security updates without delay and generally free of charge.
Technical documentation and conformity
Prepare classification, risk evidence, conformity procedures, the EU declaration of conformity and CE marking.
10
Decision matrix and ten-point checklist
First classification of an incoming event
| Signal | Immediate question | Next step |
|---|---|---|
| Vulnerability report | Is there reliable evidence of active exploitation? | Validate technically, preserve evidence, begin CRA classification. |
| Product incident | Are security properties severely affected and severity criteria met? | Determine impact and scope; record awareness time. |
| Dependency alert | Is there evidence that the vulnerability is being actively exploited in our product? | Check affected versions, code reachability and evidence of exploitation in the product itself. |
| Operational outage | Is this a product security incident or only an operational interruption? | Assess CRA and other notification paths separately. |
Complete before 11 September
- Identify the for each covered product.
- Create a central security reporting channel with immutable receipt time.
- Define awareness time and escalation criteria in writing.
- Prepare 24/72-hour templates with clear required fields.
- Define internally who may report during an incident and will use an EU Login. Start SRP registration only when a specific notification is required.
- Make product, version and dependency data discoverable.
- Name accountable owners and reachable deputies.
- Test patch, rollback and customer communication paths.
- Record decisions, including “not reportable”.
- Run a tabletop exercise using a realistic vulnerability.
11
Frequently asked questions
Must every vulnerability be reported from September 2026?
No. Mandatory notification concerns actively exploited vulnerabilities and severe security incidents as defined by the CRA. Other vulnerabilities still need handling but do not trigger Article 14 by themselves.
Does the 24-hour clock wait for complete technical confirmation?
No. Under the Commission guidance, awareness exists once a prompt initial assessment provides a reasonable degree of certainty that a vulnerability in the product is being actively exploited or that a severe incident has compromised product security. Complete forensics are not required, but the initial assessment must not be artificially delayed.
Are pure SaaS offerings covered?
Standalone SaaS is not automatically a product with digital elements. Remote processing may nevertheless be part of a CRA product where it is required for the product function and sits within the responsibility of the .
Do small companies need the same process?
Reporting generally applies when a small company is the too. The process can be lean but must connect deadlines, ownership and product knowledge reliably. Under the CRA administrative-fine regime, microenterprises and small enterprises are exempt from fines specifically for missing the 24-hour deadline. This does not remove the reporting duty itself.
Does a CRA notification replace other reporting duties?
No. NIS2, data-protection, contractual or sector-specific notification routes may apply as well. A good incident process checks them in parallel without conflating them.
Can information be added later?
Yes. The staged process exists for that purpose: early warning, fuller notification and final report. Available facts are reported on time and completed as the investigation progresses.
12
Official sources
Primary sources and official implementation material used for this article. Last checked on 2 August 2026.
- Regulation (EU) 2024/2847 (Cyber Resilience Act)
- European Commission: CRA reporting obligations
- European Commission: implementation guidance of 27 July 2026
- European Commission: CRA implementation FAQ
- European Commission: CRA implementation timeline
- ENISA: Single Reporting Platform
- European Commission: CRA summary
- European Commission: obligations attached to the legal manufacturer role
- CVE Program: glossary and definitions