Artifact GuideGLOBALETSI EN 303 645

ETSI EN 303 645 implementation checklist

A practical checklist for turning ETSI EN 303 645 consumer IoT provisions into owned implementation records and assessment-ready evidence.

Based on EN 303 645 Annex B and ETSI TS 103 701. Use it to organize implementation work, not as a certification claim or legal opinion.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
8

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

Create an for the exact consumer IoT product and software version, then record what is implemented, what is not applicable, what evidence exists, and what still blocks a credible claim. This checklist separates the ETSI EN 303 645 V3.1.3 provisions and Annex B support record from ETSI TS 103 701 V2.1.1 assessment concepts such as DUT, ICS, , test groups, verdicts, and .

Section 1

Confirm the product boundary before filling the checklist

ETSI EN 303 645 applies to consumer IoT devices connected to network infrastructure and to their interactions with . Associated services are digital services that, together with the device, are part of the overall consumer IoT product and are typically required for intended functionality.

Start the checklist by identifying the exact consumer IoT device, software version, interfaces, companion apps, associated-service interactions, support process, and any use-case-determined resource constraints. ETSI TS 103 701 calls the assessed product the and says the most up-to-date software version should be used for assessment.

  • Record the product model and software or firmware version that the checklist covers.
  • List network, logical, physical, user, and API interfaces because many provisions depend on how those interfaces behave.
  • Name and describe the device interactions with them without claiming the services are assessed as standalone services.
  • Identify resource constraints, such as energy supply, processing, memory, or communication bandwidth, only where the use case creates the constraint and it affects a provision.
  • Treat support-period, vulnerability-reporting, update, data-deletion, and user-information workflows as part of the implementation boundary because EN 303 645 includes organizational and user-facing provisions.
Section 2

Use Annex B as the implementation checklist backbone

Annex B of ETSI EN 303 645 is the pro forma. It gives each provision a reference, status, support field, and detail field. The support notation is Y for supported, N for not supported, and N/A where a stated condition is not satisfied or an F-marked feature, capability, or mechanism does not exist.

Keep recommendations visible. EN 303 645 Provision 5.0-1 requires a recorded justification for each recommendation considered not applicable or not fulfilled by the consumer IoT device.

  • Create one row for every provision in the V3.1.3 Annex B table, including 5.0-1, the split A/B provisions, and the clause 6 data-protection provisions.
  • Use the Annex B status markers exactly: M for mandatory, R for recommendation, C for a stated condition, and F where the provision applies only if an identified feature, capability, or mechanism exists. A row can combine these markers.
  • Use support values consistently: Y for supported, N for not supported, and N/A only where Annex B permits it because a stated condition is not satisfied or an F-marked feature, capability, or mechanism does not exist.
  • Fill the detail field with the implemented measure, the reason implementation is not possible or appropriate, or the rationale for N/A.
  • Keep Provision 5.0-1 justifications attached to the checklist rather than burying them in meeting notes or release tickets.
Section 3

Checklist the EN 303 645 security provisions by control family

Group the implementation rows by the EN 303 645 provision families so engineering owners can see what kind of evidence they owe. This is still EN 303 645 implementation work: it records the baseline provisions, their support status, and the implementation detail.

Do not turn this into an unqualified compliance claim. The standard is outcome-focused and sets a security baseline; it does not solve all consumer IoT security challenges or cover prolonged, sophisticated, or sustained physical-access attacks.

  • Passwords and authentication: cover no universal default passwords, per-device or user-defined passwords, change mechanisms, best-practice cryptography, and brute-force resistance where applicable.
  • Vulnerability and update processes: cover public vulnerability disclosure, timely vulnerability handling, monitoring during the defined support period, updateability, secure installation, update authenticity and integrity, user notifications, support-period publication, and model designation.
  • Security parameters and communication: cover secure storage, hard-coded parameter avoidance, unique critical security parameters, secure communication, authentication for network-accessible functions, and secure management of critical security parameters.
  • Attack surface and integrity: cover disabling unused interfaces, minimizing unauthenticated disclosure, physical and debug interface exposure, software-service minimization, code minimization, least privilege, memory access control, secure development, secure boot, and unauthorized-change response.
  • Privacy, resilience, telemetry, deletion, setup, and input validation: cover personal-data confidentiality, external sensing documentation, outage resilience, telemetry anomaly examination when telemetry is collected, simple deletion of user data, secure setup guidance, and input validation.
Section 4

Map implementation rows to TS 103 701 IXIT evidence

