Vigilon Why ETSI EN 303 645 Matters
ETSI EN 303 645 has established itself as the de facto baseline cybersecurity standard for consumer IoT devices globally. It is referenced by regulators in the UK (PSTI Act), the EU (Radio Equipment Directive, Cyber Resilience Act), and has influenced standards in Singapore, India, Australia, and beyond.
For manufacturers, this standard is no longer optional — it is the minimum expectation from regulators, retailers, and increasingly, from consumers themselves.
Practical Guide to All 13 Provisions
Provision 1: No Universal Default Passwords
What it requires: Device passwords must be unique per device, or the user must be required to set a password during initial setup. Universal default passwords (e.g. "admin/admin") are explicitly prohibited.
Common pitfall: Manufacturers sometimes use device-unique passwords but derive them from predictable data (e.g., MAC address). Assessors will check that the derivation method is not trivially reversible.
Provision 2: Vulnerability Disclosure Policy
What it requires: A public point of contact for reporting vulnerabilities, acknowledgement of reports in a timely manner, and a commitment to act on legitimate reports.
Common pitfall: Having a generic "contact us" page is not sufficient. You need a dedicated security contact (e.g., security@yourcompany.com) and a published policy document.
Provision 3: Keep Software Updated
What it requires: Timely security updates, secure update mechanism, clear communication to users about update availability, and a defined support period.
Common pitfall: Not communicating the end-of-support date to users. The standard requires that users know how long they can expect security updates.
Provision 4: Securely Store Credentials
What it requires: Sensitive security parameters must be stored securely with appropriate protection against extraction. Hard-coded credentials in source code are prohibited.
Common pitfall: API keys and credentials stored in unencrypted configuration files or firmware that can be extracted with basic tools.
Provision 5: Communicate Securely
What it requires: Security-sensitive data must be encrypted in transit using best-practice cryptography. This includes device-to-cloud, device-to-device, and device-to-app communications.
Common pitfall: Using TLS but with outdated versions or weak cipher suites, or not validating server certificates properly.
Provision 6: Minimise Exposed Attack Surfaces
What it requires: Unused network services and ports should be disabled. Software should run with least privilege. Hardware debug interfaces should be disabled in production.
Common pitfall: Leaving development services (telnet, SSH with default keys, debug UART) enabled in production firmware.
Provision 7: Ensure Software Integrity
What it requires: Software on the device should be verified using secure boot or similar integrity verification mechanisms. Updates must be verified before installation.
Common pitfall: Implementing signature verification for OTA updates but not for the initial boot process, leaving the device vulnerable to firmware replacement via physical access.
Provision 8: Ensure Personal Data Is Secure
What it requires: Personal data must be protected with appropriate security measures. The device should process and store only the personal data necessary for its functionality.
Provision 9: Resilient to Outages
What it requires: Devices should maintain local functionality when network connectivity is lost and recover gracefully when connectivity is restored.
Provision 10: Examine Telemetry Data
What it requires: If the device collects telemetry data, it should be examined for security anomalies. Any telemetry collection should be transparent to the user.
Provision 11: Easy Deletion of Personal Data
What it requires: Users must be provided with a simple mechanism to delete their personal data from the device and associated services, including during ownership transfer (factory reset).
Provision 12: Easy Installation and Maintenance
What it requires: Setup should guide users towards secure configurations. Security maintenance (updates, password changes) should be straightforward.
Provision 13: Validate Input Data
What it requires: Input data from external sources (APIs, user interfaces, network protocols) must be validated to protect against malformed or malicious input.
Common pitfall: Validating input on the companion app but not on the device firmware itself, leaving the device vulnerable to direct protocol attacks.
Testing Against ETSI TS 103 701
ETSI TS 103 701 is the associated test specification that defines how to assess conformity with EN 303 645. It provides specific test procedures for each provision. During assessment, our testers follow these procedures to generate formal compliance evidence.
Getting Started
If you're developing a consumer IoT device, we recommend:
- Review EN 303 645 requirements during the design phase
- Commission a gap analysis before your product is finalised
- Address findings and carry out penetration testing
- Complete formal assessment against ETSI TS 103 701