It is a current development of some fascination as the vast, fundamentally impossible scope and basic objective of a lawfare wreck unfold. The EU Cyber Resilience Act (CRA) was begun several years ago as the most ambitious cybersecurity regulatory regime ever pursued to assert European leadership in the domain of cybersecurity. The Act attempts to assert jurisdiction over all “digital elements” (devices, software, remote processes) entering the European market and impose an incomprehensible, expansive regulatory regime on all providers (manufacturers, distributors, importers, developers) under the threat of enormous fines and vicariously pursue the fundamentally impossible—“to make sure all digital products are safe from cyber threats.”

The CRA also upends human rights norms in the process. For example, under the CRA regime, an EU citizen is prevented from obtaining a non-conformant digital product through supply-side enforcement mechanisms. The CRA distributes strict legal accountability across the entire supply chain. If a manufacturer creates a non-conformant product, intermediate parties are legally required to block it. The result is a European Union CRA Firewall.

Sixty years ago, the National Security Agency (NSA) and the RAND Corporation at the outset of digital computer networks collaborated for more than a year and at the first public cybersecurity conference in 1967 articulated the two fundamental Peters-Ware principles. Cybersecurity per se is not possible. The degree of achievable cybersecurity varies significantly by context and is determined by resources applied—largely by end-users. Hundreds of major programmes and developments over the past six decades have reaffirmed these fundamentals and the art of the achievable.

For cybersecurity historians, the EU CRA replicates in a mammoth public legal regime the attempts forty years ago by the NSA to improve cybersecurity in a much simpler world. It did not end well. Today, CRA has emerged as the sum of all cyber law foibles. Its failure provides an opportunity for lawfare analysts to examine the forensics of its unfolding demise for lessons learned and not repeated.

Lawfare Elements and Dependencies of the CRA Regime

The exercise of such an omniscient regulatory regime necessarily required the creation of a full arsenal of new regulatory mechanisms. The final CRA enactment is a 336-page document formally adopted by both EU legislative bodies on 10 October 2024 that includes 130 explanatory recital statements, 71 implementing articles and 7 annexes that are extended by reference to thousands of pages of normative requirement obligation standards. The universe of “digital elements” is further subdivided to distinguish 20 specific “important services” and 5 “critical services”. Several specialised domains such as medical devices, transportation systems, and national security products are excluded.

The CRA overreach as to those obligated is extraordinary. The provisions apply not only to “product manufacturers” but also extend to distributors and importers into the EU market, for example, telecommunication providers and cloud data centres. A “manufacturer” is defined as any “person who develops or manufactures products with digital elements or has [them] designed, developed or manufactured, and markets [them] whether for payment, monetisation or free of charge”. The boundaries of what constitutes code are especially blurred in the realm of Artificial Intelligence. The CRA sweeps what in many jurisdictions is protected expression within its penumbra.

The regulatory components included extensive product requirement obligations concerning every aspect of a product lifecycle and implemented through hundreds of conformity certification, notification, reporting, surveillance, enforcement, and penalty provisions. The European Commission is given broad authority to implement the Act, including outsourcing the necessary product requirement obligations and conformance technical standards, altering the provisions, engaging with the 27 EU Member States to instantiate the regime, and harmonising the provisions among overlapping EU regulatory regimes, including notably the AI Act.

The scores of CRA baseline product requirement obligations and conformance certification standards are vastly extended through standards deliverables incorporated by reference via the CRA Annexes. These obligations and certification standards are extended potentially multiple times still further through additional seriatim incorporations by reference of still more provisions to constitute an essentially incomprehensible set of legal requirements imposed extraterritorially on much of the vast amorphous digital universe.

