Dieses Dokument befindet sich in aktiver Entwicklung und ist noch nicht finalisiert.
Skip to content

CRA Scope-Checker

Verwenden Sie diesen Entscheidungsbaum, um festzustellen, ob der Cyber Resilience Act auf Ihr Produkt anwendbar ist und welcher Konformitätsweg einzuschlagen ist.

BAUER GROUP Regel

Jedes Produkt mit digitalen Elementen durchläuft diese Bewertung vor der EU-Markteinführung. Klassifizierungsentscheidungen müssen mit dem Produktklassifizierungs-Protokoll dokumentiert werden.

Entscheidungsbaum

Gate 1: Produkt mit digitalen Elementen?

┌───────────────────────────────────────────────┐
│ Enthält das Produkt digitale Elemente?        │
│ (Software, Firmware oder Hardware mit         │
│ logischer Datenverbindung — Art. 3(1) CRA)    │
│                                               │
│   NEIN → CRA nicht anwendbar → STOP          │
│   JA   ↓                                     │
└───────────────────────────────────────────────┘

„Produkt mit digitalen Elementen" bezeichnet jedes Software- oder Hardwareprodukt und seine Lösungen zur Ferndatenverarbeitung, einschließlich separat in Verkehr gebrachter Software- oder Hardwarekomponenten (Art. 3(1) CRA).

Gate 2: Ausnahmen (Art. 2(2))

┌───────────────────────────────────────────────┐
│ Trifft eine der folgenden Ausnahmen zu?       │
│                                               │
│ ☐ Medizinprodukt (VO 2017/745, 2017/746)     │
│ ☐ Kraftfahrzeug (VO 2019/2144)               │
│ ☐ Luftfahrt (VO 2018/1139)                   │
│ ☐ Schiffsausrüstung (RL 2014/90/EU)          │
│ ☐ Nationale Sicherheit / Militärprodukt      │
│ ☐ Reines SaaS ohne Produktkomponente         │
│                                               │
│   JA   → CRA nicht anwendbar (sektorale      │
│           Regulierung gilt) → STOP            │
│   NEIN ↓                                     │
└───────────────────────────────────────────────┘

NIS2-Synergie

Reine SaaS-Dienste fallen unter NIS2, nicht unter den CRA — es sei denn, die Ferndatenverarbeitung ist integraler Bestandteil eines physischen oder installierbaren Produkts.

Gate 3: Open-Source-Bewertung (Art. 18–19)

┌───────────────────────────────────────────────┐
│ Handelt es sich um Open-Source-Software?      │
│                                               │
│   NEIN → Weiter zu Gate 4 ↓                  │
│   JA   → Liegt eine kommerzielle Aktivität    │
│           vor? (Verkauf, bezahlter Support,    │
│           monetarisierte Integration, SaaS)    │
│                                               │
│     NEIN → CRA nicht anwendbar → STOP         │
│     JA   → Open-Source-Steward-Pflichten      │
│             gelten (Art. 18–19) → Weiter ↓   │
└───────────────────────────────────────────────┘

Hinweis

„Kommerzielle Aktivität" wird weit ausgelegt. Spenden allein begründen keine kommerzielle Aktivität. Die Bereitstellung der Software als Teil eines kostenpflichtigen Produkts oder Dienstes hingegen schon.

Gate 4: Produktklassifizierung (Art. 6–7, Annex III & IV)

┌───────────────────────────────────────────────┐
│ Ist das Produkt in Annex IV gelistet?         │
│                                               │
│   JA   → KRITISCH                             │
│          → EUCC-Zertifizierung erforderlich   │
│          → Siehe: Konformität / EUCC           │
│   NEIN ↓                                     │
├───────────────────────────────────────────────┤
│ Ist das Produkt in Annex III gelistet?        │
│                                               │
│   JA   → Welche Klasse?                       │
│     Klasse II → Modul B+C oder Modul H        │
│                 → Siehe: Konformität / Modul B+C│
│     Klasse I  → Modul A (mit hEN) oder B+C    │
│                 → Siehe: Konformität / Modul A  │
│   NEIN ↓                                     │
├───────────────────────────────────────────────┤
│ STANDARD (Standardkategorie)                  │
│ → Modul A (Selbstbewertung)                   │
│ → Siehe: Konformität / Selbstbewertung         │
└───────────────────────────────────────────────┘

Ergebnisübersicht

ErgebnisProduktklasseKonformitätswegAufwandsniveau
StandardStandardModul A (Selbstbewertung)Gering
Klasse IWichtig (Klasse I)Modul A mit hEN oder Modul B+CMittel
Klasse IIWichtig (Klasse II)Modul B+C oder Modul HHoch
KritischKritisch (Annex IV)EUCC-ZertifizierungSehr hoch

Geschätzter Compliance-Aufwand

AnforderungEinmaligJährlichGilt für
Sicherheitsrisikobewertung (Annex I)20–40h10–20hAlle Klassen
SBOM-Generierung & -Pflege8–16h8–16hAlle Klassen
Schwachstellenbehandlungsprozess20–40h20–40hAlle Klassen
Incident-Reporting-Aufbau (Art. 14)16–32h8–16hAlle Klassen
Technische Dokumentation (Annex VII)40–80h10–20hAlle Klassen
CE-Kennzeichnung & EU-DoC8–16h4–8hAlle Klassen
Drittbewertung (Modul B+C)40–80h20–40hKlasse I* / II
QMS-Aufbau (Modul H)60–120h30–60hKlasse II (Alt.)
EUCC-Zertifizierungsprozess80–160h40–80hKritisch
Gesamt Standard112–224h60–120h
Gesamt Klasse I (mit hEN)112–224h60–120h
Gesamt Klasse I (ohne hEN)152–304h80–160h
Gesamt Klasse II212–424h110–220h
Gesamt Kritisch252–504h130–260h

* Klasse I erfordert nur dann eine Drittbewertung, wenn harmonisierte Normen nicht vollständig angewendet werden.

BAUER GROUP Ansatz

BAUER GROUP setzt auf eine vollautomatisierte Toolchain (Trivy, Grype, CycloneDX, Cosign, GitHub Actions), um den manuellen Aufwand für Standard- und Klasse-I-Produkte zu minimieren. Details in der Tooling-Zuordnung.

Nächste Schritte

Basierend auf Ihrem Klassifizierungsergebnis:

  1. Entscheidung dokumentierenProduktklassifizierungs-Protokoll
  2. Konformitätsverfahren startenKonformitätsbewertung Übersicht
  3. Dokumentation vorbereitenTechnische Dokumentation
  4. Meldewesen einrichtenENISA-Meldeprozess

Dokumentation lizenziert unter CC BY-NC 4.0 · Code lizenziert unter MIT