Security by Default: The EU Cyber Resilience Act and the End of the Insecure Product

The Hook: The Router Nobody Repairs Anymore

Picture an utterly ordinary Wi-Fi router. It sits in millions of European living rooms, has done its faithful duty for four years, and somewhere in its firmware lurks a security flaw that an attacker can exploit remotely. The manufacturer knows about it—or could. But the device was sold as a cheap mass-market product, the margin was thin, and the development team moved on to the successor model long ago. A security update? It costs money, brings in no additional revenue, and no one is legally requiring it. So nothing happens. The router stays vulnerable until it ends up as electronic waste—or until it becomes part of a botnet that takes down entire data centers.

This scene does not describe the failure of individual companies. It describes a market failure. As long as security is invisible, justifies no purchase price, and no one is liable for its absence, it is systematically underproduced. The buyer cannot tell how secure the router is; they see the price, the design, and the transfer rate. And the cost of poor protection is borne, in the end, not by the manufacturer but by the hacked user, the paralyzed hospital, the overloaded infrastructure. Security is, in the language of economists, a negative externality—a harm that the party causing it does not pay for.

This is precisely where the Cyber Resilience Act comes in—the CRA for short, officially Regulation (EU) 2024/2847. It is the EU's attempt to build cybersecurity into products themselves, and to do so before they reach the market and throughout their entire expected lifetime of use. The CRA turns a voluntary virtue into a legal obligation: anyone selling a product with digital elements in the EU must in future be able to demonstrate that it was designed securely, that vulnerabilities are handled, and that it receives security updates for a defined period. The visible symbol of this obligation is an old acquaintance: the CE marking, which until now stood for electrical safety and electromagnetic compatibility and is now being extended to the dimension of cybersecurity.

For someone like Sven—a Senior AI Engineer with one foot in cloud architecture and one in IT security—the CRA is relevant from two directions. As an engineer who builds software and connected systems, the CRA defines what security properties, what documentation, and what update commitments a product must have before it may cross the EU border. And as someone who uses open-source components and contributes to them, he is affected by one of the thorniest questions in the whole regulation: how do you regulate security in a world built on voluntarily maintained, unpaid software? This article takes you the whole distance: from the basic idea through the scope, the manufacturer's obligations, the three product classes, and the reporting obligations, to open source, the timeline, and penalties.

Part 1: Why the CRA? Two Problems and a Market Failure

The Political Birth

On 15 September 2021, Commission President Ursula von der Leyen announced a "Cyber Resilience Act" in her State of the Union address. The ambition was bold: Europe was to take a leading role in cybersecurity. The context was a series of spectacular attacks with global reach—from ransomware waves that struck hospitals and pipelines to vulnerabilities in widely used software libraries that rendered practically half the internet vulnerable at once. The Commission's proposal followed in September 2022, and after the usual legislative process among Parliament, Council, and Commission, the regulation was adopted at the end of 2024.

The Two Problems

In its rationale, the CRA names two concrete problems it aims to solve. The first is the low cybersecurity standard of many products: two-thirds of attacks exploit known vulnerabilities, and a substantial share of products on the market contain such flaws. The second is the information deficit among users: buyers can reliably assess neither the security state of a product before or after purchase, nor often even whether and for how long they will receive security updates at all.

Both problems point to the same economic root. Because security is invisible and its absence causes harm only later and elsewhere, no single market participant has the incentive to produce more of it than competition compels. Whoever voluntarily invests in security makes their product more expensive than competitors who do not—and the buyer does not reward the difference, because they cannot see it. The result is a race to the bottom. Regulation, in this picture, is not bureaucratic self-indulgence but an attempt to install a floor below which no one is allowed to fall, so that investment in security no longer functions as a competitive disadvantage.

The Lever: The Product, Not the Organization

The decisive conceptual move of the CRA is its choice of regulatory point. Other European cybersecurity laws attach to the organization: the NIS2 Directive obliges operators of essential and important entities to run a security-management program; DORA obliges financial firms to achieve operational resilience. The CRA, by contrast, attaches to the product. It does not ask whether a company has a security team, but whether the specific device or specific software it sells was built securely. This makes the CRA the perfect complement: NIS2 and DORA secure the operators, while the CRA secures the building blocks from which those operators assemble their systems. Only together do they yield an unbroken chain—from the individual microcontroller to the systemically important bank.

