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.
Structured answer sets in this page tree.
Cited legal and guidance references.
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.
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.
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.
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.
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.
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.
Use this workflow to connect update mechanism design, support-period disclosures, user notifications, and TS 103 701 evidence before release or assessment.
Convert secure-update provisions into owners, IXIT-style evidence requests, and assessment-ready review milestones.
Resolve update scope, constrained-device assumptions, support-period wording, and evidence gaps against cited ETSI sources.
Review update mechanisms, support promises, user notices, and the next compliance actions with Sorena.
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 software updated"
"conformance assessment methodology"