Securing IoT devices: a practical checklist mapped to ETSI EN 303 645

Why a baseline matters for connected products

A connected product is never just the device. It is the firmware, the companion app, the cloud service it talks to, the update server and the people who will report bugs to you years after launch. A weakness in any one of them can expose the rest.

The good news is that you do not have to invent a security baseline from scratch. ETSI EN 303 645, the European standard for consumer IoT cyber security, sets out a set of provisions that regulators and national bodies now point to. The current version is V3.1.3, dated September 2024. It is written for consumer devices, but the same ideas translate well to industrial and commercial products.

This article turns those provisions into a working checklist, cross-references the OWASP IoT Top 10 (2018), and summarises the regulatory dates you should plan around.

How ETSI EN 303 645 is structured

Clause 5 of the standard groups its cyber security provisions under 13 headings, from “No universal default passwords” (5.1) to “Validate input data” (5.13). Clause 6 adds data protection provisions. Each provision is marked as either a mandatory requirement (“shall”) or a recommendation (“should”), and some are conditional on features the device actually has (ETSI EN 303 645).

One provision is easy to overlook: 5.0-1 asks you to record a justification for every recommendation you decide is not applicable or not met. In practice this means keeping a short, dated decision log rather than silently skipping items.

The checklist

1. No universal default passwords (ETSI 5.1, OWASP I1)

If the device uses passwords in any state other than factory default, each one must be unique per device or set by the user (provision 5.1-1).
Pre-installed unique passwords must be generated in a way that resists automated attacks against a whole product line, so no sequential serial numbers or MAC-derived patterns (5.1-2).
Use best practice cryptography for authentication, including machine-to-machine authentication (5.1-3).
Make brute-force attacks over network interfaces impracticable, for example with rate limiting or lock-outs (5.1-5).

Practical check: take two units off the production line and confirm nothing about one unit’s credentials helps you guess the other’s.

2. A way to receive and act on vulnerability reports (ETSI 5.2)

Publish a vulnerability disclosure policy. At a minimum it must give a contact for reporting issues, a timeline for acknowledging receipt, and a timeline for status updates until the issue is resolved (5.2-1).
Act on disclosed vulnerabilities in a timely manner. The standard notes that, conventionally, a software fix is completed within 90 days, including patch availability and notification, while hardware fixes can take longer (5.2-2).
Keep monitoring for vulnerabilities in the products you sell and the services you run throughout the defined support period (5.2-3).

Practical check: search your own website as a stranger would. Can a security researcher find where to report a flaw in under a minute?

3. Keep software updated (ETSI 5.3, OWASP I4 and I5)

Have a secure update mechanism unless a genuine resource constraint prevents it (5.3-2), and make updates simple for the user to apply (5.3-3).
Use best practice cryptography to secure the update mechanism (5.3-7) and ship security updates in a timely way (5.3-8).
Verify the authenticity and integrity of updates before installing them (5.3-9).
Publish the defined support period clearly, so buyers know how long updates will be provided (5.3-13).
Make the model designation clearly recognisable, on a label or through an interface (5.3-16).
If a device genuinely cannot be updated, the standard recommends that it be isolable and its hardware replaceable (5.3-15A, 5.3-15B).

The OWASP list covers the same ground from the attacker’s side: “Lack of Secure Update Mechanism” (I4) and “Use of Insecure or Outdated Components” (I5). A software bill of materials for every firmware release makes both easier to manage.

4. Store credentials and keys securely (ETSI 5.4, OWASP I7)

Store sensitive security parameters securely in persistent storage (5.4-1).
If a hard-coded per-device identity is used for security, make it resistant to physical, electrical and software tampering (5.4-2).
Never hard-code critical security parameters in source code (5.4-3). Reverse engineering routinely finds embedded usernames, passwords and API keys.
Keys used for update integrity and for protecting communication with your services must be unique per device (5.4-4).

Practical check: extract a firmware image and search it for strings that look like keys, tokens or passwords. Automate this in your build pipeline.

5. Communicate securely (ETSI 5.5, OWASP I2, I3 and I7)

Use best practice cryptography for communications (5.5-1), preferably through reviewed or evaluated implementations (5.5-2).
Design for crypto-agility: algorithms and primitives should be replaceable (5.5-3).
Require authentication before network access to device functionality (5.5-4), and always before security-relevant configuration changes over a network interface (5.5-5).
Protect critical security parameters in transit and manage them securely across their whole lifecycle (5.5-6 to 5.5-8).

OWASP’s “Insecure Ecosystem Interfaces” (I3) is a reminder that the web API, mobile app and cloud back end are part of the attack surface, not just the radio link.

6. Minimise the attack surface (ETSI 5.6, OWASP I2, I9 and I10)

