As our homes and workplaces fill with “smart” devices—from thermostats and cameras to coffee machines—the surface area for cyberattacks grows. To combat these risks, the European Telecommunications Standards Institute (ETSI) released EN 303 645.
This standard isn’t just a dry regulatory document; it is the global “gold standard” for consumer IoT security. It provides a baseline to ensure that “smart” doesn’t mean “vulnerable.” This guide breaks down the core provisions of the standard and explains what they mean for the people building the next generation of tech.
The 13 Key Provisions of ETSI EN 303 645
The standard is built around 13 specific areas of security. Here is a breakdown of the core requirements and how they impact the design process.
1. No Default Passwords
Summary: Many IoT attacks happen because devices ship with “admin/admin” or “1234” as credentials. The standard mandates that all passwords must be unique per device or defined by the user during the first setup. This prevents “botnets” from taking over thousands of devices simultaneously using a single known password.
What it means: You must implement a mechanism for unique per-device credentials at the factory or force a password change during the initial setup. This often requires a unique QR code or sticker on each physical unit.
2. Implement a Vulnerability Disclosure Policy
Summary: Security is a process, not a destination. Companies must have a public point of contact so security researchers can report flaws before hackers exploit them. This ensures that the manufacturer is part of the global security community rather than being caught off guard by “Zero Day” exploits.
What it means: You need to establish a clear internal pipeline for receiving, triaging, and fixing reported bugs. This includes maintaining a “security.txt” file or a dedicated web page for researchers.
3. Keep Software Updated
Summary: Devices must be able to receive security updates, and these updates must be delivered in a secure manner. The standard also requires manufacturers to state clearly how long a device will be supported with security patches.
What it means: Design an Over-the-Air (OTA) update mechanism that verifies the authenticity of the software (using digital signatures) so a hacker can’t “update” your device with malicious code.
4. Securely Store Sensitive Security Parameters
Summary: Hard-coded API keys or credentials stored in plain text are a goldmine for attackers who gain physical access to a device. These must be stored in a way that makes them difficult to extract even if the hardware is dismantled.
What it means: Use secure enclaves, Trusted Execution Environments (TEEs), or hardware security modules (HSMs) rather than storing secrets in standard, easily readable flash memory.
5. Communicate Securely
Summary: Data moving between the device and the cloud (or app) should be encrypted. This prevents “Man-in-the-Middle” attacks where a hacker on the same Wi-Fi network snoops on private data or sends fake commands to the device.
What it means: Use industry-standard protocols like TLS (Transport Layer Security) rather than proprietary, unencrypted methods. Ensure that the device validates the certificates of the servers it connects to.
6. Minimize Exposed Attack Surfaces
Summary: If a feature or “port” isn’t necessary, it should be closed. Every open communication channel is a potential door that a hacker might try to kick down.
What it means: Disable debug ports (like UART or JTAG) on production hardware and close any unused network ports. Follow the principle of “least privilege” for all software services.
7. Ensure Software Integrity
Summary: The device should check that its own software hasn’t been tampered with during boot-up or operation. If the firmware has been modified by an unauthorized party, the device should refuse to run to prevent it from becoming a “spy” in the home.
What it means: Implement “Secure Boot” if possible. This uses a chain of trust to ensure the device only runs code signed by the manufacturer’s private key. However on smaller devices this may not be possible so an alternative scheme may be required.
8. Ensure Personal Data is Protected
Summary: This aligns with GDPR and other privacy laws. Devices must handle user data with privacy in mind, ensuring that only the minimum necessary information is collected and that it is stored securely.
What it means: Incorporate “Privacy by Design.” Minimize data collection and ensure any personal data stored on the device or cloud is encrypted at rest.
9. Make Systems Resilient to Outages
Summary: A loss of network or power shouldn’t leave a device in an “unsafe” or permanently broken state. Critical functions—like a smart lock or a smoke detector—must maintain basic local functionality even if the internet goes down.
What it means: Design your local logic so the device remains functional (or fails gracefully) if the cloud goes offline. Avoid “cloud-only” dependencies for safety-critical operations.
10. Examine System Telemetry Data
Summary: If a device is being attacked, the manufacturer should be able to see the “smoke” before the “fire.” Monitoring for unusual patterns, such as repeated login failures, helps companies react to new threats quickly.
What it means: Log security-relevant events (like failed login attempts) without collecting sensitive personal information. Ensure these logs are transmitted securely to your monitoring system.
11. Make it Easy for Users to Delete Personal Data
Summary: When a user sells or recycles a device, they should be able to wipe it easily. This prevents the next owner from accessing the previous user’s Wi-Fi passwords or personal account details.
What it means: Create a simple, verifiable “Factory Reset” function that securely erases all user-specific data, credentials, and configuration files.
12. Make Installation and Maintenance Easy
Summary: Security shouldn’t be so hard that users skip it. If a security feature is too annoying or complex, users will find a way to disable it, leaving them vulnerable.
What it means: Ensure the setup process guides the user through security steps (like setting a strong password) intuitively. Provide clear, jargon-free feedback if a security setting needs attention.
13. Validate Input Data
Summary: Don’t trust data coming from the internet; it could be a “buffer overflow” attack in disguise. Every piece of information received from an external source must be checked to ensure it fits the expected format and size.
What it means: Always sanitize and validate any data input from users or external APIs. Use modern programming practices to prevent common memory-related exploits and injection attacks.
Summary and Conclusion
ETSI EN 303 645 isn’t just about preventing a single hack; it’s about building a culture of security. For the layman, it provides peace of mind that a product has met a rigorous international benchmark. For the product designer, it serves as a comprehensive roadmap to ensure that security is “baked in” from the first prototype rather than “bolted on” as an afterthought.
By adhering to these 13 points, manufacturers can protect their brand reputation, comply with emerging global regulations (like the UK’s PSTI Act or the EU’s Cyber Resilience Act), and, most importantly, protect the privacy and safety of their customers in an increasingly connected world.
