Everything You Need to Know About the Cyber Resilience Act

While working on compliance solutions for our customers, we kept running into the same thing: most companies have not heard of the Cyber Resilience Act, and the ones that have assume it is optional. It is not. The CRA is Regulation (EU) 2024/2847. It applies to almost any software or hardware product sold or made available in the EU, and not complying carries fines of up to EUR 15 million or 2.5 percent of worldwide turnover. Part of it already applies. Since 11 September 2026, if someone is actively exploiting a vulnerability in your product, you have 24 hours to file an early warning with a national CSIRT and ENISA. The rest applies from 11 December 2027.

When we went looking online, we could not find any resource that maps the whole regulation, and that is why I am writing this. This article maps all 71 articles and 8 annexes, and for each one, whether it applies to you and what you actually have to do. If you are working on CRA compliance, read it all the way through. It is long, but that is the point: every rule is here, so nothing gets missed. Treat it less like a blog post and more like a map of everything your organisation needs to have in place to be compliant with the CRA.

The roles the CRA talks about

Every article below carries an "Applies to" verdict, using the regulation's own roles. These are the ones that matter:

• Manufacturer: whoever develops a product with digital elements, or has it developed, and markets it under their own name or trademark, paid or free. This is the role with nearly all the obligations.
• Open-source software steward (OSS steward): a legal person, other than a manufacturer, that supports the development of an open-source project meant for commercial use without selling it. Foundations are the obvious case; a company that maintains a project but does not sell it is another.
• Importer: whoever first brings a product from a manufacturer outside the EU into the EU market.
• Distributor: anyone else in the supply chain who makes the product available, such as a reseller.
• Authorities only: the article is addressed to the Commission, Member States, market surveillance authorities or notified bodies. Nothing for a company to do.

The map at a glance

One row per chapter, plus the annexes. Use it to skip to what applies to you.

Chapter	Articles	Who it applies to	What you have to do
I: General provisions	1 to 12	Everyone (2, 3, 6, 7, 8); authorities for the rest	Work out whether you are in scope, your role, your product class
II: Obligations of economic operators and open-source provisions	13 to 26	Manufacturers (13, 14, 18, 21 to 23), importers (19, 21, 23), distributors (20, 21, 23), OSS stewards (24, plus parts of 14 via 24)	The actual compliance work: security by design, vulnerability handling, reporting, documentation
III: Conformity of the product	27 to 34	Manufacturers	Pick the assessment route, write the technical documentation and DoC, affix CE marking
IV: Notification of conformity assessment bodies	35 to 51	Authorities and notified bodies only	Nothing
V: Market surveillance and enforcement	52 to 60	Authorities; manufacturers and stewards on the receiving end	Hand over documentation and take corrective action when asked
VI: Delegated powers and committee procedure	61 to 62	Authorities only	Nothing
VII: Confidentiality and penalties	63 to 65	Manufacturers, importers, distributors; stewards exempt from fines	Know the fine tiers
VIII: Transitional and final provisions	66 to 71	Everyone for 69 and 71; nobody for 66 to 68 and 70	Know the dates and the grandfathering rule
Annexes I to VIII		Manufacturers; stewards for the substance of Annex I Part II, not as a legal duty	The actual checklists

Chapter I: General provisions (Articles 1 to 12)

Article 1: Subject matter

Applies to: everyone, in the sense that it says what the law is for.

Rules for placing products with digital elements on the market, essential cybersecurity requirements, vulnerability handling, market surveillance. The whole regulation in four bullet points.

Article 2: Scope

Applies to: everyone. This decides whether the rest is your problem.

The scope sentence is broad on purpose: the regulation applies to "products with digital elements made available on the market, the intended purpose or reasonably foreseeable use of which includes a direct or indirect logical or physical data connection to a device or network." Software, hardware and separately sold components all count. Even a piece of software that never connects to a network on its own, but is built into a product that does, has an indirect connection and counts too.

The exclusions are products already covered by their own cybersecurity law: medical devices and in vitro diagnostics, motor vehicles, products certified under the civil aviation regulation (EU) 2018/1139, marine equipment. Spare parts identical to what they replace are out. Products built exclusively for national security, defence or classified information are out. The Commission can carve out further sectors by delegated act where sector rules give the same or better protection (Article 2(5)).

