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 must include contact information for reporting issues plus timelines for initial acknowledgement and status updates until reported issues are resolved.

The same clause expects disclosed vulnerabilities to be acted on in a timely manner and expects manufacturers to monitor for, identify, and rectify security vulnerabilities in products and services during the defined support period. EN 303 645 describes timeliness as incident-specific and notes a conventional 90-day completion period for a software solution, including patches and notification, while hardware fixes and deployed device fixes can take longer.

Clause 5.3 expects consumer IoT software components to be securely updateable where practicable, and says non-constrained devices shall have an update mechanism for secure installation of updates. EN 303 645 explains that secure installation means adequate measures to prevent an attacker from misusing the update mechanism.

For implemented update mechanisms, EN 303 645 addresses user simplicity, automatic update mechanisms, post-initialization update checks, user control over automatic updates and notifications, best-practice cryptography, timely security updates, authenticity and integrity verification, trust relationships for network-delivered updates, recognizable user notices for required security updates, disruption notices, support-period publication, and special handling for constrained devices that cannot be updated.

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, ICS, IXIT, test planning, conceptual tests, functional tests, and PASS, FAIL, or INCONCLUSIVE verdicts.

That distinction matters for visitor value and audit readiness. A public product page can state a support period and vulnerability reporting route. An internal 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.

Use 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.

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

Most weak claims come from mixing 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 all 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.