| Scope | 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 associated services themselves are out of scope in the ETSI text. | CRA scope cannot be fully stated from the assigned ETSI grounding. Confirm product and service coverage from official CRA materials before reusing the ETSI boundary. | 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. | CRA duties are allocated to EU law actors: manufacturers, importers, and distributors of products with digital elements. The CRA creates binding obligations and market-access requirements that differ from the voluntary baseline in EN 303 645. | Assign EN 303 645 work to the product or security team. Assign CRA compliance to the manufacturer or EU-importer legal owner. Do not use the same actor assignment for both without checking whether the person or entity is both the security engineer and the legally responsible manufacturer. |
|---|
| 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. | CRA scope is triggered by placing or making available a product with digital elements on the EU market. The regulation applies mandatory essential requirements, conformity assessment, CE marking, and vulnerability-reporting obligations once a product meets the CRA product-type scope. | 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 essential requirements should be mapped separately. The ETSI grounding does not provide a complete CRA essential-requirements list; teams should use official CRA text for the authoritative product-security, vulnerability-management, and market-placement obligations. | 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, test laboratory, test specification, and compliance claim. Evidence should show the assessed product boundary, tested provisions, test methodology, and a conformance claim clearly limited to EN 303 645 V2.1.1. | CRA technical documentation and conformity evidence may overlap with EN 303 645 records but require additional fields and a distinct legal basis. EN 303 645 assessment records may be included as technical evidence in a CRA technical file if the product boundary and tested requirements 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 software components in consumer IoT devices to use only components actively supported. Teams should track support timelines and plan reassessment when key components reach end-of-life or when the assessed product configuration changes significantly. | CRA timing obligations include vulnerability-reporting, support commitments, and product lifecycle expectations that differ from EN 303 645 advisory language. CRA deadlines are regulatory and tied to market-placement and post-market surveillance obligations. | 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. | CRA enforcement is handled by market-surveillance authorities in Member States. Non-compliance with CRA essential requirements can result in corrective-action orders, market-access restrictions, product withdrawal, and administrative penalties under national implementing law. | Do not describe an EN 303 645 compliance claim as equivalent to CRA market-access conformity. Maintain a separate CRA conformity record that identifies the enforcement route, responsible MSA jurisdiction, and CE-marking basis. |
|---|
| 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 requirements may accept EN 303 645 TS 103 701 evidence as supporting input for relevant product-security essential requirements, but the reuse requires a CRA-specific mapping note, a conformity-route decision, and a CE-marking basis check. | 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. | The safest bridge is evidence-first and claim-second: collect ETSI proof, then map it to CRA only where the CRA source supports the same product boundary and requirement. |
|---|