That is why the CRA is called a horizontal regulation: it applies not to one industry but across all product categories, from the smart door lock through the industrial controller to the operating system. And like DORA, the CRA is a regulation, not a directive: it applies directly and uniformly in all member states, without first needing to be translated into national law. This is a deliberate contrast to the NIS2 Directive, whose national transposition is stalling in many states and which therefore looks different from country to country.

Part 2: What Is a "Product with Digital Elements"?

The CRA applies to products with digital elements (PDEs). The definition is deliberately broad: it means any software or hardware product together with its remote data-processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network. Put simply: almost anything that contains software, or is software, and can somehow communicate falls within scope—from the connected toy through the router and firewall to the operating system, the mobile app, and the firmware of a sensor. Components placed on the market separately are covered too; a software library that another manufacturer integrates is itself a product in the sense of the CRA.

Equally important is what is not covered. The CRA bites only when a product is "made available on the market," that is, supplied in the course of a commercial activity. Purely private, non-commercial software is out. And several categories are excluded because they are already covered by their own sector-specific EU laws: medical devices, motor vehicles, civil aviation, and certain areas such as military or national security. Here again the lex specialis principle applies—the more specific law takes precedence, to avoid double regulation. Pure cloud services (software as a service) also fall in principle outside the CRA and are instead covered by NIS2—unless the remote data processing is an integral part of a product (for instance the cloud connection without which a smart device could not perform one of its functions). This boundary between "product" and "service" is one of the subtler and, in practice, most contested questions of the CRA.

Part 3: The Economic Operators and the Manufacturer's Obligations

The CRA distributes obligations along the supply chain across four economic operators: the manufacturer, the authorized representative, the importer, and the distributor. The weight clearly rests with the manufacturer—the natural or legal person who places a product on the market under their own name or trademark. Importer and distributor have chiefly verification and due-diligence duties: they must ensure that a product bears the CE marking, ships with the required information, and comes from compliant manufacture, and they may not place on the market or make available a product they know to be non-compliant.

The Core: Security Across the Lifecycle

The manufacturer's central obligation sits in Article 13 and is fleshed out by the annexes—above all Annex I. In essence, it reads: a product must be secure across its entire lifecycle, from design and development through production to maintenance during the period of use. To achieve this, the manufacturer must carry out a cybersecurity risk assessment. This risk assessment is not a one-off document but the starting point for all further decisions: it determines which of the essential requirements are to be implemented and how, and it must be taken into account in every phase—planning, design, development, production, delivery, and maintenance.

If the manufacturer uses third-party components—and what modern product does not?—it must exercise due diligence to ensure that those components do not undermine the security of its product. This clause is the direct legislative reflex to the era of supply-chain attacks: whoever integrates a vulnerable or even malicious library can no longer plead that it came from someone else.

Annex I: The Essential Requirements in Two Parts

The substantive heart of the CRA is Annex I, which sets out the essential cybersecurity requirements and consists of two parts.

Part I concerns the properties of the product—the requirements for secure design. These include principles such as: the product is delivered without known exploitable vulnerabilities; it is delivered with a secure default configuration (security by default), for instance without hard-coded default passwords; it protects the confidentiality and integrity of data through encryption where appropriate; it enforces access control; it minimizes the attack surface; it provides protection mechanisms against unauthorized access and logs security-relevant events. These principles—often summarized as roughly thirteen individual requirements—codify what security experts have preached for years as security by design and security by default, elevating it from a recommendation to a legal obligation.

Part II concerns the handling of vulnerabilities—that is, not the product at the moment of sale but its upkeep over time. The manufacturer must identify and document the vulnerabilities of its product (including its components), among other things in a software bill of materials (SBOM)—a structured inventory of all contained components. It must remediate vulnerabilities without delay, provide security updates, run a coordinated vulnerability disclosure policy, and set up a contact point for reports. Crucially: security updates must in principle be provided free of charge and, where technically possible, automatically.

