ETSI EN 303 645

The manufacturer shall publish a Statement of Implementation, identifying for each provision in the standard whether the provision is implemented, the justification for any non-implementation, and the specific reason for any provision marked as not applicable. The Statement is the basis for conformity claims.

• Published Implementation Conformance Statement (ICS) per product/model
• Justification per non-implemented provision

• No ICS published
• Blanket-not-applicable claims without specific justification

Where passwords are used and in any state other than the factory default, all consumer IoT device passwords shall be unique per device or defined by the user. Pre-installed unique per-device passwords shall be generated by a mechanism that reduces the risk of automated attacks against a class or type of device.

• Per-device unique-password generation evidence
• User-set password enforcement at first use

• Single shared default password across the product line
• Predictable per-device defaults

If telemetry data is collected from consumer IoT devices and services, it shall be examined for security anomalies. Telemetry collection and use shall be transparent to the user.

• Telemetry inventory and security-analysis pipeline
• User-facing telemetry disclosure

• Telemetry collected but not examined for anomalies
• No user disclosure of telemetry collection

User data on devices and on associated services shall be easily deletable; the deletion mechanism shall be available to the user via simple steps; deletion shall be confirmed; and where data is transferred or shared, deletion shall propagate where feasible.

• User-facing delete-data path and confirmation
• Service-side deletion propagation evidence

• Hidden or absent delete-data function
• No service-side deletion on factory reset

Installation and maintenance of consumer IoT devices shall employ minimal steps and shall follow security best practice on usability. Manufacturer-provided instructions shall be clear and accessible to users.

• Setup-flow security best-practice review
• Clear user guidance for secure installation

• Setup that defaults to insecure configuration
• Maintenance steps that require user-level cryptographic operations

Data input via user interfaces and transferred between consumer IoT devices, devices and associated services shall be validated, including for length, structure and content; protocol or API misuse shall not undermine security.

• Input-validation design across interfaces and APIs
• Fuzzing and abuse-case test evidence

• No input validation on device-to-service API
• Buffer / injection issues from un-validated inputs

The manufacturer shall make available to the public a vulnerability disclosure policy, including a contact for the disclosure of vulnerabilities and an acknowledgement timeline; received reports shall be acted on within a reasonable time, with status updates to the reporter.

• Published vulnerability disclosure policy and contact
• Disclosure-pipeline records and SLA evidence

• No published disclosure policy
• No acknowledgement / triage process

Software components in consumer IoT devices shall be securely updateable; the manufacturer shall publish a defined support period during which security updates are provided; updates shall be timely and shall not adversely affect the function of the device. Where the device is not updateable, the rationale, replacement period and disposal information shall be published.

• Defined and published support period
• Secure update mechanism (signed, integrity-checked)
• Update-history records

• No published support period
• Updates without integrity protection
• No replacement guidance for non-updateable devices

Sensitive security parameters (e.g. cryptographic keys, credentials) in persistent storage shall be securely stored, protected against tampering and unauthorised disclosure; secure storage should use hardware-protected secure elements or equivalent mechanisms where feasible.

• Storage-protection design evidence (e.g. secure element/TPM/keystore)
• Threat-model coverage of physical-extraction attacks

• Plaintext storage of credentials/keys
• Keys in source or shipped firmware

Consumer IoT devices shall use best-practice cryptography to protect personal data and security-sensitive data in transit; cryptographic algorithms and protocols shall be reviewed regularly. Devices shall mutually authenticate where appropriate, and credentials shall not be sent in clear over the network.

• TLS / current best-practice cryptographic configuration evidence
• Mutual-authentication design where applicable
• Periodic cryptography review

• Plaintext credentials over network
• Outdated TLS/cipher suites

Consumer IoT devices shall minimise exposed attack surfaces by adopting the principle of least functionality: unused services and ports shall be disabled by default; hardware shall not be unnecessarily exposed; debug interfaces shall be disabled in shipped product.

• Port/service inventory with default-disabled posture
• Hardware/debug interface lockdown in production builds

• Open debug ports / serial consoles shipped enabled
• Default-on services not required by typical use

Consumer IoT devices shall verify their software using secure boot mechanisms, and a verifiable record shall be available. If an unauthorised change is detected, the device shall alert and limit functionality.

• Secure-boot design and verification evidence
• Unauthorised-change detection and response behaviour

• No secure boot
• No integrity check on critical software components

Personal data shall be protected by appropriate technical and organisational measures. Where personal data is transmitted between a device and a service, it shall be transmitted using best-practice cryptography. Devices shall provide cryptographic mechanisms with adequate cryptographic strength.

• Personal-data classification and protection design
• End-to-end protection of personal data in transit

• Unencrypted personal-data flows
• Weak cryptography on personal-data channels

Resilience shall be built into consumer IoT devices and services so that they can return to a usable state where appropriate, in the case of a network or power outage; devices shall continue to operate locally where applicable.

• Outage-mode design and tested recovery
• Local-operation capabilities where applicable

• Total dependence on cloud connectivity
• No documented recovery from network/power outage

Where personal data is processed by consumer IoT devices and services, the manufacturer/operator shall: provide transparent and accessible information about the processing of personal data, the purposes and lawful bases; obtain consent where required and provide a mechanism to withdraw consent; provide a means to opt out of telemetry/usage data where not strictly necessary; minimise the data collected and retained; and maintain a privacy-by-design design approach throughout the device lifecycle.

• Privacy notice for the device/service
• Consent and withdrawal records where consent is the lawful basis
• Telemetry opt-out where applicable
• Data-minimisation evidence in design

• No privacy information at first use
• Telemetry forced on with no opt-out where not strictly necessary
• No data-retention/deletion guarantees