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 V3.1.3 says software components that are not immutable for security reasons should be securely updateable. TS 103 701's test group for provision 5.3-1 does not discover the DUT's software components, so the supplier's inventory and immutability rationales are necessary assessment inputs.

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 devices that cannot be updated, keep the rationale, replacement-support method, 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.

Keep evidence 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. IXIT 7-UpdMech does not replace the software-component inventory in IXIT 6-SoftComp or the process and confirmation evidence in IXIT 8-UpdProc and IXIT 4-Conf.

This workflow is 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 | V3.1.3 Annex B support and detail entries, including split A/B provisions | Are N/A and N claims justified against the C and F markers?

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.

Weak secure-update evidence is often too broad or attached to the wrong layer. A signed package does not prove the whole update workflow, a support-period statement does not prove secure installation, and a completed IXIT is assessment information rather than 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.