ETSI TR 103 621 (implementation guide to EN 303 645), explained

ETSI TR 103 621, "Guide to Cyber Security for Consumer Internet of Things," is the worked-examples companion to ETSI EN 303 645's baseline requirements. Where EN 303 645 states outcomes ("the consumer IoT device shall have a secure update mechanism") and ETSI TS 103 701 defines how to test for them, TR 103 621 answers the question a firmware team actually asks first: what does meeting this provision look like in practice? Currently at V2.1.1 (July 2025), it is freely downloadable from ETSI — unlike the paywalled IEC/ISO standards covered elsewhere on this site — and this guide was written directly from that published text.

What it is, and what it deliberately isn't

Clause 1's scope states the document "serves as guidance to help manufacturers and other stakeholders in meeting the cyber security provisions defined for Consumer IoT devices in ETSI EN 303 645 and ETSI TS 103 645," and is "complementary to ETSI EN 303 645 and ETSI TS 103 701." The Introduction is explicit about the division of labour: EN 303 645 "provides baseline cyber security provisions for a wide range of Consumer IoT products and remains outcome focused," while TS 103 701 "deals with the assessment of conformance of IoT products against the provisions." TR 103 621 fills the gap between the two — it "guide[s] manufacturers on its implementation, by providing non-exhaustive examples of practical solutions that can be used to meet these provisions."

Two limits matter as much as the purpose. First, the examples are explicitly non-exhaustive and non-binding: "the examples provided herein are not limitative; it is possible to meet the provisions in ETSI EN 303 645 by using other solutions." Second, Clause 5 states examples "are not given in a specific qualitative order" — example 1 under a given provision is not necessarily better than example 2 or 3, they are simply ordered "from the most widely applicable examples to the more specific ones." A manufacturer reading TR 103 621 is meant to find a workable approach, not the single correct one.

How it sits between EN 303 645 and TS 103 701

Document	Role
ETSI EN 303 645	States the outcome-focused baseline requirements ("shall"/"should" provisions)
ETSI TR 103 621 (this guide)	Non-exhaustive worked examples of how to meet each provision
ETSI TS 103 701	Defines the conformance-assessment methodology (ICS/IXIT, test cases) used to test against EN 303 645

Clause 4.3 notes a practical feedback loop: TR 103 621's examples, once implemented, "can be used (when implemented) to inform the definition of test scenarios and the development of a test plan based on ETSI TS 103 701," and a domain-specific specialization of EN 303 645 "can allow more precise examples to be provided which, when implemented, would allow more precise test scenarios and test plan, leading to stronger certainty on the test expectations and outcomes." TR 103 621 itself cites TS 103 701 V2.1.1 (2025-04) as its current companion edition in its own reference list — a newer edition than the V1.1.1 (2021-08) this site's TS 103 701 guide currently covers; treat TS 103 701's own latest publication page as authoritative for which edition is current.

What the examples actually look like

Clause 6 works through essentially every numbered EN 303 645 Clause 5 provision in order — authentication (5.1-x), vulnerability disclosure (5.2-x), secure update mechanisms (5.3-x, the longest section at 18 provisions), secure storage and critical security parameters (5.4-x), secure communication (5.5-x), minimized attack surface (5.6-x), software integrity (5.7-x), personal data protection (5.8-x), resilience (5.9-x), telemetry (5.10-x), deletion of personal data (5.11-x), installation and maintenance (5.12-x), and input validation (5.13-x). Two representative examples:

• Provision 5.3-8 ("Security updates shall be timely"): the guide gives three examples, including a manufacturer process where "the security update creation is triggered within 14 days and the update is published within 90 days," and explains EN 303 645's own "bulletin process" language with a worked example of notifying users via a bulletin website, newsletter and social media after a fix ships.
• Provision 5.2-1 (public vulnerability disclosure policy): examples include a dedicated policy page following ETSI TR 103 838's CVD guide or ISO/IEC 29147, or using a third-party vulnerability-reporting service such as the IoT Security Foundation's or HackerOne's, to "remain up-to-date on CVD best practice and avoid the resource needed to create a bespoke policy."

