Skip to content
ReadinessNavigator
EnglishDeutsch

Regulation (EU) 2024/2847

The Cyber Resilience Act, reduced to what a manufacturer must actually do

The CRA makes cybersecurity a condition of market access for products with digital elements. It applies horizontally across sectors, covers the entire support period rather than the moment of sale, and carries penalties of up to EUR 15 million or 2.5% of worldwide annual turnover.

The dates that drive your plan

The reporting obligation arrives more than a year before full application, and it applies to products you have already shipped. That is the deadline most teams underestimate.

  1. 10 December 2024

    Entry into force

    Regulation (EU) 2024/2847 enters into force following publication in the Official Journal. The transition period begins.

  2. 11 June 2026

    Notified body provisions apply

    Rules covering conformity assessment bodies take effect, allowing notified bodies to be designated so they are available before manufacturers need them.

  3. 11 September 2026

    Reporting obligations apply

    Article 14 reporting begins. Manufacturers must notify actively exploited vulnerabilities and severe incidents to their CSIRT and ENISA — including for products already on the market.

  4. 11 December 2027

    Full application

    All remaining obligations apply. Products with digital elements placed on the EU market must meet the essential requirements and carry CE marking on that basis.

Step one

Classification determines everything downstream

Your product class sets the conformity assessment route, whether a notified body must be involved, and how much lead time you need. Get this wrong and the rest of the plan is built on sand.

CRA product classes and their conformity assessment routes
ClassAssessment routeWhat falls here
DefaultSelf-assessmentThe majority of products with digital elements. The manufacturer performs the conformity assessment internally and issues the EU declaration of conformity.
Important — Class IStandards or third partyAnnex III Class I products such as password managers, standalone routers, VPNs, and operating systems. Self-assessment is available only where harmonised standards, common specifications, or a European cybersecurity certification scheme are applied in full; otherwise a notified body must be involved.
Important — Class IIThird party requiredAnnex III Class II products such as hypervisors, firewalls, and tamper-resistant microprocessors. A notified body must be involved in the conformity assessment.
CriticalEuropean certificationAnnex IV products including hardware devices with security boxes, smart meter gateways, and smartcards. May be required to hold certification under an EU cybersecurity certification scheme.
Run the classification check

Annex I

The essential cybersecurity requirements

Part I governs the product itself. Part II governs the processes you run around it for the whole support period. Part II is where most manufacturers have the furthest to go.

Part I

Product requirements

  • 01Delivered with no known exploitable vulnerabilities
  • 02Secure-by-default configuration, with the ability to reset
  • 03Security updates available, and automatic where appropriate
  • 04Protection against unauthorised access with strong authentication
  • 05Confidentiality of stored, transmitted, and processed data
  • 06Integrity protection for data, commands, and configuration
  • 07Data minimisation limited to what the product actually needs
  • 08Availability of essential functions and resilience to denial of service
  • 09Minimised impact of the product or connected devices on the availability of services provided by other devices or networks
  • 10Minimised attack surface, including exposed interfaces
  • 11Mitigation of exploitation impact through hardening and segmentation
  • 12Recording and monitoring of security-relevant activity
  • 13Secure and complete deletion of data and settings on demand

Part II

Vulnerability handling

  • 01Identify and document vulnerabilities and components, including an SBOM
  • 02Remediate vulnerabilities without delay via security updates
  • 03Apply regular testing and reviews of product security
  • 04Publicly disclose fixed vulnerabilities with descriptions and remediation guidance
  • 05Enforce a coordinated vulnerability disclosure policy
  • 06Provide a contact address for reporting vulnerabilities
  • 07Provide mechanisms to securely distribute updates
  • 08Disseminate security patches without delay and free of charge

Harmonised standards

EN 40000 is the coming route to presumption of conformity

