Skip to main content

Securing the smart future: the need for product security

How evolving EU regulations like the Radio Equipment Directive (RED) and the Cyber Resilience Act (CRA) are transforming product security from a technical afterthought into a strategic business priority

Smart devices are everywhere: in homes, offices, and critical infrastructure. Each connection introduces risk; each vulnerability invites attack. The European market, driven by the EU-RED and EU-CRA regulations, is raising the bar. If it can connect, it must be secure: by law; by design; as a strategic necessity.

Introduction

Remember when fridges were just cold boxes? Now, grocery lists are stored, Wi-Fi passwords remembered, and email addresses logged. Eating habits are tracked, recipes suggested, and soon, groceries might be ordered automatically. But what happens when that same fridge exposes personal data or becomes a gateway into your home network?

This is not a dystopian tech thriller; it is a glimpse into our connected reality and agentic future. Cyberattacks are no longer considered limited to laptops. Smart devices are increasingly found in offices that connect to the internet and process data. From smart TVs and lighting systems to voice assistants and video conferencing tools, many of these devices record audio or video and store it in the cloud. For attackers, these are not just everyday products; they are potential entry points into the corporate network which can be exploited. In 2014, in one of the first documented cases of its kind, a smart refrigerator was hijacked and used to send spam emails as part of a botnet attack involving over 100,000 connected devices (according to [NBCN14]).

As everyday products become smarter, they also become more vulnerable. And when a fridge can be weaponized, it is clear: the security of products is no longer optional.

What is product security?

The field of product security exists to ensure physical products with digital elements such as Internet of Things (IoT) devices, medical equipment or Wi-Fi-enabled devices are secure. This means:

  • Designing products to be secure from the start.
  • Protecting both the hardware and the software of a product.
  • Keeping the product safe throughout its life, even after it is sold, by updating it and fixing vulnerabilities.

Product security goes beyond traditional application security. It encompasses both hardware and software, addressing risks across the entire product lifecycle, from design and development to deployment and decommissioning. Unlike standalone applications, connected products are made up of multiple integrated components, each of which can introduce unique security risks. A smart fridge may be considered as an example.

As a networked system, it may include:

  • Embedded software (firmware) – vulnerable to outdated code or hardcoded credentials that attackers can exploit to gain control of the device.
  • Cloud APIs – if improperly secured, these can be entry points for attackers to access user data or manipulate device behavior remotely.
  • Mobile applications – may lack proper authentication or expose sensitive data through insecure storage.
  • Hardware sensors – susceptible to tampering or side-channel attacks that can leak information or disrupt functionality.

C-2025-5-Raskin-1-klein

Figure 1. Example of components within an IoT product. [Click on the image for a larger image]

A vulnerability in any one of these layers can compromise the entire system. That is why product security must take a holistic approach, treating the product not as a single entity, but as a dynamic ecosystem of interconnected parts.

Challenges in product security

Concerns about products often focus on “product safety”; ensuring that items entering the market do not pose a risk of physical harm during normal use. It is easy to understand why a product that could catch fire or cause injury should never reach consumers. Product security on the other hand, which deals with protecting products from digital threats like hacking or data breaches, tends to be less intuitive. After all, when buying a fridge, most people do not immediately worry about privacy risks. However, as more products become connected and software-driven, the line between safety and security becomes blurred. A cybersecurity flaw can quickly turn into a safety hazard, for instance: if a hacked cleaning robot or connected car starts behaving unpredictably. The EU’s General Product Safety Regulation (GPSR; see [EC25]) reflects this shift by explicitly including cybersecurity and AI-related risks in its definition of product safety. While the risks are real, product cybersecurity risk remains invisible to the consumer, manufacturer, or importer. One of the biggest challenges with product security is that it is invisible.

On the manufacturing side, security was historically seen as a one-time checkbox and not an ongoing responsibility. Many connected products are shipped with little to no plan for long-term patching or support. If applied at all, security updates are often infrequent, especially for low-cost or legacy devices. Consumers do not typically think about updating fridges or smart lightbulbs. These devices do not prompt like a phone does, and they do not feel like computers, even though they are. So, when a vulnerability is discovered, it often goes unpatched. Furthermore, it can be difficult for consumers to understand the risk posed by a vulnerable product.