Open-source software is not on that list. Its treatment lives in the Article 3 definitions (which is why so many people get it wrong).

Article 3: Definitions

Applies to: everyone. There are dozens of definitions; these decide your role.

Product with digital elements. "A software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately." So a device plus the cloud API it needs to work is one product.

Manufacturer. Whoever develops a product with digital elements, or has it developed, and markets it under its own name or trademark, "whether for payment, monetisation or free of charge." Charging nothing does not make you not a manufacturer.

Making available on the market and placing on the market. Making available is supplying a product for distribution or use in the EU "in the course of a commercial activity, whether in return for payment or free of charge." Placing on the market is the first time that happens. The hinge word is commercial. Free software supplied outside a commercial activity is outside the regulation. Free software supplied as part of one is in.

Open-source software steward. "A legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products." Foundations are the obvious case. A company that maintains a project it does not sell is another.

Substantial modification. A change after placing on the market that affects compliance with Annex I Part I or changes the intended purpose the product was assessed for. This is the trigger in Articles 21, 22 and 69.

Support period. The period during which the manufacturer has to handle vulnerabilities in line with Annex I Part II.

Actively exploited vulnerability. One "for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner." Not a high-severity finding in a security scan report. Evidence that someone has actually used it in an attack. This is the Article 14 trigger.

Article 4: Free movement

Applies to: authorities only.

Member States cannot block a product that complies and carries CE marking.

Article 5: Procurement or use of products with digital elements

Applies to: authorities only, unless you sell to government.

Member States may add cybersecurity requirements when procuring or using products for purposes such as national security, and public procurement has to weigh Annex I compliance and vulnerability handling.

Article 6: Requirements for products with digital elements

Applies to: manufacturers.

A product may only be made available if it meets Annex I Part I and the manufacturer's processes meet Annex I Part II. This is the legal hook for Annex I. Annex II, the user information, comes in through Article 13(18).

Article 7: Important products with digital elements

Applies to: manufacturers of anything in Annex III.

Annex III products are "important," split into Class I and Class II. The class changes which conformity assessment route you can use (Article 32).

Article 8: Critical products with digital elements

Applies to: manufacturers of anything in Annex IV.

Annex IV products are "critical." The Commission can require a European cybersecurity certificate for them; until it does, they follow the Class II route.

Article 9: Stakeholder consultation

Applies to: authorities only.

The Commission consults stakeholders, the open-source community explicitly among them, when preparing delegated acts and guidance.

Article 10: Enhancing skills in a cyber resilient digital environment

Applies to: authorities only.

Member States promote cybersecurity skills.

Article 11: General product safety

Applies to: manufacturers, only where the product has non-cyber safety risks.

Where neither the CRA nor other sectoral law covers a risk, parts of the General Product Safety Regulation (EU) 2023/988 apply. A connected kettle is regulated by the CRA for the network side and by product safety law for the boiling water.

Article 12: High-risk AI systems

Applies to: manufacturers whose product is also a high-risk AI system.

Meet Annex I, and say so in your CRA Declaration of Conformity, and you are deemed to meet the AI Act's cybersecurity requirement (Article 15 of Regulation (EU) 2024/1689). Conformity assessment then runs under the AI Act's procedure, except for important and critical products that would otherwise go through the AI Act's internal-control route, which keep the CRA's procedures for the cybersecurity part.

Chapter II: Obligations of economic operators and provisions relating to free and open-source software (Articles 13 to 26)

This is the chapter with the work in it.

Article 13: Obligations of manufacturers

Applies to: manufacturers. Not OSS stewards, who have their own much shorter article (24).

Article 13 runs to 25 paragraphs. Grouped by what they make you do:

Build it right, and prove you thought about it. Products must be designed, developed and produced in line with Annex I Part I, on the basis of a cybersecurity risk assessment covering planning, design, development, production, delivery and maintenance. The assessment is documented, kept updated through the support period, and included in the technical documentation. It has to say which Annex I Part I point (2) requirements apply and how they are met, and where one does not apply, why. "Not applicable" without a justification is not an answer.

