1. The CRA – a policy analysis

The Commission explored four policy options for CRA-appropriate regulation.Footnote ³⁶ Out of these, the third and fourth options were NLF-based, diverging in what would form CRAs material scope. Finally, the Commission opted for the fourth option with a broader scope.

Considering the questions in NLF-consultations, does the CRA also modernise the NLF template? This points to the first difference, i.e., regulatory objectives pursued. The “how” is still product approximation; the “why” is more nuanced. Consistent with NLF, products with digital elements (PDEs) must meet essential requirements to enter the European market. However, CRA requirements are for cybersecurity rather than, conventionally, for product safety. This is a first for NLF-style legislation. While NLF-style legislations have been supplemented by cybersecurity recommendations such as guidance documents,Footnote ³⁷ a product legislation solely about cybersecurity is novel.

The second difference is scope. As expected from NLF-based legislation, it places “high level” entry requirements for products – using an apt “pre-market regulatory logic.”Footnote ³⁸ While this is reinforced by the CRAs material scope, i.e., PDEs, it is designed as a product cybersecurity lex generalis that includes products yet unlegislated for – consisting of most hardware and software products.Footnote ³⁹ The CRA was proposed anticipating two issues; there being no EU legislation dealing with PDE cybersecurity and pre-emptively preventing fragmentation in national legislations on PDE cybersecurity.Footnote ⁴⁰ Such a legislation is bound to have an expansive material scope.

This scope includes all PDEs – hardware and software – and components thereof, thereby including IoT devices.Footnote ⁴¹ This casts a two-fold net. Firstly, it recognises the interconnected nature of PDEs while still regulating them “individually.” Secondly, it has been argued that such a scope is well-suited to address dynamism in threats.Footnote ⁴² This net may be thusly interpreted. Firstly, an instance of horizontal regulation, rather than sectoral legislation, being considered more appropriate for cost-effective product cybersecurity. This stems from the NLF route being chosen for its ability to regulate the entire PDE supply-chain and lifecycle through one legislation.Footnote ⁴³ NLF-style regulation is also considered fitting since the CRA complements an overarching cybersecurity framework in coverage and fosters easier compliance.Footnote ⁴⁴

These may be strong reasons favouring an unconventionally broad-scoped NLF-style legislation – CRA designed as lex generalis being instrumentalFootnote ⁴⁵ – but divergence from earlier NLF legislation is pronounced. Older NLF legislation (except the Machinery RegulationFootnote ⁴⁶) has focused on prescribing essential requirementsFootnote ⁴⁷ for specific products.Footnote ⁴⁸ Contrarily, newer legislations intended for broader swathes of products contain scope carve-outs instead.Footnote ⁴⁹

2. Scope differences deconstructed

This subsection addresses the first reason adduced for NLF-based cybersecurity legislation – efficient supply-chain and product lifecycle regulation. The product supply-chain here involves pre-market considerations such as securing PDE components. The product lifecycle involves post-market considerations like ensuring PDE cybersecurity throughout reasonable use periods.

First, engaging with the more prominent reason, i.e., efficiency. Here, efficiency is better understood as a relative construction rather than an absolute one. This bolsters analysis by keeping the research CRA centric, avoiding digressions into contextual interpretations of the term and qualifying argumentation supporting the CRAs large scope, allowing more detail.

Efficiency is seen as added value for stakeholders across regulatory and market spaces. Common rules claim to make business easier by homogenising requirements and easily scaling up market surveillance by disambiguating cross-border transactions. Joint-surveillance becomes cost-effective, arguably evening the playing field – both in product safety (with the GPSR) and in product cybersecurity (with the CRA).Footnote ⁵⁰

Harmonised cybersecurity requirements apply both pre- and post-market.Footnote ⁵¹ Pre-market, efficiencies lie primarily in securing product development supply chains. These include numerous hardware and software components – a complex multi-tiered web of actors designing and developing PDEs.Footnote ⁵² The CRA mandates PDE manufacturers to maintain records of this web and possible vulnerabilities in each node through Software Bills of Materials (SBOM) – a detailed inventory of components used in building software.Footnote ⁵³

SBOMs are useful in differing capacities throughout a PDEs life-cycle. Pre-market, it is a record of components and known vulnerabilities, acting as a safeguard for potential consumers through its inclusion in mandatorily published technical documentation.Footnote ⁵⁴