The result? A growing ecosystem of vulnerable products that remain online for years, quietly expanding the attack surface for cybercriminals that can result in real world consequences. These challenges are not just theoretical; when product security is neglected, the consequences can ripple far beyond the device itself.

Based on recent threat intelligence, the groups exploiting these vulnerabilities fall under two categories:

  • Cybercrime-as-a-service (CaaS) groups
  • Nation State Actors

Cybercrime-as-a-Service (CaaS) refers to the growing underground economy where cybercriminals offer tools, infrastructure, and services (such as malware kits and botnet rentals) to other criminals for a fee. Campaigns like BADBOX 2.0, which involved pre-infected smart TVs are often linked to this ecosystem according to [CGU25].

Furthermore, nation state actors have targeted popular IoT devices for espionage purposes. In April 2020, Microsoft security researchers observed the Russian-backed hacking group STRONTIUM (also known as Fancy Bear or APT28) compromising popular IoT devices (a VOIP phone, an office printer, and a video decoder) across multiple customer locations according to [NCSC22].

Real-world consequences

As mentioned prior, most people would not think twice about updating their fridge’s firmware. It is conceptually easy to grasp that skipping a patch might leave users exposed, but it can be quite difficult to imagine the tangible risk emerging from a fridge at home or robot cleaner in the office left vulnerable (see also [Bel23]). Below are some real-world examples where poor product security led to several “real world” consequences.

Mirai botnet attack

According to [Hern17], the Mirai malware was designed to hijack insecure IoT devices like routers, IP cameras, and Digital Video Recorders (DVRs) by exploiting default usernames and passwords. Once infected, these devices became part of a massive botnet used to launch powerful Distributed Denial of Service (DDoS) attacks. One of the most disruptive attacks targeted Dyn, a major DNS provider, temporarily knocking major websites like Twitter, Netflix, and Reddit offline.

Medical devices

According to [Cyr22], in 2022, an industry survey found that 53% of medical devices contained known critical vulnerabilities, highlighting a widespread issue in healthcare product security. In a separate analysis ([Brac23]) of devices purchased by National Health Services, it was revealed that vulnerabilities often become publicly known an average of 3.2 years after purchase, leaving a significant window during which devices are actively used but potentially exposed to attack. These flaws can lead to unauthorized access to sensitive patient data or even allow remote manipulation of device behavior, such as altering medication dosages or disabling safety features.

While there have been no publicly confirmed cases of these vulnerabilities being exploited to cause direct physical harm, the risk is far from hypothetical. Security researchers have repeatedly demonstrated how real-world attacks could occur.

A decade ago, attacks on operational technology (OT) systems were rare. Today, they are widespread and increasingly sophisticated. Who is to say the same will not happen with connected medical devices, especially as global tensions and cyber warfare continue to escalate?

As risks become more apparent, so does the need for stronger safeguards.

Technology drivers: greater need for security

An important angle to consider is that consumers and business customers are increasingly drawn to interconnected products, including those powered by artificial intelligence. This growing demand for seamless connectivity is driving companies to accelerate the rollout of modern technologies. However, in the rush to bring these innovations to market, security considerations are often overlooked. The pressure to deliver quickly can result in implementations that are not thoroughly assessed for vulnerabilities, potentially exposing users and systems to significant risks.

These technologies are fundamentally built on trust. The moment a security incident occurs involving interconnected or AI-powered products, consumer confidence can be eroded instantly. Users are quick to voice concerns and may avoid purchasing from brands they no longer trust. As a result, security is becoming a critical factor in making purchasing decisions.

Product security also plays a pivotal role in B2B and B2G relationships. Businesses and governments increasingly rely on connected products, from smart building systems to autonomous cleaning robots and fleet vehicles, to support operations and service delivery. In these contexts, a security breach can have far-reaching consequences, including operational disruption, reputational damage, and regulatory fallout. Vendors who can demonstrate robust product security not only reduce risk but also gain a competitive edge in winning contracts and building long-term partnerships.

