EN 303 645 — Cybersecurity Standard for Consumer IoT Devices

ETSI EN 303 645 (full title: Cyber Security for Consumer Internet of Things: Baseline Requirements) is the European — and now globally referenced — cybersecurity baseline standard for consumer IoT devices. Developed by ETSI (European Telecommunications Standards Institute) and first published in June 2020, it defines 13 security provisions and 5 data protection provisions that establish the minimum cybersecurity posture any internet-connected consumer device should have.

EN 303 645 sits at the centre of the EU’s IoT security regulatory ecosystem: it is referenced by the RED Delegated Act, forms part of the harmonisation roadmap for the CRA, and has been adopted as the basis for national cybersecurity labelling schemes in the UK, Singapore, Finland, and Germany.

Key Facts

The 13 Security Provisions

EN 303 645 structures its requirements into 13 numbered provisions. Each provision contains a mix of mandatory requirements (SHALL) and best practice recommendations (SHOULD):

Provision 1: No Universal Default Passwords

The most impactful provision. Every IoT device must either:

• Ship without a default password, with the user required to set one during setup, or
• Have a unique per-device password generated in a way that makes it unpredictable

Shared default credentials (e.g., admin/admin, root/1234) that are identical across all units of a model are prohibited. This single provision eliminates the most common IoT attack vector of the past decade — credential stuffing against default passwords.

Hardware implication: Unique per-device passwords must be stored securely in non-volatile memory and must survive factory resets (or be regenerated after reset). This requires a provisioning process at manufacturing time.

Provision 2: Implement a Vulnerability Disclosure Policy

Manufacturers must publish a clear, accessible vulnerability disclosure policy (VDP) that:

• Provides contact information for security researchers
• States the minimum period for which vulnerability reports will be accepted
• Defines the expected response process and timeline

This is an organisational requirement — not a hardware requirement — but it must be in place before the product enters the EU market.

Provision 3: Keep Software Updated

Devices must support security software updates and:

• Update processes must be simple for the user (not require specialist knowledge)
• The device must notify the user when a security update is available
• Updates must be timely — critical vulnerabilities must be addressed promptly
• Updates must be available for the device’s defined support period
• The device must not allow downgrade to a vulnerable firmware version

Hardware implication: Requires secure OTA update capability with rollback protection. If the MCU cannot implement anti-rollback (e.g., via monotonic counters in secure storage), firmware downgrade attacks become feasible.

Provision 4: Securely Store Sensitive Security Parameters

Credentials, cryptographic keys, and other sensitive parameters must be stored with appropriate protection. Hard-coded credentials in firmware are prohibited.

Hardware implication: Sensitive parameters should be stored in hardware-protected storage (Secure Element, TrustZone-protected memory, eFuse-locked areas). Software-only storage in standard flash is insufficient for high-assurance use cases.

Provision 5: Communicate Securely

All device communications must use:

• Encrypted transport — plaintext communication of sensitive data is prohibited
• Authenticated endpoints — the device must verify it is communicating with the intended server/service
• Current best practice protocols — deprecated protocols (SSLv3, TLS 1.0, WEP, WPA) must not be used

This provision requires TLS 1.2 minimum (TLS 1.3 recommended) for internet communications and appropriate encryption for local network-to-device communication.

Provision 6: Minimise Exposed Attack Surfaces

The device must expose only the services necessary for its intended functionality:

• Unused network interfaces, ports, and services must be disabled by default
• Physical interfaces (JTAG, UART debug interfaces) must be disabled or protected in production firmware
• Network services must not run with elevated privileges beyond what is needed

Hardware implication: Physical debug interfaces (JTAG, SWD) should be locked via OTP-fuse protection or permanently disabled in production devices. Leaving JTAG enabled on production units is a common finding in security audits.

Provision 7: Ensure Software Integrity

The device must verify the integrity of software at startup and during update:

• Secure boot — cryptographic verification of firmware before execution
• Update validation — firmware updates must be verified before installation
• Any software modification attempt must be detected and handled

Hardware implication: Full secure boot chain from boot ROM through application firmware, anchored in hardware (OTP-fused root key). Software-only integrity checks can be bypassed.

Provision 8: Ensure Personal Data Security

Devices that process or store personal data must:

• Use appropriate encryption for personal data at rest
• Provide users mechanisms to control their personal data
• Not transmit personal data without appropriate user consent
• Support secure data deletion (factory reset that actually wipes personal data)

Provision 9: Make Systems Resilient to Outages

Devices should continue to operate in a degraded but functional mode during network outages, and should:

• Not enter a permanently inoperable state due to a network service outage
• Support recovery from failed updates

Provision 10: Examine System Telemetry Data

Manufacturers should monitor telemetry from devices in the field to detect security anomalies. This provision is largely a SHOULD (recommendation) rather than SHALL (requirement).

Provision 11: Make It Easy for Users to Delete Personal Data

Devices should provide users with a simple, accessible mechanism to delete all personal data — factory reset functionality with confirmed, complete data wipe.

Provision 12: Make Installation and Maintenance Easy