CRA-mandated SBOMs could increase efficiency; value-addition driven by increased clarity and legal certainty throughout the development supply-chain. Such supply-chain wide cybersecurity is itself novel,Footnote ⁵⁵ first prescribed legislatively in the NIS2 Directive.Footnote ⁵⁶ Therein, “supply-chain cybersecurity” requirements are addressed,Footnote ⁵⁷ but not as in the CRA. NIS2 requirements focus on certain sectors of market operators and their operations, not PDEs specifically. Since this section examines CRA’s supply-chain security and related efficiencies, it is an actors-based examination, not limited to market operators.

3. Examining efficiency – pre-and post-market

CRA obligations apply to manufacturers of (and less extensively, other economic operators dealing in) PDEs.Footnote ⁵⁸ Pre-market, obligations include secure risk-based PDE design, development and production, process documentation, followed by an assessment of the final products conformity.Footnote ⁵⁹ Hence, relevant actors pre-market are manufacturers and bodies (notified by Member States) that assess PDE conformity.

From a manufacturer’s perspective, value-addition comes from legal certainty. Annex I provides essential requirements for PDEs; forming positive obligations about the “condition” in which a PDE is brought to market, the manner of operation in use and a record of performing these obligations.Footnote ⁶⁰ These activities may differ based on PDE specifics or use, but the obligation to act persists. Thus, manufacturers must act following PDE-specific risk-assessments.Footnote ⁶¹ Such risk-assessment allows for PDE-specific implementation of generally applicable obligations.

However, burdens placed vis-à-vis implementation capacity must be considered. An important variable affecting implementation is manufacturer size. Specifically, whether obligations are proportionally implementable by small and micro-enterprises (SMEs). In a study supporting the 2022 NLF Evaluation,Footnote ⁶² a cost–benefit analysis of inputs by stakeholders regulated by NLF-style legislations suggests that benefits of harmonised requirements either outweigh or are commensurate to costs, but with a caveat calling attention towards enterprise size.Footnote ⁶³

This regards proportionately heavier costs SMEs may bear due to limited legal staff, lack of in-house testing capabilities and lower relative benefit from smaller scales of production.Footnote ⁶⁴ While the study excludes cost transfer to end-users, it determines that most costs of harmonisation are manufacture-borne, which means proportionately, SMEs bear significantly higher burdens than larger manufacturers in their sector.Footnote ⁶⁵

The second variable is conformity assessment costs. It has been argued that while these costs are NLF-borne, they would be higher in the absence of harmonising legislation.Footnote ⁶⁶ However, these arguments are adduced for legislations with scopes significantly smaller than the CRA. With a broad scope as the CRAs, whether this argument applies re-emerges as a (yet unanswered) question – a much wider group of conformity assessment mechanisms, bodies and competencies are required, affecting implementation costs.

Conformity assessment processes see possible benefits. Firstly, notification procedures require Conformity Assessment Bodies (CABs) to maximise epistemic competence while mitigating conflicts of interest.Footnote ⁶⁷ Secondly, CAB accreditation using harmonised standardsFootnote ⁶⁸ adds value by reducing national divergences. These arguments gain traction since there have been prevalent interpretational differences among notified bodies on safety and procedure and low transparency and red tape in notification procedures.Footnote ⁶⁹ An EU-wide accreditation framework has been dubbed an important achievement. However, challenges persist, e.g., notification being voluntary makes monitoring non-accredited CABs difficult.Footnote ⁷⁰

Post-market, NLF-style laws prescribe market surveillance for continued product conformity. The CRA reflects this; market surveillance is an integral to its obligations. PDE manufacturers must provide continued support for a reasonable time, especially software products.Footnote ⁷¹ It relies on the Market Surveillance Regulation, placing obligations on market operators and national market surveillance authorities.Footnote ⁷² The CRA further specifies market surveillance obligations, augmenting Market Surveillance Regulation provisions,Footnote ⁷³ adapting them to product cybersecurity and streamlining them into the wider cybersecurity framework.Footnote ⁷⁴ It also places coordination obligations with other statutory entities, along with post-market enforcement procedures at national and Union level.Footnote ⁷⁵

