Artifact GuideGLOBALETSI EN 303 645

ETSI EN 303 645 Applicability and Scope

Decide whether a connected product is a consumer IoT device under ETSI EN 303 645, then define the evidence boundary before making assurance claims.

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

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

Use four branches to decide scope. First, determine whether the product is a . Second, identify the physical device and the associated services typically required for its intended functionality. Third, test each provision's mandatory, recommended, conditional, or feature-dependent status against the product facts. Fourth, record the Device Under Test, support decision, evidence, and reassessment triggers before making a claim.

Section 1

What is in scope of ETSI EN 303 645?

ETSI EN 303 645 applies to consumer IoT devices connected to network infrastructure, such as the Internet or a home network, and to their interactions with associated services. The standard gives examples such as connected children's toys and baby monitors, smoke detectors, door locks, window sensors, gateways, smart cameras, smart TVs, speakers, wearable health trackers, home automation and alarm systems, connected appliances, and smart home assistants.

Decide whether the product is a , which associated services are part of the overall IoT product, and whether any security claim depends on companion apps, cloud services, APIs, telemetry services, gateways, hubs, or support processes. Having software alone does not put a product in scope.

  • Branch 1 - consumer product: continue when the network-connected or network-connectable device is typically used by consumers in the home or as an electronic wearable. Retail sale, professional installation, or business deployment does not by itself move an otherwise consumer device out of scope.
  • Branch 2 - primary industrial purpose: stop the EN 303 645 scope analysis when the device is primarily intended for manufacturing, healthcare, or another industrial application. Record the intended-purpose evidence and check the separate law, contract, or sector standard that prompted the review.
  • Record the device and required associated services together, but keep the boundary explicit: the EN provisions apply to the device and its interactions with associated services, and V3.1.3 defines those services as part of the overall consumer IoT product.
  • Record whether the product is typically used in the home or as an electronic wearable, even if it is also deployed in a business setting.
  • Treat products primarily intended for manufacturing, healthcare, or other industrial applications as outside this EN's scope. A law or contract may impose separate duties or request an EN 303 645 mapping, but it does not change the standard's stated product scope.
  • Do not claim that EN 303 645 covers every security issue: the standard describes a baseline and says it is not intended to solve all consumer IoT security challenges.
Section 2

How should associated services be handled?

EN 303 645 defines associated services as digital services that, together with the device, form part of the overall consumer IoT product and are typically required for intended functionality. Examples include mobile applications, cloud computing or storage, third-party APIs, and a manufacturer-chosen telemetry service.

EN 303 645 V3.1.3 defines associated services as part of the overall consumer IoT product and applies its provisions to the device and its interactions with those services. For practical evidence work, this means a team should not ignore a service that is required for authentication, updates, telemetry, remote access, deletion, user information, or vulnerability handling.

  • List every associated service needed for the intended product functionality.
  • Classify a manufacturer-selected telemetry service, required mobile application, cloud storage endpoint, or third-party API as an associated service when it forms part of the product and is typically required for intended functionality.
  • Keep a user-chosen news website, streaming service, video-sharing service, or optional app outside the associated-service boundary when the manufacturer does not include it as part of the product's intended functionality.
  • State which security provisions rely on a companion app, cloud endpoint, gateway, hub, API, or telemetry flow.
  • Keep a separate note for external services that are visible to the user but not required for the consumer IoT product's intended functionality.
  • Review the boundary whenever firmware, apps, cloud behavior, APIs, or support processes materially change.
Section 3

When can a provision be marked not applicable?

EN 303 645 recognizes that applicability depends on the device. Provision 5.0-1 requires a recorded justification for each recommendation considered not applicable or not fulfilled. Annex B separately limits an N/A support entry to a conditional provision whose condition is not satisfied or a provision tied to a feature, capability, or mechanism that does not exist.

The standard gives examples such as resource constraints, a missing function, or an additional industry or regulatory requirement that precludes a provision. A statement such as "not relevant to our architecture" is not enough: identify the condition or feature, the product facts, and the supporting evidence.

  • For a mandatory provision without an applicable C or F condition, do not use N/A. Record support or non-support and let the applicable assessment or scheme determine the consequence.
  • Record a justification for every recommendation treated as not applicable or not fulfilled.
  • Tie each resource-constraint claim to the use case, the product facts, and the exact provision it affects. Do not use a product-wide constrained-device label as a substitute for provision-by-provision analysis.
  • Tie each N/A claim to an unmet Annex B condition or the absence of the relevant feature, capability, or mechanism.
  • Keep N/A justifications reviewable by assurance assessors, supply-chain stakeholders, security researchers, or retailers.
Section 4

What evidence should be ready for TS 103 701 assessment?

ETSI TS 103 701 is a conformance assessment methodology for consumer IoT devices, their relation to associated services, and corresponding relevant processes against ETSI EN 303 645. It can be used in first-, second-, or third-party assessment and within certification or conformance-declaration schemes, but it does not define a scheme.

For scope work, the key assessment artifacts are the Device Under Test identification, the Implementation Conformance Statement, and the Implementation eXtra Information for Testing. TS 103 701 says the supplier organization provides ICS and IXIT to the test laboratory, and the test laboratory uses them to derive a test plan.

  • Complete the DUT identification for the specific and software version being assessed.
  • Complete the ICS in a way that makes conditional and feature-based N/A claims consistent with implemented functionality.
  • Complete the IXIT for provisions claimed as Yes, including information needed for conceptual and functional test activities.
  • Provide enough product, service, process, and user-documentation evidence for the test laboratory to check completeness, consistency, and soundness.
  • Use external evidence only where the assessment scheme and TS 103 701 method allow it.
Section 5

Practical scope checklist before publishing a claim

Before a public page, procurement response, or assessment package says that a product follows ETSI EN 303 645, make the scope statement specific enough to test. The standard is a baseline for consumer IoT, while TS 103 701 test cases are generic and expect competent bodies to derive a suitable test plan.

The scope record should stand alone: a reviewer should be able to identify the device, associated services, relevant processes, provisions claimed Yes or N/A, and the evidence location without relying on tribal knowledge.

  • Name the specific consumer IoT product and the software or firmware version used for the claim.
  • List required associated services and the provisions that depend on them.
  • Separate baseline EN 303 645 claims from additional internal policy, customer, legal, or procurement requirements.
  • Record constrained-device reasoning and every recommendation treated as not applicable or not fulfilled.
  • Reassess after a change to intended use, target market, device model, firmware, companion app, cloud endpoint, API, telemetry provider, update route, authentication feature, support process, or public claim.
  • Avoid broad compliance wording unless the boundary, assessment method, evidence set, and version are stated.
Primary sources

References and citations

etsi.org
Referenced sections
  • ETSI's public standards search page for checking deliverable status before relying on a specific ETSI version in public claims.
"Search Standards"
Related guides

Explore more topics

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 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 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 CVD Workflow for IoT Vulnerability Reports
Cited workflow for ETSI EN 303 645 vulnerability disclosure: public policy contents, reporting contact, acknowledgement and status timelines, timely action, and TS 103 701 evidence.
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 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 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.
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 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 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 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 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 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.
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.
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.