ETSI EN 303 645 Secure Update Evidence Workflow

The evidence workflow should start with the Device Under Test and the exact software components that are or are not updateable. EN 303 645 says all software components in consumer IoT devices should be securely updateable, while also recognizing that not all software on a device will be updateable.

Record the update boundary before collecting proof: firmware, operating system, embedded software services, companion update path, network update path, physical update path, associated service involvement, user documentation, model designation, and defined support period. For constrained devices that cannot be updated, keep the rationale, replacement-support method, support period, isolation position, and hardware-replacement position separate from the evidence for updateable devices.

For each secure-update provision, write an evidence entry that states the provision reference, support value, product condition, implemented measure, and private artifact that proves the statement. This avoids a common weak pattern: saying a product has secure updates without identifying the update mechanism, trust relationship, user interaction, or support-period publication behind the claim.

The strongest evidence is narrow and release-specific. A support-period web page does not prove authenticity checks, and a signed firmware package does not prove user notification, update simplicity, or support-period transparency. Each claim needs its own evidence path.

After the EN 303 645 provision map is scoped, prepare the TS 103 701 assessment inputs. The Supplier Organization completes the DUT identification, the ICS, and the necessary IXIT information for provisions claimed as Yes. The Test Laboratory verifies the ICS, checks conditional N/A claims, uses ICS and IXIT to derive a test plan, performs the selected test groups, and assigns verdicts.

For secure updates, IXIT 7-UpdMech is the central record. It should describe each update mechanism with an ID, description, security guarantees, cryptographic details, initiation and interaction, configuration, update checking, and user notification where those fields are needed by the applicable test groups.

Use this workflow as a release, audit, or assessment-preparation gate. Each row should result in a named owner, a source provision, a private artifact, and a status that can be reviewed when software, associated services, update infrastructure, support pages, or user documentation change.

1 | Scope the DUT and software components | Product security owner | DUT identification, software component inventory, model designation | Does each component have an update mechanism or a justified absence of updates?

2 | Complete the EN 303 645 support/detail map | Compliance owner | Annex B-style support and detail entries for provisions 5.3-1 through 5.3-16 | Are N/A and N claims justified, especially for conditional provisions?

3 | Document update mechanisms | Firmware, app, cloud, and security engineering owners | IXIT 7-UpdMech entries plus architecture, cryptography, trust-relationship, update-checking, and user-notification evidence | Can a Test Laboratory understand how each update path works?

4 | Document update procedures and timeliness | Release and vulnerability-response owners | IXIT 8-UpdProc, IXIT 4-Conf, release records, vulnerability triage records, and deployment logs | Can the team show how security updates are prioritized and delivered?

5 | Verify user-facing information | Support and product owners | Support-period publication, update instructions, notification copy, disruption notices, and model designation evidence | Can a consumer find the support period and understand required security updates?

6 | Assessment handoff | Assessment owner | ICS, IXIT, referenced documentation, external evidence, and test-plan assumptions | Are the required elements sufficient to avoid an inconclusive result?

TS 103 701 secure-update test groups are not a single generic update test. They inspect different aspects of the update story: whether update mechanisms are documented, whether secure installation prevents misuse, whether updates are simple and configurable for users, whether update checks occur, whether cryptography is appropriate, whether security updates are timely, and whether authenticity and integrity are verified.

The evidence pack should therefore contain both conceptual evidence and functional evidence. Conceptual evidence explains the design and its security guarantees through IXIT and referenced documents. Functional evidence shows that the DUT, associated service relation, or process behaves consistently with the documented design.

Most weak secure-update evidence fails because it is either too broad or attached to the wrong layer. A signed package is not the whole update workflow, a support-period statement is not a secure-installation proof, and a completed IXIT is not itself an EN 303 645 provision.

The page should also avoid public conformance claims unless the assessment boundary, source version, ICS status, IXIT inputs, test groups, accepted external evidence, and verdict context are available. ETSI TS 103 701 defines how PASS, FAIL, and INCONCLUSIVE verdicts are assigned; marketing copy should not imply a verdict that has not been produced.