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.

Applicability WorkflowGLOBALETSI EN 303 645

ETSI EN 303 645 IoT Applicability Workflow

A practical workflow for deciding whether a product is in ETSI EN 303 645 scope and how to document provision-level applicability.

Use it to separate consumer IoT scope decisions, associated-service boundaries, device resource constraints, and TS 103 701 assessment inputs.

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

Decide first whether the product is a : a network-connected or network-connectable device that consumers typically use in the home or wear, rather than equipment primarily intended for manufacturing, healthcare, or another industrial application. Then identify , decide each provision separately, document any resource-constraint rationale, and prepare the evidence needed for an ETSI TS 103 701 V2.1.1 assessment against ETSI EN 303 645 V3.1.3.

Section 1

Start with the consumer IoT scope test

ETSI EN 303 645 is written for consumer IoT devices connected to network infrastructure, such as the Internet or a home network, and for the device's interactions with . The standard gives examples including connected toys, baby monitors, smoke detectors, door locks, window sensors, gateways, hubs, smart cameras, TVs, speakers, wearable health trackers, home automation systems, alarms, connected appliances, and smart home assistants.

A product is not outside scope merely because it is used by a business. ETSI defines consumer IoT devices as network-connected or network-connectable devices used by consumers typically in the home or as electronic wearables, and notes that consumer IoT devices can also be used in business contexts. The stronger exclusion is product intent: devices primarily intended for manufacturing, healthcare, or other industrial applications are not in scope.

  • Record the product type, intended users, intended environment, network connectivity, and whether consumers can typically buy or use the device.
  • Treat business deployment of a consumer product as still potentially in scope; do not use business use alone as an exemption.
  • If the product is primarily industrial, healthcare, or manufacturing equipment, document that intended-use basis rather than using a generic non-IoT label.
  • Record the edition used for the decision. This page uses ETSI EN 303 645 V3.1.3 (September 2024) and ETSI TS 103 701 V2.1.1 (May 2025), which identifies EN 303 645 V3.1.3 as its normative EN reference.
Section 2

Draw the product boundary before mapping provisions

ETSI EN 303 645 defines an IoT product as the and its . Associated services are digital services that, together with the device, form the overall consumer IoT product and are typically required for the intended functionality. Examples include mobile applications, cloud computing or storage, and third-party APIs when they are part of the product.

The boundary is not every remote service the device can reach. Manufacturer-included telemetry, a companion app required during initialization, and a cloud access service used to control a smart lock are . A user-chosen streaming service, a website opened in a device browser, or an app installed later at the user's choice is not automatically an associated service under the ETSI examples.

  • List device hardware, firmware, mobile apps, cloud functions, telemetry services, update services, APIs, hubs, gateways, and support processes that are needed for intended functionality.
  • Classify each service as manufacturer-included, required during initialization, user-chosen after initialization, or unrelated third-party content.
  • Keep associated-service interactions in the evidence boundary. EN 303 645 V3.1.3 covers consumer IoT devices and their interactions with , while TS 103 701 assesses the DUT's relation to those services and relevant processes.
  • Use the boundary to decide which teams must provide evidence: firmware, app, cloud, support, vulnerability disclosure, privacy, and product documentation.
Section 3

Decide applicability at provision level, not by blanket exemption

ETSI EN 303 645 sets a consumer IoT security and data protection baseline, but provision applicability depends on the device. Provision 5.0-1 requires a recorded justification for each recommendation considered not applicable or not fulfilled. Annex B provides a structured implementation conformance statement table for provision references, status, support, and detail.

Record why each provision is supported, not supported, or not applicable. In the V3.1.3 Annex B pro forma, Y means supported and N means not supported. N/A is available when a stated condition is not satisfied or when the feature, capability, or mechanism to which an F-marked provision applies does not exist; the detail column records the rationale.

  • For every provision, capture whether it is mandatory or recommended, any conditional (C) or feature-dependent (F) applicability marker, its Y, N, or N/A support value, implementation detail, and the rationale for any N/A or N decision.
  • Use N/A only when a listed condition is not satisfied or an identified feature, capability, or mechanism does not exist; otherwise record implementation detail or a non-fulfilment rationale.
  • Do not turn a device resource constraint into a whole-standard exclusion; tie it to the specific provision, use case, and resource limitation.
  • Keep recommendation decisions visible because ETSI explicitly requires justification when a recommendation is considered not applicable or not fulfilled.
