Artifact GuideGLOBALETSI EN 303 645

ETSI EN 303 645 Support period for consumer IoT security updates

A focused answer on how ETSI EN 303 645 treats the defined support period for security updates and how TS 103 701 assesses its publication.

Based on ETSI EN 303 645 V3.1.3 and ETSI TS 103 701 V2.1.1. The defined support period covers security updates, not warranty or general support.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
3

Structured answer sets in this page tree.

Primary sources
7

Cited legal and guidance references.

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

ETSI EN 303 645 V3.1.3 defines the as the minimum time, stated as a period or end date, for which the manufacturer will provide . Provision 5.3-13 requires the manufacturer to publish it in an accessible way that is clear and transparent to the user.

Search this module

Find a question or answer quickly

3 of 3 questions
Question 1

What does ETSI EN 303 645 mean by support period?

The is not a general warranty promise. ETSI EN 303 645 defines it specifically around : the minimum length of time, expressed as a period or by an end date, for which the manufacturer will provide security updates.

The public statement should identify the product or model and give either a duration with a clear start point or a specific end date. Avoid wording such as "supported for a reasonable period": it does not tell a buyer when security-update support ends.

EN 303 645 does not prescribe a universal minimum number of months or years. The manufacturer defines the period for the product and publishes it. Other laws, contracts, procurement terms, assurance schemes, or product-specific standards may impose a different or longer commitment and need separate review.

  • State the as a concrete period or end date for the consumer IoT product.
  • Keep the claim limited to security-update support unless separate sources support broader product-support or warranty language.
  • Tie the support-period statement to the product or model designation users need in order to check update support.
Citations
Question 2

What must be published for users?

Provision 5.3-13 requires the manufacturer to publish the defined in an accessible, clear, and transparent way. The surrounding ETSI text explains why: when purchasing a product, the consumer expects the period of software-update support to be clear.

TS 103 701 makes this assessable through IXIT 2-UserInfo and the software-component information in IXIT 6-SoftComp. The laboratory checks whether a user with limited technical knowledge can understand and access the publication, whether access is unrestricted, and whether the published statement matches the documented .

  • Publish the where users can reach it without registration or other access restrictions.
  • Document the publication path in IXIT 2-UserInfo as "Publication of ", including the information needed to access it.
  • Check that the public page, product information, app help path, or manual points to the same recorded in the assessment evidence.
  • Recheck the publication at product launch and whenever the model designation, support end date, duration start point, update policy, public URL, or software-component support dependency changes.
Citations
Question 3

How should devices that cannot be updated be handled?

If a device cannot have its software updated, do not stop at saying updates are unavailable. Provision 5.3-14 recommends publishing the reason, plus the period and method of hardware replacement support, in an accessible, clear, and transparent way. The mandatory defined under 5.3-13 still applies.

V3.1.3 applies this route to any device that cannot have its software updated; it is no longer limited to a defined constrained-device class. Provisions 5.3-15A and 5.3-15B also recommend that such a device be isolable and that its hardware be replaceable. TS 103 701 maps the replacement and isolation evidence to IXIT 9-ReplSup.

  • For updateable products, publish the defined security-update and keep it aligned with update evidence.
  • For non-updateable products, also publish why software updates are absent and how hardware replacement support works.
  • Keep replacement-support and isolation evidence separate from general marketing claims so assessors can trace the non-updateable-device route.
Citations
Primary sources

References and citations

etsi.org
Referenced sections
  • Primary ETSI source requiring publication of the defined support period in an accessible, clear, and transparent way.
"The manufacturer shall publish"
etsi.org
Referenced sections
  • Current ETSI source for devices that cannot have software updated, including publication of rationale and replacement support, plus isolability and hardware replaceability recommendations.
"the period and method of hardware replacement support"
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 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 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.