Should you pursue the EU AI Act, the Cyber Resilience Act, or both?
If you make an AI-enabled product with digital elements that is also a high-risk AI system, the Cyber Resilience Act can satisfy the AI Act's cybersecurity requirement, so most such makers pursue both laws with one cybersecurity evidence set. Under Article 12(1) of the CRA, a high-risk AI system that is a product with digital elements is deemed to meet AI Act Article 15 cybersecurity where it meets CRA Annex I Parts I and II and its EU declaration of conformity shows the required level of protection. Article 42(3) of the AI Act, added in 2026, gives the same deemed compliance for systems that fall under the CRA and meet the conditions of its Article 12(1).
The laws apply on their own in two common cases. AI-only software that is not a product with digital elements falls under the AI Act alone, so its Article 15 work must be built directly, with no CRA route. A product with digital elements that is not a high-risk AI system falls under the CRA alone, and the AI Act does not add obligations to it. Both laws apply when the product is a CRA product and the AI system inside it is high-risk, and then Article 12(2) and 12(3) decide which conformity procedure governs. Confirm the product's CRA class and its Annex III or Annex I AI Act category with your notified body and your legal counsel before you plan the file. The CRA matters more to a hardware or embedded maker whose main exposure is the Annex I vulnerability handling duties, while the AI Act matters more to a software provider whose exposure sits in the AI-specific obligations.
Doing both is required when the product is a high-risk AI system and a CRA product, because the AI Act will not accept the CRA route without the CRA conformity steps being completed. Teams should check the timeline first: the CRA reporting obligations under Article 14 applied from 11 September 2026, the main CRA obligations apply from 11 December 2027, and the AI Act high-risk rules for Annex I product systems apply from 2 August 2028 under the 2026 amendment. Ask your notified body whether it can assess CRA Annex I under AI Act Article 43 and whether Article 52(14) puts market surveillance with your AI Act authority. Regulatory sandboxes under Article 57 are open to these manufacturers under Article 12(4), so ask whether a sandbox fits your roadmap before you finalize the evidence set.
How the AI Act and the CRA compare on scope, obligations and fines
This table compares the EU AI Act and the Cyber Resilience Act on legal form, scope, cybersecurity requirements, conformity procedure, supervision, sandboxes, fines and application dates. Read each row as a question to answer for your product, since a single AI-enabled device can fall under both regulations at once. The main takeaway is that the two laws use different fine scales and different application dates, so your plan should track both.
| Dimension | EU AI Act (Regulation (EU) 2024/1689) | Cyber Resilience Act (Regulation (EU) 2024/2847) |
|---|---|---|
| Legal form | EU regulation, binding in all member states | EU regulation, binding in all member states |
| Who it applies to | Providers and deployers placing AI systems on the EU market or using their output in the EU, wherever established (Article 2) | Manufacturers of products with digital elements placed on the EU market, including software and devices |
| What it regulates | AI systems by risk level, with high-risk rules for systems in Annex III and Annex I product systems | Cybersecurity of products with digital elements through essential requirements and vulnerability handling |
| Cybersecurity requirements | Article 15 accuracy, robustness and cybersecurity; high-risk products meeting CRA Annex I Parts I and II may be deemed compliant (Article 12(1), 42(3)) | Annex I Part I product properties and Part II vulnerability handling requirements for manufacturers |
| Conformity procedure | Mostly internal control under Annex VI; notified bodies for some biometric systems and Annex I products (Article 43). CRA products that are high-risk AI systems follow Article 43 (Article 12(2)) | Mostly self-assessment under module A; notified body needed for class I important products not fully covered by standards, and for class II and critical products (Article 32) |
| Supervising authority | National market surveillance authorities for AI systems; the Commission's AI Office for general-purpose AI model rules and specified AI systems (Article 75(1), 88) | CRA products that are high-risk AI systems are supervised by AI Act authorities (Article 52(14)); otherwise CRA market surveillance authorities apply. Confirm the designated authority in your member state |
| Sandboxes | Manufacturers of these products may take part in AI regulatory sandboxes under Article 57 (Article 12(4)) | No sandbox provision for CRA products is included in the supplied facts; confirm with your national authority |
| Fines | Up to EUR 35 million or 7% for prohibited practices; EUR 15 million or 3% for most operator obligations; EUR 7.5 million or 1% for misleading information (Article 99) | Up to EUR 15 million or 2.5% for Annex I and Articles 13 and 14 breaches; EUR 10 million or 2% for other listed obligations; EUR 5 million or 1% for misleading information (Article 64) |
| Application dates | Chapters I and II from 2 February 2025; general-purpose AI, governance and penalties from 2 August 2025; high-risk rules for Annex III from 2 December 2027 and Annex I product systems from 2 August 2028, as amended in 2026 (Regulation (EU) 2026/1744) | Chapter IV from 11 June 2026; Article 14 reporting from 11 September 2026; the regulation generally from 11 December 2027 (Article 71(2)) |
How the CRA can satisfy AI Act Article 15 for high-risk AI products
A high-risk AI system that is also a product with digital elements can meet the AI Act's cybersecurity requirements through the Cyber Resilience Act. Under Article 12(1) of the CRA, such a product is deemed to meet Article 15 of the AI Act where it satisfies Parts I and II of Annex I to the CRA and its EU declaration of conformity shows the required level of protection. Article 42(3) of the AI Act, added in 2026, gives high-risk systems that fall under the CRA the same deeming effect, provided they meet the conditions of CRA Article 12(1). The practical result is that one body of cybersecurity evidence can support both regulations, as long as the product actually meets those conditions.
The deeming is limited to the cybersecurity requirements in Article 15, which also sets accuracy requirements. It does not cover the rest of the high-risk obligations, including the risk management system, data governance, technical documentation, record keeping, human oversight and quality management. Those still need their own evidence in the AI Act file. Accuracy metrics and test results also need separate support. Teams should build a requirement-by-requirement map that shows which AI Act obligations the CRA technical file can support and which must be documented from scratch.
Before relying on the deeming, confirm three things: that the product is a high-risk AI system under the AI Act, that it falls within a CRA product category, and that every condition of CRA Article 12(1) is met. Check that the EU declaration of conformity states the cybersecurity level it demonstrates, because the deeming depends on that statement. Ask your notified body or conformity assessment provider which procedure applies to your product and whether it will assess both regulations together. Finally, have counsel confirm how the 2026 amendments and the placing-on-market dates affect your product's timeline.
Which conformity procedure applies to my product
Some AI systems that are also products with digital elements reach the AI Act through internal control, the Annex VI route in which the provider assesses its own conformity. Article 12(2) applies the AI Act Article 43 procedure to these products, and Article 12(3) connects internal control to the CRA procedures for the essential cybersecurity requirements where the product is important or critical.
- Most high-risk AI systems: Most Annex III high-risk systems use Annex VI internal control, so the provider prepares the technical documentation and the EU declaration of conformity itself.
- Default CRA products: Most CRA products follow module A self-assessment, in which the manufacturer declares conformity with Annex I. This applies to AI-enabled products outside the important and critical classes.
- Article 12(3) overlap: An important or critical product that is also a high-risk AI system under internal control follows the CRA procedures for the essential cybersecurity requirements, so the CRA route governs that part of the evidence.
- One evidence file: Keep the EU declaration, the cybersecurity risk assessment and the vulnerability handling records in one controlled file so both regulations can reference the same documents.
Check with your conformity lead whether the system appears in Annex III and whether the Article 12(1) conditions are met before you commit to this route.
Important and critical products carry the strictest CRA procedures. Annex III lists 19 categories in class I and 4 in class II, and Annex IV lists 3 categories of critical products. When one of these products is also a high-risk AI system, Article 12(3) brings its essential cybersecurity assessment under the CRA procedures.
- Class I products: A notified body is needed where harmonized standards, common specifications or certification schemes are not applied in full. Applying every relevant harmonized standard may keep you on the self-assessment route.
- Class II products: Article 32 requires a notified body for class II products, so plan for third-party assessment from the start.
- Critical products: Critical products listed in Annex IV also require a notified body under Article 32.
- Shared assessment body: Where the AI Act route runs through a notified body, ask whether that body will also assess CRA Annex I, so one body's work can cover both regulations.
Confirm the class and category against Annex III or Annex IV and Commission Implementing Regulation (EU) 2025/2392, and ask each notified body for its CRA scope in writing.
AI Act notified bodies may also assess conformity with CRA Annex I, but only when their compliance with CRA Article 39 was assessed during their notification. Chapter IV of the CRA, which covers the notification of conformity assessment bodies in Articles 35 to 51, applies from 11 June 2026, so the date of a body's notification matters when you select one.
- Scope check: Confirm that the body's notification covers CRA Article 39, not only the AI Act procedure.
- Combined review: A single body may review both sets of requirements, which can reduce duplicate scheduling and repeated information requests.
- Notification date: Ask for the date and scope of the body's notification in writing, and check it against the Commission's current published status.
- Market surveillance: Article 52(14) assigns market surveillance of CRA products that are high-risk AI systems to the authorities designated under the AI Act, so one authority may act on both.
Request the body's notification scope and confirmation that CRA Article 39 was assessed before you sign a contract, because a body without that scope cannot cover the CRA part of your product.
The product class decides the route, so map the product to the lists before planning evidence work. Commission Implementing Regulation (EU) 2025/2392, adopted on 28 November 2025, gives the technical description of each category, as Article 7(4) of the CRA requires. The headline lists alone do not settle the question.
- Map the AI use: Identify whether the system is listed in Annex III of the AI Act or falls under the product legislation in Annex I, because that determines the AI Act route.
- Map the CRA class: Compare the product with the 19 class I and 4 class II categories in Annex III of the CRA and the 3 critical categories in Annex IV.
- Read the technical descriptions: Use Implementing Regulation (EU) 2025/2392 to match the product to the detailed description of its category, which sets out the detail behind each category.
- Record the decision: Keep a dated classification memo with the reasoning, so auditors and market surveillance authorities can follow how you reached the route.
Have counsel and your conformity lead confirm the classification in writing, because the conformity route follows directly from it.
Who assesses the product and what proof each law produces
This table compares who checks a product under each law, what document or proof results, and when the obligation runs. Read it as a sequence: most CRA products self-assess, most Annex III AI systems use internal control, and notified bodies appear only in specific cases. Neither law issues a certificate that DeployOpen or the manufacturer can simply obtain.
| Regime and point | Who assesses or supervises | Proof produced and timing |
|---|---|---|
| AI Act internal control (Annex VI) | The provider, through internal control, for most Annex III high-risk systems | EU declaration of conformity and technical documentation; applies from 2 December 2027 for Annex III systems as amended in 2026 |
| AI Act notified body route | An AI Act notified body, for some biometric systems and Annex I products (Article 43) | Notified body assessment outcome plus EU declaration of conformity; confirm the specific route with the notified body |
| CRA module A self-assessment | The manufacturer, for most products with digital elements under the CRA | EU declaration of conformity and CE marking; applies from 11 December 2027 |
| CRA notified body route | A notified body, for class I important products not fully applying harmonised standards, and for class II and critical products (Article 32) | Notified body conformity assessment plus EU declaration of conformity; confirm the module with the notified body |
| AI Act Article 12(2) and 12(3) overlap | AI Act notified bodies may assess CRA Annex I if they were assessed under CRA Article 39; internal-control products follow CRA procedures | Single assessment path where one body covers both regulations; check notification scope before relying on it |
| Market surveillance of CRA-covered AI | National authorities designated under the AI Act (Article 52(14)) | Surveillance supervision rather than a certificate; the AI Act authority responds to non-conformity |
| CRA Single Reporting Platform | CSIRT designated as coordinator receives notifications; ENISA receives them at the same time | Vulnerability and incident notifications from 11 September 2026 under Article 14; ENISA launched the platform on that date |
| Certificates available to DeployOpen | Neither law issues a certificate for DeployOpen to obtain; the only third-party assessors named in the facts are notified bodies | DeployOpen prepares evidence and documentation; it does not issue declarations or conformity assessments |
Where the cybersecurity work overlaps and where it does not
The CRA and the AI Act share a cybersecurity baseline, and Article 12 of the AI Act lets a product that meets the CRA essential requirements count toward Article 15. The cards below separate the CRA obligations that carry over from the AI-specific items that still need separate evidence, and they flag where the mapping must be confirmed with the Commission guidance or a notified body.
Vulnerability handling and support periods
Annex I Part II sets eight vulnerability handling requirements for manufacturers, and these run for the product's support period. Check that your intake, triage, patch and disclosure processes cover the AI model, its runtime components and its updates, not only the application code. Confirm with the Commission guidance on support periods how long you must keep the product supported and whether model updates count as substantial modifications.
Essential requirements in Annex I Part I
Part I sets product properties, including a general requirement and points (2)(a) to (m), such as secure configuration defaults, access control, data protection and resilience. These are the controls most likely to satisfy Article 15 cybersecurity for an AI system that runs on the same hardware or software stack. Map each Part I point to a specific control in your design file and confirm the mapping with your notified body where one is needed.
Secure-by-default and risk assessment
The CRA expects a documented cybersecurity risk assessment for each product and secure default settings at delivery. For an AI-enabled product, the risk assessment must also consider threats to the model, such as prompt injection, data poisoning and unauthorized model access, which the CRA does not name. Treat the CRA assessment as the base and extend it with AI threat scenarios, then confirm with the Commission guidance on risk assessment how far the shared assessment can be reused.
Documentation and the EU declaration
The CRA requires technical documentation and an EU declaration of conformity for the product. Under Article 12(1) of the AI Act, that declaration must demonstrate the required level of protection for the AI system to be deemed compliant with Article 15. Keep one technical file that cross-references both regulations, and ask your notified body whether it will accept a single declaration that covers both requirements.
AI-specific Article 15 items
Article 15 also requires accuracy, robustness of model behavior and data governance, and the CRA does not cover these. Accuracy metrics, performance under distribution shift, and training and validation data controls need their own evidence, such as test records and dataset documentation. Expect to produce this evidence separately, since Article 12 only deems the cybersecurity elements of Article 15 met.
AI Act quality management system
The AI Act requires a quality management system for high-risk providers, covering areas such as design controls, post-market monitoring and incident handling. The CRA does not require a quality management system in this form, so the AI Act QMS is the place to record model lifecycle processes that fall outside the CRA. Confirm with the harmonised standard work, including EN 18286:2026 cited in the Official Journal on 14 October 2026, how the QMS and the CRA processes should be linked.
Sandboxes, market surveillance and who supervises the product
A product that is both a CRA product and a high-risk AI system will be watched by AI Act authorities for market surveillance, and its manufacturer can apply to join an AI regulatory sandbox. Article 52(14) of the Cyber Resilience Act assigns market surveillance of CRA products that are high-risk AI systems to the authorities designated under the AI Act, so the national body that checks the AI system is also the body that checks its cybersecurity conformity. Article 12(4) allows these manufacturers to take part in AI regulatory sandboxes under Article 57 of the AI Act. Confirm with your counsel whether a sandbox application is worth the effort for your product and timeline, and whether your sandbox plan will cover the CRA evidence as well as the AI evidence.
The AI Office holds exclusive competence in a narrower set of cases. Under Article 75(1) of the AI Act as amended in 2026, it is exclusively competent for AI systems built on a provider's own general-purpose model and for AI in very large online platforms and search engines. A device maker using a third-party model, or embedded AI in an industrial product, should expect national market surveillance authorities to handle its case. Confirm whether your product falls into either exclusive category before you assume the AI Office is involved.
Reporting duties under the CRA follow a different path. Manufacturer notifications on actively exploited vulnerabilities and severe incidents go to the CSIRT designated as coordinator, and ENISA receives them at the same time through the CRA Single Reporting Platform. Your incident response runbook should name the designated CSIRT for your member state and map who on your team can file. Confirm which national authority your member state has designated for AI Act market surveillance, since that name determines who receives your technical documentation and who you call during an inquiry.
Which timeline to plan around first
This sequence turns the overlapping EU dates into one evidence set, so the team builds the shared records once and reuses them for both the CRA and the AI Act as each deadline arrives.
Confirm which products and notified bodies are in scope
Start by mapping each product to its CRA class and to its AI Act category, and check whether it is a high-risk AI system that is also a product with digital elements. The product owner and regulatory lead should record the answer for each product in one scope register. Notified body rules under Chapter IV of the CRA have applied since 11 June 2026, so if a product needs a notified body, confirm that the body is accredited for the relevant assessment before you commit to a route. The output is a signed scope register that names the conformity procedure each product will follow.
Stand up CRA reporting before 11 September 2026
The Article 14 reporting obligations under the CRA apply from 11 September 2026 and reach products already on the market, so this is the first hard obligation for manufacturers. The product security team should define who files early warning and follow-up notifications, how they are triaged, and which CSIRT is the coordinator for the manufacturer's market. ENISA's Single Reporting Platform began its initial operating capability on the same day. The check that closes this step is a tested notification runbook with named roles and a dry run recorded in the evidence file.
Build one vulnerability handling process and SBOM record
Create a single vulnerability handling process that covers the eight Part II requirements in Annex I of the CRA, and use the same process for AI-specific vulnerabilities in the system. Produce one software bill of materials and one support-period record per product, so the cybersecurity evidence used for the AI Act Article 15 claim is the same evidence used for the CRA. Engineering and security should own the process, and the output is a versioned procedure plus an SBOM that is refreshed with each release.
Assemble one technical file for both declarations
Write a single technical file that covers the design, risk assessment, test results and cybersecurity evidence for the product, and cross-reference it from both the CRA EU declaration of conformity and the AI Act declaration. Legal, product and compliance teams should agree the structure before drafting, so each section answers an Annex I requirement and the matching AI Act obligation. The check is a reviewer who can trace each Article 15 claim to a test, a control and a declaration paragraph without opening a second file.
Use sandboxes and supervisory contacts early
Article 12(4) of the AI Act allows manufacturers of these products to take part in AI regulatory sandboxes under Article 57, so decide whether to apply during design rather than after the file is closed. Confirm with the market surveillance authority designated under the AI Act, which Article 52(14) names for CRA products that are high-risk AI systems, who the contact point is for each market. The output is a short record of the authority contacts and any sandbox application, kept alongside the technical file.
Plan the high-risk product date of 2 August 2028
After the 2026 amendment, the high-risk rules for Annex I product systems apply from 2 August 2028, so the AI Act obligations for these products have a later start than the CRA reporting duty. Use the interval to finish the conformity assessment route, the quality management system and the post-market monitoring plan. The check is a dated plan that shows which AI Act artifacts exist before that date and which harmonised standards each one depends on, with the status of those standards confirmed against the Official Journal.
Apply the CRA main obligations from 11 December 2027
The main CRA application date is 11 December 2027, and products placed on the market before that date fall under the regulation only if they are substantially modified from then on, under Article 69(2) and (3). Product owners should decide, product by product, whether a planned change counts as a substantial modification, and record the reasoning in the scope register. The output is a substantial modification review gate in the release process, so each new version is checked against the CRA before it ships.
Keep the shared evidence current after each release
After both dates have passed, the single vulnerability process, SBOM, support-period record and technical file must stay in step with each release, or the two declarations drift apart. Assign one owner for the evidence set, and review it at every release and at every support period change. The check is that the declarations, the SBOM and the support record all show the same version and the same end-of-support date for each product.
What buyers ask before they hire help with both laws
Does a CRA declaration of conformity satisfy the AI Act on its own?
Only partly, and only for the cybersecurity part. Under Article 12(1) of the CRA, a high-risk AI system that is also a product with digital elements is deemed to meet the AI Act Article 15 cybersecurity requirements, but only where it meets Annex I Parts I and II of the CRA and the EU declaration of conformity demonstrates the required level of protection. Article 42(3) of the AI Act, added in 2026, gives the same deemed compliance. The rest of the AI Act still applies, including risk management, data governance, technical documentation, logging, human oversight and accuracy obligations. Confirm with counsel which of those obligations your system triggers before relying on the CRA route.
What drives the effort and cost of meeting both laws?
Scope drives most of it. The main variables are the number of product variants, whether the product falls in CRA class I or class II or the critical category, whether a notified body must be involved, and how much secure development evidence already exists. Products that use harmonised standards in full usually need less outside assessment than products that depart from them. Cost comes from engineering time, documentation, testing and any notified body or certification fees. Fees for DeployOpen come only from a written scope, so ask for a quote that lists deliverables, product classes assumed, and which items are one-time and which recur.
What does the work need from our own team?
It needs engineering, product, legal and a named owner, and the owner has to be able to make decisions. Engineering supplies architecture, build pipelines, update mechanisms and vulnerability handling evidence. Product defines the intended purpose, variants and support periods. Legal interprets which AI Act and CRA obligations apply and signs off on the declaration. A single accountable owner keeps the evidence, the technical file and the timelines in one place. DeployOpen can plan, implement and document controls, but the manufacturer keeps responsibility for the declaration and for the product.
Can we run the CRA and AI Act work ourselves without outside help?
Yes, if you have people who know both regulations and can produce the evidence the regulations require. Most products follow self-assessment under module A of the CRA, so an in-house team can run the process without a third party. The hard parts are keeping the technical documentation current across releases, running vulnerability handling under Annex I Part II, and tracking harmonised standards that are still being published. Ask your team to map the work against the Commission guidance and the Annex I requirements before deciding whether to bring in outside help.
When do the CRA and AI Act dates affect our plan?
Plan against several dates. Under Article 113 of the AI Act, as amended in 2026, the high-risk rules for Annex I product systems apply from 2 August 2028, and Annex III systems apply from 2 December 2027. Under Article 71(2) of the CRA, the regulation applies from 11 December 2027, while the Article 14 reporting obligations applied from 11 September 2026 and the notified body chapter from 11 June 2026. Products already on the market before 11 December 2027 fall under the CRA only if substantially modified, but the reporting obligations still reach them. Confirm your own product's dates with counsel.
Do we need a notified body for conformity assessment?
Not always. Under Article 32 of the CRA, most products use self-assessment under module A. A notified body is needed for class I important products where harmonised standards, common specifications or certification schemes are not applied in full, and for class II and critical products. Under Article 12(2) of the AI Act, notified bodies may also assess CRA Annex I conformity if their CRA Article 39 compliance was assessed during notification. Check your product's class in Commission Implementing Regulation (EU) 2025/2392 and ask the notified body you are considering which assessments it covers.
What does DeployOpen not do for us under these laws?
DeployOpen does not certify products, issue audit reports, or sign a declaration of conformity on your behalf. Independent notified bodies and authorities perform assessments and issue any certificates, and the manufacturer signs the EU declaration. DeployOpen can plan the work, implement secure development and vulnerability handling controls in your environment, prepare technical documentation, run security testing, and assemble evidence for the assessment. Your team stays accountable for the product, and we will say so in writing in the scope before work starts.
How DeployOpen scopes and delivers readiness for both laws
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so readiness work for an AI-enabled product can sit next to the platform it runs on. We start from the written scope, then prepare the technical controls and evidence that the cybersecurity and conformity questions in both regulations depend on.
How we scope
- Confirm which product classes, Annex I parts and AI Act risk category apply, with the classification agreed in writing before work starts.
- Map the CRA essential requirements and AI Act Article 15 controls to one shared list of technical requirements, so each item is recorded once.
- Agree in writing which conformity route, notified body involvement and market surveillance contact the client expects, and mark any point to confirm with the authority.
How we build
- Harden the self-hosted platform and the AI system's runtime environment against the agreed requirements, within your cloud, data center or air-gapped network.
- Run security testing on the product and its APIs, including AI-specific testing where the scope includes it, and track findings to closure.
- Set up vulnerability handling, update and patch processes that match the CRA Annex I Part II requirements and the chosen support period.
How we hand over
- Deliver technical documentation, configuration records and test evidence in a form your compliance and conformity teams can reuse.
- Document the reporting workflow for CRA Article 14 notifications, including who triages, who submits and how the record is kept.
- Train your engineers and compliance staff on the controls, so the evidence trail continues after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which can follow each new release of the product.
- Re-check the scope when the Commission publishes new guidance, harmonised standards or amended application dates that affect your product.
- Confirm legal classification, notified body选择 and any formal conformity decision with your legal counsel and the relevant authorities, since DeployOpen does not issue certifications or attestations.
Sources and further reading
- Regulation (EU) 2024/2847, Article 12 (EUR-Lex) ↗
- Regulation (EU) 2024/1689 (AI Act), Article 15 Accuracy, robustness and cybersecurity, EUR-Lex ↗
- Regulation (EU) 2024/1689, consolidated text as amended by Regulation (EU) 2026/1744 (27 July 2026), EUR-Lex ↗
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex ↗
- Commission FAQs on the Cyber Resilience Act, version 1.4 ↗
- Cyber Resilience Act implementation, Shaping Europe's digital future ↗