Obligations and their allocation seem comprehensive; but resource allocation to MSAs is already a concern.Footnote ⁷⁶ Following the MSRs focus on regulating supply chains, the CRAs material scope requires that Market Surveillance Authorities pay continual attention to not just hardware and software products, but also components. This may be seen as a blessing and a bane. A holistic supply-chain focus could be a significant strength; increasingly complex global supply-chains have been significant regulatory challenges.Footnote ⁷⁷ However, a wider focus brings the challenge of increasing complexity in identifying market operators or supply-chains preceding European market entry.Footnote ⁷⁸ This is especially challenging in IoT devices considering their diversity. While there are CRA measures that may mitigate this problem,Footnote ⁷⁹ their practical adequacy is yet untested.

Both pre-market and post-market, this section indicates that the CRA enhances efficiency and legal clarity through harmonised requirements. However, implementation challenges can be directly traced to its expansive scope of diverse PDEs (in this case IoT devices) whose cybersecurity must be maintained throughout development and usage. This examination further reinforces a concern the Commission speculated upon in their NLF evaluation but overlooked in the following revision initiatives. Specifically, its readiness for (i) “the ability of products to change after being placed on the market” and (ii) “increasing digitalisation and complexity of products” including increasing internet connectivity of products – both IoT hallmarks.Footnote ⁸⁰

Another risk of the broad scope is possible unavailability of conformity assessment avenues once the CRA is applicable.Footnote ⁸¹ Stakeholders consulted within the NLF evaluation voiced concerns that NLF effectiveness would suffer if harmonised standards were not use-ready for assessment once a legislation applies. It also makes market surveillance difficult.Footnote ⁸² The CRA heavily relies on harmonised standards for efficient conformity assessment;Footnote ⁸³ with its immense scale requiring numerous standards, horizontal and vertical. As of writing, some harmonised standards have reached “mature draft” stage, allowing reference for future product engineering decisions.Footnote ⁸⁴

While a “backup” is available in common specifications for IoT products, they are contingent on unavailability of harmonised standards.Footnote ⁸⁵ The three European Standardisation Organisations (ESOs) accepted the Commission’s request for CRA-led standardsFootnote ⁸⁶ in April 2025 and have committed to delivering some standards “at least a year before the CRA enters into application.”Footnote ⁸⁷ The request covers horizontal standards for all PDEs and vertical standards for specific product categories.Footnote ⁸⁸ Horizontal standards must also support development of vertical standards.Footnote ⁸⁹ This broad requirement also means that the anticipated adoption timeline is staggered.Footnote ⁹⁰

In case of standards not being ready on time – an existing concern,Footnote ⁹¹ or not meeting Commission expectations, a need for technical specifications would arise; an endeavour impacted by their techno-centric nature relative to harmonised standards. Alternatively, entry into force itself may be delayed, so delaying implementation of a major pillar of security and competitiveness of the European IoT market.Footnote ⁹² These considerations would significantly impact the “efficiency” the CRA as NLF-style legislation brings to IoT cybersecurity.Footnote ⁹³

4. Testing transparency and fundamental rights protection – user and consumer benefits

The second reason supporting NLF-style cybersecurity legislation is enhanced transparency and fundamental rights protection for PDE users and consumers – seen most directly in vulnerability handling and informational requirements.Footnote ⁹⁴ Transparency refers to clarity about a PDE’s security properties to users, allowing better use. Fundamental rights refer to (inclusively) consumer privacy and data protection.Footnote ⁹⁵

“Transparency” in the CRA is a context-modified manifestation of its general characterisation in European public administration; an initially understandable deviation considering the difficulty of ascribing consistent characterisations to varying policy instruments.Footnote ⁹⁶ The CRA’s view of transparency incorporates awareness among users (consumers or businesses) of PDE security properties, enabling informed purchasing.Footnote ⁹⁷ At a glance appear inroads towards these ends. Essential PDE requirements in Annex I include informational obligations including security-relevant information, vulnerability and supply chain documentation through SBOMs, and reporting.Footnote ⁹⁸ The most user-centric transparency obligations are in Annex II that deals with user-facing information and instructions, including contact instructions and (discretionarily) SBOMs.