Disable unused network and logical interfaces (5.6-1).
Limit what the device reveals about itself before authentication (5.6-2).
Avoid exposing physical interfaces unnecessarily (5.6-3), and disable debug interfaces or protect them with proper access control (5.6-4A). Open UART or JTAG pads on shipped boards are a classic finding under OWASP I10, “Lack of Physical Hardening”.
Enable only the services the device needs, remove dead code and run software with least privilege (5.6-5 to 5.6-7).
Follow secure development processes, such as version control and security-related compiler options (5.6-9).

7. Protect software integrity (ETSI 5.7)

Verify software with secure boot, ideally anchored in a hardware root of trust (5.7-1).
If an unauthorised change is detected, alert the user or administrator and avoid connecting to wider networks than needed to raise that alert (5.7-2).

8. Personal data, resilience and user control (ETSI 5.8 to 5.12, clause 6, OWASP I6 and I8)

Protect the confidentiality of personal data in transit (5.8-1, 5.8-2) and document every external sensing capability, such as cameras and microphones, clearly for users (5.8-3).
Build in resilience to network and power outages; the device should stay locally functional where it can and reconnect in an orderly way (5.9-1 to 5.9-3).
If you collect telemetry, examine it for security anomalies (5.10-1).
Give users a simple way to erase their data from the device (5.11-1) and, as recommended, from associated services (5.11-2).
Keep set-up and maintenance simple and secure by default, with guidance on how to check the device is still securely configured (5.12-1 to 5.12-3). OWASP calls out “Insecure Default Settings” (I9) and “Lack of Device Management” (I8) as related failures.

9. Validate input (ETSI 5.13)

Validate data that reaches the device through user interfaces and APIs, and reject unexpected input that could manipulate the system (5.13-1A and 5.13-1B).

Regulation to plan around

European Union: Cyber Resilience Act

The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to “products with digital elements”, which covers both hardware and software placed on the EU market that have a data connection (CRA summary). Key dates from the European Commission:

Date	What applies
10 December 2024	Regulation entered into force
11 June 2026	Provisions on notifying conformity assessment bodies (Chapter IV)
11 September 2026	Reporting obligations for actively exploited vulnerabilities and severe incidents
11 December 2027	Regulation fully applicable

Reporting is already live. Manufacturers must send an early warning within 24 hours and a notification within 72 hours, through the CRA Single Reporting Platform, to the national CSIRT and ENISA. Manufacturers also set a support period for each product and must state its end date (month and year) at the time of purchase (CRA summary).

United Kingdom: PSTI product security regime

The UK’s product security regime under the Product Security and Telecommunications Infrastructure Act 2022 came into effect on 29 April 2024. Its three requirements cover the same ground as ETSI provisions 5.1, 5.2 and 5.3: passwords must be unique per product or user-defined, manufacturers must say how to report security issues and what response times to expect, and they must publish the minimum period for which security updates will be provided.

India: TEC code of practice and CERT-In directions

The Telecommunication Engineering Centre (TEC) under the Department of Telecommunications published its first Code of Practice for Securing Consumer IoT in August 2021 and released Release 2.0 (TEC 31318:2025) in November 2025, revised to reflect ETSI EN 303 645 V3.1.3. Its guideline headings follow the ETSI structure, so the checklist above maps onto it closely. The same document notes that IoT devices must undergo testing and certification under DoT’s Mandatory Testing and Certification of Telecom Equipment (MTCTE) regime before sale, import or use in India, so check which essential requirements apply to your device category early in the project.

Separately, CERT-In’s directions of 28 April 2022 under section 70B(6) of the IT Act require service providers, intermediaries, data centres, body corporates and government organisations to report listed cyber incidents within 6 hours of noticing them. “Attacks on Internet of Things (IoT) devices and associated systems” is one of the listed incident types. The directions also require ICT system logs to be kept securely for a rolling 180 days within Indian jurisdiction, and clocks to be synchronised with NTP servers of NIC or NPL (or traceable to them). If you operate the cloud side of a connected product, these duties apply to you.

Putting it into practice

Start with the mandatory “shall” provisions in ETSI EN 303 645; they are the baseline the standard expects every in-scope device to meet.
Write the support period and disclosure policy before launch. PSTI requires both to be published, the CRA requires the support period’s end date to be stated at the time of purchase, and both shape your update infrastructure.
Treat the cloud and app as part of the device. Most OWASP IoT Top 10 items sit at the interfaces.
Keep evidence. A short record per provision (met, not applicable with reason, or planned) is useful for conformity assessment and for your own engineering reviews.
Rehearse incident reporting. With the CRA’s 24-hour early warning and CERT-In’s 6-hour window, the reporting path needs to be known and tested before you need it.

Sources

Facts in this article were checked against the linked sources on 9 October 2026. Rules, prices and standards change; check the source before relying on a detail. This article is general information, not legal or financial advice.