The Support Period: An Expiry Date for Vulnerability

One of the most consequential innovations in practice is the obligation to define a support period. For this period the manufacturer guarantees that it will handle vulnerabilities and deliver security updates. The support period must correspond to the expected duration of use of the product and should, as a rule, be at least five years (shorter only where the expected lifetime is demonstrably less). The end date—with month and year—must be communicated to the buyer clearly and understandably at the time of purchase.

I am of the opinion that this seemingly bureaucratic requirement is one of the most elegant in the entire law. It attacks precisely the problem of the hook's router: until now it was entirely unclear how long a product would receive updates, and manufacturers discontinued support quietly and covertly. The CRA forces them to commit in advance and in public. This turns the question "How long is this device secure?" from an invisible afterthought into a statement on the packaging—comparable to a best-before date for cybersecurity.

Part 4: The Three Product Classes and Conformity Assessment

Not every product carries the same risk. A smart thermometer is a different matter from an operating system or a hardware security module in which cryptographic keys reside. The CRA accounts for this by sorting products into three risk tiers and tying to them the stringency of conformity assessment—the procedure by which a manufacturer demonstrates that it meets the requirements.

The Three Tiers

For the vast majority of products—the default class—a self-assessment suffices: the manufacturer checks its product internally against the requirements (the so-called internal control procedure, module A), compiles the technical documentation, signs the EU declaration of conformity, and affixes the CE marking. It is important to stress this, because the debate often creates the impression that every product must be externally certified: that is not true. The effort is real, but for most products it stays in the manufacturer's own hands.

For important products (Annex III) the bar rises. For Class I—such as password managers or VPNs—the manufacturer may self-assess only if it applies recognized harmonized standards (or common specifications, or a European certification scheme); otherwise an independent notified body must assess it. For Class II—such as operating systems, firewalls, or industrial routers—assessment by a notified body is always mandatory.

For critical products (Annex IV) the bar is highest: these include devices of particularly high security relevance such as hardware security modules, smart meter gateways, and smartcards and devices with secure elements. For them the Commission may make a European cybersecurity certification (for instance under the EUCC scheme) mandatory. The Commission specified the technical descriptions of these important and critical categories in a dedicated implementing regulation—(EU) 2025/2392 of 28 November 2025—so that manufacturers can reliably determine which class their product falls into.

Harmonized Standards and the Presumption of Conformity

A central instrument that makes the whole mechanism run is the presumption of conformity: if a manufacturer applies a harmonized European standard listed in the Official Journal, its product is presumed to meet the corresponding essential requirements. This translates abstract legal duties into concrete, verifiable technical standards, and it is why the European standardization organizations (CEN, CENELEC, ETSI) are currently working under high pressure on CRA standards. If this standardization is delayed, manufacturers lose the simplest means of demonstrating conformity—a sore point in the timeline that many observers regard with concern.

The CE Marking: An Old Symbol with New Meaning

At the end stands a familiar sign: the CE marking. For decades it has been the visible token of conformity with EU product law under the so-called New Legislative Framework. Until now it stood for things like electrical safety or electromagnetic compatibility; with the CRA it gains a new dimension. A CE mark on a product with digital elements will in future also mean: "This manufacturer declares that it meets the essential cybersecurity requirements." Cybersecurity thereby moves into the same legal framework in which physical product safety has long been at home—a remarkable symbolic and practical step.

Part 5: The Reporting Obligations—The 24-Hour Clock

Alongside the product-related duties, the CRA contains in Article 14 a sharp reporting obligation that bites even before the big cutoff date. As soon as a manufacturer becomes aware of an actively exploited vulnerability in its product, or of a severe incident affecting the security of the product, a staggered clock begins:

• an early warning within 24 hours of becoming aware;
• a main notification within 72 hours with more detailed information;
• a final report—for actively exploited vulnerabilities, no later than 14 days after a corrective or mitigating measure is available; for severe incidents, within one month of the 72-hour notification.