While these contribute to transparency, whether this enhancement is attributable specifically to the CRA must be determined. The NLF evaluation report does allude to relative increases in transparency, since most stakeholders consider clarity on using the CE mark as beneficial.Footnote ⁹⁹ However, this enhancement is from the market operator perspective and not necessarily end-user/consumer perspective.Footnote ¹⁰⁰ In the CRA, transparency refers to users having more information rather than clarifying legal ambiguities. The NLF was designed to ensure products entering the European market meet a minimum threshold. While this is a user/consumer safeguard, such transparency contributes usually towards product safety (or in the CRA, cybersecurity).

Thus, added transparency for user/consumers in the CRAFootnote ¹⁰¹ is present. However, it is argued to be incidental to NLF-style legislation rather than being directly attributable to the framework. Regulation 765/2008, the NLFs foundation, aimed for transparent accreditation of conformity assessment bodies; since such harmonisation-led procedural transparency would ease cross-border cooperation and implementation.Footnote ¹⁰² It would be dissonant to expect user/consumer facing transparency requirements from a legislation not aimed at specific products. The argumentation adduced above would be strengthened by examining NLF-style product legislation of the past.

Looking at other NLF-style legislation reinforces consumer-facing transparency being incidental to the product being regulated for and the harmonisation objective (safety, cybersecurity, etc.). Recent NLF-style legislation like the AI ActFootnote ¹⁰³ contains consumer-facing transparency requirements for certain AI systems, but most requirements relate to information exchange between AI developers, deployers and notified authorities. Even the revised regulation on toy safety; a modernisation of the Toy Safety Directive, limits transparency to accreditation and operational procedures for Conformity Assessment Bodies.Footnote ¹⁰⁴ Consumer-facing transparency requirements being contextual to the regulated product is seen through other NLF-style legislation, such as the Medical Devices RegulationFootnote ¹⁰⁵ and the Batteries Regulation.Footnote ¹⁰⁶

Thus, consumer-facing transparency requirements in NLF-style legislation are a relatively new development, with the only consistent consumer-facing transparency measure being the CE mark. However, the mark’s efficacy for consumers is questioned through the Commission noting varying (and often inaccurate) consumer interpretations as one of quality and not conformity.Footnote ¹⁰⁷ Enhanced transparency for consumers would more accurately be a CRA-specific outcome.

From a fundamental rights standpoint, CRA has as a rationale enhanced privacy and data protection for consumers. It defers to the GDPR,Footnote ¹⁰⁸ including to its data protection certification mechanisms.Footnote ¹⁰⁹ Cybersecurity is seen as an avenue to enhance data protection and privacy, evident through data protection principles such as data minimisation, secure access, data erasure and portability being essential CRA requirements.Footnote ¹¹⁰ Requirements for security by design, control mechanisms like access management and an emphasis on security measures like encryption coupled with resilience measures like reporting strengthen intersections between cybersecurity and privacy/data protection.Footnote ¹¹¹

However, this intersection and therefrom developed complementarity in law-driven regulation is also a novel development.Footnote ¹¹² As with any novel development, this intersection results from developments in intersecting elements. The conceptualisation of “personal data” in European jurisprudence has been quite broad, reflecting an intent to cast a wide net in securing data protection rights.Footnote ¹¹³ Additionally, GDPR applies to basically anything that processes personal data, regardless of which product(s) may be used while processing.Footnote ¹¹⁴ Similarly, the CRA is applicable to basically any PDE; placing information security requirements on any “processing” by PDEs. Prima facie the complementarity between GDPR and CRA is clear, but a closer look reveals tensions.

Illustratively, data protection being potentially conflicting to operation of data-intensive network-security systems has been noted even before the CRA was adopted.Footnote ¹¹⁵ More generally, while product cybersecurity intends to bolster data protection, implementing broad tech-neutral security requirements that are often data-intensive can concurrently jeopardise data protection.Footnote ¹¹⁶

Thus, the CRAs claimed enhancement of fundamental rights protection for consumers would still be debatable. When analysed from an NLF lens, establishing a specific fundamental rights protection outcome is still case-based. The GDPR is not an NLF legislation but can be seen akin to the NIS2 for data protection, as it regulates operations of entities processing personal data. Similarly, the NIS2 places operational obligations on market operators. Secondly, resonant to earlier transparency argumentation, enhanced protection of fundamental rights is a construction not directly attributable to the NLF but a function of products being harmonised.

5. Synthesis

