Does RED DA work count toward CRA compliance?

Partly. Evidence produced against EN 18031 for network protection, personal data protection and fraud protection maps onto CRA Annex I Part I and belongs in the CRA technical file. The post-market duties in Annex I Part II do not carry forward, because the RED Delegated Regulation never asked for them.

That distinction decides how much of your compliance budget is already spent and how much is still ahead of you. It is also the point where most manufacturers we speak to have set their expectations too high.

Key takeaways

• Delegated Regulation (EU) 2022/30 made the RED cybersecurity requirements mandatory on 1 August 2025, and the Commission adopted its repeal on 16 February 2026 with effect from 11 December 2027.
• EN 18031 evidence transfers into the CRA technical file as product-property evidence, covering roughly the Annex I Part I half of the essential requirements.
• The vulnerability handling and reporting duties have no RED DA equivalent, and the first of them binds on 11 September 2026, fifteen months before the CRA applies in full.
• A portfolio of 50 products can generate 500 to 1,000 exploitability assessments a year under Article 14, each on a 24-hour clock, before firmware versions are counted.
• Self-assessment under the CRA default class removes the notified body, not the technical file.

What RED DA actually requires

Delegated Regulation (EU) 2022/30 activated three of the essential requirements in Article 3(3) of the Radio Equipment Directive for connected radio equipment. Point (d) covers network protection, point (e) covers protection of personal data and privacy, and point (f) covers protection from fraud. Those requirements became mandatory on 1 August 2025.

The EN 18031 series is the practical route to showing conformity. The Commission harmonised all three parts through Commission Implementing Decision (EU) 2025/138 of 28 January 2025.

Standard	Requirement it supports	Scope
EN 18031-1:2024	Article 3(3)(d), network protection	Internet-connected radio equipment
EN 18031-2:2024	Article 3(3)(e), personal data and privacy	Internet-connected radio equipment, childcare equipment, toys, wearables
EN 18031-3:2024	Article 3(3)(f), fraud protection	Equipment processing virtual money or monetary value

One detail in that decision is easy to miss and expensive to discover late. The references were published with restrictions. Clauses 6.2.5.1 and 6.2.5.2 of the standards allow a manufacturer to let a user decline to set a password, and presumption of conformity does not extend to that option. A product that relies on it does not get the benefit of the harmonised standard for that clause, and the gap has to be closed another way.

The scope of the assessment is also wider than the phrase "radio testing" suggests. The questions reach hardware, firmware, cloud communication, mobile applications, authentication and update mechanisms. If the device sends data to a cloud service, the assessor asks how that channel is protected. If it accepts commands, the assessor asks how those commands are authenticated. If the firmware can be updated, the assessor asks how updates are signed, validated and protected against rollback.

Why the RED DA is being withdrawn

CRA Annex I already contains every element of the essential requirements in Article 3(3), points (d), (e) and (f) of the Radio Equipment Directive. Leaving both instruments in force would mean two conformity routes over the same ground.

So the Commission adopted a delegated regulation on 16 February 2026 that repeals Delegated Regulation (EU) 2022/30 with effect from 11 December 2027, the date the Cyber Resilience Act applies in full.

Read that as a transition, not a reprieve. Between now and 10 December 2027 the RED cybersecurity requirements still apply to radio equipment in scope, and a product placed on the market in that window still needs them. From 11 December 2027 the same product needs a CRA conformity assessment instead.

What carries forward, and what does not

The CRA splits its essential requirements into two parts, and the split is what determines reuse.

CRA Annex I	Subject	Does RED DA work cover it?
Part I	Product properties, secure configuration, access control, confidentiality and integrity of data, attack surface, update mechanism	Largely. EN 18031 evidence maps onto most of it
Part II	Vulnerability handling across the support period, SBOM, coordinated disclosure policy, security updates, reporting	No. RED DA set no post-market obligation

Part I is a photograph of the product at the moment it ships. Part II is a process that has to keep running for the whole support period. Test reports demonstrate the first. Only an operating programme demonstrates the second.

That is why "we passed RED DA" is a reasonable answer to half of the CRA and no answer at all to the half that binds first.

The 24-hour clock starts before the rest of the CRA

Article 14 of the Cyber Resilience Act applies from 11 September 2026. It runs three deadlines from the point of awareness. An early warning within 24 hours, a detailed vulnerability notification within 72 hours, and a final report within 14 days for an actively exploited vulnerability. Reports go to the CSIRT designated as coordinator and to ENISA.

Two features of that duty catch manufacturers out.

It applies to products already on the market. There is no grace period tied to your next product launch, and no exemption for a device certified under RED DA last year.

And it is never a self-declaration. The point is worth stating plainly, because the CRA's self-assessment route gets discussed so much that people assume it covers everything. Conformity can be self-assessed for many products. An actively exploited vulnerability is always reported externally.

We have covered the mechanics of that filing in a readiness drill and the recipient routing in reporting to ENISA and national authorities.

The arithmetic that should set your tooling budget

The legal position is the easy half. The harder question is how often the duty fires, and that is a volume calculation most manufacturers have not run.

