Artifact GuideGLOBALETSI EN 303 645

ETSI EN 303 645 Current Version Tracker

A practical tracker for recording which ETSI EN 303 645 and ETSI TS 103 701 versions support a consumer IoT security claim.

Based on ETSI deliverables and status-check links. Use it as implementation guidance, not for legal interpretation.

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

Structured answer sets in this page tree.

Primary sources
6

Cited legal and guidance references.

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

ETSI's deliver directory listed V3.1.3 (2024-09) as the latest EN edition when checked on 25 July 2026. The TS 103 701 directory listed V2.1.1 (2025-05), and that assessment edition names EN 303 645 V3.1.3 as a normative reference. Record the baseline, assessment method, product release, status-check date, and selecting authority separately.

Section 1

What version facts are supported by cited sources?

The baseline used throughout this artifact is V3.1.3 (2024-09), Cyber Security for Consumer Internet of Things: Baseline Requirements. ETSI's directory contained no later EN edition when checked on 25 July 2026. The change history says V3.1.1 was published as TS 103 645 in January 2024 as a revision to improve applicability and testability; V3.1.3 is the September 2024 EN publication.

The assessment source is ETSI TS 103 701 V2.1.1 (2025-05), Cyber Security for Consumer Internet of Things: Conformance Assessment of Baseline Requirements. Its normative references identify ETSI TS 103 645 V3.1.1 and V3.1.3. This alignment does not decide which edition or assessment scheme a particular buyer, law, or laboratory requires.

  • Record EN 303 645 V3.1.3 (2024-09) only when the work actually relies on that PDF.
  • Do not reuse a V2.1.1 map as a V3.1.3 map without a clause-by-clause review; V3 revised the text and Annex B statuses and added or split provisions.
  • Record TS 103 701 as V2.1.1 (2025-05) only when your assessment method uses that ETSI PDF.
  • Use current or latest only with a dated ETSI directory or status check. Use harmonized, certified, or mandatory only when the applicable legal act or assurance scheme supports that separate claim.
  • Keep the status-check date separate from the publication date; they answer different questions.
Section 2

How to verify current ETSI status before relying on the tracker

ETSI states that electronic or print versions can differ and that the prevailing ETSI deliverable is the PDF made publicly available through the ETSI deliver repository. The EN 303 645 notice points to the ETSI milestones listing for revisions or status changes.

For a public product claim or customer answer, show both the PDF version used and the independent status check. If the milestones listing, Search and Browse Standards, or deliver repository points to a newer or changed deliverable, update the evidence pack before repeating an older claim.

  • Open the ETSI deliver repository or Search and Browse Standards entry for EN 303 645 and TS 103 701.
  • Capture the visible deliverable version, publication date or month, status, and URL checked.
  • Record who checked it, when they checked it, and which customer-facing claim or assessment pack depends on it.
  • If the check is inconclusive, say "version used" instead of "current version" and route the question to a standards owner.
Section 3

What belongs in the version tracker?

Tie each standard version to the product or assessment boundary that depends on it. ETSI TS 103 701 frames the assessment around a Device Under Test, a Supplier Organization, a Test Laboratory, an ICS, an IXIT, and test groups that support assessment against ETSI TS 103 645 or .

For each product release or assessment pack, record the baseline requirement version, the assessment-method version, the DUT boundary, associated services, user documentation, evidence owner, and the specific public claim that will be made. That makes it clear when an updated ETSI deliverable or a product change requires a review.

  • Standard row: EN 303 645 version, publication month, ETSI URL, status-check date, and reviewer.
  • Assessment row: TS 103 701 version, publication month, ETSI URL, compatible baseline used, and assessment scheme or lab expectation.
  • Authority row: contract clause, procurement rule, laboratory instruction, legislation, or assurance-scheme rule that selects the edition and any additional criteria.
  • Product row: DUT name, firmware and app releases, associated services, support period page, and public security claim.
  • Evidence row: completed ICS, IXIT inputs, conceptual and functional test results, exceptions, and external evidence decisions.
Section 4

When should a team refresh the tracker?

Refresh the tracker when the source version changes, when ETSI status information changes, or when the product boundary no longer matches the evidence. EN 303 645 notes that software update management can involve associated service updates, device updates, and other service updates, and that transparency about update support is beneficial to consumers.

Refresh the tracker when the assessment method changes. TS 103 701 notes that ETSI TS 103 645 can be updated before and that the assessment document scope lists compatible versions. Record version alignment as part of the evidence.

  • Refresh after firmware, mobile app, cloud, update server, user documentation, or support-process changes.
  • Refresh after a new , ETSI TS 103 645, or ETSI TS 103 701 deliverable appears in the ETSI sources you track.
  • Refresh before reusing old ICS, IXIT, test results, or external evidence in a new customer, procurement, or certification context.
  • Refresh when the contract, law, laboratory instruction, or assurance scheme changes the selected edition even if ETSI has not published a newer deliverable.
  • Refresh when a public page moves from "we use EN 303 645 V3.1.3" to a stronger claim such as "conforms to" or "assessed against".
Section 5

Version tracker workflow

This workflow is a markdown-readable operating table in planning documents: Step | Owner | Evidence | Decision.

1 | Standards owner | PDF version and status-check record | Which baseline requirements version supports the claim?

2 | Assessment owner | ETSI TS 103 701 PDF version and compatibility note | Which assessment method version will be used?

3 | Product owner | DUT, associated services, firmware, app, and support-period scope | Does the evidence boundary match the shipped product?

4 | Evidence owner | ICS, IXIT, conceptual tests, functional tests, external evidence, and exceptions | Can the claim be repeated without unsupported assumptions?

5 | Release owner | Change log and next review date | Should the public claim stay, narrow, or be refreshed?

  • Keep the status-check link and date visible in the evidence pack, not only in an internal ticket.
  • Use "version used" when the team has not performed a current-status check.
  • Use stronger wording only when the evidence names the standard version, product boundary, assessment method, and result.
Section 6

Common version-tracking mistakes

Do not overstate the evidence. A PDF publication date does not prove today's current status, and a completed checklist does not prove conformance if it omits the product boundary, assessment method, or changed associated services.

Keep EN 303 645 baseline versions separate from TS 103 701 assessment versions. Mixing them in one row can hide an incompatible or stale assessment.

  • Do not repeat the 25 July 2026 latest-version finding indefinitely; date every later ETSI status check.
  • Do not cite TS 103 701 assessment results unless the evidence names the DUT, ICS, IXIT, test approach, and assessor context.
  • Do not reuse old evidence after firmware, app, associated service, support-period, or vulnerability-disclosure-process changes.
  • Do not expose local reference files or evidence record names in public source entries; use external ETSI HTTPS URLs with the Sorena reference parameter.
Primary sources

References and citations

etsi.org
Referenced sections
  • Grounds the workflow requirement to keep the relied-upon ETSI deliverable PDF and checked source URL visible.
"ETSI deliver"
etsi.org
Referenced sections
  • The official directory listed editions through 03.01.03_60 when checked on 25 July 2026; that directory contains the V3.1.3 PDF used here.
etsi.org
Referenced sections
  • ETSI EN 303 645 points to this listing when warning that a deliverable may be revised or have its status changed.
"may be revised or have its status changed"
etsi.org
Referenced sections
  • This ETSI standards search entry point helps look up the public deliverable record before making a current-version claim.
"Search Standards"
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 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 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.