--- title: "ETSI EN 303 645 Secure Update Workflow" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-workflow" source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-workflow" author: "Sorena AI" description: "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." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 303 645 secure update workflow" - "consumer IoT software updates" - "update mechanism evidence" - "support period disclosure" - "ETSI TS 103 701 IXIT" - "ETSI EN 303 645" - "secure updates" - "consumer IoT security" - "ETSI TS 103 701" - "software update evidence" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # 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. *Artifact Guide* *GLOBAL* *ETSI 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, ICS, IXIT, and conceptual or functional tests. Use this page when a consumer IoT product team needs to prove that software updates are secure, understandable to users, supported for a defined period, and ready for assessment. It separates EN 303 645 clause 5.3 obligations from TS 103 701 evidence mechanics so product, security, and compliance owners can build one update workflow instead of scattered release notes. ## 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 any constrained-device dependency such as a hub or base station. EN 303 645 clause 4 requires a recorded justification for each recommendation that is treated as not applicable or not fulfilled. For update work, that means unavailable update paths, immutable components, constrained-device limits, user-controlled automatic updates, and support-period statements should be documented before public claims are made. - Record the product model designation and the exact software components covered by the update mechanism. - Classify the device as constrained only when the limitation is grounded in the product design, such as power, storage, bandwidth, or processing constraints. - 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. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT baseline provisions, including clause 5.3 on keeping software updated and clause 4 on recording applicability justifications. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT, SO, TL, ICS, IXIT, external evidence, and conceptual or functional test cases for EN 303 645 update provisions. ## Build the update mechanism before writing compliance claims EN 303 645 says all software components in consumer IoT devices should be securely updateable, and non-constrained devices shall have an update mechanism for secure installation of updates. The page should therefore answer a concrete engineering question: which mechanism prevents attackers from misusing the update process? A useful workflow names the update source, transport, trust relationship, cryptographic verification, anti-rollback approach where used, failure behavior, and the evidence owner. It should also show how version information moves between the device and the manufacturer, because update management generally relies on that communication. - Describe how the device or associated service checks for update availability after initialization and periodically after that. - Show how update authenticity and integrity are verified, including network-delivered updates that rely on a trust relationship. - Document the cryptography used to facilitate the update mechanism without turning the EN 303 645 page into an unsupported cryptographic certification claim. - Define the rejection, logging, notification, or recovery behavior for invalid, failed, or potentially malicious update attempts. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT baseline provisions, including clause 5.3 on keeping software updated and clause 4 on recording applicability justifications. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT, SO, TL, ICS, IXIT, external evidence, and conceptual or functional test cases for EN 303 645 update provisions. ## Design the user-facing update flow EN 303 645 treats usability as part of update security. Updates are expected to be simple for the user to apply, and automatic mechanisms should be used where appropriate, but user control still matters: if automatic updates or update notifications are supported, they should be enabled in the initialized state and configurable by the user. 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. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT baseline provisions, including clause 5.3 on keeping software updated and clause 4 on recording applicability justifications. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT, SO, TL, ICS, IXIT, external evidence, and conceptual or functional test cases for EN 303 645 update provisions. ## Handle timeliness, support periods, and constrained devices EN 303 645 requires security updates to be timely, while recognizing that timeliness depends on the issue, fix, device reachability, stakeholder dependencies, and constrained-device considerations. The workflow should therefore include severity triage, release decision ownership, and dependencies across software libraries, device manufacturing, and IoT service operations. EN 303 645 says the manufacturer shall publish the defined support period in a clear and accessible way. If a constrained device cannot have software updated, the public story needs to change: explain the rationale, the hardware replacement support period and method, the defined support period, and whether the product is isolable and hardware 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 constrained devices without software updates, document why updates are absent and how replacement or isolation reduces risk. - Track third-party component and associated-service dependencies because EN 303 645 says supply-chain complexity is not a reason to withhold updates. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT baseline provisions, including clause 5.3 on keeping software updated and clause 4 on recording applicability justifications. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT, SO, TL, ICS, IXIT, external evidence, and conceptual or functional test cases for EN 303 645 update provisions. ## Translate the workflow into TS 103 701 evidence TS 103 701 does not add new EN 303 645 update provisions; it gives an assessment method. Use it to structure evidence around the Device Under Test, the Supplier Organization, the Test Laboratory role, the Implementation Conformance Statement, the IXIT, external evidence, and conceptual or functional test cases. For secure updates, TS 103 701 uses update-mechanism evidence such as IXIT 7-UpdMech and test groups for EN 303 645 clause 5.3. The practical output should be an evidence pack that lets a competent assessor derive a test plan without guessing how updates are initiated, configured, verified, or observed. - Prepare an ICS-style statement of the update capabilities implemented or supported by the DUT. - Prepare IXIT-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 external evidence clearly so reviewers know whether it comes from release records, test results, user documentation, source-control history, support pages, or vulnerability-handling records. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT baseline provisions, including clause 5.3 on keeping software updated and clause 4 on recording applicability justifications. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT, SO, TL, ICS, IXIT, external evidence, and conceptual or functional test cases for EN 303 645 update provisions. *Recommended next step* *Placement: after practical guidance* ## Operationalize the secure update workflow Use this workflow to connect update mechanism design, support-period disclosures, user notifications, and TS 103 701 evidence before release or assessment. - [Open Assessment Autopilot for ETSI EN 303 645](/solutions/assessment.md): Convert secure-update provisions into owners, IXIT-style evidence requests, and assessment-ready review milestones. - [Research ETSI EN 303 645 update questions](/solutions/research-copilot.md): Resolve update scope, constrained-device assumptions, support-period wording, and evidence gaps against cited ETSI sources. - [Talk through secure update implementation](/contact.md): Review update mechanisms, support promises, user notices, and the next compliance actions with Sorena. ## Secure update workflow table Use this workflow table to plan releases or prepare assessments: each row shows the owner, the evidence to collect, and the decision that should be made before moving to the next step. 1 | Product and security owner | DUT scope, software-component list, constrained-device analysis, support-period location | Which EN 303 645 update provisions apply? 2 | Update-mechanism owner | Architecture record, update path, trust relationship, cryptographic details, anti-rollback or recovery notes | Can the update mechanism be misused by an attacker? 3 | Release owner | Security update triage record, dependency review, delivery plan, user notice copy | Is the update timely and understandable to the user? 4 | Assessment owner | ICS/IXIT-style evidence, conceptual checks, functional test results, external evidence index | Can TS 103 701 assessment work proceed without hidden assumptions? 5 | Lifecycle owner | Published support period, end-of-support notice plan, constrained-device replacement or isolation rationale | Is the post-sale update promise clear and maintainable? - Keep EN 303 645 provision mapping separate from TS 103 701 test evidence so the page 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, or constrained-device assumptions. Sources for this answer: - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT baseline provisions, including clause 5.3 on keeping software updated and clause 4 on recording applicability justifications. - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT, SO, TL, ICS, IXIT, external evidence, and conceptual or functional test cases for EN 303 645 update provisions. ## Primary sources - [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT baseline provisions, including clause 5.3 on keeping software updated and clause 4 on recording applicability justifications. - Quote: "Keep software updated" - [ETSI TS 103 701 V2.1.1 conformance assessment for consumer IoT](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for DUT, SO, TL, ICS, IXIT, external evidence, and conceptual or functional test cases for EN 303 645 update provisions. - Quote: "conformance assessment methodology" ## Related Topic Guides - [ETSI EN 303 645 Applicability and Scope](/artifacts/global/etsi-en-303-645/applicability-and-scope.md): 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](/artifacts/global/etsi-en-303-645/compliance.md): Plan ETSI EN 303 645 compliance evidence for consumer IoT products with scope, ICS, IXIT, TS 103 701 assessment steps, verdict risks, and source-linked controls. - [ETSI EN 303 645 consumer IoT products: what is in scope?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md): ETSI EN 303 645 FAQ on consumer IoT product scope: devices, associated services, constrained devices, out-of-scope industrial uses, ICS, IXIT, and TS 103 701 evidence. - [ETSI EN 303 645 Current Version Tracker](/artifacts/global/etsi-en-303-645/current-version-tracker.md): 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](/artifacts/global/etsi-en-303-645/vulnerability-disclosure-cvd-workflow.md): Source-linked 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](/artifacts/global/etsi-en-303-645/data-protection-provisions.md): source-linked guide to ETSI EN 303 645 data protection provisions for consumer IoT: personal data security, telemetry transparency, consent, and deletion evidence. - [ETSI EN 303 645 default passwords: what must consumer IoT teams do?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md): 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](/artifacts/global/etsi-en-303-645/faq.md): source-linked answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, default passwords, updates, vulnerability disclosure, telemetry, deletion, and TS 103 701 evidence. - [ETSI EN 303 645 ICS and IXIT Evidence Template](/artifacts/global/etsi-en-303-645/ics-and-ixit-evidence-template.md): Build a source-linked 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](/artifacts/global/etsi-en-303-645/implementation-checklist.md): Use this ETSI EN 303 645 implementation checklist to 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](/artifacts/global/etsi-en-303-645/implementation-evidence.md): 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](/artifacts/global/etsi-en-303-645/iot-applicability-workflow.md): 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](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md): 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](/artifacts/global/etsi-en-303-645/requirements.md): 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](/artifacts/global/etsi-en-303-645/secure-update-evidence-workflow.md): 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](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): source-linked guide to ETSI EN 303 645 clauses 5.2 and 5.3 for consumer IoT vulnerability disclosure, security updates, support periods, and TS 103 701 evidence. - [ETSI EN 303 645 support period: what must consumer IoT teams publish?](/artifacts/global/etsi-en-303-645/faq/support-period.md): ETSI EN 303 645 support-period guidance for consumer IoT: defined security-update support periods, user-accessible publication, constrained-device replacement support, model designation, and TS 103 701 evidence. - [ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?](/artifacts/global/etsi-en-303-645/faq/telemetry.md): 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?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md): 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](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-eu-cra.md): Use ETSI EN 303 645 and ETSI TS 103 701 evidence when preparing consumer IoT cybersecurity work that may also need a separate EU CRA legal mapping. - [ETSI EN 303 645 vs RED Cybersecurity Delegated Act](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-red-cybersecurity-delegated-act.md): Compare ETSI EN 303 645 consumer IoT security evidence with RED cybersecurity planning without treating the ETSI baseline as a substitute for RED legal scope. - [ETSI EN 303 645 vs UK PSTI: Evidence Crosswalk](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Compare ETSI EN 303 645 evidence with UK PSTI review needs without assuming the same scope, legal trigger, or assurance route. - [ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md): 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](/artifacts/global/etsi-en-303-645/ts-103-701-test-evidence-workflow.md): 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?](/artifacts/global/etsi-en-303-645/faq/constrained-devices.md): ETSI EN 303 645 constrained-device guidance: what counts as constrained, when non-applicability can be justified, and what evidence should support update and authentication decisions. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-workflow