Start with the published numbers for 2025. Around 48,000 CVEs were published across all software, an increase of roughly 16 percent on 2024. About 5,700 of those were in the Linux kernel, which is the operating system in most connected products, and works out at around 15 a day. Over the same year the CISA Known Exploited Vulnerabilities catalogue grew from 1,239 entries to 1,484, so 245 vulnerabilities were confirmed as exploited.

The trigger for Article 14 is not that a vulnerability exists in your product. It is that a vulnerability under active exploitation exists in your product. So 245 is the number that matters rather than 48,000, and 245 is still not small once it meets a product portfolio.

The example runs like this. Take 50 products on the market in Europe. Assume 10 to 20 actively exploited vulnerabilities a year land somewhere in the software supply chain those products share. Every one of them has to be assessed against every product, because the question "is this exploitable in the context of this device?" has a different answer per device.

50 products x 10 to 20 exploited vulnerabilities = 500 to 1,000 assessments per year

Each assessment starts a 24-hour clock. And that figure counts only the current firmware. A portfolio with ten supported firmware versions in the field multiplies it again.

Substitute your own numbers before deciding the workload is somebody else's problem. Products on the market, times exploited vulnerabilities reaching your supply chain, times supported firmware versions. If the result runs to hundreds, manual triage is not a plan. Work at that volume needs automation and a defined process, not goodwill from an engineering team that already has a roadmap.

The output of each assessment also has to be recorded. An assessment that concluded "not exploitable" and left no artifact is indistinguishable, to a market surveillance authority, from an assessment that never happened.

Self-assessment is not self-exemption

The CRA sorts products into classes, and the class decides who signs off.

Class	Examples	Route
Default	Most IoT, smart home devices, toys, general appliances	Self-assessment, full technical file retained
Annex III class I, important	Routers, cameras, smart home security systems, VPNs, industrial PCs	Self-assessment only with a cited harmonised standard applied in full, otherwise a notified body
Annex III class II, important	Firewalls, hypervisors, secure microcontrollers, operating systems	Third-party assessment
Annex IV, critical	Smart meters, secure elements, public safety systems	European cybersecurity certification scheme

Some products sit outside the CRA because another instrument already regulates their cybersecurity. Medical devices fall under the Medical Devices Regulation and the In Vitro Diagnostic Regulation. Vehicles fall under UNECE R155 and R156, though aftermarket telematics does not follow the vehicle out of scope. Civil aviation falls under the EASA framework.

For everything else in the default class, self-assessment removes the notified body and nothing else. The technical file still has to exist, in full, on the day an authority asks for it. Airport security is the closest analogy. Most people walk through. Being selected for the deeper examination is not rare enough to plan around, and the fine tier that applies to Annex I and to Articles 13 and 14 reaches 15 million euros or 2.5 percent of total worldwide annual turnover, whichever is higher.

One related timing error is common enough to be worth naming. The secure-by-design requirements bind on 11 December 2027, not on 11 September 2026. September is the reporting date. December 2027 is the design date. Two clocks, fifteen months apart, and conflating them produces either misplaced panic or a missed deadline.

What to do in the next ninety days

If you have RED DA work behind you, four steps convert it into CRA position.

Re-file the evidence you already have. Map each EN 18031 test result onto the CRA Annex I Part I requirement it supports, and put it in a technical file structured the way the CRA expects rather than the way a radio test report is organised. This is filing work, not testing work.

Produce a software bill of materials, and keep producing it. Annex I Part II requires it, RED DA did not, and it is the input every later step depends on. Without a component inventory there is no way to answer whether an exploited vulnerability reaches your product. See SBOM as a security foundation.

Time your own response. Take a vulnerability that has already been published, and measure how long your organisation needs to decide whether it is exploitable in a specific product. If the answer is longer than a working week, the 24-hour clock is not a stretch target, it is a redesign of the process.

Check the design assumptions on products shipping after December 2027. Anything launching then is in design now. Some manufacturers are already back at a full hardware redesign, because secure boot or a signed over-the-air update path was never specified and cannot be added in firmware. A module choice made this quarter is cheap. The same choice revisited after tape-out is not.

The order matters. Reporting readiness is the September obligation and design conformity is the December 2027 obligation, so a team that spends the autumn on the technical file and none of it on vulnerability response has optimised for the later deadline.

Primary sources

• Regulation (EU) 2024/2847, the Cyber Resilience Act. Article 14 reporting, Annex I essential requirements, Annex III and IV classification, Article 64 fines.
• Commission Implementing Decision (EU) 2025/138 of 28 January 2025, harmonising EN 18031-1, EN 18031-2 and EN 18031-3 with restrictions.
• Commission Delegated Regulation (EU) 2022/30, the RED cybersecurity Delegated Regulation, repealed with effect from 11 December 2027.
• Directive 2014/53/EU, the Radio Equipment Directive, Article 3(3) points (d), (e) and (f).
• CISA Known Exploited Vulnerabilities catalogue, the source for the exploited-vulnerability counts. The catalogue held 1,239 entries at the end of 2024 and 1,484 at the end of 2025.
• CVE Program, the source for published CVE counts.

The 2025 CVE and Linux kernel figures are annual totals compiled from CVE Program records. They describe the vulnerability landscape, not CVD Portal customers, and they are quoted here to size the workload rather than to make a claim about any product.