Launch is the beginning of the CRA lifecycle
The EU Cyber Resilience Act (the “CRA”) does not end at the CE marking. From 11 September 2026, now just weeks away, manufacturers of products with digital elements must be ready to report actively exploited vulnerabilities and severe incidents, and the Commission’s newly published July 2026 guidance sharpens what that means in practice.
The CRA’s post-market obligations arrive in overlapping phases:
- 11 September 2026: reporting obligations for actively exploited vulnerabilities and severe incidents take effect; and
- 11 December 2027: most other CRA obligations apply.
Running alongside these milestones is the support period itself: for as long as it lasts, manufacturers remain responsible for vulnerability handling, and that responsibility can extend for years after a product is placed on the market.
Most compliance programmes stop at the finish line of certification: assess the product, prepare the technical documentation, complete the conformity assessment and affix the CE marking. That is only part of the picture. Placing a product with digital elements on the market also opens a continuing period of product-security work that can last years, and incident readiness cannot wait for the wider compliance programme to finish. As we covered in our previous update on the CRA, that includes understanding the Act’s scope, the 11 June 2026 milestone for the conformity assessment framework, and the steps Finnish companies should take to prepare.
The support period defines the manufacturer’s post-market responsibility
Article 13(8) of the CRA requires manufacturers to handle vulnerabilities effectively throughout the support period, including vulnerabilities in integrated components. The support period must reflect how long the product is expected to be in use, taking into account factors such as reasonable user expectations, the product’s nature and intended purpose, relevant Union law, comparable products, the operating environment and the support available for third-party components providing core functions. It must be at least five years unless the product is expected to be used for a shorter period. The Commission’s July 2026 guidance makes clear that five years is a floor rather than a default ceiling: products expected to remain in use for longer may require a longer support period.
The reasoning behind the chosen support period must be recorded in the technical documentation. The end date, expressed at least as month and year, must be communicated clearly to the purchaser in an easily accessible form and, where applicable, on the product, its packaging or by digital means. A support commitment shapes product architecture, supplier selection, maintenance capacity and the commercial terms on which long-lived products are sold. Reliance on a short-lived component does not, by itself, justify an equally short support period; the statutory criteria still apply.
Vulnerability handling must continue throughout the product lifecycle
The pre-market cybersecurity risk assessment is not a static exercise. Article 13 requires it to be updated as appropriate during the support period, and Annex I requires regular security testing and reviews. Manufacturers must also have appropriate policies and procedures, including a coordinated vulnerability disclosure policy, to process and remediate weaknesses reported from internal or external sources. That calls for clear ownership across engineering, security, product and legal teams, supported by escalation criteria and a record of the resulting risk decisions.
Vulnerabilities must be addressed and remediated without delay and proportionately to the risks they pose. Security updates must be distributed securely and, where technically feasible, separately from functionality updates. As a rule, they must be disseminated without delay and free of charge, accompanied by information on any action users should take. The limited pricing exception is confined to tailor-made products supplied to business users. Any security update made available during the support period must remain available for at least ten years after it is issued, or for the remainder of the support period, whichever is longer. Keeping an existing patch available is distinct from developing new patches after support ends.
Annex I requires manufacturers to identify and document components and vulnerabilities, including by drawing up a machine-readable software bill of materials covering, at a minimum, the product’s top-level dependencies. If a manufacturer identifies a vulnerability in an integrated component (including an open-source component), it must report the vulnerability to the component’s manufacturer or maintainer and address and remediate it in its own product. Integrating a third-party component does not transfer responsibility away from the final product manufacturer; the relevant question is whether, and how, the vulnerability affects the final product.
Actively exploited vulnerabilities and severe incidents start a separate reporting clock
Article 14 applies to actively exploited vulnerabilities contained in the product and to severe incidents affecting product security. An actively exploited vulnerability requires reliable evidence that a malicious actor has exploited it without the system owner’s permission. An incident is severe where it meets Article 14(5), including because it negatively affects, or is capable of negatively affecting, the protection of important data or functions, or because it has led or could lead to the introduction or execution of malicious code. Under the Commission’s July 2026 guidance, a manufacturer becomes aware of a reportable event only once a prompt initial assessment gives it reasonable certainty that such an event has occurred. Initial indications – for example, a customer complaint, a telemetry anomaly, a security-researcher notification or third-party threat intelligence – will not, on their own, meet that threshold. In practice, however, manufacturers cannot use that gap to defer action: the initial assessment must itself be prompt, and leaving such indications unexamined will not keep the reporting clock from starting.
An early warning is due without undue delay, and in any event within 24 hours of awareness, followed by a more detailed notification within 72 hours. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month of the 72-hour notification. Reports are submitted through ENISA’s Single Reporting Platform to the relevant CSIRT designated as coordinator, and are simultaneously accessible to ENISA. Manufacturers must also inform impacted users, and where appropriate all users, of the vulnerability or incident and of any necessary mitigation or corrective measures. Dissemination between authorities may, exceptionally, be delayed on cybersecurity grounds. For manufacturers whose main establishment is in Finland, the coordinating CSIRT is the National Cyber Security Centre Finland (“NCSC-FI”) at Traficom.
The reporting regime is distinct from the support commitment. Article 69(3) extends Article 14 to all in-scope products placed on the market before 11 December 2027, even though those products are generally subject to the CRA’s other requirements only if they undergo a substantial modification from that date. The Commission also reads the reporting duty as capable of continuing after a product’s support period ends. Manufacturers may therefore still need to assess and report serious field information, and to inform users where required, even when the CRA no longer requires the full set of vulnerability-handling measures for that product. For legacy portfolios, ending patch support does not remove the need for serious field information to reach the manufacturer and be escalated promptly.
Updates and new versions may change the compliance position
A post-market change may be a substantial modification where it affects compliance with the essential cybersecurity requirements, or changes the product’s intended purpose, and in either case leads to a change in the product’s cybersecurity risk. The Commission’s guidance emphasises the effect on cybersecurity risk rather than the engineering scale of the change. A technically extensive security update that only reduces existing risk will not generally be substantial for that reason alone. New functionality, new threat vectors or a material change in the likelihood or impact of an attack may support a different, case-specific conclusion.
A substantial modification may require renewed conformity work. The Commission’s guidance indicates that the support period should be reassessed against Article 13(8), although it is not automatically reset or extended. For successive substantially modified versions of a software product, Article 13(10) permits the manufacturer to meet the specific vulnerability-remediation requirement in Annex I, Part II, point 2 only for the latest version, provided that users of earlier versions can move to it free of charge and without additional costs to adjust their hardware or software environment. Other vulnerability-handling duties continue to apply; this is not a general licence to abandon older releases.
What manufacturers should put in place now
The immediate task is to translate product-security responsibilities into a repeatable operating process. Manufacturers should consider the following steps:
- Document your support periods, including the rationale and end date for each product or relevant version;
- Link product and component inventories to relevant vulnerability-monitoring sources;
- Operate a coordinated vulnerability disclosure channel, with clear internal ownership and supplier escalation routes;
- Build the reporting workflow now: record when awareness arises and pre-assemble templates for the 24-hour early warning, 72-hour notification and final report;
- Prepare proportionate user-notification and mitigation templates; and
- Rehearse secure update distribution, patch availability and end-of-support procedures before you rely on them.
For many organisations, the reporting process will be the first live CRA control. It should be exercised before 11 September 2026, not left as a policy awaiting its first incident.
Conclusion
The CRA turns cybersecurity by design into lifecycle governance. Compliance after launch depends on whether the manufacturer can receive field information, reassess risk, develop and preserve updates, communicate with users and meet reporting deadlines measured in hours. Those capabilities need to be built into the organisation alongside the product itself.
If you have questions on how the CRA applies to your products or organisation, please get in touch with our team at HPP. We are happy to assist with scoping assessments, compliance planning and preparing for the upcoming deadlines. This article was prepared by Lasse Riski (Partner), Jenna Tyynilahti (Senior Associate), Sara Laitila (Senior Associate) and Max Visser (Associate Trainee) of HPP’s Technology and Data team. The team regularly advises clients on technology and data-related matters, including cybersecurity regulation and EU product compliance
