New to the terms? The CRA glossary explains CSIRT, KEV, SBOM and the rest in plain English.
Does the CRA apply to your product?
A few questions on the scope of Regulation (EU) 2024/2847. Nothing you tick is sent anywhere.
The result shows here as you answer.
Guidance, not legal advice. Delegated acts under Art. 2(5) can limit the CRA for products covered by other EU rules.
In short
- The CRA is Regulation (EU) 2024/2847. It sets cybersecurity requirements for products with digital elements made available on the EU market, from design to the last security update.
- The duty to report actively exploited vulnerabilities and severe incidents has applied since 11 September 2026. The rest applies from 11 December 2027.
- What triggers the obligations is a sale in the EU, not where the manufacturer is based. Norwegian manufacturers are covered for the products they sell in the EU.
- The CRA isn’t part of the EEA Agreement. Until it is, it doesn’t apply to products sold only in Norway.
- Most products are in the default class, where the manufacturer assesses conformity itself. Important and critical products have stricter conformity assessment.
- Breaches can mean administrative fines of up to EUR 15 million or 2.5% of worldwide annual turnover.
The timeline
- 10 December 2024: the CRA entered into force.
- 11 June 2026: the rules on notified bodies (Chapter IV) apply. Member states can notify the bodies that will carry out conformity assessments.
- 11 September 2026: the Article 14 reporting duties apply, including to products placed on the market before that date (Article 69(3)).
- 11 December 2027: the rest of the CRA applies: the essential requirements in Annex I, conformity assessment, CE marking, technical documentation and the obligations of importers and distributors. This covers products placed on the market from that date. Older products are only covered if they are substantially modified afterwards (Article 69(2)).
- Norway: the CRA applies once it is part of the EEA Agreement and Norwegian law. The aim is 11 December 2027, but that date isn’t decided.
Does the CRA apply to you?
The CRA covers products with digital elements made available on the market whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1)). A product with digital elements is software or hardware, with the remote data processing the product needs to work. Components placed on the market separately are products too (Article 3(1)–(2)).
“Made available on the market” means supplied in the EU in the course of a commercial activity, for payment or free of charge (Article 3(22)). Software you only offer as a service, with no product at the customer’s end, is outside the CRA (recital 12).
The CRA doesn’t apply to:
- medical devices and in vitro diagnostic medical devices (Regulations (EU) 2017/745 and 2017/746)
- products covered by the motor vehicle type-approval rules of Regulation (EU) 2019/2144
- products certified under the civil aviation rules of Regulation (EU) 2018/1139
- marine equipment under Directive 2014/90/EU
- spare parts that replace identical components and are made to the same specifications
- products developed or modified exclusively for national security or defence, or designed to process classified information
Free and open-source software is only covered when it’s supplied in the course of a commercial activity (recitals 17–18). The checker at the top of the page walks through the questions, one product at a time.
Who has obligations
Most obligations fall on the manufacturer: whoever develops or manufactures a product, or has it made, and markets it under its own name or trademark (Article 3(13)). The Regulation has four other roles:
- Authorised representative: a person in the EU with a written mandate from the manufacturer to carry out specified tasks (Article 18).
- Importer: whoever in the EU places on the market a product from a manufacturer outside the EU (Article 19). When a Norwegian manufacturer sells through a reseller in the EU, that’s usually the reseller.
- Distributor: anyone else in the supply chain who makes the product available without changing it (Article 20).
- Open-source software steward: a legal person that systematically supports the development of free and open-source software intended for commercial use. It has lighter obligations and doesn’t affix the CE marking (Article 24 and recital 19).
An importer or distributor that puts its own name on the product, or substantially modifies it, becomes the manufacturer (Article 21). The roles also decide which country your reports go to: see Does the CRA apply before the EEA?.
The product classes
The class decides how conformity is assessed, and it follows from the product’s core functionality (Article 7(1)):
- Default: most products. The manufacturer assesses conformity itself (internal control, module A).
- Important, class I (Annex III): among others operating systems, routers and switches, password managers, VPNs, browsers and smart home products with security functions. Internal control is only possible when harmonised standards, common specifications or a European cybersecurity certification scheme are applied in full. Otherwise a notified body is needed.
- Important, class II (Annex III): hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers. Always a notified body or a European certification scheme.
- Critical (Annex IV): hardware devices with security boxes, smart meter gateways, and smartcards or similar devices, including secure elements. European certification where a delegated act requires it, otherwise as class II.
As of 1 November 2026, no harmonised standard for the CRA is cited in the Official Journal, and no notified bodies are listed under the CRA. For now, class I products should plan for a notified body.
The reporting duties are the same in every class. Check your product’s class.
The product requirements
Part I of Annex I holds the essential cybersecurity requirements. The product must have a level of security that fits its risks, and the risk assessment decides how each requirement applies to it (Article 13(2)–(3)). Among the requirements:
- no known exploitable vulnerabilities when it’s placed on the market
- a secure default configuration, and a way to reset the product
- security updates, automatic by default where applicable, with an easy way to opt out
- protection from unauthorised access, with authentication and access control
- encryption and protection of the data’s integrity
- data minimisation: only the data the product needs
- availability of essential functions, during and after an attack
- the smallest possible attack surface, and limited damage when something happens
- recording of security-relevant activity, with an opt-out for the user
- an easy way to remove data and settings permanently
Vulnerability handling
Part II of Annex I covers your processes, for the whole support period:
- a software bill of materials (SBOM) in a commonly used, machine-readable format
- assessing and fixing vulnerabilities without delay, based on risk
- testing and reviewing security regularly
- publishing information about fixed vulnerabilities
- a coordinated vulnerability disclosure policy, and an address where vulnerabilities can be reported
- distributing updates securely, and providing security updates free of charge with advice for users
The support period must be at least five years, unless the product is expected to be in use for less. Each security update must stay available for at least ten years, or the rest of the support period if that’s longer (Article 13(8)–(9)).
Reporting under Article 14
When you become aware of an actively exploited vulnerability in a product, or a severe incident affecting its security, you send:
- an early warning within 24 hours
- a notification within 72 hours
- a final report: for a vulnerability, no later than 14 days after a fix or mitigation is available; for an incident, within a month of the notification
The reports go to the CSIRT designated as coordinator and to ENISA at the same time, through ENISA’s Single Reporting Platform (SRP). You also inform the users affected (Article 14(8)). The CRA playbook covers the deadlines, what each report must contain and who you report to.
Conformity assessment, CE marking and documentation
Before a product is placed on the market from 11 December 2027, you:
- Carry out a risk assessment and include it in the technical documentation (Article 13(2)–(4)).
- Draw up the technical documentation under Annex VII (Article 31).
- Carry out the conformity assessment the class requires (Article 32).
- Draw up the EU declaration of conformity under Annex V (Article 28).
- Affix the CE marking. For software it can go on the declaration of conformity or on the website that accompanies the product (Article 30).
- Ship the product with the user information in Annex II, including the contact point for vulnerabilities and when the support period ends.
Keep the technical documentation and the declaration of conformity for at least ten years after the product was placed on the market, or for the whole support period if that’s longer (Article 13(13)).
The fines
Member states set the penalties, within three ceilings for administrative fines (Article 64):
- EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher: breaches of the requirements in Annex I and the obligations in Articles 13 and 14
- EUR 10 million or 2%: breaches of, among others, the obligations of authorised representatives, importers and distributors, and the rules on the declaration of conformity and CE marking
- EUR 5 million or 1%: incorrect, incomplete or misleading information to notified bodies and market surveillance authorities
Micro and small enterprises aren’t to be fined for missing the 24-hour deadline for the early warning (Article 64(10) and recital 120). Market surveillance authorities can also require a product to be brought into compliance, withdrawn or recalled (Article 54).
Where Norway stands
The CRA is marked as EEA-relevant but hasn’t been incorporated into the EEA Agreement. That means:
- For products you sell in the EU, the CRA applies now, and reports go to a CSIRT in an EU country.
- For products sold only in Norway, the CRA doesn’t apply yet.
- Nkom will supervise the CRA in Norway, but can’t receive reports until the regulation is part of the EEA Agreement and Norwegian law.
The aim is for the CRA to apply in Norway from 11 December 2027, but that date isn’t decided. For radio equipment, the cybersecurity requirements of the Radio Equipment Directive already apply, in Norway too. Reporting from Norway walks through the route step by step.
Checklist
- List the products you sell in the EU, including older models still in use.
- Check whether each product is in scope, and find its class.
- Have reporting ready now: your Article 14(7) route, SRP access for two people and on-call cover around the clock.
- Publish a coordinated vulnerability disclosure policy and a contact address, for example in security.txt.
- Produce an SBOM for each version, generated by the build system.
- Set and justify the support period for each product.
- Run a gap analysis against Annex I, and plan the work into product development.
- Choose the conformity assessment route, and contact a notified body early if the class requires one.
- Agree the roles with importers and distributors in the EU.
- Have the technical documentation, declaration of conformity and CE marking ready before products are placed on the market from 11 December 2027.
Templates
Word templates you can adapt:
- Coordinated vulnerability disclosure policy
- Vulnerability handling procedure
- Support period determination
The templates are a starting point, not legal advice.
Sources
- Regulation (EU) 2024/2847 (CRA)
- Implementing Regulation (EU) 2025/2392, with the technical descriptions of the product categories
- The Commission’s guidance on applying the CRA, 27 July 2026
- ENISA’s list of CSIRTs designated as coordinators
- Nkom on CRA reporting, 11 September 2026 (in Norwegian)
Articles on the CRA
Pharus with Claude and other AI agents: how the MCP server works
The Pharus MCP server lets an AI assistant such as Claude read your workspace, register a vulnerability and draft a CRA report for you to review. It can’t start a clock, decide, file or send anything: that stays with a person signed in to Pharus. Here’s how it works, how to connect one, and where your data goes.
Do small companies get fined for missing the CRA’s 24-hour deadline?
Not for missing the 24-hour early warning, if you’re a micro or small enterprise. The early warning is still required, and the exemption doesn’t cover the 72-hour notification, the final report or medium-sized companies.
A CRA early warning, filled in: an example
An early warning only needs what you know within 24 hours: the product, the versions, where it’s sold and when you became aware. Here is one filled in, field by field, for a made-up gateway maker, with what comes after.
When is a vulnerability “actively exploited”, and when does the 24-hour clock start?
When, after a quick initial assessment, you’re reasonably certain that a vulnerability in your product is being exploited by a malicious actor. The 24 hours start then, not when the investigation is done. A vulnerability in a third-party component is only reportable when it’s exploited in your product.
Does the CRA apply to Norwegian manufacturers before it’s part of the EEA Agreement?
Yes, for everything you sell in the EU. The duty to report actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, including to products placed on the market before then. What waits for the EEA Agreement is Norwegian supervision, and products sold only in Norway.