ETSI TS 103 701 is assessment guidance for EN 303 645; it does not supersede the EN 303 645 provisions. Use it after the implementation checklist has a support status so each Yes claim can be mapped to the entries needed for assessment.

TS 103 701 says the Supplier Organization completes the necessary information for provisions claimed as "Yes" in the assessment ICS, and its Table B.1 maps provisions to IXIT entries. This wording belongs to the TS assessment method; the EN Annex B pro forma displays Y in its support notation. Incomplete or insufficient IXIT can lead to an inconclusive verdict when proper test execution is not possible.

  • For authentication provisions, prepare 1-AuthMech and related user-information entries where required.
  • For vulnerability disclosure, updates, and support-period claims, prepare 2-UserInfo, IXIT 3-VulnTypes, IXIT 4-Conf, IXIT 5-VulnMon, IXIT 6-SoftComp, IXIT 7-UpdMech, IXIT 8-UpdProc, and IXIT 9-ReplSup as applicable.
  • For communication, attack-surface, and software-integrity claims, prepare entries for security parameters, secure communication mechanisms, network security implementations, software services, interfaces, code minimization, privilege control, access control, secure development, and secure boot.
  • For privacy, telemetry, deletion, setup, and input validation claims, prepare entries for personal data, external sensors, resilience mechanisms, telemetry data, deletion functionality, user decisions, user interfaces, logical interfaces, and input validation.
  • Use stable identifiers so test cases, evidence files, and reviewer comments can refer to the exact implementation element.
Section 5

Run the assessment-readiness gate

A useful implementation checklist should expose assessment gaps even before a formal scheme is selected. TS 103 701 describes an abstract procedure: identify the DUT, complete the ICS, complete the , verify the ICS, perform the assessment, and assign an overall verdict. The selected scheme can add requirements for tester competence, cryptography, accepted , and publication of results.

Use that procedure as a readiness gate, not as proof that the product has passed. The Test Laboratory derives a test plan from the ICS and , chooses test methods, equipment, conditions, and instructions, and assigns verdicts to test cases, test groups, and the overall assessment.

  • Check that no mandatory provision is marked N in the ICS.
  • Check every N/A claim against product behavior, user documentation, DUT identification, and content.
  • Prepare conceptual evidence for design claims and functional evidence for behavior that must be exercised on the DUT or its relevant interactions.
  • Keep public documents ready for verification where a test case checks publication, such as vulnerability disclosure policy or support-period information.
  • Track PASS, FAIL, and INCONCLUSIVE risks at the provision and test-group level instead of using one undocumented traffic-light status.
Section 6

Use external evidence without overstating it

TS 103 701 allows existing security certifications or third-party evaluations of parts of the DUT to be used partially as evidence to reduce assessment effort. That is narrower than saying a product is automatically EN 303 645 compliant because one component has a certificate.

needs to be announced in the ICS detail field, supplied to the Test Laboratory, and checked for scope, test activities, and test depth or evaluation assurance level against the corresponding test group. Keep this distinction visible in the checklist.

  • Attach only to the provision or test group it actually supports.
  • Record product version, component version, assessment boundary, evidence issuer, date or report identifier, and any limitations visible in the evidence.
  • Do not reuse another product's assessment result unless the DUT boundary, implementation, and claimed provision match.
  • Do not convert for a library, component, cloud process, or partial feature into a broad product-level conformance claim.
  • Record the EN 303 645 and TS 103 701 versions used for the checklist because the cited ETSI deliverables state that they may be revised or have their status changed.
Primary sources

References and citations

etsi.org
Referenced sections
  • Defines IXIT, grey-box testing, completion for provisions claimed as Yes, inconclusive-verdict risk from insufficient IXIT, and the Annex B mapping from provisions and test groups to required IXIT entries.
"Implementation eXtra Information for Testing"
Related guides

Explore more topics