Do due diligence on what you pull in. When integrating third-party components, including open-source components not made available commercially, exercise due diligence so they do not compromise the product's security. The regulation does not say how; in practice it means keeping a list of what your product is built from, scanning it for known vulnerabilities, and judging whether the people who maintain each component are still around to fix problems.

Feed vulnerabilities back upstream. Find a vulnerability in a component and you report it to whoever maintains it. If you developed a fix, you share the code or documentation with them, in a machine-readable format where appropriate.

Handle vulnerabilities for the support period, and the support period has a floor. Article 13(8) requires effective vulnerability handling under Annex I Part II for the whole support period. The period reflects how long the product is expected to be in use and is at least five years, unless the product is genuinely expected to be used for less, and you document the reasoning. Under Article 13(9), every security update issued during the support period stays available for at least ten years after it was issued or for the remainder of the support period, whichever is longer.

Conformity paperwork. Run the Article 32 assessment, draw up the EU Declaration of Conformity (Article 28), affix CE marking (Article 30). Keep the technical documentation and DoC for ten years after placing on the market or for the support period, whichever is longer (Article 13(13)).

Identify yourself, and tell users what they need to know. A type, batch or serial number. Manufacturer name, postal address, an email address or other digital contact and, where applicable, a website. A single point of contact where users can report vulnerabilities and reach you directly; it must be easy to find, let users pick their channel, and not be limited to automated tools. Ship the Annex II information in a language users understand. State the support period end date, at least month and year, at the time of purchase.

Fix it, cooperate, and say goodbye properly. If the product falls out of conformity, take corrective measures immediately, or withdraw or recall. On reasoned request from a market surveillance authority, hand over what is needed to demonstrate conformity. If you cease operations, inform the authorities and the users first.

Software bill of materials (SBOM). An SBOM is a list of the components your product is built from. The Commission may specify the format, and authorities may request SBOMs as part of an EU-wide dependency assessment. The requirement to have one is Annex I Part II point (1); you do not have to publish it.

Article 14: Reporting obligations of manufacturers

Applies to: manufacturers directly, from 11 September 2026. OSS stewards inherit specific paragraphs through Article 24(3), covered below.

Two triggers: an actively exploited vulnerability in your product (Article 14(1)), and a severe incident affecting the security of your product (Article 14(3)). Both go to the CSIRT designated as coordinator in your Member State and to ENISA at the same time, through the single reporting platform Article 16 tells ENISA to run. Three stages, though a later stage can be skipped where the information was already given in an earlier one:

Stage	Actively exploited vulnerability (Art. 14(2))	Severe incident (Art. 14(4))
Early warning	Within 24 hours of becoming aware. Where known, which Member States the product is in.	Within 24 hours of becoming aware. Whether the incident is suspected to be caused by unlawful or malicious acts.
Notification	Within 72 hours. General information on the exploit and the vulnerability, corrective or mitigating measures taken, measures users can take, and where applicable how sensitive you consider the information.	Within 72 hours. Nature of the incident, initial assessment, corrective or mitigating measures taken and available to users.
Final report	Within 14 days after a corrective or mitigating measure is available. Description of the vulnerability including severity and impact, information on the malicious actor where available, details of the security update or other corrective measures.	Within one month after the 72-hour notification. Detailed description including severity and impact, the type of threat or root cause likely to have triggered it, mitigation measures applied and ongoing.

Note the asymmetry on the final report: for a vulnerability the clock starts when a fix exists, for an incident it starts from the 72-hour notification, fix or no fix.

Article 14(5) defines a severe incident as one that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or could lead to malicious code being introduced into the product or users' systems. A break-in to the systems you use to build and release your software, one that could have let an attacker slip malicious code into a release, is inside that definition even if nothing was shipped.

Article 14(8) adds the user-facing duty: after becoming aware, inform impacted users, and where appropriate all users, about the vulnerability or incident and, where necessary, any mitigation they can apply. If you fail to do so in a timely manner, the CSIRT may inform them itself.

Article 15: Voluntary reporting

Applies to: anyone who wants to.