The Annex I requirements above tell you what to meet, not how to prove you meet it. That proof is meant to come from harmonised standards — the EN 40000 series that CEN and CENELEC (Technical Committee JTC 13) are drafting under the Commission’s standardisation request M/606. Once a standard is cited in the Official Journal, building to it earns a presumption of conformity with the requirements it covers — which simplifies how you prove conformity whichever assessment route you are on. That presumption is not the same as being allowed to self-assess: default products already use internal control (self-assessment) regardless of harmonised standards. Where the standards matter most is Annex III Class I, where applying harmonised standards — or common specifications, or a European cybersecurity certification scheme — is what unlocks self-assessment instead of a notified body. None of the series is cited yet, so none confers that presumption today; first citations are expected around 2027.

  • EN 40000-1-1

    Vocabulary

    StatusDraft

    The common definitions the rest of the series builds on. Through public enquiry; useful to read for alignment, but nothing to conform to on its own.

    → Shared terminology

  • EN 40000-1-2

    Principles for cyber resilience

    StatusDraft

    The horizontal principles that frame how the essential requirements are approached across product types. Advanced in drafting, not yet cited.

    → Annex I, general

  • EN 40000-1-3

    Vulnerability handling

    StatusDraft

    The process side — coordinated disclosure, SBOM, remediation, secure update delivery. Maps directly onto the Part II duties, and onto work you can already do today through the vulnerability-handling and SBOM assessments here.

    → Annex I, Part II

  • EN 40000-1-4

    Generic security requirements

    StatusIn development

    The one to watch: the horizontal product-security requirements that most manufacturers will build to for presumption of conformity. Still earlier in development than the others — its content can still shift, which is exactly why a scored self-assessment against it would be premature.

    → Annex I, Part I

  • Vertical product standards

    Category-specific standards

    StatusHorizon

    Product-family standards layered on the horizontal ones for particular categories. Numbering and scope are not settled; treat as a horizon item, not a plan input.

    → Specific product classes

Until a given part is cited in the Official Journal, meeting it grants no legal presumption of conformity — so we track the series here rather than scoring you against moving drafts. The practical move today is to build against the stable Annex I requirements above (which the assessments here already cover); a product built cleanly to those will map onto EN 40000 with little rework once the standards land. We update this section as parts are cited.

Article 14

The reporting clock is measured in hours

When you become aware of an actively exploited vulnerability in your product, or a severe incident affecting its security, notification runs on a fixed escalation schedule through a single reporting platform.

  1. 24h

    Early warning

    An initial notification to the coordinating CSIRT and ENISA indicating that an actively exploited vulnerability or severe incident has been detected.

  2. 72h

    Vulnerability notification

    A fuller report covering the nature of the vulnerability, any corrective measures taken or available, and the exploitation status.

  3. 14d / 1 month

    Final report

    The closing report, and the one stage where the two triggers diverge: for an actively exploited vulnerability it falls due within 14 days of a corrective or mitigating measure becoming available, whereas for a severe incident it falls due within one month of the 72-hour notification. It covers the vulnerability or incident, its severity and impact, and the remediation deployed. Users must be informed where relevant.

Meeting these windows is an operational problem before it is a legal one. You need a defined intake path, a triage owner, a decision authority available outside business hours, and pre-drafted notification templates. Building that after the first incident is too late.

Assessments for this framework

Structured questionnaires scored entirely in your browser — no account, nothing transmitted. Each maps its result back to the requirement it measures.

Get in touch

Work out what the CRA actually asks of your product

Send us the product category and target markets. We will map the likely CRA class, the conformity assessment route that follows from it, and where the Annex I obligations will bite hardest for what you build.

We reply within two working days.

Full contact details
consulting@readinessnavigator.com
Write to us
Book a 30-minute call

Opens our scheduling page in a new tab — pick a slot that suits you.

Worth including in a first message

  • What the product is, and whether it contains software or connects to a network.
  • Which markets you sell into, and your role — manufacturer, importer, or distributor.
  • Whether the product is already on the market or not yet released.

Please keep a first message free of confidential technical detail and trade secrets. Once we reply we can agree an encrypted channel for anything sensitive.