Section 4

Handle device resource constraints as evidence, not shorthand

ETSI EN 303 645 V3.1.3 addresses rather than defining a blanket constrained-device category. Examples include energy supply, communication bandwidth, processing power, and volatile or non-volatile memory capacity.

A resource-constraint rationale needs product-specific reasoning. For example, provision 5.3-2 allows the absence of a secure update mechanism only when a resource constraint determined by the use case prevents implementation. ETSI says economic reasons alone do not justify that design. Capture the use case, resource limitation, affected provision, risk basis, alternative control, and user-facing support information.

  • Identify the physical limitation: power, battery life, processing capacity, storage, bandwidth, physical access, limited functionality, display, or input capability.
  • Link the limitation to the exact provision affected, such as secure updates, authentication, or user interaction.
  • Describe any hub, base station, companion app, replacement support, isolation option, or associated service that carries the relevant security function.
  • Reject rationales based only on avoiding implementation cost; V3.1.3 requires a technical resource constraint determined by the use case for the secure-update exception.
Recommended next step

Assign scope decisions and evidence handoffs

This workflow helps turn scope, associated-service, device-resource, and provision-level decisions into owned ICS, IXIT, and evidence tasks.

Assessment workflow
Open Assessment Autopilot for ETSI EN 303 645

Convert applicability decisions into accountable tasks, evidence requests, and assessment milestones.

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

Resolve product scope, associated-service, device-resource, and evidence questions against cited ETSI sources.

Explore next step
Talk to Sorena
Talk through ETSI EN 303 645 implementation

Review the product boundary, provision mapping, evidence owners, and next compliance actions with Sorena.

Explore next step
Section 5

Convert the decision into TS 103 701 assessment inputs

ETSI TS 103 701 provides a conformance assessment methodology for consumer IoT devices, their relation to , and relevant processes against ETSI EN 303 645. A test laboratory can be part of the supplier organization, a user organization, or an independent testing authority. A separate assessment scheme sets matters outside TS 103 701, such as tester competence, scheme-specific cryptographic requirements, accepted third-party evidence, and publication of results.

For assessment readiness, translate the applicability decision into a defined , supplier organization responsibilities, entries, entries, and evidence records. TS 103 701 explains that the supplier organization provides ICS and IXIT to the test laboratory, and the test laboratory uses those documents to derive a test plan.

  • Name the DUT as a specific and use the most up-to-date software version for assessment unless the assessment scope says otherwise.
  • Identify the supplier organization and the teams it must coordinate with, such as component manufacturers, service providers, and application developers.
  • Prepare entries for capabilities and support decisions, then entries for security measures, assessment environment, interfaces, services, and process evidence.
  • Separate conceptual evidence about design from functional evidence about the DUT, , or development and management processes.
Section 6

Applicability checks for release reviews

Assign these checks before recording the scope decision or handing the product to an assessor.

  • Product owner: product scope. Evidence: Intended use, user type, device category, network connectivity. Check: Is this a or primarily industrial, healthcare, manufacturing, or another excluded use?
  • Architecture owner: associated-service boundary. Evidence: App, cloud, telemetry, API, hub, gateway, update, and support-service map. Check: Which services are part of the IoT product because they are manufacturer-included or required for intended functionality?
  • Security/compliance owner: provision applicability. Evidence: Annex B-style provision table with support, N/A, and detail entries. Check: Which provisions are supported, not supported, or conditionally not applicable with a recorded rationale?
  • Engineering owner: resource-constraint rationale. Evidence: Use case, technical limitation, affected provision, risk basis, alternative control, user information. Check: Is non-applicability justified for a specific provision, or is the claim too broad?
  • Supplier organization lead: assessment handoff. Evidence: DUT version, , , external evidence, conceptual and functional test evidence. Check: Can a test laboratory derive a defensible test plan from the supplied evidence?
  • Do not collapse these checks into a yes/no scope answer; provision-level records are what make the decision reusable.
  • Re-run the workflow after material firmware, app, cloud, support-process, associated-service, or product-intended-use changes.
  • Use ETSI Search & Browse before public version-sensitive claims, because ETSI deliverables may be revised or have their status changed.
