For connected radio products, the EU cybersecurity transition from 2025 to 2027 is not a simple switch from one set of documents to another. Commission Delegated Regulation (EU) 2022/30 has applied to the radio equipment within its scope since 1 August 2025. The Cyber Resilience Act, Regulation (EU) 2024/2847 (CRA), generally applies from 11 December 2027.
Delegated Regulation (EU) 2026/339 repeals Regulation 2022/30 from that same date. It also makes clear that the repeal does not undermine RED market surveillance and control for relevant radio equipment placed on the EU market between 1 August 2025 and 10 December 2027. Manufacturers therefore need to preserve the evidence for the RED period while building traceable lifecycle records for the CRA.
Map the product before mapping the documents
Regulation 2022/30 does not impose every cybersecurity requirement on every radio product. Article 1 applies RED Article 3(3)(d) to radio equipment that can communicate over the internet, directly or through other equipment. Article 3(3)(e) can apply to specified connected, childcare, toy and wearable radio equipment that processes personal, traffic or location data. Article 3(3)(f) can apply to internet-connected radio equipment that enables transfers of money, monetary value or virtual currency. Article 2 defines exclusions involving medical devices and certain aviation, vehicle and road-toll legislation.
The CRA uses a different concept—products with digital elements—and has its own scope, exclusions and interaction rules. A product-by-product review should capture connectivity, data processing, intended purpose, software, remote data processing and applicable sector legislation. A Wi-Fi or Bluetooth function alone is not enough to support one standard conclusion for every model.
Freeze a traceable RED market-placement baseline
For relevant equipment first placed on the EU market during the 1 August 2025 to 10 December 2027 period, keep a RED baseline that later CRA work cannot overwrite. Link at least the following records to the specific model and release:
- product name and model, hardware revision, firmware or software release, and enabled network and data functions;
- the applicability decision for RED Article 3(3)(d), (e) and (f), including the reasoning and exclusions considered;
- standards and clauses applied, deviations or non-applicability decisions, test configuration and test reports;
- risk assessments, design controls, user information, labels, the EU Declaration of Conformity and economic-operator details; and
- the first EU market-placement date supported by transaction, import, delivery, serial-number or other supply-chain evidence.
This baseline should answer which rules and configuration supported a particular release when it entered the market. Because Regulation 2026/339 preserves surveillance and control for the transition-period products, those records should remain readable, searchable and internally consistent after the CRA becomes generally applicable.
Lifecycle evidence cannot wait until 2027
Although the CRA generally applies from 11 December 2027, Article 71 sets earlier milestones. Chapter IV, covering notification of conformity assessment bodies, has applied since 11 June 2026. Article 14 manufacturer reporting obligations apply from 11 September 2026. Article 70(3) states that Article 14 also applies to products with digital elements within the CRA scope that were placed on the market before 11 December 2027.
Manufacturers should already be able to trace vulnerability intake, triage, investigation, decisions, remediation, updates and user communication to the affected product and software versions. Article 14 addresses actively exploited vulnerabilities and severe incidents affecting product security and establishes phased notifications. This article is not a substitute for event-specific assessment of the criteria, deadlines or reporting route; it highlights the records needed to make those decisions reliably.
Use three linked record layers
A practical structure separates three layers without isolating them:
- Release baseline: product identity, hardware and software configuration, destination market, first placement date, applicable legislation, standards and test evidence.
- Operations and change history: vulnerabilities, incidents, customer feedback, security updates, component or dependency changes, engineering decisions and reassessment results.
- CRA readiness: scope decisions, CRA risk assessment and technical-document elements, vulnerability-handling processes, software component information, support-period rationale and conformity-assessment tasks.
CRA Article 31 requires technical documentation before market placement and continuous updating, where appropriate, at least during the support period. It also permits a single technical-document set for certain products governed by other EU legislation, provided all required information is included. “Single set” should not become an unrecoverable latest-only folder. Releases, tests, accepted risks and updates need identifiers, dates, owners and change rationales.
Build the handover matrix around ownership and triggers
Regulatory, engineering, product security, quality, supply-chain and after-sales teams should maintain a shared handover matrix. Useful fields include:
- product family, commercial model, hardware revision, firmware release and key components or dependencies;
- first EU market-placement date, importer or other economic operator, and destination Member States;
- the Regulation 2022/30 applicability decision, test baseline, declaration and instruction versions;
- initial CRA scope assessment, general-application tasks, Article 14 owner and internal escalation route;
- vulnerability or incident identifier, awareness time, affected releases, disposition, remediation and user communication; and
- reassessment triggers covering connectivity, data handling, critical components, firmware, security mechanisms, intended purpose and supply-chain roles.
Test the system by selecting a unit already on the market and tracing it back to its release-time test configuration, declaration and software version, then forward to subsequent vulnerability and update records. If the team can only find the newest report, it does not yet have a defensible transition record.
How Qianxin can support record readiness
For a defined product, destination market and written scope, Qianxin can support preliminary RED and CRA applicability screening, identification of relevant standards and testing needs, sample-to-hardware and software version checks, technical-document checklists, and consistency reviews linking historical test evidence to later releases. Final legal scope, economic-operator duties, whether an event meets a reporting threshold, regulatory submissions and market-access conclusions remain the responsibility of the relevant business based on its product facts and applicable law.
This article provides general compliance information only. It is not product- or incident-specific legal advice or a final conformity assessment. Testing, reporting, certification and issuing activities depend on the project, relevant laboratory scope and written engagement.
