ETSI EN 303 645 Secure Updates + Vulnerability Disclosure

ETSI EN 303 645 requires manufacturers to make a vulnerability disclosure policy publicly available. At minimum it must include contact information for reporting issues and timelines for initial acknowledgement and status updates until resolution.

A VDP is not a marketing page. It is a contract-like interface between your organization and security reporters: it defines how reports enter your system and what reporters can expect next.

ETSI EN 303 645 expects disclosed vulnerabilities to be acted on in a timely manner, noting that 'timely' depends on the incident and that conventional disclosure processes often complete within ~90 days for software (with caveats for hardware fixes and rollout constraints).

'Timely' becomes real only when you instrument it: triage SLAs, fix lead time, rollout lead time, and user/partner communication lead time.

The standard recommends continual monitoring for vulnerabilities in products and services during the defined support period, including due care for third-party components and associated services.

This is where SBOM and dependency monitoring become unavoidable: you can't fix what you can't inventory.

ETSI EN 303 645 expects software components to be securely updateable and, for non-constrained devices, requires an update mechanism for secure installation of updates. Secure installation means adequate measures prevent attackers from misusing the update mechanism.

Build the update mechanism as a security boundary. If it can be subverted, an attacker can install malicious software, downgrade to vulnerable versions, or brick devices at scale.

ETSI EN 303 645 expects updates to be simple for users to apply, recommends automatic update mechanisms, recommends periodic checking for security updates, and recommends that automatic updates/notifications be enabled by default (where supported) while remaining configurable.

The operational goal: updates should happen reliably without demanding 'security expertise' from users, while still respecting user control and safety-critical product behavior.

ETSI EN 303 645 requires using best-practice cryptography for secure update mechanisms and expects devices to verify authenticity and integrity of software updates. When updates are delivered over a network interface, authenticity and integrity verification must be done via a trust relationship (e.g., authenticated channels, signature verification, or other validated trust conditions).

Design your update system so that verification is undeniable: either the device verifies signatures directly, or a trusted peer verifies and delivers over a secure channel, with strong safeguards against substitution and replay.

Security updates must be timely, with priority for critical vulnerabilities and coordination across supply-chain stakeholders when necessary. The standard also recommends informing users when a security update is required and notifying users if an update will disrupt basic device functioning (unless handled by an associated service).

Timely updates are a program capability: release engineering, staged rollout, monitoring, and rollback/recovery plans must exist before the incident happens.

ETSI EN 303 645 requires publishing a defined support period in an accessible, clear, and transparent way. It also addresses constrained devices that cannot be updated: publish rationale, replacement support, and support period; and consider isolability and replaceability.

Support period transparency is both a compliance control and a trust signal. It also drives your internal vulnerability handling obligations: if you commit to support, you must be able to patch.

Your strongest evidence is operational: it shows you do this continuously, not only when asked. Keep artifacts that prove the workflow works: intake, triage, remediation, release, rollout, and communication.

Aim for evidence that is attributable (who approved), current (per release), and traceable (links to specific provisions and versions).