ETSI EN 303 645 Applicability and Scope
Decide whether a connected product is in scope of ETSI EN 303 645, define the consumer IoT evidence boundary, and document N/A justifications for assessment.
ETSI EN 303 645 compliance: ICS, IXIT, evidence
Plan ETSI EN 303 645 compliance evidence for consumer IoT products with scope, ICS, IXIT, TS 103 701 assessment steps, verdict risks, and cited controls.
ETSI EN 303 645 consumer IoT products: what is in scope?
Decide whether a device and its associated services are in scope of ETSI EN 303 645 V3.1.3 and document the DUT, ICS, IXIT, and assessment boundary.
ETSI EN 303 645 Current Version Tracker
Track ETSI EN 303 645 version evidence, ETSI deliverable status checks, TS 103 701 assessment alignment, and change triggers for consumer IoT security work.
ETSI EN 303 645 CVD Workflow for IoT Vulnerability Reports
Cited workflow for ETSI EN 303 645 vulnerability disclosure: public policy contents, reporting contact, acknowledgement and status timelines, timely action, and TS 103 701 evidence.
ETSI EN 303 645 Data Protection Provisions
Guide to ETSI EN 303 645 data protection provisions for consumer IoT, including security, consent, telemetry, deletion, minimization, aggregation, and anonymization.
ETSI EN 303 645 default passwords: what must consumer IoT teams do?
ETSI EN 303 645 default password guidance for consumer IoT: unique or user-defined passwords, pre-installed password generation, change mechanisms, brute-force controls, and TS 103 701 evidence.
ETSI EN 303 645 FAQ: Consumer IoT Security Questions
Practical answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, passwords, updates, vulnerability disclosure, telemetry, deletion, and assessment evidence.
ETSI EN 303 645 ICS and IXIT Evidence Template
Build a cited ICS and IXIT evidence template for ETSI EN 303 645 consumer IoT assessments, with clear separation between EN provisions and TS 103 701 test information.
ETSI EN 303 645 Implementation Evidence Guide
Build ETSI EN 303 645 implementation evidence from Annex B support/detail records, TS 103 701 ICS and IXIT inputs, test verdicts, and scoped external evidence.
ETSI EN 303 645 IoT Applicability Workflow
Decide whether ETSI EN 303 645 applies to a consumer IoT product, what associated services belong in scope, and how to record justified non-applicability.
ETSI EN 303 645 personal data deletion FAQ for consumer IoT
What ETSI EN 303 645 says about deleting user data and personal data from consumer IoT devices, associated services, apps, and evidence records.
ETSI EN 303 645 requirements: consumer IoT provision map
Map ETSI EN 303 645 consumer IoT requirements to product scope, Annex B ICS entries, TS 103 701 evidence, and implementation owners.
ETSI EN 303 645 Secure Update Evidence Workflow
Build secure-update evidence for ETSI EN 303 645 using provision 5.3, Annex B support/detail records, and TS 103 701 ICS, IXIT, and test-plan inputs.
ETSI EN 303 645 Secure Update Workflow
Map ETSI EN 303 645 secure-update provisions into a practical workflow for consumer IoT update mechanisms, support-period disclosures, and TS 103 701 evidence.
ETSI EN 303 645 Secure Updates and Vulnerability Disclosure
Source-backed guide to ETSI EN 303 645 clauses 5.2 and 5.3 for consumer IoT vulnerability disclosure, security updates, support periods, and assessment evidence.
ETSI EN 303 645 support period: what must consumer IoT teams publish?
ETSI EN 303 645 support-period guidance for consumer IoT: defined security-update support periods, user-accessible publication, non-updateable-device replacement support, model designation, and TS 103 701 evidence.
ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?
ETSI EN 303 645 telemetry guidance for consumer IoT teams: security anomaly examination, IXIT 24-TelData evidence, personal-data minimization, and consumer telemetry disclosures.
ETSI EN 303 645 test evidence: what should consumer IoT teams keep?
ETSI EN 303 645 test evidence guidance for consumer IoT teams: ICS support claims, IXIT detail, TS 103 701 test plans, verdicts, and external evidence checks.
ETSI EN 303 645 vs EU CRA for Consumer IoT
Compare ETSI EN 303 645 consumer IoT evidence with the EU Cyber Resilience Act's scope, manufacturer duties, application dates, and conformity requirements.
ETSI EN 303 645 vs RED Cybersecurity Delegated Act
Compare ETSI EN 303 645 consumer IoT evidence with the RED cybersecurity requirements, EN 18031 standards, application date, and conformity routes.
ETSI EN 303 645 vs UK PSTI: Evidence Crosswalk
Compare ETSI EN 303 645 evidence with UK PSTI scope, three mandatory security requirements, statements of compliance, duties, and enforcement.
ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT
What ETSI EN 303 645 requires for consumer IoT vulnerability disclosure policies, report handling, status updates, timely action, and TS 103 701 evidence.
ETSI TS 103 701 Test Evidence Workflow for EN 303 645
Build an ETSI TS 103 701 test evidence workflow for EN 303 645 consumer IoT assessments: DUT identification, ICS, IXIT, test plans, verdicts, and external evidence.
How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products?
How ETSI EN 303 645 V3.1.3 treats use-case resource constraints, non-updateable devices, N/A claims, authentication controls, and assessment evidence.