| Scope | 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. | 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. | Use the ETSI boundary to build product evidence, then run a separate CRA scope analysis instead of assuming the two scopes are identical. |
|---|
| Who must act | 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. | 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. | 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. |
|---|
| Trigger or threshold | 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. | 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. | 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. |
|---|
| Core obligations | 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. | 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. | 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. |
|---|
| Evidence and records | 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. | 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. | 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. |
|---|
| Timing and cadence | 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. | 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. | 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. |
|---|
| Enforcement and assurance route | 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. | 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. | 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. |
|---|
| Overlap and reuse | 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. | 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. | 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. |
|---|
| Practical decision rule | Use EN 303 645 and TS 103 701 when the question is how to design, test, document, or assess consumer IoT baseline cybersecurity controls. | 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. | Collect ETSI proof, then map it to CRA only where the regulation supports the same product boundary and requirement. |
|---|