Manufacturers, stewards and anyone else can voluntarily notify vulnerabilities, cyber threats, incidents and near misses, including ones a manufacturer would have had to report anyway, without creating new obligations for themselves.

Article 16: Establishment of a single reporting platform

Applies to: authorities only, but it is where your Article 14 reports go.

ENISA builds and runs it, with national endpoints so one submission reaches both the CSIRT and ENISA.

Article 17: Other provisions related to reporting

Applies to: authorities only.

How CSIRTs and ENISA handle what they receive and who they share it with.

Article 18: Authorised representatives

Applies to: manufacturers outside the EU, optionally.

A manufacturer may mandate an EU-based representative to hold documentation and deal with authorities; responsibility for the product stays with the manufacturer.

Article 19: Obligations of importers

Applies to: importers, whoever first brings a third-country manufacturer's product into the EU.

Before placing a product on the market, verify the manufacturer ran the conformity assessment, drew up the technical documentation, affixed CE marking and provided the Annex II information. Report non-conformity and significant risks. Put your own name on the product, keep the DoC for ten years or the support period, whichever is longer, and be able to produce the technical documentation.

Article 20: Obligations of distributors

Applies to: distributors, resellers and anyone else in the chain who is not the manufacturer or importer.

A lighter Article 19: check the CE marking and documentation are there, and report non-conformity and vulnerabilities upstream and, where there is a significant risk, to the authorities.

Article 21: Cases in which obligations of manufacturers apply to importers and distributors

Applies to: importers and distributors who rebrand or modify.

Put your own name on a product, or substantially modify it, and you are its manufacturer with Articles 13 and 14 attached.

Article 22: Other cases in which obligations of manufacturers apply

Applies to: anyone else who substantially modifies a product and places it on the market.

Same principle for integrators and system builders.

Article 23: Identification of economic operators

Applies to: manufacturers, importers and distributors.

On request, identify who supplied you with a product and who you supplied it to, for ten years in each direction.

Article 24: Obligations of open-source software stewards

Applies to: OSS stewards only. Manufacturers are not subject to it, and stewards are not subject to Article 13.

This is the article the open-source world spent two years negotiating for, and it is short. Four obligations.

One. Put in place and document a cybersecurity policy. Article 24(1) requires stewards to "put in place and document in a verifiable manner a cybersecurity policy to foster the development of a secure product with digital elements as well as an effective handling of vulnerabilities by the developers of that product." It has to cover secure development and vulnerability handling, including how vulnerabilities are documented, addressed and remediated, encourage developers to report voluntarily under Article 15, and promote sharing of vulnerability information within the open-source community. "In a verifiable manner" is doing real work in that sentence. A policy in someone's head does not count. A published page alongside the project does.

Two. Cooperate with market surveillance authorities. Article 24(2): if an authority asks, with a view to mitigating cybersecurity risks, you cooperate and hand over the policy documentation.

Three and four. Report, in two narrow situations. Article 24(3) imports parts of Article 14 rather than the whole thing:

• Article 14(1), the actively exploited vulnerability report, applies to stewards "to the extent that they are involved in the development of the products with digital elements." If you actually write or maintain the affected code, an actively exploited vulnerability in it triggers the 24-hour early warning, the 72-hour notification and the 14-day final report.
• Article 14(3) and 14(8), the severe incident report and the user notification, apply "to the extent that severe incidents having an impact on the security of products with digital elements affect network and information systems provided by the open-source software stewards for the development of such products." That is your build and release infrastructure. A severe incident in a user's deployment of your software is not your report to file. A break-in to the systems that build and release it is.

What is not in Article 24 is most of the regulation: no Annex I obligation, no risk assessment, no technical documentation, no conformity assessment, no DoC, no CE marking, no support period minimum, no ten-year retention. And under Article 64(10), administrative fines do not apply to any infringement by an open-source software steward. Enforcement against a steward is Article 52(3): an authority can require corrective action, not pay a fine.

Article 25: Security attestation of free and open-source software

Applies to: OSS stewards and developers, voluntarily; useful to manufacturers.

The Commission may set up voluntary attestation programmes so developers or users of open-source software can attest to its conformity with Annex I, which feeds a manufacturer's Article 13 due diligence.

