---
title: "ETSI EN 303 645 CVD Workflow for IoT Vulnerability Reports"
canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/vulnerability-disclosure-cvd-workflow"
source_url: "https://www.sorena.io/artifacts/global/etsi-en-303-645/vulnerability-disclosure-cvd-workflow"
author: "Sorena AI"
description: "Source-linked workflow for ETSI EN 303 645 vulnerability disclosure: public policy contents, reporting contact, acknowledgement and status timelines, timely action, and TS 103 701 evidence."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "ETSI EN 303 645 vulnerability disclosure"
  - "coordinated vulnerability disclosure IoT"
  - "CVD workflow"
  - "ETSI TS 103 701 TSO 5.2"
  - "IXIT 5.2 vulnerability evidence"
  - "ETSI EN 303 645"
  - "coordinated vulnerability disclosure"
  - "consumer IoT security"
  - "ETSI TS 103 701"
  - "vulnerability reporting"
---
**[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 CVD Workflow for IoT Vulnerability Reports

Source-linked workflow for ETSI EN 303 645 vulnerability disclosure: public policy contents, reporting contact, acknowledgement and status timelines, timely action, and TS 103 701 evidence.

*Artifact Guide* *GLOBAL* *ETSI EN 303 645*

## ETSI EN 303 645 CVD workflow

A practical workflow for implementing the EN 303 645 requirement to manage vulnerability reports for consumer IoT products.

Grounded in ETSI EN 303 645 and ETSI TS 103 701. Use it as implementation and evidence guidance, not for legal interpretation.

Use this page when a consumer IoT product needs a coordinated vulnerability disclosure process that can be shown to product, security, support, procurement, or assessment teams. The workflow keeps EN 303 645 provision 5.2 separate from TS 103 701 assessment evidence: EN 303 645 states the disclosure, timely action, and monitoring expectations; TS 103 701 describes how those expectations can be assessed through public policy checks, IXIT information, confirmations, and test verdicts. Timings in this page are source-linked; verify current legal source language before implementation decisions.

## What EN 303 645 requires for vulnerability disclosure

EN 303 645 provision 5.2-1 requires the manufacturer to make a vulnerability disclosure policy publicly available. At minimum, the policy has to give contact information for reporting issues and timelines for initial acknowledgement and status updates until resolution.

Provision 5.2-2 says disclosed vulnerabilities should be acted on in a timely manner. The standard warns that timing is incident-specific: software fixes are conventionally completed within 90 days including patches and notification, while hardware fixes or deployed-device rollouts can take longer.

Provision 5.2-3 adds the operating duty behind the policy: manufacturers should continually monitor for, identify, and rectify security vulnerabilities in products and services they sell, produce, have produced, and operate during the defined support period.

- Publish a vulnerability disclosure policy where researchers and others can access it without an account or gated support flow.
- Include a reporting contact route, acknowledgement timeline, and status-update timeline in the public policy.
- Define how reported vulnerabilities are triaged, remediated, communicated, and tracked to resolution.
- Keep vulnerability monitoring active for products and related services during the defined support period.

Sources for this answer:

- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary source for provision 5.2 on public vulnerability disclosure policy, timely action, and ongoing vulnerability monitoring.
- [ETSI TS 103 701 V2.1.1 consumer IoT conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for TSO 5.2 test groups that check publication, policy contents, vulnerability action, and monitoring evidence.

## Workflow from report intake to remediation decision

Treat the public disclosure policy as the start of the workflow, not the whole control. A useful CVD process shows how a report reaches the right team, how the reporter receives an acknowledgement, how severity and product impact are assessed, and how the organization decides between a fix, mitigation, warning, or coordinated escalation.

EN 303 645 recognizes different disclosure paths. Product-specific vulnerabilities are expected to be reported to the affected stakeholder first, such as the device manufacturer, IoT service provider, or mobile application developer. For systemic vulnerabilities, a competent industry body can coordinate a wider response.

- Intake: receive reports through the published contact route and record affected product, service, firmware, app, component, and reporter contact details.
- Acknowledgement: respond within the policy timeline and give the reporter a status-update expectation that can be tracked.
- Triage: classify whether the issue affects a single product or service, a third-party component, hardware, firmware, software, an associated service, or a potentially systemic vulnerability.
- Action: assign a remediation path, owner, collaboration contacts, expected timeframe, and communication decision.
- Closure: record the fix, mitigation, update, notification, or unresolved risk decision and keep the status history with the report.

Sources for this answer:

- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Grounds the distinction between direct reporting to affected stakeholders and wider coordination for systemic vulnerabilities.
- [IoT Security Foundation Vulnerability Disclosure Best Practice Guidelines](https://www.iotsecurityfoundation.org/wp-content/uploads/2017/12/Vulnerability-Disclosure_WG4_2017.pdf?ref=sorena.io) - External coordinated vulnerability disclosure guidance referenced by EN 303 645.

*Recommended next step*

*Placement: after practical guidance*

## Operationalize vulnerability disclosure evidence

Use this ETSI EN 303 645 workflow as the shared source for public policy checks, vulnerability action records, IXIT evidence, and review milestones.

- [Open Assessment Autopilot for ETSI EN 303 645](/solutions/assessment.md): Convert the CVD workflow into accountable tasks, evidence requests, and review milestones.
- [Research ETSI EN 303 645 source questions](/solutions/research-copilot.md): Use cited ETSI source material to resolve vulnerability disclosure, support-period, and evidence-scope questions before implementation.
- [Talk through implementation](/contact.md): Review disclosure policy contents, triage workflow, evidence owners, and the next compliance actions with Sorena.

## How TS 103 701 turns the workflow into assessment evidence

TS 103 701 does not supersede the EN 303 645 requirement. It gives an assessment method for checking whether the DUT, associated services, and relevant processes support the claimed provision. For TSO 5.2, it separates public-policy publication checks from process and monitoring evidence.

The assessment vocabulary matters. The supplier organization provides ICS and IXIT information to the test laboratory. IXIT 2-UserInfo describes the publication of the vulnerability disclosure policy, IXIT 3-VulnTypes describes actions and time frames for vulnerability types, IXIT 4-Conf records confirmations, and IXIT 5-VulnMon documents monitoring, identifying, and rectifying procedures.

- Use EN 303 645 to define the public policy and operating expectations.
- Use TS 103 701 TSO 5.2 to structure assessment evidence for publication, contents, action timeliness, implementation confirmation, and vulnerability monitoring.
- Do not call a policy assessed merely because it exists internally; TS 103 701 checks public accessibility and required contents.
- Do not use IXIT evidence as public marketing copy unless the claim also matches the published policy, DUT boundary, and assessment scope.

Sources for this answer:

- [ETSI TS 103 701 V2.1.1 consumer IoT conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Defines DUT, SO, TL, ICS, IXIT, test groups, conceptual and functional tests, and the TSO 5.2 assessment structure.
- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary source for the underlying vulnerability disclosure provisions assessed by TS 103 701.

## Evidence table for a CVD workflow

Use this operating table when turning provision 5.2 into reviewable evidence. The rows are written so each one can become a task, IXIT entry, support runbook item, or assessment request.

| Step | Owner | Evidence | Decision |

| --- | --- | --- | --- |

| 1 | Product security owner | Public vulnerability disclosure policy URL and access path | Can anybody access the policy without an account? |

| 2 | Security operations or support owner | Contact route, acknowledgement timeline, and status-update timeline | Does the policy contain the minimum EN 303 645 information? |

| 3 | Vulnerability response owner | Vulnerability-type action matrix with owners, time frames, collaboration contacts, and escalation rules | Is there no indication that described vulnerability types are handled untimely? |

| 4 | Engineering or supplier owner | Fix, mitigation, warning, rollout, or third-party coordination record | Does the response path fit firmware, hardware, software, associated-service, or component realities? |

| 5 | Compliance or assessment owner | ICS support claim, IXIT 2-UserInfo, IXIT 3-VulnTypes, IXIT 4-Conf, IXIT 5-VulnMon, and test verdicts | Does the evidence match the DUT and associated services in scope? |

- Keep the table product-specific; copying another product's response timings or vendor contacts creates weak evidence.
- Record third-party component and associated-service dependencies because TS 103 701 considers collaboration and clearly defined responsibilities as indicators for timely deployment.
- Keep public policy evidence separate from internal vulnerability action records so public accessibility and remediation operations can be assessed independently.

Sources for this answer:

- [ETSI TS 103 701 V2.1.1 consumer IoT conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Grounds the assessment evidence items for publication, vulnerability actions, confirmations, and vulnerability monitoring.
- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Grounds the public policy minimum contents and the expectation to act on disclosed vulnerabilities in a timely manner.

## Implementation checklist for EN 303 645 provision 5.2

Use this checklist before release, procurement review, or TS 103 701 evidence collection. It focuses on whether the CVD workflow is visible, actionable, and tied to the product boundary rather than buried in general support language.

- Public policy: publish a vulnerability disclosure policy on a stable external page and make sure it is reachable without a login.
- Minimum contents: include reporting contact information, initial acknowledgement timing, and status-update timing until resolution.
- Intake records: capture affected products, firmware, software, app, cloud or associated-service dependencies, component origin, reporter contact, dates, and current status.
- Action matrix: define actions and time frames for vulnerability types, including firmware, hardware, software, associated services, open source components, and commercial third-party libraries where applicable.
- Monitoring: document how the team continually monitors for, identifies, and rectifies security vulnerabilities during the defined support period.
- Assessment pack: maintain the ICS claim and IXIT entries needed for TSO 5.2, with confirmations that the implementation preconditions are in place.

Sources for this answer:

- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary source for the provision 5.2 public policy, timely action, and continuous monitoring expectations.
- [ETSI TS 103 701 V2.1.1 consumer IoT conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for checking public accessibility, policy contents, action time frames, confirmations, and monitoring procedures.

## Common mistakes that weaken CVD evidence

Most weak evidence is not caused by missing terminology. It comes from treating a generic security email address as a disclosure policy, publishing a policy with no update expectations, or keeping vulnerability actions in ticket notes that cannot be mapped to the DUT, associated services, and support period.

Be careful with the 90-day statement in EN 303 645. It is described as a conventional software vulnerability process timeline, not a universal deadline for every hardware, firmware, associated-service, or third-party dependency scenario.

- Do not claim provision 5.2 coverage if the disclosure policy is internal, login-gated, or missing acknowledgement and status-update timelines.
- Do not mix EN 303 645 provisions with TS 103 701 verdict language; one states baseline expectations, the other structures assessment checks.
- Do not assume a hardware or third-party component issue follows the same remediation timing as a server-side software fix; document the dependency and communication path.
- Do not stop at intake; provision 5.2-3 also expects continuous monitoring, identification, and rectification during the defined support period.
- Do not cite local evidence paths or internal source files in public JSON sources; use stable external HTTPS URLs with the Sorena reference parameter.

Sources for this answer:

- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Grounds the incident-specific nature of timely action and the support-period monitoring expectation.
- [ETSI TS 103 701 V2.1.1 consumer IoT conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Grounds the distinction between conceptual/functional checks and public policy evidence under TSO 5.2.

## Primary sources

- [ETSI EN 303 645 V2.1.1 consumer IoT baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/02.01.01_60/en_303645v020101p.pdf?ref=sorena.io) - Primary ETSI source for consumer IoT vulnerability disclosure policy, timely action on disclosed vulnerabilities, and continuous vulnerability monitoring during the defined support period.
  - Quote: "Provision 5.2-1"
- [ETSI TS 103 701 V2.1.1 consumer IoT conformance assessment](https://www.etsi.org/deliver/etsi_ts/103700_103799/103701/02.01.01_60/ts_103701v020101p.pdf?ref=sorena.io) - Assessment source for TSO 5.2, including public accessibility checks, policy contents, IXIT vulnerability action evidence, confirmations, monitoring evidence, and verdict assignment.
  - Quote: "Test group 5.2-1"
- [IoT Security Foundation Vulnerability Disclosure Best Practice Guidelines](https://www.iotsecurityfoundation.org/wp-content/uploads/2017/12/Vulnerability-Disclosure_WG4_2017.pdf?ref=sorena.io) - External vulnerability disclosure guidance referenced by EN 303 645 for coordinated vulnerability disclosure practices.
  - Quote: "Vulnerability Disclosure"

## Related Topic Guides

- [ETSI EN 303 645 Applicability and Scope](/artifacts/global/etsi-en-303-645/applicability-and-scope.md): Decide whether a connected product is in scope of ETSI EN 303 645, define the consumer IoT evidence boundary, and document N/A justifications for assessment.
- [ETSI EN 303 645 compliance: ICS, IXIT, evidence](/artifacts/global/etsi-en-303-645/compliance.md): Plan ETSI EN 303 645 compliance evidence for consumer IoT products with scope, ICS, IXIT, TS 103 701 assessment steps, verdict risks, and source-linked controls.
- [ETSI EN 303 645 consumer IoT products: what is in scope?](/artifacts/global/etsi-en-303-645/faq/iot-consumer-products.md): ETSI EN 303 645 FAQ on consumer IoT product scope: devices, associated services, constrained devices, out-of-scope industrial uses, ICS, IXIT, and TS 103 701 evidence.
- [ETSI EN 303 645 Current Version Tracker](/artifacts/global/etsi-en-303-645/current-version-tracker.md): Track ETSI EN 303 645 version evidence, ETSI deliverable status checks, TS 103 701 assessment alignment, and change triggers for consumer IoT security work.
- [ETSI EN 303 645 Data Protection Provisions](/artifacts/global/etsi-en-303-645/data-protection-provisions.md): source-linked guide to ETSI EN 303 645 data protection provisions for consumer IoT: personal data security, telemetry transparency, consent, and deletion evidence.
- [ETSI EN 303 645 default passwords: what must consumer IoT teams do?](/artifacts/global/etsi-en-303-645/faq/default-passwords.md): ETSI EN 303 645 default password guidance for consumer IoT: unique or user-defined passwords, pre-installed password generation, change mechanisms, brute-force controls, and TS 103 701 evidence.
- [ETSI EN 303 645 FAQ: Consumer IoT Security Questions](/artifacts/global/etsi-en-303-645/faq.md): source-linked answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, default passwords, updates, vulnerability disclosure, telemetry, deletion, and TS 103 701 evidence.
- [ETSI EN 303 645 ICS and IXIT Evidence Template](/artifacts/global/etsi-en-303-645/ics-and-ixit-evidence-template.md): Build a source-linked ICS and IXIT evidence template for ETSI EN 303 645 consumer IoT assessments, with clear separation between EN provisions and TS 103 701 test information.
- [ETSI EN 303 645 implementation checklist](/artifacts/global/etsi-en-303-645/implementation-checklist.md): Use this ETSI EN 303 645 implementation checklist to scope a consumer IoT product, record Annex B support statuses, map IXIT evidence, and avoid weak conformance claims.
- [ETSI EN 303 645 Implementation Evidence Guide](/artifacts/global/etsi-en-303-645/implementation-evidence.md): Build ETSI EN 303 645 implementation evidence from Annex B support/detail records, TS 103 701 ICS and IXIT inputs, test verdicts, and scoped external evidence.
- [ETSI EN 303 645 IoT Applicability Workflow](/artifacts/global/etsi-en-303-645/iot-applicability-workflow.md): Decide whether ETSI EN 303 645 applies to a consumer IoT product, what associated services belong in scope, and how to record justified non-applicability.
- [ETSI EN 303 645 personal data deletion FAQ for consumer IoT](/artifacts/global/etsi-en-303-645/faq/personal-data-deletion.md): What ETSI EN 303 645 says about deleting user data and personal data from consumer IoT devices, associated services, apps, and evidence records.
- [ETSI EN 303 645 requirements: consumer IoT provision map](/artifacts/global/etsi-en-303-645/requirements.md): Map ETSI EN 303 645 consumer IoT requirements to product scope, Annex B ICS entries, TS 103 701 evidence, and implementation owners.
- [ETSI EN 303 645 Secure Update Evidence Workflow](/artifacts/global/etsi-en-303-645/secure-update-evidence-workflow.md): Build secure-update evidence for ETSI EN 303 645 using provision 5.3, Annex B support/detail records, and TS 103 701 ICS, IXIT, and test-plan inputs.
- [ETSI EN 303 645 Secure Update Workflow](/artifacts/global/etsi-en-303-645/secure-update-workflow.md): Map ETSI EN 303 645 secure-update provisions into a practical workflow for consumer IoT update mechanisms, support-period disclosures, and TS 103 701 evidence.
- [ETSI EN 303 645 Secure Updates and Vulnerability Disclosure](/artifacts/global/etsi-en-303-645/secure-update-and-vulnerability-disclosure.md): source-linked guide to ETSI EN 303 645 clauses 5.2 and 5.3 for consumer IoT vulnerability disclosure, security updates, support periods, and TS 103 701 evidence.
- [ETSI EN 303 645 support period: what must consumer IoT teams publish?](/artifacts/global/etsi-en-303-645/faq/support-period.md): ETSI EN 303 645 support-period guidance for consumer IoT: defined security-update support periods, user-accessible publication, constrained-device replacement support, model designation, and TS 103 701 evidence.
- [ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?](/artifacts/global/etsi-en-303-645/faq/telemetry.md): ETSI EN 303 645 telemetry guidance for consumer IoT teams: security anomaly examination, IXIT 24-TelData evidence, personal-data minimization, and consumer telemetry disclosures.
- [ETSI EN 303 645 test evidence: what should consumer IoT teams keep?](/artifacts/global/etsi-en-303-645/faq/test-evidence.md): ETSI EN 303 645 test evidence guidance for consumer IoT teams: ICS support claims, IXIT detail, TS 103 701 test plans, verdicts, and external evidence checks.
- [ETSI EN 303 645 vs EU CRA for Consumer IoT](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-eu-cra.md): Use ETSI EN 303 645 and ETSI TS 103 701 evidence when preparing consumer IoT cybersecurity work that may also need a separate EU CRA legal mapping.
- [ETSI EN 303 645 vs RED Cybersecurity Delegated Act](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-red-cybersecurity-delegated-act.md): Compare ETSI EN 303 645 consumer IoT security evidence with RED cybersecurity planning without treating the ETSI baseline as a substitute for RED legal scope.
- [ETSI EN 303 645 vs UK PSTI: Evidence Crosswalk](/artifacts/global/etsi-en-303-645/etsi-en-303-645-vs-uk-psti.md): Compare ETSI EN 303 645 evidence with UK PSTI review needs without assuming the same scope, legal trigger, or assurance route.
- [ETSI EN 303 645 vulnerability disclosure requirements for consumer IoT](/artifacts/global/etsi-en-303-645/faq/vulnerability-disclosure.md): What ETSI EN 303 645 requires for consumer IoT vulnerability disclosure policies, report handling, status updates, timely action, and TS 103 701 evidence.
- [ETSI TS 103 701 Test Evidence Workflow for EN 303 645](/artifacts/global/etsi-en-303-645/ts-103-701-test-evidence-workflow.md): Build an ETSI TS 103 701 test evidence workflow for EN 303 645 consumer IoT assessments: DUT identification, ICS, IXIT, test plans, verdicts, and external evidence.
- [How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products?](/artifacts/global/etsi-en-303-645/faq/constrained-devices.md): ETSI EN 303 645 constrained-device guidance: what counts as constrained, when non-applicability can be justified, and what evidence should support update and authentication decisions.


---

[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/vulnerability-disclosure-cvd-workflow