CRA Deadlines 11 September 2026 and 11 December 2027: What Must Be Provable by When

The Cyber Resilience Act has been in force since the end of 2024, but its obligations apply in stages. For planning in product development, two dates are decisive — and the first is closer than it appears in most roadmaps.

The Timeline

Date	What applies
11 Sep 2026	Reporting obligations: actively exploited vulnerabilities and severe security incidents must be reported to ENISA and the competent national CSIRT
11 Dec 2027	Full application: essential requirements of Annex I, conformity assessment, technical documentation, EU declaration of conformity, CE marking

Affected are products with digital elements whose intended use includes a data connection to a device or network — hardware as well as software. The CRA distinguishes two criticality classes with stricter conformity assessment routes; certain product areas with their own EU regulation, such as medical devices, civil aviation and marine equipment, are excluded. For typical industrial field devices, the question is therefore rarely whether, but in which class.

Why the First Date Is the Underestimated One

The reporting obligations are not a development topic but an operations topic — and they also affect products that have long been on the market. Anyone who learns of an actively exploited vulnerability in one of their devices from September 2026 onwards must be able to report within short deadlines. That requires things that cannot be built in a week:

a reachable point of contact at the manufacturer that accepts and processes reports from outside — including outside the office hours of product management,
knowledge of what has been shipped: which firmware versions are running at which customers and which components they contain,
a process capable of making decisions that triggers a report instead of escalating it,
and the ability to respond — to provide an update that the customer can actually install.

Anyone who cannot say which product versions are affected by a reported vulnerability does not have a reporting problem but an evidence problem. This is where an SBOM generated from the build pays off immediately.

What Must Be in Place by the Second Date

On 11 December 2027 the topic becomes a question of market access. Without fulfilled essential requirements, a completed conformity assessment, technical documentation, a declaration of conformity and CE marking, a product with digital elements may not be placed on the market.

For products already placed on the market, a transitional logic applies: in principle, they are only covered by the requirements if they are substantially modified after this date. The reporting obligations apply independently of this.

Also relevant for the second date, because it directly affects product planning: the manufacturer defines a support period during which vulnerabilities are handled. It is based on the expected period of use; for long-lived industrial devices this is a commitment with tangible consequences for architecture, toolchain and supplier contracts.

Planning Backwards

For a device that is to enter series production in 2028, the plan looks soberly like this:

Conformity assessment needs lead time — depending on the product category with the involvement of a notified body, whose capacity will not be freely available in 2027.
Technical documentation is not created at the end; it is the by-product of a process that generates it. Documentation compiled after the fact is exactly the work nobody planned for.
The risk assessment must already exist at that point, because the Annex I requirements are to be traced back to it. It does not stand at the end of the chain, but at the beginning.
The reporting process must be running a year earlier, i.e. in 2026 — not as a document, but as a rehearsed procedure.

This moves the actual deadline forward: the relevant point in time for development is not December 2027, but the start of the last project that must be completed by then.

What Can Be Derived From This

The CRA does not enforce a new methodology — it enforces that an existing one is carried through all the way to evidence. A development process that genuinely follows IEC 62443-4-1 delivers most of what the technical documentation requires. The context is covered in the overview article on the secure development process.

This article is a technical assessment and not legal advice. For the binding interpretation in an individual case, please refer to the legal text and seek legal counsel.

Sources

This article was originally published in German on the Alsensio Cybersecurity Hub.