We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALETSI EN 303 645

ETSI EN 303 645 Secure Update Workflow

A practical workflow for turning EN 303 645 clause 5.3 secure-update provisions into scoped decisions, update-mechanism controls, user communications, and evidence.

Use EN 303 645 for the baseline provisions and TS 103 701 for assessment evidence concepts such as DUT, , , and conceptual or functional tests.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
6 sections2 primary sources
Overview

A should verify update authenticity and integrity, prevent unauthorized installation, and support the product's documented update and support-period decisions. This workflow separates ETSI EN 303 645 V3.1.3 clause 5.3 provisions from ETSI TS 103 701 V2.1.1 assessment evidence so product, security, and compliance owners can assign every trigger, action, user notice, record, and outcome.

Section 1

Start with the EN 303 645 update boundary

The workflow begins by identifying every software component in the consumer IoT product that can affect security: device firmware, software on the device, companion application paths, update servers, associated services used to trigger updates, and dependencies such as a hub or base station.

EN 303 645 Provision 5.0-1 states that a justification shall be recorded for each recommendation treated as not applicable or not fulfilled. For update work, document components claimed to be immutable for security reasons, use-case-determined resource constraints, update paths, automation and notification features, and support-period statements before making public claims.

  • Record the product model designation and the exact software components covered by the update mechanism.
  • Record a only when the product use case creates the technical limit, such as energy supply or communication bandwidth; economic reasons alone do not justify the secure-update exception.
  • List update paths separately: direct device download, associated-service or mobile-app initiation, web interface, USB, or other physical transfer.
  • For every not-applicable update provision, keep a justification that can be reused by assurance assessors, supply-chain reviewers, retailers, or security researchers.
Section 2

Build the update mechanism before writing compliance claims

EN 303 645 V3.1.3 says software components that are not immutable for security reasons should be securely updateable. It also states that the device shall have a unless a determined by the use case prevents implementation. The workflow should identify which mechanism prevents attackers from misusing the update process and justify every claimed exception.

A useful workflow names the update source, transport, trust relationship, cryptographic verification, anti-rollback approach where used, failure behavior, and evidence owner. It should also show how version information moves between the device and the manufacturer, because update management generally relies on that communication. Anti-rollback is an ETSI example, not a separate universal provision; record it only when the product uses it.

  • Describe how the device or associated service checks for update availability after initialization.
  • Show how update authenticity and integrity are verified, including network-delivered updates that rely on a trust relationship.
  • Document the cryptography used by the update mechanism without turning the EN 303 645 record into an unsupported cryptographic certification claim.
  • Define the rejection, logging, notification, or recovery behavior for invalid, failed, or potentially malicious update attempts.
Section 3

Design the user-facing update flow

EN 303 645 treats usability as part of update security. Updates shall be simple for the user to apply. One should be configurable for automation, and initialization should activate an automatic secure update mechanism after the user's consent. If the device supports automated updates or update notifications, the user should be able to enable or disable the relevant function; automated installation should also be postponable.

The workflow should make the user journey visible. A reviewer should be able to see where a user is told that a security update is required, what risks are mitigated, whether the update will disrupt basic device functionality, and how the user can enable, disable, or postpone automatic update behavior.

  • Use screenshots, user-interface copy, emails, or app notification records as evidence that update prompts are recognizable and apparent.
  • Capture whether the update is automatic, initiated by an associated service, started from a device web interface, or performed through another user-appropriate route.
  • When updates can interrupt basic functioning, include the notice text and the expected downtime or operational impact.
  • Keep security updates distinct from complex feature updates when feature changes could slow delivery or change the product context.
Section 4

Handle timeliness, support periods, and non-updateable devices

EN 303 645 states that security updates shall be timely, while recognizing that timeliness depends on the issue, fix, device reachability, stakeholder dependencies, and device resource constraints. The workflow should include severity triage, release decision ownership, and dependencies across software libraries, device manufacturing, and IoT service operations.

