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 evidence record 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.

Assign each check to an owner and retain the provision, evidence, and result for the exact product release.

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.

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.