ETSI EN 303 645 vs RED Cybersecurity Delegated Act

ETSI EN 303 645 covers consumer IoT devices connected to network infrastructure and their interactions with associated services. Associated services are considered for interactions, but the services themselves are outside the standard's scope.

RED scope must be confirmed from RED sources: whether the product is radio equipment, which delegated cybersecurity requirements apply, and which EU conformity route is available cannot be concluded from the assigned ETSI grounding alone.

Start with two scope records: an ETSI consumer IoT boundary for control evidence and a separate RED radio-equipment boundary for legal and CE-file decisions.

For an ETSI assessment, the supplier organization requests the DUT assessment, provides ICS and IXIT information, and coordinates across parties such as manufacturers, service providers, component suppliers, application developers, vendors, or distributors.

RED ownership should be assigned separately to the manufacturer or other RED economic-operator roles after RED source review. The assigned ETSI sources do not define those RED duties.

Do not give one compliance owner both jobs. Assign ETSI evidence owners for ICS/IXIT and test support, then assign RED owners for legal scope, conformity assessment, and technical documentation.

ETSI EN 303 645 applies when the team is assessing a consumer IoT device and its relevant interactions with associated services against the baseline provisions. Conditional ETSI provisions then depend on product facts such as whether passwords, update mechanisms, telemetry, consent-based personal-data processing, or hard-coded device identities exist.

RED cybersecurity triggers must come from RED sources, not from ETSI EN 303 645. Treat radio-equipment status, product category, data-processing facts, and applicable dates as RED research items unless already grounded in a RED file.

Use an ETSI condition matrix for provisions and a separate RED trigger matrix for legal applicability. Do not infer RED applicability from the presence of an ETSI control.

ETSI EN 303 645 turns into product-security work: no universal default passwords, vulnerability disclosure, software updates, sensitive security parameter storage, secure communication, attack-surface reduction, software integrity, personal-data security, resilience, telemetry review, user-data deletion, secure usability, and input validation.

RED core obligations should be written only after RED source review. The ETSI provisions can support cybersecurity evidence, but the assigned ETSI grounding does not establish RED legal duties or CE-file completeness.

Build the ETSI action list from clauses 5 and 6, then add RED duties in a separate source-linked column instead of renaming ETSI provisions as RED obligations.

ETSI evidence should include the DUT identification, ICS support claims and details, IXIT entries, user documentation, conceptual and functional test results, verdict rationale, and any external evidence accepted for a provision.

RED evidence should be kept in a separate technical-file record until RED-specific scope, requirements, standards status, conformity assessment, and authority-facing documentation are confirmed.

Create a traceability matrix with source, product version, claim, ETSI artifact, RED artifact, owner, and gap status. Shared evidence should be tagged as supporting evidence, not proof that both regimes are complete.

ETSI timing is product-security timing: defined support period, timely vulnerability action, timely security updates, periodic update checks, reassessment after product or service changes, and assessment use of the most up-to-date DUT software.

RED timing must be tracked separately from RED sources. The assigned ETSI grounding does not establish the RED delegated-act application date, transition plan, or recertification cadence.

Maintain separate clocks: ETSI support and assessment timing for security operations, and RED legal timing for EU market-access decisions.

ETSI EN 303 645 is a baseline standard. TS 103 701 can support first-party, second-party, third-party, certification, and conformance-declaration schemes, but defining a certification or conformance-declaration scheme is outside TS 103 701.

RED enforcement and conformity-assessment route must be determined under RED sources. Do not use ETSI assessment wording to imply CE acceptance, notified-body status, or market-surveillance outcomes.

Use ETSI assessment results as assurance evidence only. Escalate legal, CE-marking, harmonised-standard, notified-body, or market-surveillance questions to RED-specific source review.

ETSI overlap exists at the control and evidence level: a well-scoped ETSI assessment can show implemented cybersecurity measures for the consumer IoT product.

RED overlap exists only after a RED requirement has been mapped to the same product facts and evidence. If the RED source or harmonised-standard position is unknown, mark the row as a gap.

Reuse evidence by reference, not by renaming. Keep the ETSI result, RED requirement, common product facts, and remaining RED gaps visible in the same row.

Use ETSI EN 303 645 as the controlling source when the decision is about consumer IoT baseline controls, ICS/IXIT content, assessment evidence, or support for a product-security claim.

Use RED sources as the controlling source when the decision is about radio-equipment scope, delegated cybersecurity applicability, conformity assessment, CE technical documentation, or market access.

The safest comparison output is a bridge table: ETSI evidence accepted, RED source checked, RED gap remaining, and owner assigned.