Choosing broad-scoped NLF regulation for product cybersecurity may be considered a response to the NLFs effectiveness concerns in an increasingly digitised product landscape.Footnote ¹¹⁷ The Commissions focus has expanded from smooth movement of goods to also accounting for product usage (seen from intended use-based classifications and expanding material scopes) to reinforce stakeholder confidence in the market.Footnote ¹¹⁸ It is also influenced by observations of increasing prevalence of services within products (often through non-embedded software). This blurs the line between “goods” and “services.”Footnote ¹¹⁹ Securing network infrastructure and data processed within secures associated services and enhances their resilience.

Regulating product cybersecurity obligations through a Regulation instead of a Directive more effectively addresses identified problems through direct application to products, additionally mitigating fragmentation by circumventing Member State discretion employed while transposing Directives.Footnote ¹²⁰ These benefits are overt but result from direct effectFootnote ¹²¹ of EU Regulations.

The CRA does bring benefits across the PDE supply chain. They however stem from there finally being an EU legislation harmonising product cybersecurity, not from the framework used. Furthermore, from intersections between cybersecurity and data protection, the broad-scoped and technologically neutral approach for product cybersecurity built upon the NLF has potential detrimental effects in the absence of clearer legislative direction.Footnote ¹²²

Therefore, a clearer delineation between relative benefits of the NLF as a “legislative template” vis-à-vis the objective benefits of the subject matter being regulated is desirable. Whether the NLF brings benefits in regulating products is not in question, whether the benefits associated to NLF-style legislation are solely an NLF outcome is. To further add clarity, this article now explores regulatory objectives, i.e., safety and cybersecurity, the second part of this article.

1. Safety and cybersecurity as risk-regulation foci

First, an understanding of safety as an objective of risk-based regulation. The GPSR characterises safety as “a lack of/mitigated risk to the health and safety of the consumer of a product when a product is used as intended including reasonably foreseeable uses.”Footnote ¹²⁶ Thus, safety is a products’ state of existence when used appropriately.Footnote ¹²⁷ Use “as intended” also forms an important aspect; the basis upon which risks are assessed.Footnote ¹²⁸

The existence of a product in a usable manner, free from unsafe substances or health risks makes it safe.Footnote ¹²⁹ Risks represent a combination of a hazard’s probability and its severity, when a product is used as intended.Footnote ¹³⁰ Thus, while safety is inherently risk-based, it also acknowledges that a product without risks is practically impossible.Footnote ¹³¹ Hence, risk-mitigation informs the GPSR’s core notion of a safe product. In EU product regulation, safety means existence with minimal (not zero) risk.

Cybersecurity finds itself part of this dynamic, seen in the GPSR contributing to safety.Footnote ¹³² An argument could be made for product cybersecurity being just an element of safety were it not for the Cybersecurity Act and CRAs intersection. It is a manifestation of cybersecurity not being considered a singular regulatory concept in EU digital regulation and thus having multiple varying but valid conceptualisations.

At the core of these conceptualisations lies a singular understanding, that cybersecurity fundamentally is a characteristic of digital infrastructures, agnostic to contexts of use, but essential to the resilience of every use.Footnote ¹³³ Unlike purely analogue infrastructures, however, digital infrastructures are fluid; the transmission of data underpinning their value rather than the hardware on which they function. As a characteristic of fluid infrastructures, it would only be prudent for cybersecurity to have fluid conceptualisations as well. While safety is an inherently static concept, regulated for through safety prescriptions for every static component physical infrastructure, how does one secure “components” to whom fluidity is essential? The Commission seems to have attempted this through regulating its foreseeable fluid contexts.

The NIS2 Directive enhances cybersecurity in the context of market operations conducted using digital infrastructures, obliging relevant market operators to make cybersecure decisions in their operations and obliging Member States to build robust regulatory architectures at the national level.Footnote ¹³⁴ The Cybersecurity Act approaches cybersecurity in the context of ensuring epistemic expertise and coordination at the Union level, while preventing possible national level fragmentation through a Union-wide certification framework.Footnote ¹³⁵ The Cyber-Solidarity Act addresses cybersecurity from the context of institutional security, providing for European-institutional level frameworks and coordination mechanisms to ensure inter-institutional resilience and post-incident solidarity.Footnote ¹³⁶ Finally, the CRA addresses cybersecurity in the context of digitally-enabled products, devices used in diverse contexts by the market operators and institutions mentioned hereinabove, and also by consumers.Footnote ¹³⁷ Thus, the CRAs approach to cybersecurity is context-agnostic; CRA obligations are not driven by who uses these devices. Its approach is function-driven, justifying a risk-based purpose-driven regulatory approach; something characteristic of NLF-style legislations. It is this risk-based product-bound cybersecurity context that the current article explores.