Section 7

Common mistakes that weaken applicability decisions

An applicability record needs the reasoning between product scope, the associated-service boundary, conditional provisions, and assessment evidence. It should show why the product is within the consumer IoT scope, why a specific provision is not applicable, or why the product's primary intended use places it outside scope.

  • Do not claim the whole standard is inapplicable because a device resource constraint affects one provision.
  • Do not omit cloud, mobile app, telemetry, update, or API dependencies that are required for intended functionality.
  • Do not treat a user-installed optional service as an associated service without showing why the manufacturer included it or required it for initialization.
  • Do not mark a provision N/A unless a stated condition is not satisfied or an F-marked feature, capability, or mechanism does not exist.
  • Do not present TS 103 701 as a certification scheme; it supplies assessment methodology, and scheme definition is outside its scope.
Primary sources

References and citations

ETSI EN 303 645 V3.1.3
etsi.org8 citations
Referenced sections
  • Primary source for consumer IoT scope, associated-service definitions, device resource constraints, Provision 5.0-1, and V3.1.3 Annex B implementation-record fields.
  • Primary source for consumer IoT scope, examples, exclusions, associated-service definitions, and provision applicability records.
  • Defines associated services and gives examples distinguishing manufacturer-provided services from user-chosen content.
Show 5 more
  • Primary source for Provision 5.0-1 and the V3.1.3 Annex B M, R, C, F, Y, N, N/A, and detail-column rules.
  • Explains device resource constraints, use-case dependence, and the secure-update exception where a resource constraint prevents implementation.
  • Baseline provisions source that TS 103 701 assesses against.
  • Supports the scope, associated-service, device-resource-constraint, and V3.1.3 Annex B provision-recording decisions in the workflow.
  • Grounds the warnings about resource-constraint rationales, associated-service classification, and N/A limitations.
"high-level security and data protection provisions"
More quoted passages
"Devices that are not consumer IoT devices"
"digital services that, together with the device"
"A justification shall be recorded"
"constraints in device resources"
"baseline provisions applicable to all consumer IoT devices"
"Table B.1 provides a schema"
"N/A"
ETSI TS 103 701 V2.1.1
etsi.org8 citations
Referenced sections
  • Primary source for the assessment methodology, including DUT, SO, TL, ICS, IXIT, conceptual and functional tests, and external evidence handling.
  • Assessment methodology source for consumer IoT devices, associated services, relevant processes, ICS, IXIT, and test-plan derivation.
  • Explains that TSOs address DUT functionality, relation to associated services, and development or management processes.
Show 5 more
  • Assessment methodology source for using ICS and IXIT as inputs to a test plan.
  • Explains assessment against DUT functionality, associated-service relation, and processes rather than device-only narrative claims.
  • Primary assessment source for DUT, SO, TL, ICS, IXIT, conceptual tests, functional tests, and test-plan derivation.
  • Supports the DUT, SO, TL, ICS, IXIT, conceptual-test, functional-test, and external-evidence handoff decisions.
  • Grounds the warning that TS 103 701 supports assessment activity while scheme definition is out of scope.
"conformance assessment methodology"
More quoted passages
"conformance assessment methodology for consumer IoT devices"
"relation to associated services"
"ICS and IXIT are provided"
"DUT functionality, its relation to associated services"
"The TL uses these documents to derive a test plan."
"Conceptual: Assessing conformity"
"Defining a certification or conformance declaration scheme is out of scope"

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

Show all related guides (25)

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