Product security is not just a technical requirement. It is a key enabler for organizations to strengthen customer loyalty and differentiate themselves in an increasingly crowded and connected marketplace.

Regulatory drivers: Radio Equipment Directive & Cyber Resilience Act

The growing list of real-world threats has made one thing clear: product security can no longer be an afterthought. The Radio Equipment Directive (RED) was originally adopted by the EU in 2014, with the transitional period for local transposition finishing in 2017 to regulate wireless communication devices sold in Europe. However, as the number of connected products exploded, especially in the consumer IoT space, the EU recognized the need to address the growing cybersecurity risks. In response, RED was updated to include mandatory cybersecurity requirements, which will come into effect on August 1, 2025. As this is a directive, member states are required to update to amend their national laws to reflect these cybersecurity requirements. These updates aim to improve network resilience, protect consumer privacy, and reduce the risk of fraud by ensuring that connected devices meet baseline security standards.

Building on this momentum, the EU introduced the Cyber Resilience Act (CRA): a broader and more ambitious regulation that targets all products with digital elements, not just those with wireless capabilities (see Figure 2). Set to come into force in 2027, the CRA is designed to ensure that cybersecurity is embedded throughout the entire lifecycle of a product, from design and development to maintenance and end-of-life. Together, RED and CRA represent a significant shift in how the EU approaches digital product safety.

C-2025-5-Raskin-2-klein

Figure 2. Overlap of RED & CRA (source: KPMG). [Click on the image for a larger image]

What this means for manufacturers, importers, and distributors:
All manufacturers, importers, and distributors of digital products or radio equipment placed on the EU market (regardless of where they are based) must comply with the applicable requirements, respectively with the Radio Equipment Directive (RED) and the Cyber Resilience Act (CRA).

Radio Equipment Directive (RED)

By August 1, 2025 (under the RED for wireless products)

Article 3(3)(d): Protection of Communication Networks

  • Devices must not harm communication networks or misuse network resources.
  • Must include safeguards against unauthorized access.
  • Standard: EN 18031-1:2024 – Common security requirements for internet-connected radio equipment

Article 3(3)(e): Protection of Personal Data and Privacy

  • Devices must protect personal data and user privacy.
  • Includes secure data transmission, storage, and access control.
  • Standard: EN 18031-2:2024 – Security requirements for internet-connected, childcare, toy, and wearable radio equipment

Article 3(3)(f): Protection from Fraud

  • Devices must prevent fraud, especially in financial or sensitive applications.
  • Includes secure authentication and transaction integrity.
  • Standard: EN 18031-3:2024 – Security requirements for devices processing virtual money or monetary value

Cyber Resilience Act (CRA)

By September 2026 (early CRA reporting requirements for digital products)

Incident Reporting Obligations:

  • Manufacturers must report actively exploited vulnerabilities and incidents with significant impact to both the designated national CSIRT and ENISA (EU Agency for Cybersecurity).
  • Reporting must follow a three-stage timeline:
    • Early warning notification within 24 hours of becoming aware
    • Detailed notification within 72 hours, unless already provided
    • Final report:
      • Within 14 days after a fix is available (for vulnerabilities)
      • Within 1 month after the 72-hour notification (for incidents)
      • CSIRTs may request intermediate updates, though these are not mandatory unless requested.
  • Manufacturers must also inform impacted users (and where appropriate, all users) of the vulnerability or incident, including any corrective or risk mitigation measures.
  • If the manufacturer is outside the EU, importers may assume reporting duties.

By December 2027 (full CRA compliance for digital products)

Vulnerability Handling Processes:

  • Companies must implement a coordinated vulnerability disclosure (CVD) process.
  • This includes secure channels for receiving vulnerability reports and timely remediation.

Security Support Throughout Product Lifecycle:

  • Manufacturers must provide security updates and patches for at least 5 years (or the expected product lifetime, whichever is longer).
  • Updates must be delivered securely and effectively, with minimal user burden where possible.

Full Cybersecurity Compliance for Digital Products:
All products with digital elements (hardware and software) must meet essential cybersecurity requirements related to:

  • Secure design and development
  • Protection against unauthorized access and data breaches
  • Minimization of attack surfaces
  • Default secure configurations

