ETSI EN 303 645 Secure Updates and Vulnerability Disclosure

Clause 5.2 starts with a public vulnerability disclosure policy. EN 303 645 says the manufacturer shall make the policy publicly available and that it shall include contact information for reporting issues plus timelines for initial acknowledgement and status updates until reported issues are resolved.

The same clause says disclosed vulnerabilities should be acted on in a timely manner and manufacturers should continually monitor for, identify, and rectify vulnerabilities in products sold or produced and associated services operated during the defined support period. Timeliness is incident-specific. The explanatory text describes 90 days as a conventional completion period for a software solution, including patches and notification; it is not a fixed deadline for every report, and hardware or deployed-device fixes can take longer.

Clause 5.3 says software components not made immutable for security reasons should be securely updateable. The device shall have a secure update mechanism unless a resource constraint determined by the use case prevents one. Secure installation means measures that prevent an attacker from misusing the mechanism.

Where the relevant update feature exists, V3.1.3 addresses simple installation, an automatable secure mechanism, activation of automatic updates with user consent during initialization, post-initialization update checks, controls for automatic updates and notifications, cryptography, timely delivery, authenticity and integrity, trust relationships for network delivery, user notices, and disruption notices. It also states that the manufacturer shall publish the defined support period and that the model designation shall be clearly recognizable. Devices that cannot be updated have separate recommendations for publishing the rationale and replacement support, isolation, and hardware replacement.

Treat EN 303 645 as the provision source and TS 103 701 as the assessment method. EN 303 645 says what the manufacturer, device, or update process should or shall do. TS 103 701 describes how a Supplier Organization and Test Laboratory structure the assessment of a Device Under Test through identification, an Implementation Conformance Statement (ICS), Implementation eXtra Information for Testing (IXIT), test planning, conceptual tests, functional tests, and PASS, FAIL, or INCONCLUSIVE verdicts.

A public product page can state a support period and vulnerability reporting route. A non-public evidence pack should show the IXIT entries, design details, public-document locations, test observations, and confirmations that a TS 103 701 assessor would need to evaluate those claims.

Review this checklist before making an EN 303 645 claim in a product page, procurement response, assessment workbook, or release gate. Each item should be tied to a specific product model, associated service, firmware stream, and support period.

Use concrete, versioned evidence: public URLs, release records, update-mechanism descriptions, cryptographic details, user-notification screenshots, component inventories, vulnerability triage procedures, and assessor-ready IXIT references.

Claims weaken when they mix provision language, evidence language, and marketing language. Avoid saying a product is conformant unless the scope, DUT, ICS support claims, IXIT evidence, test groups, and assessment outcome are clear.

Also avoid treating secure updates and vulnerability disclosure as isolated paperwork. EN 303 645 links security updates to vulnerability handling, support periods, user communication, associated services, and third-party components.