Article 26: Guidance

Applies to: authorities only.

The Commission publishes guidance, explicitly including scope, substantial modification, open-source software and remote data processing. Creates no obligation.

Chapter III: Conformity of the product with digital elements (Articles 27 to 34)

Applies to: manufacturers throughout.

Article 27: Presumption of conformity

Apply a harmonised standard, a Commission common specification, or a European cybersecurity certification scheme, and you are presumed to meet whatever it covers. The harmonised standards for the CRA are still being written, which is why so many companies are stuck at "self-assess against what, exactly?"

Article 28: EU declaration of conformity

One DoC per product on the Annex V template, kept current and retained for ten years or the support period, whichever is longer (Article 13(13)). The simplified Annex VI version can ship with the product as long as the full one is online.

Article 29: General principles of the CE marking

The general CE rules from Regulation (EC) 765/2008 apply; the CRA-specific rules are in Article 30.

Article 30: Rules and conditions for affixing the CE marking

The marking must be visible, legible and indelible on the product, or on packaging and the DoC where the product cannot carry it. For products "in the form of software," it goes either on the EU declaration of conformity or on the website accompanying the software product. The minimum height is 5 mm, but it may be lower on account of the product's nature as long as it stays legible. If you used Module H, full quality assurance, the notified body's identification number follows the mark; under Module B+C it does not. So for pure software, "CE marking" concretely means a CE logo on your DoC page or product website.

Article 31: Technical documentation

Before placing on the market, draw up the Annex VII technical documentation. Keep it current, retain it for ten years or the support period, whichever is longer, and hand it to market surveillance authorities on request.

Article 32: Conformity assessment procedures for products with digital elements

The assessment is how you prove Annex I is met. It comes in four variants, called Modules A, B, C and H. What each module involves and who does the work is explained in the Annex VIII section further down; here Article 32 only says which module a given product category may use:

Product category	Allowed routes
Default (not in Annex III or IV)	Module A (self-assessment), or B+C, or H, or a European cybersecurity certification scheme. Almost everyone picks A.
Important, Class I (Annex III)	Module A only if you fully apply harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least "substantial" covering the requirements. Otherwise B+C or H.
Important, Class II (Annex III)	B+C, or H, or a European cybersecurity certification scheme at assurance level "substantial." Third-party involvement is mandatory.
Critical (Annex IV)	A European cybersecurity certification scheme where the Commission has mandated one; until then, the Class II options.
Open-source manufacturer, product in Annex III	Article 32(5): any route in paragraph 1, including Module A, provided the technical documentation is made public at the time of placing on the market.

The last row is easy to misread. It is relief for manufacturers of open-source software. It is not about stewards, who have no assessment to do at all.

Article 33: Support measures for microenterprises and small and medium-sized enterprises

Member States run awareness and training, may set up regulatory sandboxes, and provide a dedicated communication channel for micro and small enterprises. Micro and small enterprises may also supply the Annex VII technical documentation in a simplified form. The only obligation is that if you use the simplified form, you must use the Commission's template for it (Article 33(5)).

Article 34: Mutual recognition agreements

The EU can agree with third countries to recognise each other's conformity assessments.

Chapter IV: Notification of conformity assessment bodies (Articles 35 to 51)

Applies to: national notifying authorities and notified bodies only.

Seventeen articles on how a Member State designates and supervises the labs that do third-party assessment, applying from 11 June 2026. For the record: Article 35 (notification), Article 36 (notifying authorities), Article 37 (requirements relating to notifying authorities), Article 38 (information obligation on notifying authorities), Article 39 (requirements relating to notified bodies), Article 40 (presumption of conformity of notified bodies), Article 41 (subsidiaries and subcontracting), Article 42 (application for notification), Article 43 (notification procedure), Article 44 (identification numbers and lists), Article 45 (changes to notifications), Article 46 (challenge of the competence of notified bodies), Article 47 (operational obligations of notified bodies), Article 48 (appeal against decisions of notified bodies), Article 49 (information obligation on notified bodies), Article 50 (exchange of experience), Article 51 (coordination of notified bodies).

Chapter V: Market surveillance and enforcement (Articles 52 to 60)