Additional Obligations:

  • Maintain a Software Bill of Materials (SBOM)
  • Integrate cybersecurity compliance into the CE marking process
  • Encourage good-faith security research and bug bounty programs

Non-compliance could result in fines, product recalls, or bans from the EU market. In this way, RED and CRA are setting a global benchmark for product cybersecurity, much like GDPR did for data privacy. Meeting these regulatory demands requires more than awareness, it calls for action. The following practical steps provide insight into how to embed security into products to support compliance and resilience.

Practical steps for improving product security

As with GDPR, achieving full compliance is not a static or absolute state; rather, it involves a risk-based approach focused on continuous improvement and proportional security measures. The following actions are designed to align with key principles of the Radio Equipment Directive (RED) and the Cyber Resilience Act (CRA), helping companies in scope build more secure, resilient, and regulation-ready digital products.

Strong governance

It is recommended that organizations establish a robust governance structure around product security. This begins with clearly defining roles, responsibilities, and tasks across relevant teams. Once these foundations are in place, aspects such as communication channels and escalation paths can be structured to support efficient collaboration.

Security should be embedded early in the product lifecycle through a “Security-by-Design” approach, ensuring that cybersecurity considerations are integrated into every product decision. Involving security teams in strategic and technical decision-making is essential, as they play a critical role in identifying vulnerabilities and guiding necessary product changes.

Product development typically involves multiple cross-functional teams (such as R&D, Procurement, and Software and Hardware Engineering) each with distinct priorities and workflows. This diversity can lead to siloed practices, especially when coordination mechanisms are weak. Even within R&D departments of the same organization, teams may operate under different objectives, timelines, or technical standards, further reinforcing these silos. A well-defined governance structure helps foster cross-functional collaboration, ensuring that security requirements are consistently identified, communicated, and met throughout the development lifecycle. By breaking down organizational silos, governance aligns teams around shared objectives, streamlines decision-making, and strengthens the overall security posture of the product.

Additionally, it is important to maintain proper documentation. This includes, but is not limited to, defining and maintaining minimum cybersecurity standards for products. These standards serve as a reference point for development teams and support compliance with EU regulations. Well-documented processes not only improve internal alignment but also simplify audits and regulatory assessments.

Establishing a PSIRT

To meet the incident notification and vulnerability handling requirements under the Cyber Resilience Act (CRA), organizations are encouraged to establish a dedicated Product Security Incident Response Team (PSIRT).

A PSIRT is responsible for managing security vulnerabilities and incidents specifically related to products. This includes monitoring for threats, coordinating internal responses, and ensuring timely communication with regulators, customers, and other stakeholders when required.

While many organizations already operate a Cyber Security Incident Response Team (CSIRT) focused on enterprise IT systems, these teams may not be equipped to handle product-specific vulnerabilities or meet the regulatory timelines and reporting obligations required under the CRA. A PSIRT addresses this gap by focusing on the unique risks and responsibilities associated with connected products and software.

Key responsibilities of a PSIRT include:

  • Receiving and triaging vulnerability reports from internal teams, researchers, or external sources.
  • Coordinating incident response across engineering, legal, and communications teams.
  • Ensuring timely notification to EU authorities and affected users, as required by CRA.
  • Maintaining documentation of incidents and response actions for audit and compliance purposes.

By formalizing a PSIRT, organizations can respond more effectively to security issues, reduce risk exposure, and demonstrate alignment with EU regulatory expectations.

Leading organizations such as Cisco have established dedicated teams like the Product Security Incident Response Team (PSIRT) to manage vulnerabilities across their product lifecycle (see [Cisc25]).

Utilize an SBOM tool

Deploying an SBOM (Software Bill of Materials) tool is a critical first step towards compliance, but it is not enough on its own. An SBOM tool is only as powerful as the processes that support it; without the right processes, an SBOM is just a list. To meet CRA requirements and manage software supply chain risks effectively, organizations must also establish clear procedures for using SBOMs to track vulnerabilities and assess risk.

Without these processes, vulnerabilities may go unaddressed, risk assessments may be inconsistent, and compliance obligations could be missed. Simply generating SBOMs without action creates a false sense of security.

