ETSI EN 303 645 Current Version Tracker

The grounded ETSI EN 303 645 deliverable is V2.1.1 (2020-06), titled Cyber Security for Consumer Internet of Things: Baseline Requirements. Its history table records V1.1.1 as ETSI TS 103 645 in February 2019, EN approval and vote stages in 2019 and 2020, and V2.1.1 publication in June 2020.

The grounded ETSI TS 103 701 assessment document is V2.1.1 (2025-05), titled Cyber Security for Consumer Internet of Things: Conformance Assessment of Baseline Requirements. It specifies a conformance assessment methodology against ETSI TS 103 645 and ETSI EN 303 645, but the grounding does not prove that these are the latest ETSI deliverables on the day a visitor reads this page.

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 grounding also tells users to check the current status of ETSI documents through ETSI deliverable-status information.

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

A useful tracker is not just a list of URLs. It ties the 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 ETSI EN 303 645.

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.

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.

A refresh is also needed when an assessment method changes. TS 103 701 notes that ETSI TS 103 645 can be updated before ETSI EN 303 645 and that the assessment document scope lists compatible versions. That makes version alignment a first-order evidence issue, not a filing detail.

Use this workflow as a markdown-readable operating table in planning documents: Step | Owner | Evidence | Decision.

1 | Standards owner | ETSI EN 303 645 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?

The main mistake is overstating 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.

Another common mistake is mixing EN 303 645 baseline requirements and TS 103 701 assessment language without recording which versions were used. Keep those rows separate so teams can update one without silently invalidating the other.