Comparison GuideGLOBALETSI EN 303 645

ETSI EN 303 645 vs EU Cyber Resilience Act

Use ETSI EN 303 645 as technical evidence for consumer IoT controls, then map it to the EU CRA's separate legal scope, lifecycle duties, technical documentation, and conformity route.

The CRA reporting duties apply from 11 September 2026 and most other provisions from 11 December 2027. An ETSI assessment is supporting evidence, not automatic CRA conformity.

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

Structured answer sets in this page tree.

Primary sources
5

Cited legal and guidance references.

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

ETSI EN 303 645 V3.1.3 and the EU do different jobs. EN 303 645 is a voluntary baseline for network-connected consumer IoT devices; the CRA is binding EU law for products with digital elements made available on the EU market. A consumer IoT product may fall under both, but an EN 303 645 assessment does not establish CRA scope, satisfy every Annex I requirement, select the conformity-assessment route, or authorize CE marking. Reuse the ETSI control and test evidence only after mapping it to the same product version and the applicable CRA requirement.

Side-by-side comparison

ETSI EN 303 645 vs EU CRA: controls, evidence, and legal duties

The two instruments overlap on product-security controls but differ in scope, legal force, responsible actors, lifecycle duties, reporting, and conformity assessment.

Review all sources
First framework
ETSI EN 303 645

A consumer IoT baseline standard covering high-level security and data-protection provisions for network-connected consumer IoT devices and their interactions with associated services.

Second framework
EU Cyber Resilience Act

Binding EU law for products with digital elements, with manufacturer, importer, distributor, conformity-assessment, CE-marking, vulnerability-handling, and reporting duties.

Comparison row 1

Scope

ETSI EN 303 645

EN 303 645 V3.1.3 applies to consumer IoT devices connected to network infrastructure, such as the Internet or a home network, and to their interactions with associated services, which it defines as part of the overall consumer IoT product.

EU Cyber Resilience Act

The CRA covers products with digital elements made available on the EU market when their intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Article 2 excludes specified sectors and non-commercial free and open-source software; product-specific exclusions still need checking.

Operational implication

Use the ETSI boundary to build product evidence, then run a separate CRA scope analysis instead of assuming the two scopes are identical.

Comparison row 2

Who must act

ETSI EN 303 645

EN 303 645 addresses manufacturers and other relevant entities involved in developing or operating consumer IoT devices. It does not allocate legal duties; it describes baseline security behaviors that product teams, procurement functions, and assurance programs should verify.

EU Cyber Resilience Act

The CRA assigns the main design, risk-assessment, documentation, conformity, CE-marking, support, and vulnerability-handling duties to the manufacturer. Importers and distributors must verify specified compliance elements and act when they believe a product is non-compliant; an importer or distributor can become the manufacturer when marketing under its own name or making a substantial modification.

Operational implication

Assign ETSI evidence to product and security owners, but record the CRA manufacturer, importer, and distributor separately. Contracting out development or testing does not transfer the manufacturer's CRA duties.

Comparison row 3

Trigger or threshold

ETSI EN 303 645

EN 303 645 applies as a voluntary baseline whenever a product is a consumer IoT device connected to a network. No formal regulatory trigger is required; teams may apply the standard at design time, procurement, or assurance review for any network-connected consumer product.

EU Cyber Resilience Act

The main CRA product requirements apply from 11 December 2027 to in-scope products placed on the EU market. Article 14 reporting applies from 11 September 2026, including to in-scope products already placed on the market. A pre-11 December 2027 product otherwise becomes subject to the substantive requirements when it undergoes a substantial modification after that date.

Operational implication

Confirm CRA product-type classification before deciding how EN 303 645 evidence will be used, because the CRA may require different or additional conformity routes beyond what a voluntary EN 303 645 assessment covers.

Comparison row 4

Core obligations

ETSI EN 303 645

EN 303 645 baseline topics include no universal default passwords, vulnerability disclosure policies, keeping software updated, secure communications, minimised attack surface, software integrity, secure personal data storage, resilient connectivity, accessible system telemetry data, and ease of deletion of personal data.

EU Cyber Resilience Act

CRA Annex I requires products to be designed, developed, and produced for an appropriate level of cybersecurity based on risk, made available without known exploitable vulnerabilities, securely configured by default where applicable, protected against unauthorized access, and supported by vulnerability-handling processes. Article 13 also requires a cybersecurity risk assessment, technical documentation, conformity assessment, an EU declaration of conformity, CE marking, and user information.

Operational implication

