SPAIN Law and Practice Contributed by: Vicente Moret, Rodrigo González, María Teresa Martínez and Cristina Durante, Deloitte Legal
This rights‑based framing aligns closely with the EU’s product‑layer regulatory strategy. When EU legisla - tion requires manufacturers to ship products without known exploitable vulnerabilities, implement secure defaults, and provide security updates throughout a defined life cycle, it gives enforceable content – through market‑access mechanisms – to the nor - mative expectations Spain already articulates as rights‑based guarantees. The EU’s product security agenda can thus be understood not as an external imposition but as a mechanism that operationalises domestic constitutional values through binding obli - gations on manufacturers. The Cyber Resilience Act is the central structural instrument driving this shift. It is the first EU regula - tion to impose horizontal, mandatory cybersecurity requirements on products with digital elements across their entire life cycle – from design to end‑of‑support. Cyber resilience is no longer left to market incentives or downstream organisational controls; it becomes a baseline condition for placing products on the EU internal market, enforced through market surveillance and meaningful penalties. The CRA directly targets a persistent market failure. For years, insecure‑by‑design products were eco - nomically rational because the costs of insecurity – breaches, ransomware propagation, botnet recruit - ment – were borne by users and society rather than by producers. By making security a legal obligation enforced through market access, the CRA changes the economics of product development: non‑com - pliance becomes a manufacturer risk rather than a user externality. This shift is particularly relevant in Spain, where connected devices and software prod - ucts are widely deployed across consumer, industrial, and public‑sector environments, and where product life cycles often exceed traditional security‑support practices. In terms of scope, the CRA applies broadly to products with digital elements that connect – directly or indi - rectly – to devices or networks. This includes consum - er devices, industrial systems, network equipment, operating systems, and standalone software. A key operational boundary concerns software‑as‑a‑ser - vice: purely remote SaaS without a locally installed
component falls outside the CRA’s direct scope, but SaaS components that are functionally integrated into in‑scope products – such as IoT backends or remote‑management layers – are regulated as part of the product. For Spanish businesses, this distinction is critical for procurement, supply‑chain assessments, and compliance mapping. The CRA also establishes a risk‑based conformi - ty‑assessment model. Most products may rely on self‑assessment where harmonised standards exist, whereas higher‑risk categories require more struc - tured third‑party evaluation. In practice, the availability and timing of these harmonised standards will be a key implementation variable during the initial applica - tion phase. 4.2 Key Obligations Under Legislation The CRA introduces demanding obligations for manufacturers, importers and distributors – not sim - ply because it adds new requirements, but because it requires a fundamental shift in how products are developed and supported. Security must be treated as a primary design objective throughout the entire life cycle. The CRA is therefore best understood as a life cycle governance framework, not a compliance checklist: it requires security to be built in, maintained, and demonstrably upheld over time. Security by Design and Secure Defaults (Annex I) The CRA establishes essential security requirements that must be met before products can be placed on the EU market. Products must be designed and devel - oped to be free of known exploitable vulnerabilities at launch and to minimise their attack surface through architectural choices and default configurations. This addresses a common failure mode: products that can be secured in theory but are shipped with insecure default settings to reduce friction, simplify onboard - ing, or lower costs. Under the CRA, secure defaults become a legal baseline rather than a best prac - tice. Security functions must be enabled by default unless manufacturers can demonstrate that doing so would impose disproportionate cost or performance impacts. Beyond default configurations, Annex I requires pro - tection for the confidentiality, integrity, and availabil -
338 CHAMBERS.COM
Powered by FlippingBook