Notifications run through a Single Reporting Platform operated by the EU cybersecurity agency ENISA, and go to the national Computer Security Incident Response Team (CSIRT) of the member state in which the manufacturer has its main establishment, as well as to ENISA itself. Notably, the scope is broad: the reporting obligation applies to all products made available on the EU market—including those already placed on the market before the big cutoff date in December 2027.

This reporting obligation is not uncontroversial. Critics—among them prominent security researchers—have objected that requiring actively exploited but still unpatched vulnerabilities to be reported to government bodies within 24 hours concentrates sensitive knowledge in the hands of authorities before a fix exists. In the worst case, the worry goes, a database of highly explosive zero-day information could arise that might itself become an attack target or—in the wrong hands—a weapon. The regulation tries to counter this with strict confidentiality rules and a limitation on access; whether the balance between transparency and secrecy succeeds will only become clear in practice from September 2026 onward.

Part 6: Open Source—The Hardest Question

No topic stirred the making of the CRA as much as the question of open-source software. The reason is structural: the entire modern digital world rests on free software, which is predominantly maintained by unpaid volunteers or small foundations. If one were to burden these volunteers with the same obligations as a billion-euro device manufacturer, the consequence would be foreseeable: many would rather shut down their projects, or turn their backs on Europe, than assume legal liability for software they give away free and in their spare time. The early draft of the CRA therefore triggered a storm of indignation in the open-source community.

The final text draws a careful line in response. Non-commercially provided open-source software falls in principle outside the CRA. An individual developer who publishes a project on a platform does not become a liable manufacturer. Only when software is "made available on the market"—that is, in the course of a commercial activity—do the obligations bite, and then they fall on whoever commercializes it.

For an intermediate zone the CRA creates a new, specially invented role: the open-source software steward. These are legal persons—typically foundations—that systematically and sustainably support the development of specific free software used for commercial purposes and secure its viability. Such stewards are subject to softened obligations: they must have a cybersecurity policy, cooperate with market surveillance authorities, and report certain vulnerabilities and incidents—but they are not subject to the full catalogue of a manufacturer's duties. And, importantly: open-source stewards cannot be fined for infringements of the CRA.

Here it is worth looking back at another article in this vault. The piece The Backdoor at the Heart of Linux: The XZ Attack and the Anatomy of a Supply-Chain Compromise describes how a single overwhelmed volunteer maintaining an inconspicuous compression library became the entry point for a nearly catastrophic attack on half the Linux ecosystem. The CRA is, among other things, the regulatory answer to precisely this fragility. Yet the irony is sharp: the problem in the xz affair was not too little regulation but too few resources for an exhausted human being. Whether a cybersecurity policy on paper really protects an underfunded maintainer—or merely burdens them further—is one of the open questions the CRA raises but does not conclusively answer.

Part 7: Timeline and Penalties

The Timeline

The CRA does not apply all at once but in stages—a deliberate contrast to DORA, which became fully effective on a single cutoff date.

For existing products there is a pragmatic rule: products placed on the market before 11 December 2027 fall under the full CRA obligations only if they are substantially modified from that date. The reporting obligations, however, apply—as mentioned—to all products made available.

The Penalties: Three Tiers

Article 64 sets the fine ranges, whose concrete implementation the member states carry out nationally (in Germany presumably under the lead of the BSI and market surveillance). The regulation grades the maximum amounts by the severity of the infringement in three tiers:

As with the EU AI Act and DORA, the maximum is thus anchored to worldwide turnover—a mechanism that ensures the penalty remains meaningful even for global corporations and cannot be dismissed as a cost of doing business. At the same time, the CRA shows a sense of proportion at decisive points: microenterprises and small enterprises cannot be punished for missing the 24-hour reporting deadline, and open-source stewards are exempt from fines. These exceptions are not a loophole but an attempt to preserve proportionality and not to crush the most fragile parts of the ecosystem.

Part 8: The CRA in Context—Neighbors in the Web of Rules

The CRA does not stand alone but is one building block in a whole architecture of European digital regulation. Its family relationships help to place it.

