For most of our profession's history, shipping insecure software has carried roughly the same legal consequence as shipping software with an ugly icon. Which is to say, none. You clicked "I accept" on a licence that disclaimed every warranty known to law, and if anything went horribly wrong, well, that was nobody's fault in particular. Those days are ending. The European Union has decided that software should carry the same basic duty of care as a kettle or a car, and it has written that decision into law. The law is called the Cyber Resilience Act (CRA), and if you build software that reaches European users, you need to pay attention.
This is the first article in a series I’ve drafted to demystify the CRA for .NET developers who’d rather understand it now, when they’ve time to implement the required changes, than learn about it in 2027 when a customer's procurement team forwards you a compliance questionnaire with a deadline. We’ll get into the details (and there is a lot of detail), but the goal of this post is to give you a basic understanding of what the CRA is, where it came from, who it impacts, what it demands, and timelines. Later posts drill into the parts that will matter most depending on who you are, whether that's an open-source maintainer, a commercial manufacturer, or someone contributing code occasionally.
What is the Cyber Resilience Act?
The Cyber Resilience Act is Regulation (EU) 2024/2847. It entered into force on 10 December 2024, and it lays down a single set of mandatory cybersecurity requirements for what it calls "products with digital elements" placed on the European market.
That clumsy phrase is doing an enormous amount of heavy lifting. A product with digital elements is, in the words of the Regulation, "a software or hardware product and its remote data processing solutions".
In plain English: software, hardware with software in it, and the cloud bits that a product needs to function. If it has a direct or indirect data connection to a device or a network, and it’s available in the EU, the CRA likely impacts it.
Because it’s a Regulation rather than a Directive, it applies directly and uniformly across all twenty-seven member states without each country having to pass its own version. There’s no patchwork of national interpretations to arbitrage. It’s one set of rules that all twenty-seven enforcement authorities will be enforcing.
The CRA sits on top of a piece of EU legal machinery called the New Legislative Framework, the same framework that governs the CE marking you have seen on the underside of every phone charger and toaster you own. That lineage should tell you almost everything you need to know about the CRA's ambitions. The goal is to treat software the way Europe already treats physical goods: as a product that must meet essential requirements, undergo a conformity assessment, carry a CE mark, and come with a manufacturer who stands behind it. It’s a significant change, given that software has spent decades enjoying a liability holiday that no other engineered product has ever been granted.
Why Europe created it
The CRA was born from a simple observation that digital products were shipping with poor security, security updates were patchy or absent, and buyers had no way to tell a well-secured product from a negligent one before they purchased it. When a connected doorbell or a smart thermostat gets conscripted into a botnet, the cost more often than not lands on everyone except the company that built it. Economists call that an externality. Regulators call it a market failure. Either way, the fix Europe has reached for is to make the manufacturer internalise the cost by making security a legal condition of sale.
The CRA set out to close two specific gaps. It requires products to be secure when they are placed on the market, and it requires manufacturers to keep them secure through vulnerability handling and security updates, for a defined support period afterwards. Security by design, and security over time. Remember that pairing, because nearly every specific obligation in the CRA is an instance of one or the other.
Who the CRA applies to (this means you, probably)
Here is where a lot of developers make a hopeful error. They read "products with digital elements", picture a smart fridge, and conclude that the CRA is a hardware problem for companies. It’s not.
Standalone software is squarely in scope. A desktop application, a mobile app, a developer tool, a library that a company sells, an operating system, a password manager: all of these are products with digital elements. The Commission's own guidance is emphatic: software supplied via digital means is placed on the market the moment its manufacturing phase is complete, and it’s first offered for download or use.
The Regulation defines several types of "economic operators", and your obligations depend on the role you play. The manufacturer develops a product and markets it under its own name or trademark, and it carries the heaviest obligations. The importer is an EU-established party that places a non-EU manufacturer's product on the market. The distributor makes a product available without changing it. And then there is a genuinely new legal creature, the open-source software steward, which the CRA invented specifically to deal with foundations and organisations that sustain open-source projects without selling them. Each role gets a different weight of responsibility, and one of the first useful things you can do is work out which one you occupy, because the same company can be a manufacturer for one product and a steward for another.
Two categories of people get meaningful relief. Individual open-source contributors who write code for a project they do not control are not manufacturers, and a project maintained purely as free and open-source software outside any commercial activity is not "placed on the market" at all. That carve-out was hard-won, and it is more nuanced than "open source is exempt", which is why it gets its own article later in this series. The other group getting a lighter touch is micro and small enterprises, who benefit from proportionate enforcement and simplified documentation, though not from exemption.
The four things the CRA asks of a product
If we strip away the legal scaffolding, the CRA asks a manufacturer to do four things.
First, assess the risk. Before a product goes to market, the manufacturer must carry out a cybersecurity risk assessment that looks at the product's intended purpose and its reasonably foreseeable use, and that assessment drives everything else. The CRA is risk-based, and asks you to understand your product's threats and to justify your choices against them, which is either liberating or terrifying depending on your appetite for documentation.
Second, meet the essential requirements. Annex I of the Regulation sets out the essential cybersecurity requirements in two parts. Part I is about the product's security properties: ship without known exploitable vulnerabilities, default to a secure configuration, protect the confidentiality and integrity of data, minimise the attack surface, provide security updates, and so on. Part II is about the process: identify and document your components, including a software bill of materials; remediate vulnerabilities without delay; run regular security testing; and operate a coordinated vulnerability disclosure policy.
Third, prove it. The manufacturer must run a conformity assessment appropriate to the product's risk class, draw up technical documentation, issue an EU declaration of conformity, and affix the CE marking. For the vast majority of software, this is a self-assessment: you do the work, document it, sign the declaration, and take the liability. For a smaller set of security-critical products, an independent notified body has to be involved. Which camp you fall into is a question we untangle in a later manufacturer-focused post.
Fourth, stand behind it. Once the product is on the market, the manufacturer must handle vulnerabilities for the entire support period, issue free security updates, and report actively exploited vulnerabilities and severe incidents to the authorities within defined timelines. The obligation doesn’t end at the point of sale. In some ways, the sale is only the beginning.
The timeline (closer than it looks)
The single most common mistake people make about the CRA is thinking it’s a problem to solve in 2027. The full weight of the Regulation, the essential requirements, conformity assessment, and CE marking, does indeed apply from 11 December 2027. But the deadlines arrive in waves, and the first wave is almost here.
From 11 September 2026, the reporting obligations in Article 14 apply. That’s a matter of weeks from the time of writing, not years. From that date, manufacturers must report actively exploited vulnerabilities and severe incidents through a single reporting platform operated by the EU cybersecurity agency, ENISA, on a twenty-four-hour early-warning clock. The product-security requirements are not yet enforceable, but the duty to raise your hand when something is being exploited in the wild is about to be. Between those two dates, from 11 June 2026, the provisions that let notified bodies get themselves designated also kick in, so that the assessment infrastructure exists before everyone needs it in 2027. I’ll devote an entire post to the timeline, because the sequencing genuinely matters and treating it as one distant cliff will likely cause you to prepare for the wrong thing first.
Penalties
Regulation without teeth gets ignored, and the folks writing the CRA know it. The penalty structure has three tiers. Breaching the essential cybersecurity requirements in Annex I, or the core manufacturer duties in Articles 13 and 14, can cost up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other obligations top out at €10 million or 2%. Supplying incorrect or misleading information to a notified body or a market surveillance authority can still cost €5 million or 1%. These are GDPR-scale numbers, calculated on global turnover, not European revenue, which means a company's exposure is not limited to the size of its EU business. Enforcement is proportionate for smaller companies, and nobody expects a wave of maximum fines on day one, but the ceiling is set high enough to make board-level attention rational. That’s the entire point of it.
Why a .NET framework company is writing this
You might reasonably ask why AvaloniaUI, of all people, is publishing a guide to a European cybersecurity regulation. The honest answer is that the CRA lands on us from every direction at once, and that exposure is exactly what makes it worth writing about.
Start with the most direct one: we are a manufacturer ourselves. AvaloniaUI OÜ is a commercial company, and alongside the open-source framework we sell developer tooling, premium components, and Avalonia XPF, our cross-platform compatibility layer for WPF. These are products with digital elements that we place on the EU market as part of commercial activity, which makes us a manufacturer under the CRA in the plainest sense, subject to the very obligations this series describes. We are not writing about someone else's compliance problem. We are writing about ours.
We are also open source, which pulls us into the CRA from the opposite end. The framework is MIT-licensed and free, built in the open by a community, and that puts us inside the conversation about maintainers, open-source stewards, and the projects that thousands of commercial products quietly depend on. We have skin in that game too, and a direct interest in the steward rules.
Our customers are manufacturers, and we sit inside their products as a dependency. The people who develop with Avalonia are shipping cross-platform desktop, mobile, and embedded applications on Windows, macOS, Linux, iOS, Android and WebAssembly, into industries like industrial control, medical, finance and energy. Many of those applications are products with digital elements in the precise sense the CRA means, and many run on hardware that will sit in the field for years. Avalonia XPF exists to take long-lived line-of-business and industrial WPF applications to new platforms without a rewrite, and long-lived connected software is exactly the population the CRA's support-period and vulnerability-handling rules were written for. When our customers do due diligence on their dependencies, we’re one of them, so their CRA problem is ours a second time over.
So this is not a detached explainer written from a comfortable distance. It’s the guide we needed for ourselves, from every angle at once, shared because you probably need it too.
Closing thoughts
The CRA is large, and in places it is frustratingly verbose, but it’s not beyond understanding, and it is emphatically not a reason to retreat from the European market. It’s a reason to build the way good engineers have always wanted to build in the first place, securely, deliberately, with an eye on the whole life of the product, and then to write down that you did. Most of what the Regulation asks for is the discipline you already wished you had time for. It simply makes that time non-optional.
We think the CRA is good for the industry. Software has enjoyed a liability holiday that no other engineered product has ever been granted, and it has shown. More secure and better-supported software is a net win for everyone who builds it, sells it, or depends on it, and that includes every last one of us. A regulation that lifts the baseline, and rewards the teams who take security seriously, is not an enemy of good engineering. It is an overdue ally.
Over the coming months, we will publish the rest of this series, working through the CRA one audience and one obligation at a time: what it means for open-source maintainers, what it asks of manufacturers, where it meets the AI Act, the dates that actually matter, how to build a vulnerability-handling process, and how support periods and substantial modifications govern the whole life of a product. We aim to help you understand the CRA and be ready for it, well before the deadlines make readiness urgent.
*This article is part of AvaloniaUI's series on the Cyber Resilience Act for .NET developers. It is general information, not legal advice; the authoritative text is Regulation (EU) 2024/2847 and, where relevant, the European Commission's official guidance. *