Applies to: authorities as the actors; manufacturers, importers, distributors and stewards as the subjects.

Article 52: Market surveillance and control of products with digital elements in the Union market

Each Member State designates market surveillance authorities under the general market surveillance regulation (EU) 2019/1020. Article 52(3) says plainly that those authorities also supervise the Article 24 obligations of open-source software stewards, and where a steward is not complying, they require corrective action. Stewards are not outside enforcement. They are outside fines.

Article 53: Access to data and documentation

On reasoned request, authorities get access to the data needed to assess the design, development, production and vulnerability handling of the product, including internal documentation, under the confidentiality rules of Article 63, which name source code specifically.

Articles 54 to 60: Procedures and powers

Article 54 is the national procedure when a product presents a significant cybersecurity risk: evaluation, corrective orders, withdrawal or recall. Article 55 is the Union safeguard procedure for when Member States disagree. Article 56 lets the Commission act at Union level. Article 57 covers products that are fully compliant and still present a significant risk. Article 58 is formal non-compliance, meaning paperwork failures such as a missing DoC or wrongly affixed CE marking. Article 59 covers joint activities between authorities and Article 60 covers sweeps, coordinated checks of a product category across several Member States.

Chapter VI: Delegated powers and committee procedure (Articles 61 to 62)

Applies to: authorities only.

Article 61 sets the terms for Commission delegated acts (updating the Annex III and IV lists, for example) and Article 62 the committee procedure. Institutional plumbing.

Chapter VII: Confidentiality and penalties (Articles 63 to 65)

Article 63: Confidentiality

Applies to: authorities, protecting you.

Everyone applying the regulation has to protect what they obtain, with intellectual property, trade secrets and source code named specifically.

Article 64: Penalties

Applies to: manufacturers, importers, distributors and authorised representatives. Not OSS stewards.

Member States set the penalty rules within these ceilings:

Infringement	Maximum fine
Annex I essential requirements, or Article 13 or 14 obligations	EUR 15 000 000 or 2.5 percent of total worldwide annual turnover, whichever is higher
Articles 18 to 23, 28, 30(1) to (4), 31(1) to (4), 32(1) to (3), 33(5), 39, 41, 47, 49 and 53	EUR 10 000 000 or 2 percent of turnover, whichever is higher
Supplying incorrect, incomplete or misleading information to notified bodies or market surveillance authorities	EUR 5 000 000 or 1 percent of turnover, whichever is higher

Two exemptions in Article 64(10). Micro and small enterprises that miss the 24-hour early warning deadline are not fined for that specific failure. And administrative fines do not apply to "any infringement of this Regulation by open-source software stewards." Not reduced. Do not apply. One drafting quirk worth knowing: the paragraph is worded as a derogation from paragraphs 3 to 9, while the top fine tier sits in paragraph 2. The intent stated in the recitals, and the reading everyone works with, is that stewards are not fined at all.

Article 65: Representative actions

Applies to: manufacturers, in the sense that consumers can sue them collectively.

Directive (EU) 2020/1828 is extended to the CRA, so qualified consumer organisations can bring collective actions over infringements that harm consumers.

Chapter VIII: Transitional and final provisions (Articles 66 to 71)

Articles 66, 67 and 68: Amendments to other legislation

Applies to: nobody in industry.

Article 66 amends the market surveillance regulation (EU) 2019/1020, Article 67 amends the representative actions directive (EU) 2020/1828, and Article 68 amends Regulation (EU) No 168/2013 on type-approval of two- and three-wheel vehicles and quadricycles.

Article 69: Transitional provisions

Applies to: everyone with a product on the market before 11 December 2027.

Article 69(2): products placed on the market before 11 December 2027 are subject to the regulation only if substantially modified after that date. Article 69(3) is the derogation everyone misses: notwithstanding that, the Article 14 reporting obligations apply to all in-scope products placed on the market before 11 December 2027. A product you shipped in 2019 that gets actively exploited in 2026 is a 24-hour early warning. Article 69(1) keeps existing EU type-examination certificates issued under other harmonisation law valid until 11 June 2028.

Article 70: Evaluation and review

Applies to: authorities only.

The Commission reports on the regulation by 11 December 2030 and every four years after.

Article 71: Entry into force and application

Applies to: everyone.

In force since 10 December 2024. Applies in full from 11 December 2027. Two things come earlier: Chapter IV (Articles 35 to 51) from 11 June 2026, and Article 14 from 11 September 2026.

The annexes

Annex I: Essential cybersecurity requirements

Applies to: manufacturers, through Articles 6 and 13. Stewards are not legally bound by Annex I.

Part I: security properties of the product. Point (1) is the umbrella: designed, developed and produced to provide a level of cybersecurity appropriate to the risks. Point (2) lists thirteen properties that apply on the basis of the risk assessment, where relevant:

1. Made available without known exploitable vulnerabilities. A pre-market gate, not an aspiration.
2. Secure by default configuration, with the ability to reset to the original state.
3. Security updates, automatic by default where applicable, with opt-out, postponement and notification.
4. Protection from unauthorised access through authentication, identity and access management, with reporting of possible unauthorised access.
5. Confidentiality of stored, transmitted or processed data, including encryption at rest and in transit using state-of-the-art mechanisms.
6. Integrity of data, commands, programs and configuration, with reporting of corruption.
7. Data minimisation: only what is adequate, relevant and necessary for the intended purpose.
8. Availability of essential and basic functions, including after an incident, with resilience against denial-of-service.
9. Minimal negative impact on the availability of services provided by other devices or networks.
10. Limited attack surfaces, including external interfaces.
11. Reduced incident impact through exploitation mitigation mechanisms and techniques.
12. Security-relevant logging and monitoring of internal activity, with a user opt-out.
13. Secure and permanent removal of data and settings by the user.

Part II: vulnerability handling. Eight requirements that run for the whole support period:

1. A software bill of materials (SBOM), a machine-readable list of the components the product is built from, covering at least the top-level ones.
2. Address and remediate vulnerabilities without delay, with security updates delivered separately from functionality updates where technically feasible.
3. Effective and regular security tests and reviews.
4. Once a fix is available, publicly disclose the fixed vulnerability: description, affected versions, impact, severity, remediation guidance. Disclosure may be delayed in justified cases.
5. Put in place and enforce a coordinated vulnerability disclosure policy.
6. Facilitate sharing of vulnerability information, including a contact address for reporting vulnerabilities in the product.
7. Secure update distribution, automatic where applicable.
8. Free security updates without delay, with advisories telling users what to do.

If you are a manufacturer and want one document to build a compliance programme around, it is this annex.

Annex II: Information and instructions to the user

Applies to: manufacturers, through Article 13.

What ships with the product or is linked from it: manufacturer contact details; the vulnerability reporting contact and CVD policy; product identification; intended purpose and security properties; known circumstances that could lead to significant risk; the DoC URL; the type of security support and the support period end date; instructions for secure use, installing updates, decommissioning, turning off automatic updates, and what an integrator needs; and, if you publish the SBOM, where it is. The support end date is the part most people have never written down.

Annex III: Important products with digital elements

Applies to: manufacturers whose product is on the list.

Class I: identity management and privileged access management software and hardware, including authentication and access control readers such as biometric readers; standalone and embedded browsers; password managers; anti-malware software; products with a VPN function; network management systems; SIEM systems; boot managers; PKI and digital certificate issuance software; physical and virtual network interfaces; operating systems; routers, modems for internet connection, and switches; microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities; smart home general purpose virtual assistants; smart home products with security functionalities such as smart locks, cameras, baby monitors and alarms; internet-connected toys within the Toy Safety Directive that have social interaction or location tracking features; and personal wearables with a health monitoring purpose that are not medical devices, or wearables intended for children.

Class II: hypervisors and container runtime systems that support virtualised execution of operating systems and similar environments; firewalls, intrusion detection and prevention systems; tamper-resistant microprocessors; tamper-resistant microcontrollers.

A pointed note for our own audience. Container runtimes and hypervisors are Class II: mandatory third-party assessment for whoever manufactures them. Operating systems and network management systems are Class I. Firewalls and intrusion detection systems are Class II, and whether a Kubernetes network policy engine that inspects application traffic falls under that heading is a question the Commission guidance has not answered yet. A lot of the cloud-native stack lands in "important product" territory for whoever places it on the market commercially, and the harmonised standards that would let a Class I product self-assess are still being written.

