August 1, 2025: EU RED Cybersecurity Deadline is Approaching

• Does not harm network functionality
• Protects personal data and privacy
• Includes safeguards against fraud

To meet these goals, the new harmonized standards EN 18031-1, -2, and -3 (released in August 2024) expect manufacturers to implement technical controls and documented processes for:

1. Risk assessment and threat modeling relevant to the device's functions and interfaces
2. Security design and testing of critical components such as authentication, update mechanisms, and wireless interfaces
3. Security validation through testing, including penetration testing to confirm that protections are effective in real-world scenarios
4. Monitoring of known vulnerabilities and use of threat intelligence to assess exposure throughout the product lifecycle

Penetration testing is not optional - it’s expected as part of demonstrating protection against reasonably foreseeable threats.  That includes both interface-level testing (e.g., BLE, NFC, Wi-Fi, or cellular) and system-level evaluation of attack paths involving cloud, app, or hardware integrations.

EN 18031‑1:2024 (A 2.3) requires manufacturers to perform continuous threat modeling and security risk assessments - keeping abreast of vulnerabilities and integrating that knowledge into design, patching, and risk management processes. Although threat modeling and threat intelligence are distinct, TI informs and enhances threat modeling in several important ways, therefore using threat intelligence is a best practice that improves the quality and effectiveness of threat modeling.

EN 18031-1:2024, the harmonized standard supporting RED Articles 3.3(d)-(f), requires risk analysis, security design, and validation activities proportionate to the threats a device is exposed to. Amongst others it calls for justification like "an analysis of relevant risks related to the operation of the equipment within its reasonably foreseeable use and intended equipment functionality."

This mirrors language in other EU regulations, including:

• General Product Safety Directive (GPSD): Requires protection against “foreseeable risks.”
• Cyber Resilience Act (CRA): Also uses language such as “expected use” and protection against known vulnerabilities, implicitly referring to threats that are reasonably foreseeable based on current threat intelligence.

Cyber Resilience Act (CRA)

The CRA, approved by the EU Parliament in March 2024, will apply to virtually all connected products sold in the EU - including both hardware and software. It goes even further than RED, requiring that:

• Manufacturers perform and maintain a cybersecurity risk assessment
• Products are secure by design and default
• Critical vulnerabilities are reported within 24 hours
• Products undergo conformity assessments, including vulnerability testing
• Manufacturers maintain cybersecurity support for the entire lifecycle (minimum 5 years for most products)

Like the RED, CRA emphasizes the technical validation of security claims - including real-world testing of components and systems. The CRA’s Annex I. Part II (3) and Annex II requires to "apply effective and regular tests and reviews of the security of the product with digital elements" and that "the supporting evidence shall include, where necessary, the results of tests carried out by the appropriate laboratory of the manufacturer, or by another testing laboratory on its behalf and under its responsibility" as part of the cybersecurity conformity assessments.

Moreover, the CRA also underscores the importance of continuous monitoring of threat intelligence sources and known vulnerability databases to ensure timely mitigation and reporting.

How Are RED and CRA Connected? 

The RED applies specifically to radio-enabled products (via the CE-marking framework), the CRA applies more broadly to all connected hardware and software entering the EU market.

Here's the connection:

• If you are already working to comply with the RED’s cybersecurity articles, you're addressing a subset of the CRA requirements.
• The RED is a “sector-specific” regulation, while the CRA is horizontal, meaning that the CRA serves as a legal umbrella - and the RED, where it overlaps, must align with it.
• For devices in scope of both, the requirements are complementary: the RED gets you part of the way there, but not fully CRA-compliant. The CRA adds deeper lifecycle obligations, vulnerability disclosure duties, and broader product security expectations.

In practice, this means:

• Threat intelligence, vulnerability tracking, and penetration testing are central to both regulations.
• Investing in product-focused cybersecurity now for the RED will ease your CRA compliance efforts in the coming 1–2 years.
• Manufacturers should aim for CRA-level rigor in RED preparations - especially for risk management, testing, and documentation.