IoT Security Regulations and Standards: What They Ask of Connected Devices

From guidance to law: how IoT security regulation developed

Rules arrived after connected devices were already everywhere. NIST's 2014 cybersecurity framework was not written for IoT, but its principles applied to it. In 2015 the ITU-T's Internet of Things Global Standards Initiative worked towards common technical standards, which were advisory only.

The first law aimed squarely at IoT device security was the US IoT Cybersecurity Improvement Act of 2020. It made NIST and the Office of Management and Budget responsible for minimum security standards for IoT devices bought by federal agencies, so it works through procurement rather than a ban on sale. In Europe, the EU Cybersecurity Act of 2019 created a certification framework, and ETSI EN 303 645 followed in 2020 as a security baseline for consumer IoT.

Since then the direction has been from voluntary guidance to binding requirements on the product itself. Several jurisdictions now set mandatory security requirements for connected products placed on their markets, and many of those requirements trace back to the same baseline.

Three kinds of rule, and which one reaches your product

The EU Cyber Resilience Act applies horizontal cybersecurity requirements to hardware and software products with digital elements sold in the EU, across planning, design, development and maintenance, and requires manufacturers to handle vulnerabilities through the product's lifecycle. Its obligations phase in over several years, and some product categories need third-party assessment before sale. The UK regime for consumer connectable products bans universal default passwords and requires a way to report vulnerabilities and a published minimum period of security updates.

ETSI EN 303 645: the consumer IoT baseline

ETSI EN 303 645, first published in 2020 after collaboration between industry, academia and government, sets a security baseline for consumer IoT: baby monitors and connected toys, smoke detectors, door locks and window sensors, cameras, speakers and TVs, wearable health trackers, home automation and alarm systems, connected appliances, smart assistants, and the gateways and hubs that connect them. Devices intended mainly for manufacturing, other industrial use or healthcare settings are outside its scope.

The standard is not binding on its own, but several national certification and labelling schemes are built on it, and product security laws draw on the same provisions. Its 13 provisions read as an engineering backlog.

NIS 2: operator obligations that flow down to suppliers

The NIS 2 Directive, Directive (EU) 2022/2555, raises cybersecurity requirements for essential and important entities across a wide range of sectors, including digital infrastructure and digital service providers. Member states transpose it into national law, so details vary by country. It requires organisations to take technical, operational and organisational measures, including:

• risk analysis and information system security policies;
• incident handling, backup management and disaster recovery;
• supply chain security;
• security in the acquisition, development and maintenance of network and information systems;
• cybersecurity training;
• multi-factor or continuous authentication where appropriate.

NIS 2 binds the operator, not the device. A device maker meets it indirectly: customers in covered sectors pass supply-chain requirements down to their vendors, so security documentation, update commitments and incident cooperation become part of the sale. Certain providers established outside the EU that offer services in it must also designate a representative in a member state.

ISA/IEC 62443: the industrial counterpart

The ISA/IEC 62443 series has set security requirements for industrial automation and control systems since around 2010. In 2021 the IEC designated it a horizontal standard, applicable across sectors such as manufacturing, metals and mining, power and water utilities, healthcare and transportation. It defines shared terminology, how to determine an appropriate security level, risk-assessment processes, and a security methodology for product developers.

For a device or component supplier, two parts matter most: the secure product development lifecycle requirements (62443-4-1) and the technical security requirements for components (62443-4-2). Unlike the EU instruments, 62443 is an international standard used in many markets, and industrial buyers increasingly ask suppliers to show how a product meets it.

Where connected devices actually expose data

Regulators focus on outcomes, but the weak points are concrete. A connected medical device shows the pattern: data moves over a Bluetooth link to a phone app, then to a central platform and on to a clinician. The pairing link and the central store are where an attacker gains the most.

• Healthcare: a compromised device or a malicious app update can harm patients, and recovering devices already in use is slow and expensive.
• Vehicles and transport: a widely reported 2015 demonstration showed researchers remotely controlling a production SUV, and vulnerabilities in vehicle telematics are still being found.
• Consumer electronics: buyers and retailers increasingly look for security information, and product laws now make a baseline mandatory.
• Anyone holding sensitive data: one connected device on a corporate network, even a thermostat, can become the way in.

The common engineering response is the same in each case: unique identity per device, encryption on every hop, signed updates and a plan for handling the next vulnerability. Our article on the Microchip Connectivity Framework shows one way to keep messages encrypted end to end across mixed links. Encryption alone does not meet any of these frameworks: they also cover process, policy and support commitments.

What a product team should do now