The CRA solidifies product cybersecurity as a harmonisation objective at the same level as product safety even without specific mention in Article 114(3) TFEU. Cybersecurity, generally, is seen as impacting Union economy, consumer health and safety. Summarily, cyberattacks negatively impact the economy,Footnote ¹³⁸ making cybersecurity and, specifically product cybersecurity, a necessity. Thus, how cybersecurity is characterised is the next aspect to explore.

In defining cybersecurity, the CRA defers to the EU Cybersecurity Act, defining cybersecurity as “the activities necessary to protect network and information systems, the users of such systems, and other persons affected by cyber-threats.”Footnote ¹³⁹ IoT would be included within “network and information systems.”Footnote ¹⁴⁰ While this definition doesn’t offer unambiguous phrasing, the Cybersecurity Act characterises cybersecurity as the activity of protecting network and information systems (PDEs/IoT), their users and other persons from cyber-threats. It defines “cyber-threats” as “any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons,”Footnote ¹⁴¹ basically a “cyber-risk.” This phrasing reaffirms product cybersecurity as a risk-based concept.

Cybersecurity and related concepts like cyber-resilience have been in flux,Footnote ¹⁴² especially as regulatory objectives. Attempts at concrete conceptualisations have also had outcomes that suggest cybersecurity may remain a fluid concept until, consequent to increased digitisation, it becomes akin to holistic security.Footnote ¹⁴³ Legally, conceptualisation attempts arrive at an impasse between practice-based and theoretical constructs.Footnote ¹⁴⁴

Papakonstantinou conceptualises cybersecurity first as a legally mandated set of practices regulatees must perform to achieve a “state” of cybersecurity; basically a sphere of protection within which consumers/users operate securely while doing their part in maintaining this cybersecure state.Footnote ¹⁴⁵ Erstwhile EU legislation may have suggested an intent to guide EU cybersecurity practices towards achieving such a “state,”Footnote ¹⁴⁶ the CRAs handling of PDE cybersecurity calls for a refreshed legal perspective.Footnote ¹⁴⁷

Pre-CRA cybersecurity legislation has often reflected a shifting approach to regulatory solutions, from regulating for technical objectives to using instead a rights-oriented approach. The reasoning is that legislation is now building the “state” of cybersecurity to make users virtually immune to cyber-threats.Footnote ¹⁴⁸ With the CRA, there are considerations deviating from this perspective.

The simple semantic difference between PDE cybersecurity and cyber-resilience would be that the former reflects an ability to defend, whereas the latter reflects continuity despite adverse event(s), each characterised as a function of the other in various EU laws.Footnote ¹⁴⁹ Bygrave, however, argues that trends in EU law point towards cyber-resilience being considered a facet of cybersecurity, not in a hierarchical but complementary manner. This argument stands on three pillars. These are (i) increasing prevalence of “security by design” in EU law – a notion that promotes initial security considerations, (ii) a legal presumption that ICT infrastructures will inevitably face threats and (iii) a visible move towards adaptive and iterative cybersecurity, evidenced by life-cycle focus of product cybersecurity.Footnote ¹⁵⁰

Cybersecurity per the CRA supports this notion. While the CRA does not define its namesake concept, elements of “cyber-resilience” are almost ubiquitously present. “Security by design” as a guiding principle sets requirements for developing inherently secure PDEs.Footnote ¹⁵¹ While the phrase does not see much use in text, the first requirement within Annex I, of PDEs needing to be “designed, developed, and produced” in a manner that provides risk-appropriate cybersecurity makes it evident.Footnote ¹⁵² Presumption of inevitable cybersecurity threats is also in the text, overtly through requirements of vulnerability handling and management, incident resilience and impact mitigation, both in the product and its operating environment.Footnote ¹⁵³ Arguably, adopting data protection principles such as data minimisation, data removal and secure data transferabilityFootnote ¹⁵⁴ fosters resilience through damage minimisation. Iterative cybersecurity is demonstrable through requirements on security updates, access controls, vulnerability remediation, testing, etc.Footnote ¹⁵⁵ Thus, cyber-resilience is, indeed, an indispensable part of product cybersecurity. However, cyber-resilience’s indispensability to PDE cybersecurity reinforces the notion of cybersecurity remaining praxes to optimally manage threats. After all, a resilient infrastructure is unnecessary if risk itself is eliminated. This also necessitates using risk-based legislation to deal with PDE cybersecurity – i.e., the CRA.