The closest conceptual neighbor is the NIS2 Directive. Whereas NIS2 secures the organizations that operate critical services, the CRA secures the products those organizations deploy. An operator who must run secure systems under NIS2 will in future be able to rely on the building blocks of those systems meeting a security floor under the CRA. The relationship with DORA is similar: the financial sector will in future source its IT products from manufacturers subject to the CRA—the product-side safeguard complements the operator-side resilience.

The relationship with the EU AI Act is also interesting. For high-risk AI systems that are simultaneously products with digital elements, the legislator provides a bridge: if such a system meets the essential cybersecurity requirements of the CRA, it is deemed compliant to that extent with the cybersecurity requirements of the AI Act as well. This avoids duplicate work—one CE mark can attest to several conformities at once. And finally, the CRA touches those deeper technical themes treated elsewhere in the vault: its demand for sustained vulnerability handling encompasses the long-term risk that today's encryption may one day be broken by quantum computers; and its logic of essential product security bears directly on that class of hardware vulnerabilities in which a seemingly harmless optimization became a systemic flaw.

Cross-References in the Vault

• NIS2 and What It Really Means for Mid-Market IT Consulting Firms in Germany – the closest neighbor: NIS2 secures the organizations, the CRA the products.
• When IT Is Not Allowed to Fail: DORA and Digital Operational Resilience in Finance – operator-side resilience in finance, which the CRA complements on the product side.
• The Pyramid of Risk: How the EU AI Act Tames Artificial Intelligence – and Why It Concerns the Whole World – the same risk-based regulatory philosophy; CRA conformity can also cover AI Act cybersecurity.
• The Backdoor at the Heart of Linux: The XZ Attack and the Anatomy of a Supply-Chain Compromise – the fragility of the open-source supply chain to which the CRA responds.
• Harvest Now, Decrypt Later: Post-Quantum Cryptography and the Race Against the Quantum Computer – a long-term risk that CRA vulnerability handling must also encompass.
• When the Processor Guesses Too Much: Spectre, Meltdown, and the Sin of Speculative Execution – how an optimization becomes a systemic product vulnerability.

The Central Takeaway

If you take one single thing away from this article, let it be this: The CRA shifts responsibility for cybersecurity away from users and back to manufacturers—and turns it into a product property that must be demonstrated, labeled, and maintained over time. Until now, security was an invisible extra that the market systematically underrewarded; from now on it is an entry ticket to the EU single market. No CE mark without a security commitment, no sale without a defined support period, no more excuses for hard-coded default passwords or quietly discontinued updates.

For day-to-day engineering practice this means, very concretely: treat software bills of materials (SBOM), coordinated vulnerability disclosure, and automatic, free security updates not as annoying compliance add-ons but as first-class design requirements that belong in the architecture from the start. Anyone designing a product today should know what components it consists of, how to keep them current over years, and how to report an exploited vulnerability within hours if the worst happens. And anyone using open-source components should check not only their license but also how healthy and well-maintained the project behind them is—because if something goes wrong, it is your own duty of care that counts. Read correctly, the CRA is less a bureaucratic mandate than an engineering one: it forces you to build security in from the very first design decision rather than assert it afterward.

Reflection Question

The CRA requires every manufacturer to know what components its product consists of (SBOM), and to declare publicly at the point of sale how long it will supply the product with security updates. Think of a product or system you are currently working on or that you know: could you produce, off the top of your head, a complete list of all third-party components inside it—and would you dare to promise bindingly that every single one of them will be kept secure for five years?

Sources

• The Cyber Resilience Act – Summary of the legislative text – European Commission, Shaping Europe's digital future
• Regulation (EU) 2024/2847 (Cyber Resilience Act) – full text on EUR-Lex
• Cyber Resilience Act – Conformity assessment – European Commission
• Commission Implementing Regulation (EU) 2025/2392 – technical descriptions of important and critical products
• Cyber Resilience Act – Wikipedia (overview, origin, criticism)
• The Cyber Resilience Act Explained: Scope, Classes & Deadlines – cyberresilienceact.eu

← All articles