up:: The Mandates MOC

EU Cyber Resilience Act (CRA)

The EU Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847, the European Union’s horizontal cybersecurity law for “products with digital elements,” and it makes baseline product security a legal condition of selling any connected hardware or software into the EU market. It was adopted on October 23, 2024 and entered into force on December 10, 2024, and it reaches manufacturers anywhere in the world that sell into the EU, wherever they’re headquartered. It doesn’t name a single cryptographic algorithm, but its requirement to protect data with “state of the art” encryption and to keep patching products for years is the lever that pulls post-quantum readiness into EU market access.

The short version:

• The CRA is EU law, formally Regulation (EU) 2024/2847, that sets mandatory cybersecurity requirements for any product with digital elements sold in the EU, enforced through CE marking rather than a sector regulator.
• It’s extraterritorial. A U.S., UK, or Asian manufacturer selling into the EU is bound exactly as an EU manufacturer is, which is why it sets a de facto global product-security floor.
• Its obligations phase in. Vulnerability and incident reporting applies from September 11, 2026, and the full set of secure-by-design requirements, conformity assessment, and CE marking applies from December 11, 2027.
• It names no algorithm and sets no PQC deadline. Its “state of the art” encryption clause and its multi-year security-update obligation are what make post-quantum readiness an EU market-access question rather than a voluntary upgrade.
• The actual PQC dates live in a separate document, the EU Coordinated Implementation Roadmap, which asks member states to start transitioning by the end of 2026, migrate high-risk use cases by the end of 2030, and complete the transition by the end of 2035.

Think of the CRA as a building code for connected products. A building code doesn’t tell you which brand of wiring to install. It tells you the wiring has to be safe to the current standard, and it has to stay safe over the life of the building. The CRA is that same idea applied to the software and hardware you put on the market: the product has to be secure when you sell it, and you have to keep it secure with updates for years afterward. As the current standard for “safe” moves toward post-quantum cryptography, the products you shipped years earlier are the ones that have to keep up.

What is the EU Cyber Resilience Act?

The EU Cyber Resilience Act is a Regulation of the European Parliament and Council on horizontal cybersecurity requirements for products with digital elements. “Horizontal” means it cuts across every sector rather than governing one industry, and “Regulation” means it’s directly applicable in all 27 member states without each country passing its own version, which is what separates it from an EU Directive. Its full official title is Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements.

Source: EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act), official text, EUR-Lex 2024/2847.

The identity of the law, in the terms that matter when you cite it:

1. What it is: a directly applicable EU Regulation, not a Directive and not guidance. It’s mandatory, and non-compliance blocks EU market access.
2. Who issued it: the European Parliament and the Council of the European Union.
3. When it was adopted and published: adopted October 23, 2024, published in the Official Journal on November 20, 2024.
4. When it entered into force: December 10, 2024, twenty days after Official Journal publication, per Article 71.
5. What it enforces with: CE marking, the same conformity mark already on physical goods in the EU, now extended to cover cybersecurity. A product that can’t be CE-marked under the CRA is barred from lawful sale.

Source: European Commission, “Cyber Resilience Act,” EC digital-strategy CRA page, confirming Regulation (EU) 2024/2847, entry into force December 10, 2024, reporting obligations from September 11, 2026, and main obligations from December 11, 2027.

Who does the CRA apply to?

The CRA regulates the product, and through the product it binds whoever places that product on the EU market. If a company sells connected hardware or software into the EU, it’s in scope regardless of where the company is headquartered. That single fact is the one most organizations get wrong.

1. What’s covered: “products with digital elements,” meaning any hardware or software whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. That sweeps in connected devices, IoT, industrial controllers, network equipment, operating systems, applications, and libraries, including software placed on the market on its own.
2. Who carries the obligations: manufacturers carry the full weight. Importers and distributors carry lighter due-diligence duties and must not place non-compliant products on the market. A company that substantially modifies a product, or sells it under its own name, can be treated as the manufacturer.
3. The geographic reach is extraterritorial: a manufacturer in the United States, the UK, or Asia selling into the EU is bound exactly as an EU manufacturer is. This is the mechanism behind the so-called Brussels effect, where an EU rule becomes a global baseline because it’s easier to build one compliant product than two.
4. Open-source software: non-commercial open-source developed outside a commercial activity is largely carved out, and a new lighter-obligation role, the “open-source software steward,” is created for it. Commercial products that bundle open-source components pull those components into the manufacturer’s own conformity scope.
5. What’s excluded: products already governed by equivalent sector-specific EU cybersecurity law are carved out to avoid double regulation, including medical devices under Regulation (EU) 2017/745, in-vitro diagnostic devices, motor vehicles under Regulation (EU) 2019/2144, and certain civil aviation and marine equipment. Products developed exclusively for national security or defense, and products processing classified information, are also outside scope. [OPERATOR VERIFY: confirm the full Article 2 exclusion list against the OJ text before asserting a specific product is carved out.]

