The gap shows first in which route you take. Full application that hits none of the three limitation conditions goes the Module A self-declaration route; hitting any one, or only partial application, sends you to a notified body under Module B plus C, and the cycles differ by a stretch.
The three limitation conditions, restated: allowing the user to set no password at all; children's devices lacking parent or guardian controls; financial devices whose security updates rely on a single method. Self-check at launch decides how many months you schedule.
Scope determination. First decide which of (d)(e)(f) you trigger: networked at least (d); handling personal, location or traffic data adds (e); any monetary value stored, processed or settled adds (f). Fast within a week; what stalls is usually an unclear product definition.
Gap assessment. Map against the standard item by item and list the missing controls in a gap report. Firmware lacking signature verification and factory-empty passwords are the frequent finds here, budgeted in weeks.
Design remediation and product change. Adding mechanisms at the software level is fast; changes involving a secure chip, key storage or hardware root of trust need a board respin and run into months. Hardware items are the most underestimated stage.
Assessment and testing. Each applicable mechanism gets three evaluations — concept, completeness and sufficiency — with conclusions that are only pass or fail. Self-declaration completes this internally; if a third-party lab is required, you queue.
Document and declaration. Consolidate the risk assessment, architecture document, control mapping and maintenance plan into the technical file, and update the RED Declaration of Conformity with the year in the standard.
One body has given experience ranges: the self-declaration route runs about four to eight weeks for the pure assessment-and-test segment, and about two to three months for the full pass including document preparation; third-party-lab and notified-body routes add scheduling and review on top, reaching eight to sixteen weeks and sixteen to twenty-four weeks respectively. Plan against more than the shortest range and leave a margin.
These times stack on top of the normal RED testing. RF, EMC and safety still have to be done; cybersecurity is the additive item, so do not schedule only the latter.
At the August 2025 effective point, laboratories holding the full scope of accreditation globally were few — publicly verifiable at only about six with 17025 accreditation — and capacity was a real bottleneck. Over the following year-plus, labs in China and Europe gained authorisation one after another, and by 2026 the bottleneck had eased, but notified-body certification scheduling remains a variable.
The second variable is rework rounds. A mechanism that fails must be redone; a software fix is fast, while re-verifying a hardware-related mechanism takes weeks per round normally. Exposing problems fully in the first round costs less than repeated submissions.
The third variable is document consistency. What the documents say and what the sample runs do not match, and review asks for retest or clarification. This class of problem has no technical depth yet most often eats the time.
Raise the cybersecurity requirement to the design stage. Settling the security architecture, key management and boot chain at design time is far faster than bolting them on after the sample exists; late addition often moves one thing and breaks another.
Make the scope determination solid: do not prepare the full (d)(e)(f) set for something that only triggers (d), but do not under-judge what should trigger — the cost of under-judging is rerunning the whole flow.
Pick a lab with the accredited scope early and ask its schedule up front. Waiting until documents are ready to look for one spends all the time in the queue.
The RED Article 3(3) cybersecurity requirement has applied since 1 August 2025 and is what you do now. The Cyber Resilience Act (CRA) becomes fully applicable on 11 December 2027 and is a separate timetable; the two do not overlap in scope or approach.
The EN 18031 cybersecurity file you build now will carry into CRA — its risk-assessment methodology and document structure are substantively useful references for CRA — but one file serving both sides does not hold, because CRA has its own assessment path and documentation demands.
For projects of this kind, scope determination and gap assessment are launched in the first week after signing; the checklist from those two steps is the task list behind everything, so one day earlier there is one day earlier to start.
For products doing RED and other market access at once, BlueAsia's one-stop testing and certification schedules the cybersecurity assessment together with the RF, EMC and safety samples, covering what can be covered once and queuing only once.
Contact: King Email: king.guo@cblueasia.comAddress: Building C, Hongjingda Industrial Park, No. 107 Beihuan Road, Shiyan Street, Bao'an District, Shenzhen, China BlueAsia delivers more than service!
Related News