Annex IV: Critical products with digital elements

Applies to: manufacturers of three narrow hardware categories.

Hardware devices with security boxes; smart meter gateways within smart metering systems and other devices for advanced security purposes including secure cryptoprocessing; and smartcards or similar devices, including secure elements. If you write software, this annex is not about you.

Annex V: EU declaration of conformity

Applies to: manufacturers.

The template: product identification; manufacturer name and address; a statement that it is issued under the manufacturer's sole responsibility; the object of the declaration; a statement of conformity; the standards, specifications or schemes used; the notified body and certificate where one was involved; place, date, name, function and signature.

Annex VI: Simplified EU declaration of conformity

Applies to: manufacturers.

Two lines: a statement that the named manufacturer declares the named product type is in compliance with Regulation (EU) 2024/2847, then "The full text of the EU declaration of conformity is available at the following internet address:" followed by the URL.

Annex VII: Technical documentation

Applies to: manufacturers, through Article 31.

The file a market surveillance authority will ask for: a general description of the product, its intended purpose and the software versions that affect Annex I compliance; design, development and production, including architecture and the vulnerability handling process with the SBOM, CVD policy, reporting contact and update mechanism; the Article 13 risk assessment; the information used to set the support period; the standards or schemes applied, or how the requirements were met without them; test reports for Annex I Parts I and II; and a copy of the DoC.

Annex VIII: Conformity assessment procedures

Applies to: manufacturers, through Article 32.

Module	Who does the work	What happens	When it is allowed
A: Internal control	Manufacturer alone	Verifies Annex I, draws up technical documentation, signs the DoC, affixes CE marking.	Default products; Class I when harmonised standards or a scheme are fully applied; open-source manufacturers in Annex III with public technical documentation
B: EU-type examination	Notified body	Examines the technical design and vulnerability handling, issues an EU-type examination certificate, re-audits periodically.	Class I when A is unavailable, Class II, Critical until a scheme is mandated. Always paired with C.
C: Conformity to type	Manufacturer	Ensures production matches the type certified under B, issues the DoC, affixes CE marking.	Together with B
H: Full quality assurance	Notified body	Approves the whole quality system across design, development, production and vulnerability handling, with surveillance audits through the support period. CE marking carries the body's number.	Any product; common for multi-product companies

Questions we get asked

Does the CRA apply to open source?

Not by default, and not never. Open-source software supplied outside a commercial activity is not made available on the market and is out of scope. Open-source software a company commercially places on the market makes that company a manufacturer with full Article 13 obligations. In between sits the Article 24 steward role: four light obligations, no fines.

Does it apply to SaaS or managed services?

Pure SaaS is not a product with digital elements; NIS2 covers that ground. Two catches. Remote data processing that a product needs in order to function is part of that product. And software you hand a customer to run themselves is a product however you bill it, while software you deploy and operate yourself inside their environment as part of a service is not. Three questions settle it: can the customer install or remove it on their own, do they control its updates, and do they keep it when the contract ends? Three noes means it is a service, not a product.

What are the fines?

Up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher, for breaching Annex I or Articles 13 and 14. Up to EUR 10 million or 2 percent for most other obligations. Up to EUR 5 million or 1 percent for giving authorities incorrect or misleading information. Open-source software stewards cannot be fined for any infringement.

When does it apply?

Article 14 reporting from 11 September 2026. Everything else from 11 December 2027. Chapter IV, on notified bodies, has applied since 11 June 2026, but that is for authorities.

Do products already on the market need to comply?

For Annex I, CE marking and documentation, only if substantially modified after 11 December 2027. For Article 14 reporting, yes: Article 69(3) applies it to every in-scope product regardless of when it was placed on the market. Old products are grandfathered out of the paperwork, not out of the 24-hour early warning.

Need help getting compliant?

If you want to know more about the CRA, or about any other compliance requirement your organisation is facing, and how you can meet it using open-source software, we would be glad to talk it through. Book a consultation with us.