ETSI EN 303 645 Requirements

Treat each provision as a control statement you can verify. For product teams, this typically means: a design decision, an implementation pattern, a test plan (conceptual + functional), and an evidence artifact that stays current per release.

When the standard says 'shall', plan for a durable control and objective evidence. When it says 'should', treat it as a risk-based requirement you either implement or explicitly justify with documented rationale and compensating controls.

The standard requires that device passwords (once not in factory default) are unique per device or user-defined, and it sets expectations for password generation and cryptographic best practices for authentication mechanisms.

This is where IoT security programs fail in practice: account provisioning, manufacturing flows, and support tooling must all align so that 'unique per device' is true in the field-not just in a requirement doc.

You must publish a vulnerability disclosure policy with contact information and defined timelines for acknowledgement and status updates until resolution. The standard also sets expectations for timely action on disclosed vulnerabilities.

Operationally, this means you need an intake channel, triage workflow, remediation SLAs, and a way to communicate status updates to reporters and affected stakeholders.

ETSI EN 303 645 sets detailed expectations for updateability, secure installation, usability of updates, automatic updates, update checks, cryptography, authenticity and integrity verification, user notifications, and publishing a defined support period.

Build the update system as a security control: it must resist misuse, prevent downgrade attacks, verify trust relationships, and deliver timely security patches-even when supply-chain dependencies exist.

Sensitive security parameters stored persistently must be stored securely. The standard also sets expectations for resisting tampering when a hard-coded per-device identity is used for security purposes.

In practice, this provision ties together secure storage, manufacturing provisioning, device identity, and incident response: if secrets are extractable, every other control becomes brittle.

The standard addresses securing communications of critical security parameters: encrypt in transit where appropriate and protect confidentiality over remotely accessible interfaces, with secure management processes around those parameters.

This is not 'turn on TLS and forget it'. You need a threat model for your interfaces, certificate/key handling, and a plan for migration when crypto or endpoints change.

ETSI EN 303 645 requires disabling unused network and logical interfaces and minimizing unauthenticated disclosure of security-relevant information. It also addresses physical interface exposure and disabling debug interfaces when physically accessible.

This provision is where you win cheap security: if you ship less surface area, you have less to patch and less to explain in audits.

The integrity provisions focus on preventing unauthorized modification and preserving a trustworthy runtime state. For IoT devices, this often translates into secure boot, signed firmware, and protection of critical runtime components.

Integrity is also an evidence problem: you need to show how integrity is enforced and how integrity failures are detected and handled.

The standard sets expectations for protecting the confidentiality of personal data in transit (especially sensitive personal data) and for documenting external sensing capabilities in a clear, transparent, and accessible way for the user.

A strong implementation links privacy engineering to product UX: data is protected, and the user can understand what the device can sense and transmit.

ETSI EN 303 645 recommends building resilience into devices and services, including local functionality during network outages and clean recovery after power loss.

Resilience is security-relevant: unsafe failure modes become exploitable. Treat outage behavior, state recovery, and 'expected stable state' as part of your security acceptance criteria.

If telemetry is collected, it should be examined for security anomalies. This pushes teams to treat telemetry as a security sensor, not only as a product analytics pipeline.

Telemetry is also a trust boundary: collect minimally, protect it, and ensure anomaly detection does not leak sensitive information.

The standard requires simple deletion of user data from the device and expectations for removing personal data from associated services, with clear instructions and confirmation of deletion where applicable.

Deletion is a lifecycle control: it must work on-device, in associated services, and across customer support flows (returns, resale, transfers).

Installation and maintenance should involve minimal user decisions and follow security best practice on usability. The manufacturer should provide guidance on secure setup and how to check whether the device is securely set up.

Usable security is a compliance multiplier: if secure setup is hard, the field reality will violate your intended controls.

The standard requires validating data input via user interfaces, APIs, and between networks in services and devices. This is the foundation for preventing common classes of vulnerabilities in IoT ecosystems.

Make input validation measurable: schema validation, size and type limits, authentication and authorization checks, and security testing for all externally reachable surfaces.