Key elements of a mature SBOM approach include:

  • Automated SBOM generation in CI/CD pipelines.
  • Centralized tracking of components and vulnerabilities.
  • Risk-based prioritization and remediation workflows.
  • Clear ownership and cross-team coordination.

With the right processes in place, SBOMs become a powerful tool for proactive security and regulatory compliance.

Security requirements in outsourced product development

When working with external developers or outsourced development teams, it is critical to ensure that product security is not only upheld but also traceable across the entire development supply chain. Internal product security teams should clearly define security expectations and formally embed them into contracts and vendor agreements.

External developers should be required to:

  • Adhere to the organization’s minimum cybersecurity standards.
  • Support secure development practices and effective vulnerability handling.
  • Provide documentation and evidence of compliance with relevant security requirements.

Without these formalized and enforceable requirements, organizations risk losing visibility into how security is managed across their development ecosystem. This can lead to inconsistent practices, compliance failures, increased exposure to vulnerabilities, and costly remediation efforts later in the product lifecycle.

By making security a transparent and (if possible) an auditable obligation, organizations can extend their security posture beyond internal teams, reduce regulatory and operational risk, and build greater trust in their products and partners.

Conclusion

As connected products become more embedded in our daily lives, the risks they pose are growing rapidly. The EU’s RED and CRA regulations mark a pivotal shift, making cybersecurity a core requirement rather than a secondary concern. For organizations, this is not just a compliance challenge: it is a strategic opportunity to build trust, resilience, and long-term value through secure product design and lifecycle management.

Navigating this evolving landscape requires more than technical fixes. It demands a coordinated, organization-wide approach that integrates governance, incident response, supply chain transparency, and third-party accountability.

Importantly, this is also an opportunity to build trust with customers and consumers early, and enter the market with confidence. As AI and connected technologies become more widespread, the demand for transparency, accountability, and security will only grow. Organizations that prioritize these principles now will be better positioned to lead a trust-driven digital economy.

References

[Bel23] Bel, M. & Heil, R. (2023). How smart is the use of smart devices in the office? The case of industrial cleaning robots in the Netherlands. Compact 2023/1. Retrieved from: https://www.compact.nl/articles/how-smart-is-the-use-of-smart-devices-in-the-office/

[Brac23] Bracciale, L., Loreti, P., & Bianchi, G. (2023). Cybersecurity vulnerability analysis of medical devices purchased by national health services. Scientific Reports, 13(1), 19509. Retrieved from: Cybersecurity vulnerability analysis of medical devices purchased by national health services – PMC

[CGU25] CGU (2025). BADBOX 2.0 case study: Google’s July 2025 lawsuit against the botnet infecting ten million residential Android open-source IoT devices. Retrieved from: https://research.cgu.edu/icdc/2025/07/19/badbox-2-0-case-study/

[Cisc25] Cisco Systems. (2025). Security vulnerability policy. Retrieved from: https://sec.cloudapps.cisco.com/security/center/resources/security_vulnerability_policy.html

[Cyne22] Cynerio. (2022). The state of healthcare IoT device security 2022. Retrieved from: https://www.cynerio.com/landing-pages/the-state-of-healthcare-iot-device-security-2022

[EC25] European Commission. (2025). EU’s General Product Safety Regulation (GPSR): A new era of consumer protection. Retrieved from: https://trade.ec.europa.eu/access-to-markets/en/news/eus-general-product-safety-regulation-gpsr-new-era-consumer-protection

[Hern17] Hern, A. (2017). Three men plead guilty to creating Mirai botnet used in massive 2016 cyberattack. Retrieved from: https://www.theguardian.com/technology/2017/dec/13/mirai-botnet-cyber-attack-2016-men-plead-guilty

[NBCN14] NBC News. (2014). Smart refrigerators hacked to send out spam: Report. Retrieved from: https://www.nbcnews.com/tech/internet/smart-refrigerators-hacked-send-out-spam-report-n11946

[NCSC22] National Cyber Security Centre. (2022). Threat report on enterprise connected devices. Retrieved from: https://www.ncsc.gov.uk/files/Threat-report-on-enterprise-connected-devices-web.pdf