Fictitious example. Durations, effort figures and role splits are illustrative estimates for a small manufacturer, not a commitment or a quotation, and not legal advice. Check every date against the regulation as it applies to your own product.
Project Plan B — Example Product Through the CRA Lifecycle
Scope: Take one product through phases 1–4 of the simplified workflow: Plan → Build & verify → Release → Maintain, on the self-assessment route (Module A). Written for a worked example product — SensorNode S300, a connected industrial sensor node (default product per Annex III/IV) — but the plan is the same for a real product; only the effort in phase 2 scales with product complexity.
Precondition: Gate G0 from Plan A passed. Phase 1 can start in parallel with Plan A weeks 4–6 if needed, but Gate G1 must not be passed before G0.
Duration: 16 weeks to market placement, then steady-state maintenance.
Timing anchor: full CRA application is 11 December 2027 — a real product following this plan has comfortable margin; the constraint is Plan A's Art. 14 readiness, not this plan.
Phase 1 — Plan (Weeks 1–3) → Gate G1
| # | Task (workflow activity) | Resp. | Effort | Deliverable (= gate evidence) |
|---|---|---|---|---|
| 1.1 | Confirm default classification against Annex III/IV, record per-category reasoning; record Module A as the route (#1.1) | PM | 1 d | Classification record |
| 1.2 | Cybersecurity risk assessment across the lifecycle phases; decide applicability of each Annex I Part I control (#1.2) | PSL | 3 d | Risk assessment v0.9 |
| 1.3 | Derive testable security requirements; design the minimal attack surface — which interfaces exist in production, which don't (#1.3) | PSL + TLS | 2 d | Security-requirements list with traceability |
| 1.4 | Determine and record the support period with reasoning (S300 example: 7 years, matching expected field lifetime) (#1.4) | PM | 0.5 d | Support-period decision |
Gate G1 (end of week 3): all four records exist; risk assessment reviewed by TLS. Implementation may start.
Phase 2 — Build & verify (Weeks 4–12) → Gate G2
Iterative — the security tasks ride along the normal development sprints rather than forming a separate track. The CRA-specific effort below is on top of functional development.
| # | Task (workflow activity) | Resp. | Effort | Deliverable |
|---|---|---|---|---|
| 2.1 | Implement access & data protection: authentication (no universal default password — per-device initial credential), TLS for transport, encrypted storage where the risk assessment requires it, integrity-protected firmware, data minimisation, secure erase (#2.1) | TLS + team | ~8 d | Implementation evidence per requirement |
| 2.2 | Implement robustness & update path: secure-by-default config with reset, signed + rollback-protected update mechanism, DoS resilience of essential functions, exploit mitigations the platform supports, security event logging with opt-out (#2.2) | TLS + team | ~10 d | Implementation evidence; update-mechanism design note |
| 2.3 | SBOM per build from the Plan A CI job; run the due-diligence checklist on every newly adopted component (#2.3) | TLS | 0.5 d setup + ongoing | SBOM per build, due-diligence records |
| 2.4 | Continuous verification: static analysis + dependency scan in CI from week 4; requirement-by-requirement verification and end-to-end update test in weeks 10–12 (#2.4) | TLS | ~5 d | Test & review reports |
Checkpoints: end of week 6 and week 9 — PSL reviews open findings and delta to the threat picture (feeds the risk-assessment update in 3.1). Prevents a phase-3 surprise.
Gate G2 (end of week 12): every security requirement implemented and verified or consciously deferred with a recorded risk decision; no open critical findings.
Phase 3 — Release (Weeks 13–16) → Gate G3 = market placement
| # | Task (workflow activity) | Resp. | Effort | Deliverable |
|---|---|---|---|---|
| 3.1 | Release gate on a production-configured unit: secure-by-default checklist, shipped build checked against CVE watch and open findings; risk assessment updated to release version (#3.1) | PSL | 2 d | Gate record, risk assessment v1.0 |
| 3.2 | Write the Annex II user information: identity & contact, product identification, intended purpose, support period end date, update mechanism, CVD contact, secure commissioning/decommissioning/data removal (#3.2) | PM | 2 d | Published user information |
| 3.3 | Assemble the Annex VII dossier with a coverage index against items 1–8: description, design & VH processes, production process, risk assessment incl. support-period reasoning, applied standards, test reports, DoC copy, SBOM (#3.3) | PM | 3 d | Complete technical documentation |
| 3.4 | Module A self-assessment on the basis of the dossier; draw up and sign the EU DoC (Annex V content); affix CE marking; define how series production stays in conformity (#3.4) | PM | 1.5 d | Signed DoC, CE record, self-assessment conclusion |
Sequencing inside phase 3: 3.1 first (its output feeds 3.3), 3.2 and 3.3 in parallel, 3.4 last. 3.3 is the schedule risk — start collecting dossier inputs in week 10, don't begin from zero in week 14.
Gate G3 (end of week 16): product on the market with CE marking and signed DoC.
Phase 4 — Maintain (steady state, for the support period from #1.4)
Recurring cadences instead of a timeline:
| Cadence | Activity | Resp. |
|---|---|---|
| Continuous | CVD intake monitored; every report triaged within the #0.1 deadlines; Art. 14 trigger check at every intake (#4.1, #4.4) | PSL |
| Weekly | CVE watch run against the SBOMs of all fielded versions; hits routed into #4.1 | PSL |
| Per fix | Free security update through the signed update path; advisory published once the update is available (#4.2, #4.3) | TLS / PSL |
| Per triggering event | Art. 14: 24 h early warning → 72 h notification → 14 d / 1 m final report (#4.4) | PSL |
| Annual | Substantial-modification check; EOL check of tools & dependencies; documents refreshed (#4.5) | PSL + PM |
| At end of support | EOS announced in advance, final advisory, dossier + DoC archived for 10 years or the support period, whichever is longer (#4.5) | PM |
Steady-state budget estimate: ~1–2 person-days/month while no incident is running; an actively exploited vulnerability suspends normal planning.
Summary timeline
Week: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 →
Plan A ████████████████░░ (G0 wk 6)
Phase 1 ████████ G1
Phase 2 ██████████████████████████ G2
checkpoints ▲ ▲
Phase 3 ████████████ G3
Phase 4 ██████ → (support period)(Phase 1 shown overlapping Plan A weeks 4–6; G1 waits for G0.)
Dependencies & risks
- G0 → G1 is the only inter-plan dependency. Everything in phase 1 except the gate itself can run before G0.
- Risk: evidence produced retroactively. The pattern that kills week 14: implementation done, records not written. Mitigation: the two phase-2 checkpoints check records, not just code.
- Risk: update mechanism underestimated (2.2). Signed + rollback-protected + testable is routinely the largest single CRA work item on embedded platforms. If anything gets buffer, this does.
- Risk: dossier assembly as an end-of-project crunch (3.3). Mitigated by the week-10 start and by every earlier deliverable already being written as gate evidence.
- Substantial modification re-entry (#4.5): any change to intended purpose or essential-requirement compliance sends the product back to #1.1 and requires a new self-assessment — budget this into feature roadmaps from day one.