Accomplishing such an expansive regime is no small task and has multiple dependencies that include: 1) outsourcing drafting of additional detailed product requirement obligations and conformance certification standards for 41 cybersecurity requirements to two standards bodies, 2) creating the necessary array of secure IT infrastructure to support the reporting and sharing requirements, 3) meeting EU human rights norms, 4) harmonising the CRA provisions with dozens of overlapping EU regulations, 5) obtaining and managing cooperation for CRA implementation among all the EU Member States and foreign jurisdiction, and 6) passing judicial muster before the European Court of Justice (ECJ.

Unfolding Lawfare Forensics of the Train Wreck

Preludes

The expansive CRA regime began to fray near the end of the legislative process. The rapidly growing, critical sector of relatively amorphous open-source software required a number of “patches” that includes voluntary developer conformance attestation as well as the concept of an “open-source software steward” to assume some regime responsibilities. With the continuing rapid expansion of huge free cloud-based open-source software services such as GitHub or GitLab with 250 million “producers” distributed worldwide, the CRA regime essentially implodes for this now enormous market segment even if the requirements in theory still exist.

Another vexing definitional regime patch that was never completed involves exercising jurisdiction over the rapid virtualisation of digital elements globally in distributed cloud data centres. The ephemeral nature of these products that might evolve and re-instantiate by the nanosecond clearly tests the rationality and implementability of the CRA regime. These services have become essential across the marketplace—especially for small providers. The result was a CRA legislative creation of something denominated as “remote data processing solutions” or RDPS. Subsequently developing implementation standards, however, is highly problematic.

The third significant legislative patch that continues to vex the CRA regime is the practice of hardware and software “nesting” of components in a completed digital product assembly. The cybersecurity knowledge base and effective vulnerability solutions can become enormously complex with many constantly evolving hierarchical layers for digital products. Nascent efforts to create Software Bills of Material (SBOMs) have proven problematic in terms of efficacy and implementability on any significant scale. Nevertheless, multiple SBOM requirements were added to the final text. The SBOM implementability challenge complexities have significantly worsened with the emergence of Foundational AI which speeds up the dynamics of software vulnerability knowledge.

The fourth legislative patch remains at the forefront of rationality of the CRA regime—making available knowledge of vulnerabilities and software patches in a manner that does not exacerbate cybersecurity threats or reduce incentives to develop software patches. Although the text was adjusted in an attempt to balance the equities, the emergence of recent Foundational AI capabilities profoundly affects cybersecurity practices and rendered legacy certification-based schemes essentially worthless.

Another major cyber legal development never made it into the CRA legislation because the impact was profound. Led by the NSA’s former highly-respected CIO/CTO, Prescott Winter, the President’s National Security Telecommunications Advisory Committee in February 2022 delivered its report on Zero Trust and Trusted Identity Management. The proposed Zero Trust Model (ZTM) mandate was adopted as a new transformative approach to cybersecurity and cemented into place by Executive Order and then the Five Eyes Alliance of security agencies, and applied globally. The ZTM approach taken differs significantly from the CRA’s “cybersecurity is possible and can be achieved by certification approach”.

The last major CRA prelude occurred in Europe’s highest judicial body—the European Court of Justice (ECJ). The far-reaching judgment in the Public.Resource.Org case on the transparency of technical standards adopted by reference was handed down on 5 March 2024—the same month the CRA was approved by the European Parliament. The Court noted it already held “that a harmonised standard, adopted on the basis of a directive and the references to which have been published in the Official Journal of the European Union, forms part of EU law owing to its legal effects.” It also noted that “the right of access to documents of the institutions, bodies, offices and agencies of the Union” was guaranteed to all EU citizens and residents under the EU Charter of Fundamental Rights.

Going further, the Court noted that “the principle of transparency is inextricably linked to the principle of openness, which is enshrined in the [EU treaty].” It found that “the Commission should have acknowledged, in the decision at issue, the existence of an overriding public interest…arising from the principles of the rule of law, transparency, openness and good governance, and justifying the disclosure of the requested harmonised standards, since those standards form part of EU law owing to their legal effects.”

The effects of the Judgment on CRA implementation going forward thus became significant because the CRA largely relied on the adoption of such technical standards. The activities were not only required to be more transparent, but the practice in the past by CEN/CENELEC of simply repurposing ISO/IEC paywall standards became unlawful. Over the ensuing months, the Public.Resource.Org Judgment was frequently ignored or circumvention attempted by indirect referencing.

Outsourcing Additional CRA Requirement and Certification Standards

As noted above, the principal initial CRA dependency involved outsourcing the product requirement obligation and conformance certification standards extensions on which the regime is constructed. This entailed EC outsourced drafting of these deliverables via a formal Standardisation Request (SR) to two private bodies designated as European Standards Organisations (ESOs)—CEN/CENELEC (which operates as one entity) and ETSI.

The standards deliverables are denominated Harmonised European Norms or hENs in support of CRA obligations imposed on manufacturers. In effect, the ensuing drafting activities operate as an extension of the regulatory process and constitute CRA law by reference. The two private industry organisations were co-opted into undertaking the work for which they received financial compensation.

Forty-one legislative extension deliverables were requested and further described in the associated Standardisation Request annex—18 “vertical” standards from ETSI and 15 “horizontal” plus 8 “vertical” ones from CEN/CENELEC. The latter’s horizontal deliverables were subsequently reduced to four.

The terms horizontal and vertical are terms of art where the former consist of provisions applying broadly to all products, while the latter apply only to specific described products or markets. The EC Standardisation Request underscored that there were public interest considerations in the work and that the organisations should “ensure fair and diverse participation” and “the utmost transparency should be ensured” and that “particular account should be given to the needs of the free and open-source software community” and deliverables be subject to public consultation. The admonition proved challenging.

The EU’s failure to evolve its recognition of normative standards bodies over the past four decades also exacerbated the legislative extension challenges. Over that period, cybersecurity standards development became distributed across a highly-diverse array of new tailored standards organisations. However, the only recognized European Standards Organisations are CEN/CENELEC and ETSI. This legacy practice is exacerbated by CEN/CENELEC customarily using almost only paywall standards created by a small number of additional bodies with which it has strong financial relationships and representing a conflict of interest.

Accomplishing these ancillary legislative standards making tasks quickly became a heroic struggle. During an initial period, almost no one from the standards organisations would pursue drafting the requested CRA normative deliverables in their technical committees. This impediment resulted in special EU Standardisation Request groups being established consisting largely of authors paid out of a 1.5 million Euro fund to prepare the deliverables and evangelise the CRA to the public. Many of the authors were employed by certification companies that potentially benefitted significantly from the normative provisions they were writing.

Dozens of drafting groups were created that held meetings continuously over more than two years, generating many hundreds of documents and iterative versions of the deliverables. The meetings were lightly attended by anyone other than those being funded by the EC. The CEN/CENELEC deliverables continued to reference almost only paywall standards.

The resulting drafts were demonstrably inadequate as implementable secure-by-design standards—in some cases referencing outdated technical practices. Notably, they also grew to enormous size with highly prescriptive normative content—currently reaching a current aggregate of more than 3,500 pages of specifications containing more than 7,000 normative requirements. Nineteen of the deliverables from CEN/CENELEC are yet to be made available—disregarding transparency obligations. Typical reactions by independent reviewers in the EU are that they are too prescriptive, not providing enough flexibility, and not supporting appropriate risk-based decisions for the broad range of products in its scope, thus not fit for purpose.

By relying on rigid certification requirements cemented into law—an approach which has proven dramatically ineffective over many years. Additionally, the CRA regime also lacks provisions for testing and easily changing the obligation standards—a major deficiency in a the rapidly evolving digital technology sector. The frozen-in-time deficiency became prominently visible with the recent emergence of Foundational AI tools producing exponential increases in vulnerabilities for which capabilities to identify Known Exploitable Vulnerabilities (KEVs) are essential. The deficiency has also become apparent with the explosion in open-source products globally hosted on free provider sites, with the developers exceeding 250 million—all of whom appear obligated to comply with the CRA regime and distributors obligated to block delivery of non-compliant products to end users.

The unfolding inadequacies and foibles in this effort were also avoidable. Early on in one of the key committees of the standards drafting effort, a major provider proposed the adoption of the NIST Secure Software Development Framework (SSDF) that is mature, effective, and widely implemented globally. The proposal was rejected. What ensued instead was two years encompassing hundreds of sparsely attended meetings to review nearly two thousand documents to produce four inadequate draft specifications that have yet to be even accepted.

Notification Process Dependencies

The EU CRA legislators cemented into the resulting provisions an array of notification processes—many of which simply do not scale and not capable of implementation. Two of the currently prominent requirements in effect as of 11 September 2026 compel all the parties subject to CRA obligations to register a “representative” and report within time periods as short as 24 hours, “any actively exploited vulnerability contained in the product with digital elements that it becomes aware of” and “any severe incident having an impact on the security of the product”. The reporting is mandated through a Single Reporting Platform (SRP) that requires manual keystroking of extensive information. These new CRA requirements were mandated notwithstanding the existence of multiple other long-existing national and private sector databases that attempt to meet the challenges of obtaining, evaluating and disseminating this information. No SRP usage metrics are being provided.

No apparent consideration was given to the reality that all the products with digital elements and remote data processing solutions entering the European market approach infinity, the numbers of producers are largely autonomous and in the tens of millions, and the numbers of discovered vulnerabilities and incidents per day are enormous and growing rapidly. Other imposed notification requirements are similarly excessive and largely unimplementable. Yet the CRA mandates such actions under threat of enormous financial penalties.

Emerging CRA Dependency Challenges

Four additional emerging CRA dependencies exist. Each faces significant challenges. They remain to be faced over the coming months.

Complying With Human Rights Norms

Long-standing fundamental legal norms concerning proportionality, transparency, competition, and human rights are visibly abridged or were flaunted by the CRA provisions and subsequent implementation actions.

The most basic of these abridgments concerns the vicarious application of the CRA to everything, everyone, everywhere—known as overreach. The CRA applies to every digital object and remote process in existence. It imposes an endless, incomprehensible array of obligations to everyone in the ICT supply chain, from developers writing code to customer internet access providers and cloud data centres who are obligated to prevent the delivery of non-compliant products to European end users—who are the parties that principally control cybersecurity. It implements an extensive array of highly intrusive market surveillance and enforcement powers by designated national authorities. For example, CRA Art. 60 requires “market surveillance authorities and designees shall conduct simultaneous coordinated control actions (“sweeps”) of particular products with digital elements or categories thereof to check compliance with or to detect infringements to this Regulation, including under a cover identity, to verify the compliance.”

The vicarious lack of proportionality is represented in the EU legislators’ initial estimate that at least 615,000 manufacturers faced 29 billion Euros of recurrent compliance costs, knowing full well that cybersecurity is primarily dependent on end-users rather than manufacturers. No cost-benefit to assess the efficacy of what was required, or competition assessments were done by anyone in the CRA legislative processes, including standards making.

Transparency in the development of technical implementation standards was substantially missing, with 7,000 implementation standards requirements articulated across nearly 4,000 pages of standards. Venues developing these standards over more than two years produced more than 10,000 documents in several thousand meetings—frequently referencing paywall standards that were not available and non-compliant with the Public.Resource.Org ECJ Judgment on transparency.

Harmonising All the EU Regulatory Regimes

At present, the EU has several hundred different ICT regulatory enactments with different requirements and processes. There is a common desire to harmonise all these diverse requirements that is expressed in the CRA. The ability to accomplish this activity is problematic at best and potentially adversely affects compliance with human rights norms because it is more difficult for those subject to CRA obligations to understand what is required of them. The EU AI Act and CRA overlaps are significant and unresolved.

Obtaining Cooperation of EU Member States and Foreign Jurisdictions

An extensive, complex administrative infrastructure with rules among all the EU agencies and Member States has only begun to be formed. Getting the 27 EU Member States and their citizens to implement the CRA regime is highly problematic and likely to be unacceptable because of the significant adverse economic effects and impact on the rights of citizens.

Because the vast preponderance of digital elements, remote processing and providers exist outside the EU, the effective implementation of most CRA requirements depends on the willingness of foreign jurisdictions to form mutual recognition agreements with the EU. However, it is apparent that few, if any, other jurisdictions would entertain such a regulatory regime—which would result in shifting of cyber products and manufacturers away from the European Union and diminishing innovation.

Passing Judicial Muster

At some point when enforcement of the CRA provisions occurs against specific parties, sufficient causes of action will arise to obtain standing in the EU judicial system. The EU’s formative treaty instrument contains numerous requirements and safeguards relating to proportionality, transparency, competition, and human rights.

The European Court of Justice (ECJ) was also established to ensure legislative and administrative abuses remained such as those evident in the CRA and its subsequent implementation, remain checked. There is also ample evidence that is apparent or easily discovered. When CRA enforcement occurs, the sheer breadth of the CRA and its excesses ensure that many potential litigants will be seeking judicial action and financial compensation from those involved.

Lessons Learned

Although the lawfare “wreck tolerance” for the EU CRA seems large, it will—either through subsequent legislative or judicial action—alter its course of action. Ultimately, the CRA’s principal legacy as the sum of all cyber law foibles is the lessons learned and hopefully applied in the future.