In summation, PDE safety and cybersecurity are similarly constructed in EU law. Both assume inevitability of risk, employing mitigation rather than elimination. Both limit risk to intended and reasonably foreseeable use. Considering these similarities, using the NLF – a framework conventionally used to regulate for safety – seems fitting in an IoT cybersecurity context. However, one must also test differences between these concepts and their management in NLF-style regulation.

2. Safety and cybersecurity – differences between the two concepts

Product safety itself merits deeper exploration, noting its relative maturity as a regulatory objective.Footnote ¹⁵⁶ This article limits itself to IoT, building a contemporary perspective on PDE safety insofar as its differences with PDE cybersecurity.

A prominent difference is the medium for harm prevention employed respectively. Safety relies on minimising possibility of physical harm upon users/consumers during normal use.Footnote ¹⁵⁷ Harm being primarily physical in nature is established through concurrently reading the new Product Liability Directive – liability is determined based on damage to natural persons by defective products, and damage can be interpreted as physical through the Directive’s aim being increased protection of health and safety.Footnote ¹⁵⁸ Generally, product safety focuses on prevention of detrimental effects to health,Footnote ¹⁵⁹ either through product requirements (like in NLF-adjacent legislations) or through liability regimes (like in the Product Liability Directive). The underlying idea remains protecting human physical integrity. Preventing harm therefore is protecting physical integrity.

Product cybersecurity prevents consumer harm differently. Prominent therein is the object(s) of protection. Risks to physical safety by inadequate cybersecurity are increasing with IoT proliferation, making cybersecurity an important safety consideration.Footnote ¹⁶⁰ However, that is not what product cybersecurity addresses directly. As explored in Section 3.1, it protects digital infrastructures. The Cybersecurity Act characterises cybersecurity as the protection of digital infrastructures (network and information systems), businesses (users) and natural persons (users and other persons affected).Footnote ¹⁶¹ Preventing harm to persons is an essential but not proximal objective.

Consumer health forms one in multiple public interests the CRA seeks to protect from cyber-threats. While IoT’s ubiquity exponentially increases the risk of cyber-threats hampering consumers’ physical integrity, a cyberattack is not a direct physical threat. A technological layer of mediation links cyber-incidents and physical health. It is this layer the CRA regulates. CRA product requirements move towards securing digital infrastructures transmitting data. The likelihood of these digital infrastructures having an impact on consumer health is noteworthy, since the CRA is risk-based.

Firstly, PDEs that, post intended purpose-based risk-assessment, have a high risk of adversely impacting user health or safety if directly manipulated are categorised as “important” requiring stricter conformity assessment.Footnote ¹⁶² Most product categories are identified thusly for their high likelihood to impact other PDEs or networks, increasing likelihood of impacting human health, but indirectly.Footnote ¹⁶³ Additionally, per the Commissions reasoning, most PDEs would not classify as “important” or critical,Footnote ¹⁶⁴ further limiting the reach of cybersecurity regulation directly impacting physical protection. While CRA requirements further other forms of harm prevention by protecting digital infrastructures (e.g., economic harm caused by digital infrastructure breaches), furthering physical integrity seems more derivative than focal.Footnote ¹⁶⁵

The next difference is cybersecurity’s iterative nature. Both concepts use the precautionary principle, with risk-assessments (premarket) and risk-management (post-market/life-cycle).Footnote ¹⁶⁶ The iterative difference lies in risk-management. PDE cybersecurity, while mitigating life-cycle risks, must remain adaptive to emerging threats and vulnerabilities.Footnote ¹⁶⁷ Product safety is more focused on pre-market risk mitigation. For, e.g., GPSR requirements are not nearly as iterative, since post-market risk mitigation has broader deference to MSR, whose mechanisms regulate post-market compliance management and reporting.Footnote ¹⁶⁸ Unlike the CRA, there are no requirements regarding continuity, updates or the hereinabove explored resilience in the absence of connected continuous services. While the NLF has been used for product safety in the conventional static manner, this is the first instance of its use for an inherently iterative product characteristic.

