Artifact GuideGLOBALETSI EN 303 645

ETSI EN 303 645 Implementation Evidence

Build an evidence pack that connects EN 303 645 implementation claims to Annex B support/detail records and TS 103 701 assessment inputs.

Use EN 303 645 for provisions and implementation reporting; use TS 103 701 for DUT, ICS, IXIT, test-plan, verdict, and external-evidence assessment concepts.

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

Structured answer sets in this page tree.

Primary sources
2

Cited legal and guidance references.

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

Build an for one identified consumer IoT product and software version. The pack should show what the product implements, why each provision is supported, not supported, or not applicable, and which assessment record backs the claim. ETSI EN 303 645 V3.1.3 defines the baseline provisions and Annex B implementation conformance statement; ETSI TS 103 701 V2.1.1 describes assessment through identification, , , test groups, verdicts, and .

Section 1

Start with EN 303 645 implementation reporting

Implementation evidence should begin with the EN 303 645 provision map, not with a generic audit checklist. Provision 5.0-1 requires recorded justification for each recommendation treated as not applicable or not fulfilled, and Annex B gives a structured table for provision references, status, support, and implementation detail.

For each provision, identify the consumer IoT product, provision reference, Annex B M or R status, any C or F marker, Y, N, or N/A support value, and detail explaining the implemented measure, why implementation is not possible or appropriate, or why a condition or feature does not apply.

  • Use EN 303 645 provision references as the source of the obligation or recommendation.
  • Use Annex B support/detail entries to separate supported implementation, unsupported implementation, and justified non-applicability.
  • For recommended provisions marked not applicable or not fulfilled, record a justification instead of leaving a silent exception.
  • Treat use-case-determined resource constraints and missing product functionality as evidence questions that need explicit rationale, not as automatic exemptions.
  • Keep the product's risk assessment and threat model beside the provision map. EN 303 645 says they inform implementation but places the risk-assessment and threat-modelling work itself outside the standard's scope.
Section 2

Add TS 103 701 assessment evidence only after the claim is scoped

TS 103 701 turns the EN 303 645 implementation record into assessment inputs. It defines the Device Under Test, Supplier Organization, Test Laboratory, Implementation Conformance Statement, Implementation eXtra Information for Testing, test groups, conceptual tests, functional tests, and verdicts used in a conformance assessment.

Do not describe or as EN 303 645 requirements in isolation. The EN supplies the baseline provisions and Annex B implementation reporting structure; TS 103 701 explains how the supplier-provided ICS and IXIT are used by the test laboratory to derive a test plan and assess the .

  • Identify the as the specific consumer IoT device being assessed, including the relevant relation to associated services and processes.
  • Keep the Supplier Organization accountable for reliable and information and for coordinating product ecosystem inputs needed by the Test Laboratory.
  • Complete entries only where needed for provisions claimed as Yes, but make those entries exhaustive and correct enough for proper test execution.
  • Preserve the distinction between conceptual assessment of /design conformity and functional assessment of , associated-service, or process behavior.
Section 3

What belongs in an implementation evidence pack?

A useful evidence pack lets an assessor, buyer, retailer, or decision owner trace each public claim back to a provision, product boundary, implementation detail, and test result. It should avoid broad compliance language unless the version, boundary, assessment method, and verdict basis are visible.

For EN 303 645, the evidence categories should follow the actual provision areas: no universal default passwords, vulnerability reporting, keeping software updated, secure storage of sensitive security parameters, secure communication, exposed attack-surface reduction, software integrity, personal-data security, resilience, telemetry examination, user-data deletion, ease of installation and maintenance, input validation, and data protection provisions.

  • Provision map: reference each EN 303 645 provision and record the Annex B status, support value, and detail rationale.
  • Product boundary: identify the , firmware/software version, associated services, user documentation, and relevant development or management processes.
  • Assessment inputs: include the , entries, referenced documentation, and any public documents such as vulnerability disclosure policy or user instructions.
  • Assessment outputs: retain conceptual and functional test results, indications used for verdicts, test group verdicts, and overall verdict context where an assessment has been performed.
  • Change control: reopen evidence after material changes to device functionality, software update behavior, associated services, personal-data processing, telemetry collection, or user-data deletion flows.
Section 4

How to use external evidence without overstating it

TS 103 701 allows existing security certifications or third-party evaluations of parts of the to be used partially as evidence, but only under assessor review. The supplier has to announce the evidence in the detail for the addressed provision and provide the information needed for verification, such as certification details or test reports.

is not a blanket substitute for EN 303 645 implementation evidence. The Test Laboratory still has to check whether the evidence scope matches the test group objective, whether the evidence test activities meet each test purpose in that test group, and whether the test depth or assurance level is appropriate for the level addressed by the test group.

  • Name the exact provision and test group that the is meant to support.
  • Attach the certification, evaluation report, certification details, or test report needed for verification by the Test Laboratory.
  • Compare the evidence boundary with the current boundary; do not reuse evidence from a different product, version, service boundary, or feature set without a written scope match.
  • If the scope, test-purpose coverage, or depth is unclear, treat the result as unresolved evidence rather than a pass claim.
Section 5

Common evidence mistakes that reduce visitor and assessor value

Copying provision names does not show what the product implements. Each entry should identify the claim, its source provision, the product-specific artifact that supports it, and whether the record belongs to EN 303 645 implementation reporting or TS 103 701 assessment.

Avoid mixing marketing claims with assessment vocabulary. A page can say that evidence is prepared for assessment, but a conformance or pass claim needs a valid , adequate , applied test groups or accepted , and the relevant verdict context.

  • Do not mark a conditional or feature-dependent provision as Not Applicable unless the condition or feature analysis supports that result.
  • Do not leave recommended provisions unfulfilled or not applicable without the recorded justification required by EN 303 645 implementation reporting.
  • Do not describe as a complete product dossier; TS 103 701 says it contains the additional information needed for assessment, and only necessary entries must be completed.
  • Do not ask readers to trust unpublished evidence; cite stable public standards and identify which private evidence artifact supports each product-specific claim.
  • Do not omit associated-service dependencies; EN 303 645 V3.1.3 covers consumer IoT devices and their interactions with associated services, while TS 103 701 assesses the 's relation to those services and relevant processes.
Primary sources

References and citations

etsi.org
Referenced sections
  • Primary source for consumer IoT baseline provisions, implementation reporting, and Annex B implementation conformance statement support/detail fields.
"The present document sets a security and data protection baseline"
etsi.org
Referenced sections
  • Assessment source for DUT identification, supplier organization, test laboratory roles, ICS, IXIT, conceptual and functional tests, verdicts, and external evidence handling.
"conformance assessment methodology for consumer IoT devices"
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 checklist
This ETSI EN 303 645 implementation checklist helps scope a consumer IoT product, record Annex B support statuses, map IXIT evidence, and avoid weak conformance claims.
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.