ETSI TS 103 701 (conformance assessment for consumer IoT), explained

ETSI TS 103 701 is the free companion Technical Specification that turns ETSI EN 303 645's 13 outcome-focused baseline provisions into a repeatable test methodology: concrete test groups, test cases, and pass/fail criteria that a lab, manufacturer or certification scheme can actually run against a device. Its current version, V1.1.1, was published in August 2021 by ETSI's Cyber Security (CYBER) technical committee. Its own Introduction explains why a separate document exists at all: EN 303 645's provisions are "necessarily high-level and outcome-focused" because the standard covers an enormous range of consumer IoT device types, so TS 103 701 "seeks to contribute to a harmonised approach to assessing the conformance of consumer IoT products" against that baseline, independent of any specific certification scheme.

Scope: baseline-depth testing, not a penetration test

TS 103 701's own Scope clause is explicit about how deep the testing goes: the document "intends to contribute to the protection of consumer IoT products against the most common cybersecurity threats," but "multi-medium or highly targeted/sophisticated attacks and thus the invasive analysis of hard- and software modules is out of scope." The test groups "are targeting basic effort regarding test depth and test circumference in accordance to ETSI TS 103 645/ETSI EN 303 645 which addresses a baseline security level." This matters for anyone citing a TS 103 701 assessment as evidence: it demonstrates conformance to a baseline, not resistance to a dedicated, well-resourced attacker — a gap worth stating plainly rather than letting a "conformance assessed" claim imply more than it does.

Three roles: DUT, SO, TL

Role	Who it is
Device Under Test (DUT)	The specific consumer IoT device being assessed, "in live operation," tested via its offered interfaces with partial design knowledge from the IXIT (grey-box testing)
Supplier Organization (SO)	"The developer, manufacturer, vendor or distributor of the DUT" — requests the assessment, completes the ICS and IXIT, and coordinates with its own supply chain to do so
Test Laboratory (TL)	Performs the assessment; clause 4.2.3 allows 1st party (a self-assessing part of the SO), 2nd party (a user organization) or 3rd party (an independent testing authority)

ICS and IXIT: what the supplier has to produce

Before any testing starts, the SO completes two documents, defined in clauses 4.4 and 4.5:

• Implementation Conformance Statement (ICS) — a provision-by-provision Yes/No/N/A claim of what the DUT implements. Mandatory provisions must be claimed "Yes" for an overall PASS to even be possible; every "No" or "N/A" requires a written justification in the ICS's "Detail" column.
• Implementation eXtra Information for Testing (IXIT) — the design detail (password generation mechanisms, update mechanisms, communication mechanisms and so on) that lets the TL actually plan and run tests. The SO only has to complete IXIT entries tied to provisions claimed "Yes," and clause 4.5 allows pointing to existing documentation instead of re-describing it, provided that documentation is handed to the TL.

The six-phase assessment procedure in clause 4.3 runs: (1) identify the DUT, (2) complete the ICS, (3) complete the IXIT, (4) the TL verifies the ICS is internally consistent (e.g. no mandatory provision marked "No"), (5) the TL performs the test groups tied to every "Yes"-claimed provision, and (6) the TL assigns an overall verdict.

Conceptual vs. functional test cases, worked example

Most test groups split into two test-case types (clause 4.1): conceptual test cases check "conformity of the IXIT against the requirements of the provision (conformity of design)," while functional test cases check "conformity of the DUT functionality... against the requirements of the provision (conformity of implementation)." TSO 5.1, "no universal default passwords," shows the pattern concretely:

• Test case 5.1-1-1 (conceptual) — the TL reviews the IXIT's documented "Password Generation Mechanism" for every non-user-defined password and checks on paper whether it "ensures that passwords are unique per device."
• Test case 5.1-1-2 (functional) — the TL then actually probes the device: scanning its network interfaces for password-based authentication mechanisms the SO didn't document in the IXIT (the test text notes "network scanning tools allow for discovery of network-based authentication mechanisms"), confirming user-defined passwords are genuinely required before use, and checking that real passwords on the device don't contradict the documented generation method.

A later test group (5.1-2) adds a concrete password-quality check: assessing whether a pre-installed password generation mechanism "induces obvious regularities" (its own example: incremental counters like "password1", "password2") or draws from common password-dictionary strings, explicitly pointing testers to a published top-100k common-password list as a reference.

PASS, FAIL, INCONCLUSIVE — how verdicts roll up

Clause 4.6 builds verdicts bottom-up through three levels — test case, test group, overall:

Level	PASS condition
Test case	Device-/documentation-specific criteria defined per test case (e.g. the password-uniqueness checks above)
Test group	Every test case in the group passes (FAIL if any test case fails; INCONCLUSIVE if an unresolved test case exists with no FAIL)
Overall	"All selected test groups on the base of the claimed provisions in a valid ICS, at least all mandatory provisions, are fulfilled"

Note 8 under Table 1 contains a practically important escape hatch: a FAIL or INCONCLUSIVE result tied only to a recommended (non-mandatory) provision does not block an overall PASS, provided the SO withdraws that specific provision's claim in the ICS with a justification — the assessment results already gathered can be reused rather than the whole process restarting. Clause 4.7 separately allows a TL to accept external evidence — existing test reports or documentation the SO already holds — instead of independently re-running a test group, as long as that evidence is actually provided.

How this fits with EN 303 645, PSTI and the CRA

TS 103 701 only ever tests against EN 303 645's own provisions (it references TS 103 645/EN 303 645 V2.1.1, 2020-06, as its normative baseline, noting newer provision text may shift which test groups apply). It is not itself named as a conformance route for the UK's PSTI regime or the EU Cyber Resilience Act in the text reviewed for this guide; where a scheme says it accepts a TS 103 701-based assessment report as evidence, treat that scheme's own current rules — not this guide — as authoritative. What TS 103 701 reliably gives a device maker is a structured, auditable self-assessment (or third-party assessment) trail against EN 303 645, which is the same baseline UK PSTI draws its three mandatory requirements from.

A workable starting point

1. Build the ICS before touching the IXIT — claiming provisions "Yes"/"No"/"N/A" first scopes exactly which IXIT entries and test groups actually apply, per Table B.1's provision-to-IXIT mapping.
2. Write the IXIT like a design spec, not a marketing summary — clause 4.5 requires "exhaustive and correct information," and an incomplete IXIT is explicit grounds for an INCONCLUSIVE verdict rather than a benefit-of-the-doubt PASS.
3. Run the conceptual test first, functional test second, as the methodology does — reviewing the documented password/update/communication mechanism design surfaces most gaps before any device-level testing starts.
4. Decide 1st/2nd/3rd-party TL status deliberately. A self-assessment (1st party) is faster and cheaper but carries less weight with a customer or regulator than an independent (3rd party) assessment — pick based on who the conformance claim needs to convince.

SoftWSP's consumer IoT device assessments can be structured around the TS 103 701 ICS/IXIT methodology against the EN 303 645 baseline, alongside the firmware-level CVE and SBOM evidence a conformance claim doesn't otherwise cover: see Device & Firmware Security.

This guide summarises the public ETSI TS 103 701 V1.1.1 (August 2021) documentation; it is not a substitute for the full text and does not constitute compliance or legal advice.