Setup and maintenance processes should not require specialist security knowledge from the user. Security should be “by default,” not requiring user configuration to be active.

Provision 13: Validate Input Data

Devices should validate all input received through user interfaces, APIs, and network services to prevent injection attacks and buffer overflow exploitation.

EN 303 645 and EN 18031: Relationship and Differences

A common source of confusion is the relationship between EN 303 645 and the newer EN 18031 series:

Practical guidance: For radio equipment needing to demonstrate conformity with the RED Delegated Act, EN 18031 is the primary harmonised standard to apply. EN 303 645 remains highly relevant as the baseline reference, for CRA compliance planning, UK market compliance, and as the foundation for many national cybersecurity labelling schemes.

EN 303 645 and National/International Schemes

EN 303 645 has been universally adopted as the technical basis for IoT cybersecurity regulation worldwide:

A product that achieves EN 303 645 compliance has a strong foundation for multiple national market cybersecurity requirements — making it a de facto global baseline.

Conformance Testing: ETSI TS 103 701

ETSI TS 103 701 is the companion test specification for EN 303 645. It provides:

• Specific test cases for each provision
• Defined test methods (black-box, white-box, documentation review)
• Pass/fail criteria for each requirement

Accredited test laboratories use TS 103 701 to produce structured test reports that serve as technical file evidence for regulatory compliance.

Hardware-Level Requirements Summary

From Our Experience

Performing EN 303 645 gap analyses across consumer IoT products, these are the patterns we see most consistently:

Provision 1 fails in roughly 60% of first-time assessments. Despite being the most publicised EN 303 645 requirement, shared default credentials remain the single most common non-conformity we find. The credential is often not admin/admin — manufacturers are aware of that — but rather a device-model-derived default (e.g., last 4 digits of a MAC address) that is algorithmically predictable. ETSI TS 103 701 explicitly tests for predictable per-device credentials, not just universal ones. The fix requires both a hardware-level provisioning change (unique credential generated and injected at manufacturing using an HSM) and a production process change. We recommend treating this as a manufacturing engineering task, not a firmware task.

Provision 6 JTAG discovery: the most common security audit finding. In over 80% of hardware security assessments where we receive production units (not engineering samples), JTAG or SWD debug access remains active. Manufacturers typically test with engineering samples — where JTAG is intentionally enabled — and the production firmware build does not include OTP fuse blowing as a final manufacturing step. The result is a production device where any attacker with a £30 debug probe can dump the entire flash, extract credentials, bypass secure boot, and install arbitrary firmware. We implement a mandatory JTAG-locked verification step in production test fixtures: any unit that responds to a JTAG connection attempt after the production programming step is rejected.

Provision 3 anti-rollback: frequently claimed, rarely implemented correctly. Many manufacturers state that their OTA update system prevents firmware downgrade. In practice, we find this implemented as a software version check in the application firmware — which is trivially bypassed by any attacker who has already compromised the device. Genuine anti-rollback under EN 303 645 requires a hardware monotonic counter in a tamper-resistant memory region that cannot be decremented. On devices without a Secure Element or TrustZone-enabled SoC, this is architecturally impossible to implement correctly in pure software. Selecting a chipset that hardware-supports anti-rollback must be a day-one design decision.

Provision 5 TLS 1.0/1.1 legacy backend connections. A product can have perfect on-device TLS 1.3 implementation — and still fail Provision 5 if the cloud backend it connects to maintains TLS 1.0 or 1.1 support for legacy clients. EN 303 645 tests the negotiated protocol, not just the device’s minimum capability. We find this most frequently in products connecting to existing enterprise backends that were not updated when the device firmware moved to TLS 1.2+. The fix is backend-side, not device-side — and often outside the hardware manufacturer’s direct control if using a shared cloud platform.

Related Terms

• EN 18031 — The successor harmonised standard series for RED Delegated Act compliance, building on EN 303 645 principles.
• RED Delegated Act — The legal instrument that made EN 303 645 / EN 18031 compliance mandatory for internet-connected radio equipment.
• CRA — EU Cyber Resilience Act; EN 303 645 forms part of the technical foundation for CRA cybersecurity requirements.
• Secure Boot — Core hardware requirement triggered by Provision 7.
• OTA Update — Required by Provision 3; must include anti-rollback and signature verification.
• Hardware Root of Trust — Underpins Provisions 4 and 7.

Official Sources

• ETSI EN 303 645 V2.1.1 — free download (etsi.org)
• ETSI TS 103 701 — Conformance test specification for EN 303 645 (free download)
• RED Delegated Act EU 2022/30 — EUR-Lex
• ETSI Cyber Security for Consumer IoT — ETSI overview page

EN 303 645 compliance is increasingly a baseline expectation for connected hardware products entering EU, UK, and global markets. Inovasense performs gap analysis against all 13 EN 303 645 provisions — mapping existing hardware capabilities against each SHALL requirement, identifying hardware or production process changes needed (provisioning, debug port locking, secure storage), and producing test-ready documentation for accredited lab submission. See our embedded security expertise and EU Compliance services.