Source: European Commission, “The Cyber Resilience Act, Summary of the legislative text,” EC CRA summary, for the scope, the definition of products with digital elements, the economic-operator roles, and the open-source carve-out.

What does the CRA require?

The CRA runs on two obligation engines. The first is a set of properties the product must have when it’s placed on the market. The second is a set of processes the manufacturer must run across the product’s supported life.

1. Essential product requirements (Annex I, Part I). Products must be made available “without known exploitable vulnerabilities” and with a “secure by default” configuration. The cryptographically load-bearing requirement is the duty to protect the confidentiality of stored, transmitted, or otherwise processed data, “such as by encrypting relevant data at rest or in transit by state-of-the-art mechanisms,” alongside a parallel duty to protect data integrity. The requirements also cover access control, attack-surface minimization, exploitation-mitigation techniques, and the recording of security-relevant activity. [OPERATOR VERIFY: the exact sub-point lettering within Annex I Part I point (2), widely reproduced as (2)(e) for confidentiality, against the OJ text before citing a specific letter.]
2. Vulnerability-handling requirements (Annex I, Part II). Manufacturers must identify and document vulnerabilities and components, including producing a software bill of materials (SBOM) in a commonly used machine-readable format, remediate vulnerabilities without delay through free security updates, test regularly, publicly disclose fixed vulnerabilities once a fix exists, run a coordinated vulnerability disclosure policy, and provide a contact point for reports.
3. Reporting obligations (Article 14). Manufacturers must notify actively exploited vulnerabilities and severe incidents through a single reporting platform to the relevant national CSIRT and to ENISA, on a tiered schedule. This is the obligation that switches on first, in September 2026. [OPERATOR VERIFY: confirm the exact notification cadence, widely cited as a 24-hour early warning and a 72-hour notification plus a final report, and the exact ENISA/CSIRT routing, against the OJ text before quoting timings.]
4. Conformity assessment and CE marking. Before placing a product on the market, the manufacturer runs a conformity assessment matched to the product’s risk class, draws up technical documentation, issues an EU declaration of conformity, and affixes the CE marking. The assessment gets stricter as risk rises: most products (roughly 90 percent) can self-assess, “important” products face stricter routes, and “critical” products may need a European cybersecurity certification. [OPERATOR VERIFY: confirm the current important-product and critical-product lists and the certification triggers against the OJ text and any delegated acts.]
5. Support-period obligation. The manufacturer must define and honor a “support period” during which it handles vulnerabilities and ships security updates. The period must reflect how long the product is expected to be in use, and it’s widely cited as at least five years unless the product’s expected life is shorter. [OPERATOR VERIFY: confirm whether the “at least five years” figure is a hard obligation or an expectation framed around product lifetime in the OJ text.]

Source: CRA Annex I reproductions, StreamLex Annex I and EUR-Lex, Regulation (EU) 2024/2847, Annex I, for the verbatim confidentiality clause and the vulnerability-handling duties, corroborated against the EC CRA summary.

What is the CRA timeline?

The CRA phases in over three years from entry into force. The reporting obligations arrive first, and the full obligation set arrives last. These dates are the load-bearing content of the whole regulation.

Date	Provision	What applies
November 20, 2024	Article 71	Published in the Official Journal (OJ L, 2024/2847)
December 10, 2024	Article 71	Regulation enters into force, twenty days after publication
June 11, 2026	Article 71	Rules on notifying conformity-assessment bodies apply, so notified bodies can be designated ahead of full application
September 11, 2026	Article 14	Manufacturer reporting for actively exploited vulnerabilities and severe incidents applies
December 11, 2027	Article 71	Full application, the Annex I essential requirements, conformity assessment, and CE marking

Source: European Commission, EC digital-strategy CRA page, confirming entry into force December 10, 2024, reporting obligations from September 11, 2026, and main obligations from December 11, 2027; phased Article 71 dates corroborated by cyberresilienceact.eu.

Products placed on the market before the full-application date are generally only pulled into the regime if they’re substantially modified afterward, so the 36-month runway from entry into force to full application is the real transition window. [OPERATOR VERIFY: confirm the exact treatment of pre-existing products and the “substantial modification” trigger in the transitional provisions against the OJ text.]

How does post-quantum cryptography flow into the CRA?

