The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets cybersecurity requirements for products with digital elements, including software products that meet its scope. Its reporting rules for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026; most of the Regulation applies from 11 December 2027. For software manufacturers, preparation means assessing product scope and risk, building vulnerability-handling and update processes, making support information clear to users, and being ready to report qualifying events on short deadlines.
What the Cyber Resilience Act covers
The CRA is a directly applicable EU regulation that establishes horizontal cybersecurity requirements for products with digital elements across their lifecycle. It was adopted on 23 October 2024 and published in the Official Journal on 20 November 2024. Its aims include addressing product vulnerabilities and gaps in security updates.
Software can be within scope, but the fact that something is software does not by itself settle the question. Classification depends on whether the offering meets the Regulation’s definition of a product with digital elements, its intended purpose and market placement, and whether an exclusion or another Union product-safety regime applies. Assess the product itself and relevant sector rules rather than relying on a software-versus-hardware distinction.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Which CRA dates matter in 2026 and 2027?
| Date | What takes effect |
|---|---|
| 11 June 2026 | Chapter IV, Articles 35–51, on conformity assessment bodies applies. |
| 11 September 2026 | Article 14 reporting obligations for actively exploited vulnerabilities and severe incidents having an impact on product security apply. |
| 11 December 2027 | The Regulation generally applies. |
These dates are set by Articles 69 and 71 of Regulation (EU) 2024/2847. As of October 2026, Article 14 reporting is already in effect, even though the Regulation’s general application date is still ahead. Products placed on the market before 11 December 2027 are generally subject to the Regulation only if substantially modified from that date, subject to Article 69’s specific exception for Article 14 reporting.
#1 Best Overall
When and how manufacturers must report under Article 14
For the events covered by Article 14, the clock runs from when the manufacturer becomes aware of the specified vulnerability or incident. Reports must be submitted simultaneously to the designated CSIRT coordinator and ENISA through the single reporting platform.
| Event | Early warning | Notification | Final report |
|---|---|---|---|
| Actively exploited vulnerability | Without undue delay and no later than 24 hours after awareness. | Without undue delay and no later than 72 hours after awareness. | No later than 14 days after a corrective or mitigating measure is available. |
| Severe incident having an impact on product security | Without undue delay and no later than 24 hours after awareness. | Without undue delay and no later than 72 hours after awareness. | Within one month after submission of the incident notification. |
The two final-report deadlines have different triggers: availability of a corrective or mitigating measure for an actively exploited vulnerability, and submission of the incident notification for a severe incident. The 24-hour, 72-hour, 14-day, and one-month periods are statutory timelines, not targets that can be extended by an internal process.
What software manufacturers need to put in place
The CRA makes cybersecurity a product-lifecycle responsibility. The exact duties depend on the manufacturer’s role and the product’s classification, but software teams should plan for the following areas.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallRisk-based design and secure product properties
Assess cybersecurity risks and use the assessment to inform design, development, production, and maintenance. Annex I requires applicable products to be designed, developed, and produced to provide an appropriate level of cybersecurity based on risk. It also addresses secure-by-default configurations and the requirement to make applicable products available without known exploitable vulnerabilities, subject to the Regulation’s precise terms and qualifications.
Vulnerability handling and security updates
Maintain processes to identify, document, and address vulnerabilities throughout the support period. Plan for coordinated vulnerability disclosure, remediation, security updates, and communications with users. A vulnerability intake channel alone is not a complete process: teams need a way to triage reports, assign responsibility, determine remediation, and track actions through release and maintenance.
Component visibility and technical information
Keep technical documentation and component information current. The Regulation refers to a machine-readable software bill of materials (SBOM) for product components; the specific obligation and conditions for access are defined in the legal text. Component and supplier records can also help teams investigate a newly disclosed vulnerability and identify affected products.
Support-period information for users
Tell users the product’s support period and provide other required information so they can make informed purchasing and use decisions. Set a support period that the organization can actually sustain, and ensure product-facing information accurately reflects it. The CRA’s precise requirements, not an assumed standard number of years, determine what must be disclosed for a product.
Incident decisions and reporting operations
Assign responsibility for vulnerability triage and deciding whether an event meets Article 14’s reporting criteria. Record when the manufacturer became aware, preserve the evidence needed to assess the event, and coordinate technical remediation with reporting and user communications. A process that waits for a full root-cause analysis before starting the clock risks missing the initial deadlines.
Best Value
How to prepare a software portfolio
- Inventory EU-facing products. Record each offering, its manufacturer, intended purpose, delivery method, and relevant integrations.
- Determine product scope. For each offering, assess whether it is a product with digital elements, whether an exclusion or another sector regime applies, and whether the facts require a product-specific legal review.
- Map components and suppliers. Establish a maintained component inventory and an SBOM process where applicable.
- Connect risk analysis to engineering. Document cybersecurity risks and show how they inform design, testing, release, and maintenance controls.
- Operationalize vulnerability handling. Define intake, coordinated disclosure, triage, remediation, security updates, and user-notification responsibilities.
- Set and communicate support periods. Align internal support commitments with the required user-facing information.
- Prepare Article 14 reporting. Establish a decision owner, awareness-time recording, evidence handling, and a route to the single reporting platform that supports the 24-hour and 72-hour deadlines.
- Determine the conformity route. Classify each product and identify the assessment procedure that follows from its category; monitor official implementation materials as they develop.
This sequence is a practical readiness aid, not a legal determination. Product scope, exclusions, category, conformity route, and role-specific duties must be assessed against the Regulation and the facts of the product.
Conformity assessment depends on product category
The CRA does not require third-party certification for every software product. It defines product categories, including important and critical products, and conformity assessment routes that vary with the category and applicable requirements. Depending on the route, assessment may involve standards, notified bodies, or other procedures specified in the Regulation. Do not assume that a particular product needs—or is eligible for—a particular assessment route without classifying it under the legal text.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