Map EN 303 645 provisions to CRA essential requirements row by row if evidence reuse is intended, because the standard structure and the CRA requirement categories do not align one-to-one.

Comparison row 5

Evidence and records

ETSI EN 303 645

TS 103 701 structures ETSI assessment work around the Device Under Test, Supplier Organization, Test Laboratory, ICS, IXIT, test groups, and verdicts. Evidence should show the assessed product boundary, software version, tested provisions, test method, and a conformance claim that names the EN 303 645 edition used; this page uses V3.1.3.

EU Cyber Resilience Act

CRA Annex VII technical documentation must describe the product, design and development, vulnerability-handling processes, the cybersecurity risk assessment, applied standards or specifications, test reports, the EU declaration of conformity, and the support-period determination. ETSI records can support relevant entries only where the tested product boundary and requirement match.

Operational implication

Tag each evidence item by source obligation: EN 303 645 assessment record, CRA technical documentation requirement, or shared supporting evidence. Do not treat a TS 103 701 compliance claim as a CRA conformity assessment without a separate review.

Comparison row 6

Timing and cadence

ETSI EN 303 645

EN 303 645 expects all software components in consumer IoT devices that are not immutable for security reasons to be securely updateable. Teams should track support timelines and plan reassessment when key components reach end-of-life or when the assessed product configuration changes significantly.

EU Cyber Resilience Act

Manufacturers must notify an actively exploited vulnerability through the CRA reporting system with an early warning within 24 hours and a fuller notification within 72 hours, followed by a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident affecting product security, the deadlines are a 24-hour early warning, a 72-hour incident notification, and a final report within one month after that notification. These Article 14 duties apply from 11 September 2026.

Operational implication

Use EN 303 645 support-timeline guidance as a design input and as evidence for the CRA product-lifecycle claim, but record the CRA deadline obligations separately and tie them to the legal entity responsible for market-surveillance cooperation.

Comparison row 7

Enforcement and assurance route

ETSI EN 303 645

EN 303 645 is a voluntary standard with no independent enforcement authority. Compliance claims are based on internal or third-party testing against the standard. Non-conformance does not itself trigger regulatory action unless the standard is cited in an OJEU harmonised-standard reference for a binding EU regulation.

EU Cyber Resilience Act

Member State market-surveillance authorities enforce the CRA and can require corrective action, prohibit or restrict a product, or order withdrawal or recall. The CRA sets maximum administrative fines by infringement category, including up to EUR 15 million or 2.5% of total worldwide annual turnover for breaches of the essential cybersecurity requirements.

Operational implication

Do not describe an EN 303 645 compliance claim as CRA market-access conformity. Maintain a CRA conformity record identifying the selected Article 32 route, supporting standards, EU declaration, CE-marking basis, and responsible market-surveillance contacts.

Comparison row 8

Overlap and reuse

ETSI EN 303 645

TS 103 701 conformance assessment work for EN 303 645 can be reused in a CRA technical file if the product boundary, tested provisions, and methodology are documented and the CRA requirement mapping is explicit.

EU Cyber Resilience Act

CRA technical documentation may include EN 303 645 and TS 103 701 records as supporting evidence. That reuse does not create a presumption of conformity unless an applicable harmonised standard or common specification covers the CRA requirement and the manufacturer meets the conditions for the chosen Article 32 route.

Operational implication

When reusing EN 303 645 evidence for CRA, write a bridge document that lists: each CRA essential requirement, the EN 303 645 provision used, the test result, the product boundary match, and any gap requiring additional CRA-specific work.

Comparison row 9

Practical decision rule

ETSI EN 303 645

Use EN 303 645 and TS 103 701 when the question is how to design, test, document, or assess consumer IoT baseline cybersecurity controls.

EU Cyber Resilience Act

Use official CRA materials when the question is who is legally obligated, when obligations apply, which conformity route is required, or what public legal claim can be made.

Operational implication

Collect ETSI proof, then map it to CRA only where the regulation supports the same product boundary and requirement.

Practical decision rule

How to decide what controls the work

  • Use ETSI EN 303 645 when the task is to define or evidence consumer IoT baseline security controls.
  • Use ETSI TS 103 701 when the task is to assess those controls with DUT, ICS, IXIT, tests, verdicts, and external evidence.
  • Use official CRA analysis when the task is legal scope, economic-operator duty, conformity route, application timing, enforcement, or a public CRA compliance claim.
Section 2

How to use ETSI evidence in a CRA workstream

Treat EN 303 645 as an evidence-producing standard for consumer IoT. Reuse requires the CRA obligation and product boundary to match the ETSI evidence boundary; associated services identified under EN 303 645 may also form part of the CRA product's remote data-processing solution and risk assessment.

