The reporting duties that start in September 2026 are the small half of the Cyber Resilience Act. On 11 December 2027 the rest arrives: essential cybersecurity requirements, conformity assessment, technical documentation and CE marking. That work is measured in quarters, and one input to it — notified body capacity — is not something you can buy at the last minute.
One question decides how hard your route is
Not “are we compliant”, but which class is this product in. The CRA sorts products with digital elements into four tiers, and the group decides who is allowed to sign off:
- Default products — the large majority. Self-assessment is allowed, whatever technical specification you used.
- Important products (Annex III) — operating systems, routers, firewalls, password managers and similar. You may self-assess only where you apply harmonised standards, common specifications, or an EUCC scheme at assurance level “substantial” or above covering the requirements. Applied only in part, or not at all, and a notified body route (module B+C or H) becomes mandatory (Art 32(2)).
- Class II important products — hypervisors and container runtimes, firewalls, IDS/IPS, tamper-resistant microprocessors and microcontrollers. Always a notified-body route (Art 32(3)).
- Critical products (Annex IV) — hardware devices with security boxes such as HSMs, smart-meter gateways, smartcards and secure elements. A notified body is required in every case (Art 32(4)).
Two products from the same factory can land in different groups, and the wrong guess is expensive in the direction that costs time rather than money.
The harmonised standards problem
Self-assessment for an important product is conditional on applying harmonised standards. Those standards are still being developed. So a plan that reads “we will self-assess against the harmonised standard” is a plan with a dependency you do not control, and the fallback — a notified body — is the same fallback everyone else in your position will reach for, at the same time, in 2027. Book capacity early or design the plan so it does not need it.
What already on the market means here
This is where December 2027 differs from September 2026, and the difference matters. The reporting obligations reach back: they cover products already placed on the EU market. The essential requirements do not work the same way — a product placed on the market before the deadline is pulled in only when it undergoes a substantial modification after that date (Art 69(2)). The reporting duties are the stated exception — they reach every in-scope product regardless of when it was placed on the market (Art 69(3)).
Which turns a compliance question into a product-management one. What counts as substantial, who decides, and does your change-control process record enough to defend the answer two years later? Most change logs were not written to answer a regulator.
The support period is now a published commitment
The CRA requires you to determine a support period, during which vulnerabilities in the product are handled effectively, and to state its end clearly and understandably at the time of purchase. It must be at least five years, unless the product is expected to be in use for less, in which case it matches that shorter expected use time (Art 13(8)). Security updates must remain available for at least ten years after issuance (Art 13(9)). For industrial equipment that expectation is uncomfortable: plant assets outlive the teams that shipped them, and a support period chosen for the datasheet becomes an obligation the business carries for its full length.
A realistic twelve months
- Inventory and classify. Every product with digital elements placed on the EU market, sorted into default, important or critical. Nothing else can be planned until this exists.
- Pick the route per product and, where it ends at a notified body, start that conversation in 2026 rather than 2027.
- Gap the essential requirements against what your development process already produces. An IEC 62443-4-1 secure development lifecycle covers a great deal of Annex I — if you run one, you are further along than you think.
- Start the technical documentation now, as a by-product of development rather than an archaeology project at the end. Annex VII is not hard; it is just long, and reconstructing it retrospectively is what makes it painful.
- Decide the support period per product line, with the people who will actually have to honour it in the room.
Where we help
We do the classification and the Annex I gap assessment, then build the evidence trail so that the conformity assessment is a review of work already done rather than a project of its own. Where a notified body is in scope, we prepare for it early enough that their calendar is not your critical path.
If you would rather work through it with tooling than with a consultant, we build the CRA Workbench — the same classification, Annex I evidence and vulnerability handling structure as a workspace you run yourself.
This is the second of two notes on the CRA. The first covers the reporting obligations that start on 11 September 2026 — those apply to products you have already shipped.