EN 303 645

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 groups of security provisions and a set of data protection provisions (nine in the current version) that establish the minimum cybersecurity posture any internet-connected consumer device should have.

EN 303 645 is a voluntary baseline: it is not referenced in the RED Delegated Act or the CRA, but it is referenced in the UK’s product security regulations and has served as the basis for national cybersecurity labelling schemes in Singapore and Germany, and in Finland until new labels ceased in 2024.

Key Facts

The 13 Security Provisions

EN 303 645 groups its security provisions into 13 clauses (5.1–5.13). Each individual provision is either mandatory (SHALL) or a recommendation (SHOULD); clauses 5.7, 5.9, 5.10 and 5.12 contain recommendations only. A recommendation that is not applied has to be justified in writing (provision 5.0-1):

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 timeline for initial acknowledgement of a report
• States the timelines for status updates until the issue is resolved

This is an organisational requirement — not a hardware requirement. Acting on reports in a timely manner and continuous vulnerability monitoring are recommendations.

Provision 3: Keep Software Updated

Devices must have a secure update mechanism, unless a resource constraint of the use case prevents it, and:

• Update processes must be simple for the user (not require specialist knowledge)
• Updates delivered over a network must be verified for authenticity and integrity
• Updates must be timely — critical vulnerabilities must be addressed promptly
• The manufacturer must publish the defined support period
• Notifying the user that a security update is required is a recommendation

Hardware implication: The standard does not mandate OTA delivery or rollback protection; it mentions a version-check anti-rollback policy only as an example. Rollback protection is still sound practice. 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

The device must use best practice cryptography to communicate securely; the standard deliberately names no protocols or versions. In addition:

• Protected secrets — critical security parameters sent over remotely accessible interfaces must be confidentiality-protected
• Authenticated configuration — security-relevant configuration changes over a network must require authentication
• Recommended — authentication before any network access to device functions

The standard itself sets no TLS version: deprecated protocols (SSLv3, TLS 1.0, WEP, WPA) are not best practice, and TLS 1.2 or later (TLS 1.3 preferred) is the usual reading for internet communications — an interpretation, not standard text.

Provision 6: Minimise Exposed Attack Surfaces

The device should expose only what its intended functionality needs:

• Unused network interfaces and network-accessible logical interfaces must be disabled
• Debug interfaces (JTAG, SWD, UART) must be disabled or protected by authentication or access control
• Enabling only required software services and running software with least privilege are recommendations

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 should verify its software and react to unauthorised changes — the provisions in this group are recommendations (SHOULD), not mandatory requirements:

• Secure boot — the device should verify its software using secure boot mechanisms
• Update validation — covered by Provision 3 (mandatory for updates delivered over a network)
• If an unauthorised software change is detected, the device should alert the user or administrator

Hardware implication: The standard names a hardware root of trust as one way to support secure boot; it does not mandate one. A full secure boot chain from boot ROM through application firmware, anchored in hardware (OTP-fused root key), is the robust implementation — software-only integrity checks can be bypassed.

Provision 8: Ensure Personal Data Security

This group covers personal data in transit and the device’s sensors:

• Sensitive personal data sent to associated services must be confidentiality-protected with best practice cryptography (recommended for other personal data)
• All external sensing capabilities (e.g. optical or acoustic sensors) must be documented clearly for the user

Consent and transparency are covered by the separate data protection provisions (clause 6); erasing user data by Provision 11.

Provision 9: Make Systems Resilient to Outages

Devices should remain operating and locally functional when network access is lost, and should:

• Recover cleanly when power is restored after an outage
• Reconnect to networks in an orderly way

Provision 10: Examine System Telemetry Data

If telemetry data is collected from devices, it should be examined for security anomalies. This is a recommendation (SHOULD), not a requirement (SHALL).

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

Devices must give users a simple way to erase their user data from the device (mandatory). Deleting personal data from associated services, clear instructions and confirmation of deletion are recommendations.

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 must validate data input via user interfaces and via network interfaces, including APIs, to prevent manipulation and failures such as injection attacks (mandatory).

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 in scope of the RED Delegated Act, EN 18031 is the harmonised standard series cited in the Official Journal; applying it is voluntary and the presumption of conformity is subject to the published restrictions. EN 303 645 gives no presumption of conformity under RED, but remains useful as a baseline, for UK market compliance and for labelling schemes built on it.

EN 303 645 and National/International Schemes

EN 303 645 has been used as the technical basis for several national consumer IoT schemes:

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 Implications 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. EN 303 645 does not itself require anti-rollback — it mentions a version-check policy only as an example — but in our view robust anti-rollback needs 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 support TLS 1.3 on the device — and still raise a Provision 5 finding if it accepts a downgrade to TLS 1.0 or 1.1 because the cloud backend it connects to still offers those versions for legacy clients. EN 303 645 itself defines no tests; the companion ETSI TS 103 701 checks the cryptography the device actually uses against what the manufacturer declared. 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 to stop offering deprecated versions on the backend and to have the device refuse them — and the backend side is often outside the hardware manufacturer’s direct control if using a shared cloud platform.

Related Terms

• EN 18031 — The harmonised standard series cited for the RED Delegated Act; a separate CEN-CENELEC work, not a new edition of EN 303 645.
• RED Delegated Act — The legal instrument that made the RED Article 3(3)(d), (e) and (f) cybersecurity requirements applicable to specified categories of radio equipment from 1 August 2025; it mandates no specific standard.
• CRA — EU Cyber Resilience Act; it does not reference EN 303 645 — its harmonised standards are being developed separately by CEN, CENELEC and ETSI.
• Secure Boot — Recommended by Provision 7 (a SHOULD, not a mandatory requirement).
• OTA Update — Provision 3 requires a secure update mechanism and verification of updates delivered over a network; anti-rollback appears only as an example.
• Hardware Root of Trust — Underpins Provisions 4 and 7.

Official Sources

• ETSI EN 303 645 V3.1.3 — free download (etsi.org)
• ETSI TS 103 701 V2.1.1 — Conformance assessment specification for EN 303 645 (free download)
• RED Delegated Act EU 2022/30 — EUR-Lex
• ETSI releases world-leading Consumer IoT Security standard — ETSI press release (June 2020)

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.