Clause 7 mirrors this structure for EN 303 645's Clause 6 data-protection provisions (transparency about processing, consent, telemetry data minimization, and deletion/anonymization), and Annex A and Annex B give worked examples clarifying EN 303 645's physical/logical/user interface categories and its conditional/feature-based provision model respectively — including the rule-of-thumb that "every interface, that is used to physically connect the device to another device... is a physical interface," distinct from logical interfaces reachable only through another connected device.

When a recommendation legitimately can't be followed

Clause 8.1 states a principle that runs through the whole document: "not supporting a given recommendation has an impact on the security provided by the device," and whether that's acceptable is a risk-management judgment, not a free pass — "a risk analysis from the manufacturer or a third party could conclude that a given use case should not be implemented in case some recommendations are not supported." Clause 8.2 then works through more than 30 specific provisions with a concrete example of a defensible justification for each. Representative cases:

• Provision 5.3-1 (components should be securely updateable): "the software of a battery charge controller is not meant to be modified once it has been vetted for safety."
• Provision 5.9-1 (resilience to network/power outages): "the device is a temperature sensor that only provides on-demand temperature readings; resilience is not an important aspect for this device."
• Provision 5.6-9 (secure development processes): "the manufacturer is rebranding the device, which is obtained from a supplier under white label."

This matters because EN 303 645's own Provision 5.0-1 already requires "a justification... recorded for each recommendation... that is considered to be not applicable for or not fulfilled" — Clause 8 of TR 103 621 is what turns that requirement from an abstract obligation into a library of defensible, pre-written justification patterns a manufacturer can adapt rather than invent from scratch.

A discussion beyond the technical provisions

Clause 5 includes a section not found in the baseline standard itself: a discussion of consumer IoT misuse for domestic abuse and coercive control, covering audio/video recording and replay, data manipulation or unintended disclosure, shared-account access enabling social stalking, and remote control of locks or heating. Citing published research on the topic, it recommends three categories of mitigation — legal policy to prosecute abusers, technology that can evidence misuse "without violating data protection/privacy regulations," and awareness-raising for stakeholders — while noting that technical mitigation "might not eliminate the risk entirely." This sits alongside the provision-by-provision guidance as a reminder that EN 303 645's authentication, access-control and data-deletion provisions carry safety implications beyond the usual confidentiality/integrity/availability framing.

A workable starting point

1. Read TR 103 621 provision-by-provision alongside EN 303 645's own text, not as a standalone document — the examples assume you already have the exact provision wording in front of you, and the guide repeatedly says EN 303 645 itself also contains examples worth checking first.
2. Don't treat example 1 as "the recommended way" — Clause 5 states examples are ordered by applicability, not quality; pick the one that fits your device's actual constraints (constrained MCU vs. full OS, networked vs. air-gapped, battery vs. mains power).
3. Use Clause 8 as a template for your own justification file, not just a reference to read once — EN 303 645's Provision 5.0-1 already obligates you to record a justification for every unmet recommendation, and Clause 8.2's worked examples show the level of specificity a credible one needs.
4. Check which TS 103 701 edition TR 103 621 itself cites before building a conformance-assessment plan — TR 103 621 V2.1.1 references TS 103 701 V2.1.1 (2025-04), which may be newer than other summaries in circulation.
5. Treat the domestic-abuse misuse discussion as in-scope for your threat model, not a footnote — it affects how you design shared-account access, activity logging and remote-control features, not just how you write documentation.

SoftWSP's firmware and device assessments can map a product's actual implementation against TR 103 621's worked examples provision-by-provision, surfacing where a device's approach diverges from EN 303 645's outcome rather than just flagging the provision number: see Device & Firmware Security.

This guide quotes ETSI's own freely published text of ETSI TR 103 621 V2.1.1 (2025-07); it is not a substitute for the full published document and does not constitute compliance or legal advice.