The bridge matrix should show the CRA Annex I requirement, the ETSI provision, the evidence artifact, the product release or DUT boundary, the owner, and the remaining gap. It should also identify whether the product is outside the listed important and critical classes, important class I, important class II, or critical because that classification can change the permitted conformity route.

  • Start with the ETSI product boundary: consumer IoT device, software, user interface, update mechanism, telemetry path, and interactions with associated services.
  • Name the evidence artifact: provision map, ICS declaration, IXIT entry, conceptual test, functional test, software update record, vulnerability disclosure record, telemetry review, or deletion-function proof.
  • For each CRA row, record scope, responsible economic operator, Annex I requirement, support period, conformity route, application date, and whether additional evidence is needed.
Section 3

ETSI controls that often become reusable evidence

The ETSI controls most likely to help a CRA readiness project are the ones that already produce product-specific proof. Generic policies are weaker than release-specific evidence tied to the DUT, software version, support period, update process, interfaces, telemetry, and user-data lifecycle.

For example, EN 303 645 expects software components in consumer IoT devices to be securely updateable, expects manufacturers to publish the defined support period, and describes telemetry examination for security anomalies when telemetry data is collected. The CRA requires manufacturers to determine a support period that generally lasts at least five years, unless the product is expected to be used for less than five years, and to handle vulnerabilities effectively throughout that period. The CRA rule is not replaced by the ETSI support-period statement.

  • Secure updates: capture the update mechanism, authenticity and integrity controls, user notification flow, support-period publication, and update evidence.
  • Vulnerability handling: keep the reporting channel, triage process, affected component list, remediation decision, and disclosure records.
  • Personal data and telemetry: record what personal data and telemetry are processed, why they are used, who uses them, and how users receive clear information.
  • Deletion and lifecycle: prove that users can remove user data from the device and personal data from associated services in the relevant scenarios.
Section 4

Where ETSI evidence should not be overclaimed

EN 303 645 is not a CRA compliance manual. It does not allocate CRA duties among manufacturers, importers, and distributors; establish CRA reporting clocks; classify important or critical products; select conformity-assessment modules; or create a CRA presumption of conformity.

Most CRA provisions apply from 11 December 2027. Article 14 reporting applies from 11 September 2026, and the conformity-assessment-body provisions in Chapter IV apply from 11 June 2026. Products placed on the market before 11 December 2027 generally enter the substantive product requirements only after a substantial modification, but Article 14 reporting applies to all in-scope products, including those placed on the market earlier.

  • Avoid phrases such as "CRA compliant through EN 303 645" unless supported by official CRA and harmonized-standard materials.
  • Do not copy the ETSI associated-service boundary into CRA scoping without checking CRA product and service definitions separately.
  • Keep legal triggers, conformity routes, Article 14 reporting, and market-surveillance exposure in a separate CRA-owned column.
Section 5

A practical bridge-matrix workflow

Build the bridge matrix only after separating the ETSI and CRA scopes. Populate the ETSI columns from EN 303 645 provisions and TS 103 701 assessment evidence. Populate the CRA columns from the regulation, including the applicable Annex I requirement, product class, support period, Article 32 conformity route, and any reporting duty.

Leave a row marked "not assessed" when the product facts, CRA classification, or source mapping are incomplete. Do not fill the gap with an ETSI conformance verdict.

  • Column 1: ETSI provision or TS 103 701 test objective.
  • Column 2: Product boundary, DUT, software version, associated-service interaction, and support-period assumption.
  • Column 3: Evidence artifact, such as ICS, IXIT, test result, update record, disclosure record, telemetry review, or deletion proof.
  • Column 4: CRA obligation, source citation, product class, responsible economic operator, and conformity route.
  • Column 5: Reuse decision: reusable, partially reusable, not reusable, or unresolved.
Section 6

Checklist before publishing an ETSI-to-CRA claim

Before a team publishes a customer-facing statement, procurement response, or audit summary, check that every claim is tied to the correct source. ETSI evidence can be strong and still be insufficient for a CRA statement if the legal hook is missing.

  • Confirm the page names EN 303 645 as a consumer IoT baseline, not as a full CRA compliance route.
  • Verify that the ETSI source version, product boundary, associated-service assumptions, support period, and evidence artifacts are named.
  • Keep CRA-specific claims limited to what the reviewed CRA source says; otherwise mark them as unresolved mapping work.
  • Make each reused evidence item traceable to a release, DUT, test plan, or assessment window.
Primary sources

References and citations

Related guides

Explore more topics

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