The CRA never says “use ML-KEM.” It says protect confidentiality with state-of-the-art encryption and keep shipping security updates for years, and those two obligations together are what turn post-quantum readiness into an EU market-access question. Anyone claiming the CRA “requires PQC” is overstating what the text actually says.

1. No algorithm is named. The CRA sets an outcome, confidentiality protected by “state-of-the-art mechanisms,” rather than an algorithm list. It doesn’t mandate ML-KEM, ML-DSA, or any post-quantum scheme, and it sets no migration date.
2. “State of the art” is a moving target by design. As NIST FIPS standards, ENISA guidance, and CEN-CENELEC harmonized standards converge on post-quantum baselines, the practical content of “state of the art” for confidentiality is expected to shift toward PQC and PQC/classical hybrids over a product’s life. A harmonized standard, once cited in the Official Journal, gives a presumption of conformity, so PQC expectations can enter CRA compliance without the regulation itself being amended.
3. Crypto-agility is the real design consequence. Because the confidentiality requirement is outcome-based and the support period runs for years, the defensible engineering reading is that in-scope products have to be built so their cryptographic primitives can be swapped through a security update. That’s crypto-agility as a CRA design consequence, and it’s the most useful framing of the whole cryptographic story.
4. The harvest-now hook. A product shipped in 2027 with a five-year-plus support period is protecting data with public-key cryptography well into the window where harvest-now-decrypt-later exposure and the deprecation of RSA, ECDH, and ECDSA go live. The support-period obligation means the manufacturer can’t walk away from that product, so it has to be able to deliver the crypto update.

The specific PQC dates in Europe live in a separate instrument, not in the CRA. The EU Coordinated Implementation Roadmap, developed by the NIS Cooperation Group in response to the Commission’s April 2024 Recommendation on post-quantum cryptography, sets the transition schedule for member states:

Date	Milestone
End of 2026	Member states start transitioning, with national PQC roadmaps defined and planning underway for high- and medium-risk use cases
End of 2030	High-risk use cases migrated, including critical infrastructure across water, energy, health, finance, and transport
End of 2035	All migrations completed for every risk level

Source: European Commission, “EU reinforces its cybersecurity with post-quantum cryptography,” EC PQC roadmap news, and “A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography,” EC roadmap library, confirming the end-2026 start, the end-2030 high-risk deadline, and the end-2035 completion target.

The two instruments work together. The roadmap sets when Europe wants PQC in place, and the CRA is the enforceable product law whose “state of the art” clause is expected to absorb those expectations over time.

How does the CRA relate to the standards and the other mandates?

The CRA sits inside a dense EU cyber-law stack, and it connects outward to the NIST-anchored PQC standards a global manufacturer already tracks.

1. NIS2 Directive (Directive (EU) 2022/2555) regulates the cybersecurity of essential and important entities, meaning the operators. The CRA regulates the cybersecurity of products. They’re the two complementary halves of the EU framework: NIS2 governs how organizations run security, and the CRA governs what the products they buy and sell have to do.
2. The Cybersecurity Act (Regulation (EU) 2019/881) provides the European cybersecurity certification schemes, such as EUCC, that the CRA leans on for its critical-product route. ENISA, established under that act, is the recipient of CRA vulnerability and incident reports.
3. GDPR (Regulation (EU) 2016/679) governs the security of processing personal data. The CRA’s confidentiality and integrity requirements reinforce it for products that handle personal data, though the CRA applies to personal and non-personal data alike.
4. The NIST FIPS PQC standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), are not referenced by the CRA. They’re the algorithms the “state of the art” clause is expected to converge on, and the ones a global manufacturer will implement to satisfy EU and U.S. expectations with one crypto stack.
5. The contrast with the U.S. mandates is the useful part. NSA CNSA 2.0 and NIST IR 8547 drive PQC through explicit named algorithms and named deadline years. The CRA drives it indirectly, through outcome-based product-security law and market access, with the concrete dates living in the separate Coordinated Roadmap. A company operating on both continents needs both framings. The EU Quantum Act, a proposed EU industrial-policy measure to build Europe’s quantum sector, is a different kind of instrument again and isn’t a PQC migration mandate.

What does the CRA mean for a vendor or a CISO?

For a manufacturer, the CRA converts product cybersecurity from a competitive nicety into a legal precondition of EU market access, with real enforcement behind it. A product that fails the Annex I essential requirements can’t lawfully be sold in the EU after December 11, 2027, and market-surveillance authorities can order withdrawal or recall and levy administrative fines up to 15 million euro or 2.5 percent of worldwide annual turnover, whichever is higher, for breaching the essential requirements. [OPERATOR VERIFY: confirm the exact fine article and tiering against the OJ text before quoting the figure in a client deliverable.]