The manufacturer shall publish the clearly and accessibly. For any consumer IoT device that cannot have its software updated, provision 5.3-14 states that the rationale and the period and method of hardware replacement support should be published. Provisions 5.3-15A and 5.3-15B separately state that the device should be isolable and its hardware should be replaceable.

  • Tie vulnerability intake from EN 303 645 clause 5.2 to update triage so reported issues can become security updates, advisories, or documented exceptions.
  • Publish the support period consistently across product pages, manuals, support pages, and procurement answers.
  • For devices without software updates, document why updates are absent, how hardware replacement is supported, whether the device is isolable, and whether its hardware is replaceable.
  • Track third-party component and associated-service dependencies because EN 303 645 says supply-chain complexity is not a reason to withhold updates.
Section 5

Translate the workflow into TS 103 701 evidence

TS 103 701 gives the assessment method for the existing EN 303 645 update provisions. Use it to structure evidence around the Device Under Test, the Supplier Organization, the Test Laboratory role, the Implementation Conformance Statement, the , external evidence, and conceptual or functional test cases.

For secure updates, TS 103 701 uses update-mechanism evidence such as 7-UpdMech and test groups for EN 303 645 clause 5.3. Provisions 5.3-3 through 5.3-12 depend on an update mechanism. V3.1.3 splits automation into 5.3-4A and 5.3-4B, user control into 5.3-6A and 5.3-6B, and isolation and replacement into 5.3-15A and 5.3-15B. Provision 5.3-10 applies where updates can be delivered over a network interface.

  • Prepare an -style statement of the update capabilities implemented or supported by the DUT.
  • Prepare -style entries for software components, update mechanisms, user decisions, user notifications, configuration, cryptographic details, and initiation or interaction.
  • Keep conceptual evidence for design claims and functional evidence for behavior that can be exercised on the DUT.
  • Label each evidence item clearly as a release record, test result, user document, source-control record, support page, vulnerability-handling record, or, where applicable, an external security certification or third-party evaluation.
Recommended next step

Assign the update release and review gates

This workflow helps connect update mechanism design, support-period disclosures, user notifications, and TS 103 701 evidence before release or assessment.

Assessment workflow
Open Assessment Autopilot for ETSI EN 303 645

Convert secure-update provisions into owners, IXIT-style evidence requests, and assessment-ready review milestones.

Explore next step
Research workflow
Research ETSI EN 303 645 update questions

Resolve update scope, resource-constraint assumptions, support-period wording, and evidence gaps against cited ETSI sources.

Explore next step
Talk to Sorena
Talk through secure update implementation

Review update mechanisms, support promises, user notices, and the next compliance actions with Sorena.

Explore next step
Section 6

Secure update review sequence

Complete these checks before moving from update design to release and assessment.

  • Product and security owner: review DUT scope, software-component list, immutable-component rationale, resource-constraint analysis, support-period location. Check: Which EN 303 645 update provisions apply?
  • Update-mechanism owner: review architecture record, update path, trust relationship, cryptographic details, anti-rollback or recovery notes. Check: Can the update mechanism be misused by an attacker?
  • Release owner: review security update triage record, dependency review, delivery plan, user notice copy. Check: Is the update timely and understandable to the user?
  • Assessment owner: review /-style evidence, conceptual checks, functional test results, external evidence index. Check: Can TS 103 701 assessment work proceed without hidden assumptions?
  • Lifecycle owner: review published support period, end-of-support notice plan, hardware-replacement support, isolation and replaceability records. Check: Is the post-sale update promise clear and maintainable?
  • Keep EN 303 645 provision mapping separate from TS 103 701 test evidence so the record does not imply that assessment examples are new requirements.
  • Version the evidence by product model, firmware or software release, update mechanism, and assessment window.
  • Review the workflow after material changes to update infrastructure, associated services, software components, cryptographic implementation, support period, immutable-component claims, or resource-constraint assumptions.
Primary sources

References and citations

Related guides

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 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 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.

Show all related guides (25)

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 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 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 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 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.

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 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 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 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 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.

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.