| Legal scope | RED applies to radio equipment: electrical or electronic products that intentionally emit or receive radio waves for radio communication or radiodetermination. | CRA scope is not determined from these RED-focused sources. Treat it as a separate product-cybersecurity scoping question, not as a substitute for RED. | For a connected wireless product, write two scope conclusions: one official source RED conclusion and one CRA template default that cites a CRA-specific source review before release claims are made. |
|---|
| Who owns the work | RED assigns duties across manufacturers, authorised representatives, importers, and distributors; manufacturers own design compliance, technical documentation, conformity assessment, EU DoC, and CE marking. | Do not copy RED actor assignments into the CRA column without CRA legal support; create a separate CRA owner until the CRA role analysis is completed. | Use product regulatory or quality ownership for RED conformity, and track CRA responsibility as a separate legal and security-governance action item. |
|---|
| Cyber trigger | RED cybersecurity duties under Delegated Regulation 2022/30 are triggered by defined radio-equipment categories, including internet-connected radio equipment, certain equipment processing personal, traffic, or location data, and internet-connected equipment enabling transfers of money or value. | The CRA trigger is intentionally left narrow here: confirm it from CRA-specific sources before using CRA labels in product requirements, customer assurances, or release gates. | Ask RED-specific intake questions first: does the product connect to the internet, process relevant data, or enable value transfer, and is it radio equipment? |
|---|
| Core compliance duties | RED work converts the Article 3 requirements into design controls, conformity assessment, technical documentation, EU declaration of conformity, CE marking, instructions, and market-surveillance support. | CRA implementation details are blocked in this RED-only cited sources; record CRA tasks as assumptions until supported by CRA-specific law or guidance. | Do not describe a product as CRA-ready because RED cybersecurity controls exist. Reuse the control evidence only after mapping each document to both legal bases. |
|---|
| Evidence and records | RED evidence should include the radio scope memo, Article 3 matrix, cybersecurity category decision, standards or specifications, test reports, risk analysis, notified-body evidence where needed, EU DoC, CE marking basis, and technical documentation. | CRA evidence should be labeled provisional on this page: keep candidate cybersecurity artifacts, but do not assert they meet CRA documentation requirements without a CRA source. | Maintain one evidence index with source tags so RED evidence, shared engineering controls, and unresolved CRA evidence are not blurred together. |
|---|
| Application dates and clocks | For RED cybersecurity under Delegated Regulation 2022/30 as amended, the official source application date is 1 August 2025. RED technical documentation and EU DoC retention duties are tied to placing radio equipment on the market. | CRA dates are not sourced in these RED-focused sources. Keep them out of this comparison unless a CRA-specific source is added to the record. | Use the RED cyber date for RED release readiness, and keep a separate CRA calendar that is not inferred from RED or Commission announcement text. |
|---|
| Assurance and enforcement route | RED assurance runs through the applicable conformity assessment route, possible notified-body involvement, CE marking, technical documentation, and national market-surveillance authority review. | CRA enforcement and reporting routes are outside these RED-focused sources and should be documented only after CRA-specific sourcing. | Keep escalation playbooks separate: RED non-conformity, corrective action, authority response, and CE marking issues should not be mixed with unsourced CRA incident or vulnerability workflows. |
|---|
| Overlap and reuse | RED cybersecurity work can generate reusable artifacts such as threat models, vulnerability assumptions, software-update notes, test evidence, and supplier security inputs when they are tied back to Article 3(3)(d), (e), or (f). | CRA reuse is only a candidate until CRA scope and evidence requirements are separately verified. | Reuse controls, not conclusions: shared security engineering may reduce duplicate work, but it does not merge legal scope, dates, economic-operator roles, or declarations. |
|---|
| Practical decision rule | Proceed under RED when the product is radio equipment and market placement depends on Article 3 requirements, conformity assessment, technical documentation, EU DoC, or CE marking. | Open a CRA follow-up when the connected radio product also appears to be a digital product, but mark the CRA conclusion pending until a CRA-specific review supports it. | The defensible output is: RED applies, RED does not apply, CRA review needed, or both workstreams apply with separately cited evidence. |
|---|