Source: EC CRA summary for the enforcement powers and fine ceiling.

For the cryptographic side, the honest reading is narrow and specific. The CRA doesn’t hand a vendor a PQC deadline. It requires state-of-the-art confidentiality protection and multi-year security-update capability, and for any product whose supported life reaches into the 2030s, that combination is a crypto-agility-and-PQC-readiness obligation in all but name. A product that hard-codes cryptographic primitives with no update path is the hardest and most expensive gap to close, because a later shift in “state of the art” creates an obligation the shipped design can’t satisfy. The two structural facts that most change a vendor’s exposure:

1. The support period is the trap. A device with a long support period and no cryptographic update mechanism is protecting data with algorithms that may be deprecated before the support period ends, and the manufacturer is on the hook to keep it secure the whole time.
2. The technical file is the proof. The conformity-assessment evidence and the EU declaration of conformity have to be kept for ten years after a product is placed on the market, or for the support period, whichever is longer, and documenting which cryptographic algorithms a product uses and that they can be replaced is what makes the “state of the art” claim auditable. A CBOM is the natural artifact for that, even though the CRA names only an SBOM.

For a CISO buying connected products rather than making them, CRA CE marking becomes a procurement filter, and crypto-agility commitments become a fair thing to ask a vendor for as a purchase condition. That’s the same dynamic that makes vendor-controlled cryptography a first-class part of any migration.

Common misconceptions

1. “We’re not an EU company, so the CRA doesn’t apply to us.” It binds anyone placing a product on the EU market. A non-EU manufacturer with EU customers is fully in scope. This is the single most common misread.
2. “The only deadline is December 2027.” The Article 14 reporting obligations switch on more than a year earlier, on September 11, 2026. A program built entirely around 2027 misses the earlier reporting-readiness date.
3. “The CRA requires post-quantum cryptography.” It requires state-of-the-art confidentiality protection and doesn’t name any algorithm or set a PQC date. The PQC dates live in the separate Coordinated Roadmap, and the CRA is the product law expected to absorb them over time through harmonized standards.
4. “State of the art’ is whatever was current when we certified.” The phrase is deliberately dynamic. Certifying against 2027-era cryptography and never revisiting it misreads the support-period obligation, which requires the manufacturer to keep pace through updates.
5. “A declaration of conformity means we’re compliant.” A signed declaration is a paper claim. A running vulnerability-handling pipeline, a tested update mechanism, and documented cryptography are what a market-surveillance authority can actually demand.
6. “Our open-source dependencies aren’t our problem.” Commercial products that bundle open-source components pull those components, including their cryptographic pieces, into the manufacturer’s own conformity scope.

Questions people ask

Does the CRA apply to my organization? If you make, import, or distribute any product with digital elements, hardware or software, that’s placed on the EU market, yes, regardless of where you’re based. Manufacturers carry the full obligations; importers and distributors carry lighter due-diligence duties.

What’s the actual deadline? There are two that matter. Vulnerability and incident reporting under Article 14 applies from September 11, 2026, and the full body of obligations, the essential requirements, conformity assessment, and CE marking, applies from December 11, 2027.

Is the CRA law or guidance? It’s law. A Regulation is directly applicable across all 27 member states without national transposition, and non-compliance blocks market access and carries administrative fines.

What happens if we miss it? A non-compliant product can’t lawfully be sold in the EU, market-surveillance authorities can order it withdrawn or recalled, and fines run up to 15 million euro or 2.5 percent of worldwide annual turnover for breaching the essential requirements. [OPERATOR VERIFY: confirm the exact fine tiering against the OJ text before quoting.]

Does the CRA reach me through my vendors or customers? Yes. Even a company not directly in scope feels the CRA through procurement, because buyers increasingly require CE marking and crypto-agility commitments, and because bundled third-party and open-source components fall into a manufacturer’s own conformity scope.

Does the CRA set a post-quantum migration deadline? No. It names no algorithm and sets no PQC date. Europe’s PQC dates come from the separate Coordinated Implementation Roadmap, which targets a transition start by the end of 2026, high-risk migration by the end of 2030, and completion by the end of 2035.

How does the CRA line up with the NIST standards? The CRA doesn’t reference NIST, but its “state of the art” encryption clause is expected to converge on the NIST FIPS PQC standards over time, so a global manufacturer implementing ML-KEM and ML-DSA to satisfy U.S. expectations is also building toward what “state of the art” will mean under the CRA.

---

Everything here is the map, given freely. When your team needs the CRA’s obligations translated into what your own products actually have to prove, and how crypto-agility fits the support periods you ship, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.