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.
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.
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.
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.
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.
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.
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.
This workflow helps 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, resource-constraint 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.
This workflow table helps 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, immutable-component rationale, resource-constraint 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 | /-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, hardware-replacement support, isolation and replaceability records | Is the post-sale update promise clear and maintainable?
"Keep software updated"
"conformance assessment methodology"