CRA Compliance for AI Products and Connected Software
The CRA applies to your AI product if it connects, communicates, or processes data. Most software teams haven’t checked.
Cyber Resilience Act — obligations from 2026
The Cyber Resilience Act entered into force on 10 December 2024. It applies to every product with digital elements placed on the EU market — hardware and software that connects to another device or network, directly or indirectly. Most AI products qualify. Obligations phase in from September 2026, with full enforcement from December 2027.
The CRA’s central demand is security by design — not security as an afterthought, not security as a policy, but security built into the product from the earliest stage of development and maintained throughout its lifecycle. For AI systems this creates specific obligations around vulnerability handling, incident reporting, technical documentation, and conformity assessment that sit alongside and frequently interact with EU AI Act and GDPR requirements.
European Compliance Suite provides specialist CRA compliance assessments for AI products and connected software. We determine whether your product is in scope, establish your classification tier, map your security obligations against the Act’s requirements, and deliver a documented compliance record specific to your product — mapped against your EU AI Act and GDPR position where both apply.
CRA Compliance Assessment for Your AI System
A lawyer-built assessment of your AI system’s CRA obligations — product classification, security-by-design requirements, vulnerability handling duties, incident reporting obligations, conformity assessment pathway, and a documented compliance record your EU customers, enterprise buyers, and regulators can rely on.
How DORA works for AI products
Three tiers. One security standard. Direct obligations for every AI product on the EU market.
The CRA classifies products with digital elements into three tiers. The tier determines your conformity assessment pathway — but the essential cybersecurity requirements apply to every product in scope.
Default category
The majority of products with digital elements — including most AI software products. Manufacturers self-assess against the essential cybersecurity requirements and issue an EU declaration of conformity. No notified body involvement required, but the underlying security engineering and documentation must meet the standard.
Important category — Class I
Products that present higher cybersecurity risk due to their function or connectivity — identity management software, password managers, VPNs, network monitoring tools, and others listed in Annex III. Class I products can self-assess against a harmonised standard or — where no harmonised standard covers the product — must use a notified body or EU cybersecurity certification scheme.
Important category — Class II
Products presenting the highest cybersecurity risk — operating systems, industrial control systems, hypervisors, public key infrastructure, and others listed in Annex III. Class II products require third-party conformity assessment by a notified body or EU cybersecurity certification scheme. Self-assessment is not available.
Critical infrastructure AI
AI systems embedded in or connected to critical infrastructure — energy, transport, water, financial market infrastructure — face the most demanding security obligations and are likely to intersect with NIS2 requirements alongside the CRA.
Who CRA applies to
The CRA reaches every AI product placed on the EU market — including from outside the EU. The Act applies based on where the product is placed on the market, not where the manufacturer is established. The extraterritorial logic mirrors the EU AI Act and GDPR.
| Entity type | In scope of CRA? | Key obligation |
|---|---|---|
| EU-based AI software manufacturer | Yes — directly | Full CRA compliance including security-by-design, vulnerability handling, incident reporting, conformity assessment |
| Non-EU AI company with EU users or customers | Yes — extraterritorial | Same obligations as EU manufacturer — plus importer/distributor obligations for the supply chain |
| UK AI company post-Brexit | Yes — treated as non-EU manufacturer | Full CRA obligations where product reaches EU market |
| US AI company with EU SaaS users | Yes | Full CRA obligations as non-EU manufacturer |
| Open source AI software (commercial activity) | Yes — where supplied in the course of commercial activity | Essential cybersecurity requirements and vulnerability disclosure |
| Open source AI software (non-commercial) | No — specific exemption | No mandatory obligations but vulnerability disclosure encouraged |
| AI embedded in a regulated product (medical device, machinery) | Yes — CRA applies alongside sector regulation | CRA obligations plus sector-specific security requirements |
| Manufacturer placing AI product on EU market free of charge | Yes — free supply counts as placing on market | Full CRA obligations |
| Distributor or importer of AI products | Yes — due diligence obligations | Verification that manufacturer has complied, own obligations where non-compliance identified |
Security by design: the CRA’s central demand
The CRA’s essential cybersecurity requirements are not a checklist to complete before shipping. They are engineering obligations that apply from the earliest stage of product development and continue throughout the product’s lifecycle — including after it reaches the customer.
Three things AI product teams consistently misunderstand:
- Security by design means the product must be designed to minimise attack surface, operate with minimal privileges, protect against known vulnerability categories, and provide security updates for the duration of its support period — defined at the time of placing on the market. A product shipped without a defined support period is non-compliant before its first EU customer installs it.
- Vulnerability handling is an ongoing obligation, not a one-time exercise. Manufacturers must have a documented policy for handling vulnerabilities reported by third parties, must address them without undue delay, must publish security advisories, and must report actively exploited vulnerabilities to ENISA and the relevant national authority within 24 hours of discovery.
- The CRA’s incident reporting timeline — 24 hours for early warning, 72 hours for notification — is shorter than most organisations’ existing incident response procedures. AI products that experience security incidents affecting EU users must be able to meet these timelines. Most cannot on their current processes.
What CRA compliance requires for AI products
These are the CRA requirements that apply most directly to AI software products placed on the EU market — distinct from the general IT security practices your existing programme may already cover.
CE marking — CRA-compliant products must carry CE marking before being placed on the EU market, confirming that the essential cybersecurity requirements have been met and the conformity assessment completed
Product scope determination — confirmation that your AI product qualifies as a product with digital elements under the CRA, which products in your portfolio are in scope, and which — if any — benefit from the open source or other exemptions
Classification tier assessment — determination of whether your product falls into the default category, Class I important, or Class II important category under Annex III — the classification that determines your conformity assessment pathway and the level of third-party involvement required
Essential cybersecurity requirements mapping — assessment of your product against the CRA’s Annex I essential requirements: no known exploitable vulnerabilities at delivery, secure default configuration, access control, encryption, minimal data collection, integrity protection, and security update capability
Vulnerability handling programme — documented policy and process for receiving, assessing, and addressing reported vulnerabilities — including a coordinated vulnerability disclosure policy, a public point of contact, and a documented timeline for addressing reported issues
Security update obligations — defined support period communicated to users, documented process for delivering security updates separately from functionality updates, and assessment of whether automatic update mechanisms are required
Incident reporting readiness — process for identifying actively exploited vulnerabilities and security incidents affecting EU users, and the internal capability to meet DORA’s 24-hour early warning and 72-hour notification timelines to ENISA and national authorities
Technical documentation — CRA-compliant technical file covering product design, security architecture, threat model, vulnerability assessment, testing results, and the conformity assessment pathway followed — maintained and updated throughout the product lifecycle
Conformity assessment pathway — determination of the correct conformity assessment route for your product tier — self-assessment against harmonised standard, notified body assessment, or EU cybersecurity certification scheme — and execution of that assessment before placing the product on the EU market
EU declaration of conformity — a written declaration that your product satisfies the CRA’s essential cybersecurity requirements — a legal act that must be supported by the underlying technical documentation and conformity assessment.
One engagement. Every CRA obligation mapped for your AI system.
A lawyer-built CRA assessment covering product scope determination, classification tier, essential cybersecurity requirements mapping, vulnerability handling obligations, incident reporting readiness, conformity assessment pathway, technical documentation requirements, and CE marking — documented and specific to your product, mapped against your EU AI Act and GDPR position where both apply.
Frequently Asked Questions About CRA Compliance
What is the Cyber Resilience Act and who does it apply to?
The Cyber Resilience Act is an EU regulation requiring manufacturers of products with digital elements to meet essential cybersecurity requirements before placing those products on the EU market. It applies to hardware and software products that connect to another device or network — directly or indirectly. Most AI software products qualify. It entered into force in December 2024, with obligations phasing in from September 2026 and full enforcement from December 2027.
Does the CRA apply to AI products specifically?
Yes, where the AI product connects to another device or network — which most commercial AI systems do. AI software delivered as SaaS, via API, or as an embedded component in a larger system is a product with digital elements within the meaning of the CRA. The CRA applies to the AI product alongside any EU AI Act obligations — a high-risk AI system used in a financial institution may be subject to all three of the EU AI Act, CRA, and DORA simultaneously.
What are the CRA’s essential cybersecurity requirements for AI products?
The essential requirements in Annex I cover: delivery without known exploitable vulnerabilities, secure default configuration, access control and identity management, protection of data in transit and at rest, minimal data collection, integrity and availability protection, a defined and communicated support period, security update capability, and vulnerability disclosure.
These are engineering requirements — they must be built into the product, not added as a policy document.
What is the difference between CRA product tiers — default, Class I, and Class II?
The default category covers most products with digital elements — self-assessment against the essential requirements is sufficient. Class I important products present higher cybersecurity risk and must either self-assess against a harmonised standard or use a notified body where no harmonised standard applies. Class II important products present the highest risk and require mandatory third-party conformity assessment — self-assessment is not available. Classification determines your conformity assessment pathway and the level of regulatory scrutiny your product faces.
Does the CRA apply to open source AI software?
Partially. Open source software supplied in the course of commercial activity — where the manufacturer derives commercial benefit — is in scope. Genuinely non-commercial open source software benefits from a specific exemption. The boundary between commercial and non-commercial open source is not always clear, particularly for AI models released under permissive licences but supported by commercial entities. A product scope determination establishes where your specific software sits.
What are the CRA’s vulnerability reporting timelines?
Manufacturers must report actively exploited vulnerabilities to ENISA and the relevant national computer security incident response team within 24 hours of discovery — an early warning. A more complete vulnerability notification follows within 72 hours. A final report is required within 14 days. These timelines are shorter than most existing incident response procedures and require dedicated internal processes to meet reliably.
How does the CRA interact with the EU AI Act for AI products?
The CRA governs the security of the product — vulnerability handling, secure design, incident reporting. The EU AI Act governs the AI system’s risk classification, technical documentation, transparency, and human oversight. They overlap significantly in technical robustness and post-market monitoring — both require ongoing security assessment and incident response. A cross-framework assessment identifies where one piece of evidence satisfies both regimes and where distinct obligations apply.
Does the CRA apply to non-EU AI companies?
Yes. The CRA applies extraterritorially — non-EU manufacturers placing products with digital elements on the EU market face the same obligations as EU-established manufacturers. UK companies post-Brexit, US companies, Swiss companies, and Indian AI exporters with EU users are all subject to CRA requirements on the same terms. Importers and distributors of non-compliant products face their own CRA obligations where the manufacturer has not met the essential requirements.
A cross-framework assessment maps where compliance with one regime contributes to compliance with the other, and where they impose distinct and non-overlapping obligations.
What is CE marking under the CRA?
CE marking under the CRA is a declaration that the product satisfies the essential cybersecurity requirements and has undergone the appropriate conformity assessment. It must appear on the product — or its packaging or documentation where the product is software — before it is placed on the EU market. Affixing CE marking without the underlying conformity assessment and technical documentation is a serious violation carrying significant penalties.
What are the penalties for CRA non-compliance?
Non-compliance with the essential cybersecurity requirements carries fines of up to €15 million or 2.5% of global annual turnover. Non-compliance with other CRA obligations — including vulnerability reporting and documentation requirements — carries fines of up to €10 million or 2% of global annual turnover. Providing incorrect or misleading information to market surveillance authorities carries fines of up to €5 million or 1% of global annual turnover. Market surveillance authorities can also require product withdrawal from the market where safety risks are identified.
How do I start CRA compliance for my AI product?
Four steps in order. First, determine whether your product qualifies as a product with digital elements and whether any exemption applies. Second, establish your classification tier — default, Class I, or Class II — which determines your conformity assessment pathway. Third, assess your product against the essential cybersecurity requirements in Annex I and identify the gaps. Fourth, establish your vulnerability handling policy and incident reporting process before obligations apply. A lawyer-built assessment covers all four steps and delivers a documented compliance position specific to your product — mapped against your EU AI Act and GDPR position where both apply.