P.K. SHARMA

Cyber security intelligence, AI governance, practitioner analysis

Regulatory readiness

EU Cyber Resilience Act Readiness

The CRA reporting duty starts on 11 September 2026 and applies to products already on the market, not only to what you ship after 2027. Scope, classification, the 24-hour clock, and the evidence a conformity assessment will ask for.

Most CRA planning is aimed at 11 December 2027, when the essential requirements and CE marking apply. That is the wrong first date. Article 14 reporting starts on 11 September 2026 and covers products already on the Union market, including ones placed there years ago and never touched since. An actively exploited vulnerability then triggers a 24-hour early warning whether or not anything else about the regulation applies to you yet.

11 Sep 2026

Reporting obligations apply

Article 14, including for products already on the market.

24h

Early warning deadline

Then 72 hours for the main notification.

11 Dec 2027

Full application

Essential requirements, conformity assessment and CE marking.

4

Product classes

Default, Important Class I, Important Class II, Critical.

What it covers

Article 14 reporting

Early warning within 24 hours, main notification within 72, final report within 14 days for a vulnerability or one month for a severe incident. To your national CSIRT and ENISA, through the single reporting platform.

Scope and classification

Default, Important Class I, Important Class II or Critical. The class decides whether self-assessment is available at all, so it decides the evidence you should already be generating.

Annex I essential requirements

The security properties and the vulnerability handling process, assessed as evidence rather than as written policy.

Conformity assessment

Internal control where permitted, third party where not. Important Class I allows self-assessment only where harmonised standards are applied.

Support period

Must be stated at the point of purchase, in month and year. A commercial commitment as much as a technical one, and hard to shorten later.

NIS2, DORA and the AI Act

Where you are in scope of more than one, so a single incident does not produce three uncoordinated notifications on three different clocks.

How the engagement runs

  1. 1

    Determine scope, product by product

    Which products with digital elements are in scope, which are excluded because other Union law already covers them, and which are ambiguous enough to need a written position.

  2. 2

    Classify, and record the reasoning

    The class sets the conformity route. An assessor will ask why a product sits where it does, and the answer needs to have been written at the time rather than reconstructed afterwards.

  3. 3

    Build the reporting capability first

    Because it lands first, in September 2026. Who decides that a vulnerability is actively exploited, who holds the CSIRT and ENISA channel, what the 24-hour message contains, and who does it at a weekend.

  4. 4

    Assess against Annex I

    The essential requirements and the vulnerability handling obligations, against what your engineering actually does rather than what the policy says.

  5. 5

    Set the support period

    Long enough to be credible to a buyer, short enough to be deliverable, stated in months and years and published where the purchase happens.

  6. 6

    Leave a maintained pack

    Technical documentation, the classification reasoning and the reporting runbook, in a form your own team updates as products change.

What you walk away with

  • A product-by-product scope determination with the exclusions reasoned
  • Classification into default, Important Class I or II, or Critical, with the conformity route each implies
  • A reporting runbook that meets 24 hours: decision rights, contacts, message templates, out-of-hours cover
  • An Annex I gap assessment covering both the security properties and vulnerability handling
  • A support period recommendation with the commercial consequences stated
  • Technical documentation reviewed as conformity evidence rather than as a document set

How this plays out

Example scenario

A manufacturer planning entirely around the December 2027 date.

The work: Walked the Article 14 timeline against their current product estate.

Products shipped in 2023 and long since forgotten were already inside the September 2026 reporting duty. The 2027 work was on track; the duty arriving fourteen months earlier had no owner.

Example scenario

A team assuming self-assessment throughout.

The work: Classification review across the range.

Two products fell into Important Class II, where third-party assessment is mandatory. Discovering that at conformity assessment rather than during design is the expensive version.

Example scenario

An incident process built around a 72-hour regulatory clock.

The work: Tested it against the 24-hour early warning obligation.

The process worked in office hours and had no path at all on a Friday evening, which is when it would be needed.

Start the conversation

A short call to understand your situation; a clear scope if the engagement fits, and a straight answer if it does not.

Discuss CRA readiness

Share this

Send it to whoever owns the budget or the risk.

← All services

The problem

Most CRA planning is aimed at 11 December 2027, when the essential requirements, conformity assessment and CE marking apply. That is the wrong first date.

Article 14 reporting starts on 11 September 2026, and it does not wait for the rest of the regulation. It applies to every product with digital elements already made available on the Union market, including things placed there years ago and never touched since. An actively exploited vulnerability triggers an early warning to your national CSIRT and ENISA within 24 hours, a fuller notification within 72 hours, and a final report within 14 days. For a severe incident the final report runs to one month.

Three things usually go wrong at once. Nobody has decided which products are in scope. Nobody has worked out which conformity route each product takes, and the route changes what evidence you need to have been generating all along. And nobody has a duty officer who can produce a CSIRT notification on a Saturday.

What you get

  • A scope determination across your product estate, separating what the CRA covers from what other legislation already governs
  • Classification into default, Important Class I, Important Class II or Critical, with the conformity route each implies and the reasoning written down
  • A reporting capability that can actually meet 24 hours: who decides, what "actively exploited" means for you, who holds the ENISA and CSIRT channel, and what gets sent
  • A gap assessment against the essential requirements in Annex I, ahead of the 2027 date rather than into it
  • Support period determination, which has to be stated at the point of sale in months and years and is a commercial decision as much as a technical one
  • Technical documentation and vulnerability handling reviewed as evidence, not as policy

Proof point

Delivered alongside the regulatory work this practice already runs across NIS2, DORA and the EU AI Act, where the recurring lesson is the same: the reporting clocks start at the moment somebody notices, and the organisations that struggle are the ones without a named person who can act inside a day. ISO/IEC 27001 and ISO/IEC 42001 Lead Auditor.