The third difference is the nature of “inevitable threats” that safety and cybersecurity protect against. To understand this, one must presume a PDE being appropriately used. This presumption is needed since risk-assessments are based on intended use. Risk-mitigation for safety involves characteristics such as design, presence in and impact on its environment, appearance, etc., altogether static characteristics.Footnote ¹⁶⁹ Threats to these characteristics would be from risks that are rather passive. They focus on the inherent characteristics of the product, not actions of an external (often malicious) actor. Cybersecurity addresses both passive and active risks. Passive risks include aspects like PDE obsolescence increasing older PDEs’ vulnerability,Footnote ¹⁷⁰ manufacturer cessation leading to lost support,Footnote ¹⁷¹ physical deterioration, etc., which exacerbate active threats. Active threats involve external actors targeting (sometimes critical) digital infrastructures for diverse motives.Footnote ¹⁷² This difference in threats requires an iterative cybersecurity concept, thereby deepening the difference between safety and cybersecurity.

3. Differences between safety and cybersecurity – how NLF-guided legislation stacks up

First, exploring harm prevention differences. The previous section established that product cybersecurity works as a harmonisation objective, so the “end” is manageable. Are the “means” efficacious? The means employed in the CRA are essential requirements, clarifying conformity and bolstering market surveillance.Footnote ¹⁷³ However, the CRA protects digital infrastructures, more fluid and layered as regulatory subjects relative to human health. Evident in the language employed, the CRA does so through objective-oriented and technologically neutral requirements.Footnote ¹⁷⁴ However, with a regulatory subject prone to rapid, significant change, NLF-style legislation may be considered effective enough. The CRA leverages the Commission’s power to adopt delegated acts to update annexes under Article 290 TFEU.Footnote ¹⁷⁵ The limits of Article 290 TFEU and its interpretationFootnote ¹⁷⁶ in an IoT cybersecurity context, while an intriguing topic, remain outside this articles scope. However, essential cybersecurity requirements are specified in an Annex, arguably allowing faster amendments and updates per Article 290 TFEU. A major mechanism addressing digital infrastructural fluidity is conformity through harmonised standards. Technologically neutral requirements supplemented by harmonised standardsFootnote ¹⁷⁷ enhance adaptability in an evolving landscape with exploding IoT presence.

Reliance on standards also concerns the iterative difference between safety and cybersecurity. Requirements for vulnerability management, resilience and continuity must be specified through horizontal and vertical standards, especially for important PDEs.Footnote ¹⁷⁸ Pursuant to Annex I, the Commission has requested horizontal standards from ESOs directly related to the iterative nature of sustained product cybersecurity.Footnote ¹⁷⁹ Additionally, PDEs with higher risk-classifications have access to specific vertical standards, furthering iterative resilience.Footnote ¹⁸⁰ Emphasis on states-of-the-art,Footnote ¹⁸¹ on horizontal standards providing ground to develop vertical standards and on vulnerability handlingFootnote ¹⁸² further the CRAs ability to meet IoTs iterative cybersecurity needs.

Finally, cybersecurity requirements arising from active threats, i.e., malicious actors. CRA requirements address active threats also in a technologically neutral manner. Evolving infrastructures means evolving attack modii. Thus, Annex I requirements, rather than on attacks, focus on infrastructure resilience.Footnote ¹⁸³ Thus, standards adopted therefor foster broad-scoped infrastructural resilience rather than broad-scoped threat prevention.

Therefore, this article submits that NLF-adjacent legislation does address differences between safety and cybersecurity as regulatory objectives. However, its ability to do so is heavily based upon conformity assessment avenues that employ methods of private regulation like standards. Using standards bridges regulatory lacunae, allowing the NLF to regulate a whole new side of harm prevention and reconcile differences between IoT safety and cybersecurity. This catalyses curiosity regarding prevalence of privately developed standards adopted for EU product cybersecurity conformity.