---
title: "ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD)"
canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure"
source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure"
author: "Sorena AI"
description: "Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD)."
published_at: "2026-03-04"
updated_at: "2026-03-04"
keywords:
  - "ETSI EN 303 645 secure updates"
  - "ETSI EN 303 645 vulnerability disclosure policy"
  - "VDP"
  - "CVD"
  - "coordinated vulnerability disclosure"
  - "security updates timely"
  - "authenticity integrity verification"
  - "update trust relationship"
  - "anti-rollback policy"
  - "automatic updates"
  - "update notifications"
  - "publish support period"
  - "SBOM monitoring"
  - "IoT security update mechanism"
  - "Vulnerability disclosure policy"
  - "Software updates"
  - "SBOM"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# ETSI EN 303 645 Secure Updates & Vulnerability Disclosure (VDP + CVD)

Deep implementation guide for ETSI EN 303 645 update security and vulnerability disclosure: publish a VDP, run coordinated vulnerability disclosure (CVD).

*Artifact Guide* *GLOBAL*

## ETSI EN 303 645 Secure Updates + Vulnerability Disclosure

Build a VDP + CVD workflow and ship secure, verifiable, timely security updates.

Aligned to ETSI EN 303 645 provisions 5.2 (vulnerability reporting/handling) and 5.3 (software updates and support periods).

ETSI EN 303 645 treats vulnerability handling and software updates as core consumer IoT security controls. In practice, these two capabilities define whether your product security posture improves over time or silently degrades. This page focuses on implementable patterns, measurable timelines, and evidence you can generate continuously.

## Provision 5.2-1 - Publish a vulnerability disclosure policy (VDP)

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.

- Provide a stable reporting channel and make it easy to find from your product and website
- Commit to acknowledgement and status update timelines (measurable, not vague)
- Define scope (device, firmware, apps, cloud services, and associated services) and how to report affected versions

## Provision 5.2-2 - Act on disclosed vulnerabilities in a timely manner

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.

- Define severity-based SLAs: acknowledgement, triage completion, fix availability, rollout completion
- Track update coverage: what % of devices are patched, by version and cohort
- Document exceptions (e.g., constrained devices) and mitigation plans (isolation, replacement, compensating controls)

## Provision 5.2-3 - Monitor, identify, and rectify vulnerabilities during the support period

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.

- Maintain a component inventory (SBOM-style) for device firmware, apps, and cloud services
- Monitor vulnerability sources relevant to your components and ecosystems; triage with affected versions
- Keep remediation evidence: issue tracking, patch diffs, release notes, and rollout metrics

## Provision 5.3-1 and 5.3-2 - Securely updateable components and secure installation

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.

- Define update paths: OTA, mobile-app mediated, local/USB, and service-initiated; secure each path
- Implement anti-rollback controls (version checks) to prevent downgrade attacks
- Prove the trust chain: signed updates, protected channels, and device-side verification where feasible

## Provisions 5.3-3 to 5.3-6 - Usability, automatic updates, update checks, and configuration

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.

- Make security updates low-friction: safe defaults, clear prompts, and recovery behavior if an update fails
- Use automatic update mechanisms where appropriate; separate security updates from risky feature changes when possible
- Implement periodic update checks (device or associated service) and ensure users can postpone/disable where applicable

## Provisions 5.3-7, 5.3-9, 5.3-10 - Cryptography, authenticity/integrity verification, and trust relationships

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.

- Use signed update artifacts and verify signatures; store verification results and failures as security telemetry
- Protect the trust relationship: pin/update trust anchors safely and manage certificate/key rotation
- Handle invalid updates safely: reject, avoid information leakage, log securely, and alert trusted administrators/services

## Provisions 5.3-8, 5.3-11, 5.3-12 - Timely updates and user-facing notifications

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.

- Define how users are notified: device UI, app notifications, email-use recognizable, actionable messaging
- Implement staged rollout with safety guards (health metrics, crash rates, rollback criteria)
- Treat update disruption as safety/UX: estimate downtime, maintain minimal critical functions where applicable

## Provisions 5.3-13 to 5.3-15 - Publish support periods and handle constrained devices

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.

- Publish support period per model/SKU and define what 'end of support' means for security fixes
- Create an end-of-support playbook: comms, replacement options, isolation guidance, and risk advisories
- Keep support period claims consistent across packaging, websites, and procurement documents

## Evidence to keep (what proves you meet 5.2 and 5.3)

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

- VDP page + historical versions, mailbox/form logs, acknowledgement and status update timestamps
- Vulnerability records: triage notes, affected versions, fix commits, CVE advisories where applicable
- Update system evidence: signing policies, key management policies, verification logs, rollout metrics
- Support period publication evidence: user-facing pages, SKU matrices, and change control records

*Recommended next step*

*Placement: near the end of the main content before related guides*

## Turn ETSI EN 303 645 Secure Updates + Vulnerability Disclosure into an operational assessment

Assessment Autopilot can take ETSI EN 303 645 Secure Updates + Vulnerability Disclosure from turning this guidance into an operational assessment workflow to a reusable workflow inside Sorena. Teams working on ETSI EN 303 645 can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

- [Open Assessment Autopilot for ETSI EN 303 645 Secure Updates + Vulnerability Disclosure](/solutions/assessment.md): Start from ETSI EN 303 645 Secure Updates + Vulnerability Disclosure and turn the guidance into owned tasks, evidence requests, and review checkpoints.
- [Talk through ETSI EN 303 645](/contact.md): Review your current process, evidence gaps, and next steps for ETSI EN 303 645 Secure Updates + Vulnerability Disclosure.

## Primary sources

- [ETSI EN 303 645 V3.1.3 (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf?ref=sorena.io) - Primary source for provisions 5.2 (vulnerability disclosure) and 5.3 (software updates and support period).
- [ETSI TS 103 701 V2.1.1 (Conformance Assessment) (Official PDF via ETSI Deliver)](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Supporting source for how vulnerability and update provisions can be assessed using test groups and evidence.

## Related Topic Guides

- [ETSI EN 303 645 Compliance & Conformance Assessment (ICS/IXIT Evidence)](/artifacts/global/etsi-en-303-645/compliance.md): How to operationalize ETSI EN 303 645 compliance for consumer IoT: conformance assessment approach (ETSI TS 103 701), ICS/IXIT-style evidence.
- [ETSI EN 303 645 FAQ (Consumer IoT Security Standard)](/artifacts/global/etsi-en-303-645/faq.md): Answering common product-team questions about ETSI EN 303 645: unique passwords, vulnerability disclosure policy requirements, secure software updates.
- [ETSI EN 303 645 Requirements (Provision Map 5.1-5.13)](/artifacts/global/etsi-en-303-645/requirements.md): Provision-by-provision ETSI EN 303 645 requirements for consumer IoT: passwords, vulnerability disclosure policy, secure software updates, secure storage.
- [ETSI EN 303 645 vs UK PSTI (Practical Mapping for Connectable Products)](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Practical comparison of ETSI EN 303 645 baseline consumer IoT security provisions vs the UK PSTI security requirements regime.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure