We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

Artifact GuideGLOBALETSI 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 Internet of Things (IoT) products.

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

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
6 sections3 primary sources
Overview

Publish a (CVD) policy with report contact details, response timing, and enough information for a reporter to submit a vulnerability; then monitor, triage, remediate, and retain evidence through the . ETSI EN 303 645 V3.1.3 provision 5.2 states the disclosure, timely-action, and monitoring expectations. ETSI TS 103 701 V2.1.1 assesses them through public-policy checks, Implementation eXtra Information for Testing (), confirmations, and verdicts. Separate laws or assessment schemes can impose additional reporting events and clocks.

Section 1

What EN 303 645 says about vulnerability disclosure

EN 303 645 provision 5.2-1 states that the manufacturer shall make a publicly available. At minimum, the policy shall 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 describes 90 days as a conventional time in which a software vulnerability process is completed, including patch availability and notification. It is not a universal deadline: the standard says timing is incident-specific, and hardware fixes or deployment to devices can take longer.

Provision 5.2-3 adds the operating recommendation 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 .

  • Publish a 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 .
Section 2

Workflow from report intake to remediation decision

The public disclosure policy starts the workflow. A useful CVD process shows how a report reaches the responsible team, how the reporter receives an acknowledgement, how product impact is assessed, and how the organization chooses 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.
Recommended next step

Assign disclosure owners and evidence

Connect the public reporting policy to response owners, vulnerability records, remediation decisions, and the product's support period.

Assessment workflow
Open Assessment Autopilot for ETSI EN 303 645

Convert the CVD workflow into accountable tasks, evidence requests, and review milestones.

Explore next step
Research workflow
Research ETSI EN 303 645 source questions

Use cited ETSI source material to resolve vulnerability disclosure, support-period, and evidence-scope questions before implementation.

Explore next step
Talk to Sorena
Talk through implementation

Review disclosure policy contents, triage workflow, evidence owners, and the next compliance actions with Sorena.

Explore next step
Section 3

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 device under test (DUT), associated services, and relevant processes support the claimed provision. For test scenario objective (TSO) 5.2, it separates public-policy publication checks from process and monitoring evidence.

The assessment vocabulary matters. The supplier organization provides an Implementation Conformance Statement (ICS) and information to the test laboratory. IXIT 2-UserInfo describes the publication of the , 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 evidence as public marketing copy unless the claim also matches the published policy, DUT boundary, and assessment scope.
Section 4

Assign the CVD evidence checks

Assign these checks for each product so the public policy, response process, and assessment evidence remain connected.

  • The product security owner verifies that anyone can reach the public without an account and records its URL.
  • The security operations or support owner checks that the public policy includes the reporting contact, acknowledgement timeline, and status-update timeline.
  • The vulnerability response owner reviews the action matrix for each vulnerability type, including owners, timeframes, collaboration contacts, and escalation rules, and investigates signs of untimely handling.
  • The engineering or supplier owner records the fix, mitigation, warning, rollout, or third-party coordination and checks that it fits the affected firmware, hardware, software, service, or component.
  • The assessment owner checks the ICS claim, 2-UserInfo, IXIT 3-VulnTypes, IXIT 4-Conf, IXIT 5-VulnMon, and test verdicts against the DUT and associated-service scope.
  • Keep the checks 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.
Section 5

Implementation checklist for EN 303 645 provision 5.2

Review 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 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 .
  • Assessment pack: maintain the ICS claim and entries needed for TSO 5.2, with confirmations that the implementation preconditions are in place.
Section 6

Common mistakes that weaken CVD evidence

A generic security email address is not a complete disclosure policy. The policy also needs acknowledgement and status-update timelines, while internal records need to map vulnerability actions to the DUT, associated services, and .

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 .
  • Keep public policy URLs stable and link internal response records to the relevant product, reporter communication, and remediation decision.
Primary sources

References and citations

ETSI EN 303 645 V3.1.3 consumer IoT baseline requirements
etsi.org7 citations
Referenced sections
  • Primary ETSI source for consumer IoT vulnerability disclosure policy, timely action on disclosed vulnerabilities, and continuous vulnerability monitoring during the defined support period.
  • Primary source for provision 5.2 on public vulnerability disclosure policy, timely action, and ongoing vulnerability monitoring.
  • Grounds the distinction between direct reporting to affected stakeholders and wider coordination for systemic vulnerabilities.
Show 4 more
  • Primary source for the underlying vulnerability disclosure provisions assessed by TS 103 701.
  • Grounds the public policy minimum contents and the expectation to act on disclosed vulnerabilities in a timely manner.
  • Primary source for the provision 5.2 public policy, timely action, and continuous monitoring expectations.
  • Grounds the incident-specific nature of timely action and the support-period monitoring expectation.
"Provision 5.2-1"
More quoted passages
"manage reports of vulnerabilities"
"Systemic vulnerabilities"
"timely manner"
"initial acknowledgement"
"defined support period"
ETSI TS 103 701 V2.1.1 consumer IoT conformance assessment
etsi.org6 citations
Referenced sections
  • Assessment source for TSO 5.2, including public accessibility checks, policy contents, IXIT vulnerability action evidence, confirmations, monitoring evidence, and verdict assignment.
  • Assessment source for TSO 5.2 test groups that check publication, policy contents, vulnerability action, and monitoring evidence.
  • Defines DUT, SO, TL, ICS, IXIT, test groups, conceptual and functional tests, and the TSO 5.2 assessment structure.
Show 3 more
  • Grounds the assessment evidence items for publication, vulnerability actions, confirmations, and vulnerability monitoring.
  • Assessment source for checking public accessibility, policy contents, action time frames, confirmations, and monitoring procedures.
  • Grounds the distinction between conceptual/functional checks and public policy evidence under TSO 5.2.
"Test group 5.2-1"
More quoted passages
"TSO 5.2"
"ICS and IXIT"
"Publication of Vulnerability Disclosure Policy"
"VulnTypes"
"conceptual assessment"

Related guides

ETSI EN 303 645 Applicability and Scope

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

Plan ETSI EN 303 645 compliance evidence for consumer IoT products with scope, ICS, IXIT, TS 103 701 assessment steps, verdict risks, and cited controls.

ETSI EN 303 645 Current Version Tracker

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

Guide to ETSI EN 303 645 data protection provisions for consumer IoT, including security, consent, telemetry, deletion, minimization, aggregation, and anonymization.

ETSI EN 303 645 FAQ: Consumer IoT Security Questions

Practical answers to common ETSI EN 303 645 questions on consumer IoT scope, associated services, passwords, updates, vulnerability disclosure, telemetry, deletion, and assessment evidence.

ETSI EN 303 645 ICS and IXIT Evidence Template

Build a cited 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.

Show all related guides (25)

ETSI EN 303 645 implementation checklist

This ETSI EN 303 645 implementation checklist helps 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

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

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 requirements: consumer IoT provision map

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

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

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

Source-backed guide to ETSI EN 303 645 clauses 5.2 and 5.3 for consumer IoT vulnerability disclosure, security updates, support periods, and assessment evidence.

ETSI EN 303 645 vs EU CRA for Consumer IoT

Compare ETSI EN 303 645 consumer IoT evidence with the EU Cyber Resilience Act's scope, manufacturer duties, application dates, and conformity requirements.

ETSI EN 303 645 vs RED Cybersecurity Delegated Act

Compare ETSI EN 303 645 consumer IoT evidence with the RED cybersecurity requirements, EN 18031 standards, application date, and conformity routes.

ETSI EN 303 645 vs UK PSTI: Evidence Crosswalk

Compare ETSI EN 303 645 evidence with UK PSTI scope, three mandatory security requirements, statements of compliance, duties, and enforcement.

ETSI TS 103 701 Test Evidence Workflow for EN 303 645

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.

ETSI EN 303 645 consumer IoT products: what is in scope?

Decide whether a device and its associated services are in scope of ETSI EN 303 645 V3.1.3 and document the DUT, ICS, IXIT, and assessment boundary.

ETSI EN 303 645 default passwords: what must consumer IoT teams do?

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 personal data deletion FAQ for consumer IoT

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 support period: what must consumer IoT teams publish?

ETSI EN 303 645 support-period guidance for consumer IoT: defined security-update support periods, user-accessible publication, non-updateable-device replacement support, model designation, and TS 103 701 evidence.

ETSI EN 303 645 telemetry: what should consumer IoT teams evidence?

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?

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 vulnerability disclosure requirements for consumer IoT

What ETSI EN 303 645 requires for consumer IoT vulnerability disclosure policies, report handling, status updates, timely action, and TS 103 701 evidence.

How should teams handle constrained devices under ETSI EN 303 645 for consumer IoT products?

How ETSI EN 303 645 V3.1.3 treats use-case resource constraints, non-updateable devices, N/A claims, authentication controls, and assessment evidence.