Die Beispieldokumente und Projektpläne sind bewusst nur auf Englisch veröffentlicht: Sie sind Vorlagen zum Übernehmen, und eine Übersetzung wäre nicht die Fassung, mit der Sie am Ende arbeiten.
Fiktives Beispiel. Dauern, Aufwandszahlen und Rollenaufteilungen sind illustrative Schätzungen für einen kleinen Hersteller, keine Zusage und kein Angebot, und keine Rechtsberatung. Prüfen Sie jedes Datum an der Vorschrift, wie sie für Ihr eigenes Produkt gilt.
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.