EU Cyber Resilience Act timeline

Under Article 69(2), a product with digital elements placed on the market before 11 December 2027 falls under the regulation only if it is substantially modified from that date. A product that was already sold and is not changed in a way that counts as substantial stays outside the essential requirements of Annex I and the conformity assessment duties. This transitional rule protects installed products from retroactive redesign, but it does not remove every obligation, as the next tab explains.

• Placement date: the relevant date is when the product was first made available on the EU market, not when it was designed or last released.
• No substantial modification: routine maintenance and security patches generally do not reset the product into scope, although the Commission guidance should be checked for borderline cases.
• No new CE marking duty: a product in this group does not need a new EU declaration of conformity solely because the regulation now exists.
• Documentation of the decision: keep a dated record of why each product was or was not treated as substantially modified.
• Interface with other law: confirm that other Union harmonization legislation applied to the product still treats it as compliant.

Before relying on this route, ask counsel or your market surveillance contact to confirm how the product's update history will be judged.

A product placed on the market before 11 December 2027 comes under the regulation from the point it is substantially modified on or after that date. At that point the modified product is treated as a product placed on the market, so the Annex I requirements, the risk assessment, the support period and the conformity assessment route all apply to it. The trigger is the modification, not the original sale, which means a legacy product can move into scope through a single release.

• Trigger on or after 11 December 2027: a change made before that date does not bring the product into scope under this rule.
• Judgment on substance: the Commission guidance and its examples explain what counts as a substantial change, and the question should be settled per product family.
• New obligations follow: a new conformity assessment, a new support period and technical documentation are required once the product is in scope.
• Parallel product lines: check whether a release on a legacy branch could be treated as a new product version.
• Record keeping: keep release notes and change assessments that show the reasoning behind each decision.

Illustratively, a firmware overhaul released in early 2028 that changes core functionality may bring an older device into scope, while a patch fixing a known flaw usually would not. Confirm each case against the guidance before release planning.

The transitional rule does not apply to reporting. Under Article 69(3), the Article 14 duty to notify actively exploited vulnerabilities and severe incidents covers all in-scope products whenever they were placed on the market. Reporting obligations began on 11 September 2026, so an older product that is in scope of the regulation can trigger a notification today even though its full essential requirements are not yet due.

• Start date: Article 14 has applied since 11 September 2026, the day ENISA launched the initial operating capability of the Single Reporting Platform.
• Scope of the duty: it covers the product as an in-scope product, so the first step is deciding whether the product is in scope at all.
• Recipient: notifications go to the CSIRT designated as coordinator, and ENISA receives them at the same time through the platform.
• Preparation gap: a manufacturer may need a working process to detect and report exploited vulnerabilities well before the full regulation applies.
• Vulnerability handling: the processes that support reporting also serve the eight Annex I Part II requirements that apply later.

Confirm with your national CSIRT or ENISA's platform guidance which contacts and procedures are in place for your product type.

Products already covered by cybersecurity certification under other Union harmonization legislation are handled differently. Under Article 69(1), EU type-examination certificates on cybersecurity issued under that legislation remain valid until 11 June 2028, unless they expire earlier. The certificate is therefore a bridge rather than a permanent exemption, and manufacturers should plan for what happens when it lapses.

• Validity date: the certificate stays valid until 11 June 2028 or its own expiry, whichever is earlier.
• Check the expiry: the certificate's own expiry date governs if it falls before that milestone.
• Plan the successor route: decide early whether the product will move to the CRA conformity assessment route before the bridge ends.
• Scope of the bridge: confirm with the certifying body which Union legislation issued the certificate and whether it covers the whole product.
• Evidence trail: keep the certificate, its scope statement and any amendments with the technical file.

Ask your notified or certifying body to confirm the validity period and whether any extension or transition arrangement applies to your certificate.

The organization placing products on the EU market owns its obligations under the Cyber Resilience Act, and that ownership does not transfer to any outside party. Its legal role (manufacturer, importer, distributor or steward) determines which dates apply to it, and it alone decides how it classifies its products, what its risk assessment concludes and what it reports to authorities.

• Role and scope decisions: Confirm whether each product is in scope and which economic operator role the organization holds for it.
• Reporting decisions: Decide whether an event meets the Article 14 threshold and submit the notification through the ENISA platform under its own authority, from 11 September 2026.
• Declarations and CE marking: Sign the EU declaration of conformity and affix CE marking once conformity is demonstrated.
• Support period commitments: Set and publish the support period for each product and staff the vulnerability handling process that runs for it.
• Records: Keep technical documentation and records available to market surveillance authorities.

Before any deadline, check that a named executive owns each of these decisions in writing.

An implementation partner such as DeployOpen prepares the systems, documentation and evidence that support the organization's decisions. Its work is delivered inside the client's own infrastructure and is governed by a written scope, so the partner supplies material for the organization to review and adopt rather than acting as the regulated party.

• Systems and build pipelines: Harden self-hosted build, update and vulnerability management tooling so the controls exist before they are needed.
• Documentation drafts: Prepare technical documentation, risk assessment write-ups and vulnerability handling procedures for internal approval.
• Evidence collection: Gather logs, SBOM outputs, test results and configuration records that show how controls operate.
• Testing: Run security testing of products and their components so findings feed the risk assessment.
• Scope limits: The partner cannot submit Article 14 notifications, sign declarations or act as the organization's authorised representative unless the organization gives that authority in a separate, written arrangement with its own legal review.

Ask for the written scope to state which artifacts the partner produces and which steps remain with the organization.

Only an independent conformity assessment body issues certificates or conformity findings. For most products the manufacturer self-assesses under module A. A notified body is needed for class I important products where harmonized standards are not applied in full, and for class II and critical products, according to the Commission's FAQ. Member States notify these bodies, and they are listed in the Commission's NANDO system.

• Notification timing: Chapter IV, covering notified bodies, applies from 11 June 2026, and the Commission's milestone for enough notified bodies is 11 December 2026.
• Independence: The body assesses the product and documentation on its own judgment and is not a consultant to the same manufacturer.
• Certificates: Only the body issues the certificate in the routes that require one.
• Reporting: A notified body does not file the manufacturer's Article 14 reports.
• Selection: Confirm the body's notification scope in NANDO for the relevant product category before engaging it.

Check that any body you engage is listed for the correct category and that its scope covers your product before you commit to a timeline.