---
name: "CRA-Konformitäts-Selbstbewertung"
version: "1.0"
updated: "2026-07-27"
source: "https://www.orbiqhq.com/de/vorlagen/cra-konformitaets-selbstbewertung-vorlage"
license: "Kostenlos nutz- und anpassbar für Ihre Organisation. Namensnennung willkommen. Keine Rechtsberatung."
legal_basis:
  - "https://eur-lex.europa.eu/eli/reg/2024/2847/oj"            # Cyber Resilience Act — Art. 13, 14, 32, Anhang I, III, IV, VII, VIII
  - "https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj"       # CIR (EU) 2025/2392 — technische Beschreibungen der wichtigen/kritischen Produktkategorien
---

# CRA-Konformitäts-Selbstbewertung (maschinenlesbar)

Zweck: eine Cyber-Resilience-Act-Readiness-Bewertung für ein Produkt mit digitalen
Elementen durchführen — Anwendungsbereich, Klassifizierung (Standard / wichtig Klasse I /
wichtig Klasse II / kritisch), die zulässige Konformitätsroute nach Artikel 32,
Anhang-I-Prüfungen Anforderung für Anforderung sowie die Bereitschaft bei Dokumentation
und Artikel-14-Meldungen. Diese Datei ist in sich geschlossen: Ein Agent kann aus den
untenstehenden Definitionen ein Produkt klassifizieren, die zulässigen Konformitätsrouten
ableiten, die beiden Anhang-I-Checklisten mit Statusverfolgung erzeugen und einen
Gap-Report erstellen.

Die CRA-Uhr (Verordnung (EU) 2024/2847):
- `2024-12-10` — in Kraft.
- `2026-06-11` — Kapitel IV gilt (notifizierte Stellen können benannt werden).
- `2026-09-11` — Meldepflichten nach Artikel 14 gelten, auch für Produkte, die bereits auf
  dem Markt sind (zentrale Meldeplattform; 24 h / 72 h / 14 Tage bei aktiv ausgenutzten
  Schwachstellen, 24 h / 72 h / 1 Monat bei schwerwiegenden Vorfällen).
- `2027-12-11` — vollständige Anwendung: grundlegende Anforderungen des Anhangs I,
  technische Dokumentation nach Anhang VII, EU-Konformitätserklärung, CE-Kennzeichnung.

Strukturregeln:
1. Die Klassifizierung geht allem voraus: Die zulässigen Konformitätsrouten sind eine
   FUNKTION von (classification, harmonised_standards_fully_applied, is_foss). Niemals
   zuerst ein Modul wählen.
2. Die Klassifizierung folgt der KERN-Funktionalität (CIR (EU) 2025/2392, erlassen am
   28.11.2025): Ein Produkt, das eine Komponente aus einer Kategorie der Anhänge III/IV
   integriert, wird NICHT nach dieser Komponente klassifiziert, sofern die Kategorie nicht
   auf das Produkt als Ganzes zutrifft. Die Begründung festhalten.
3. Jeder Status `not_applicable` bei einer Anforderung aus Anhang I Teil I Nummer 2 MUSS
   die Cybersicherheits-Risikobewertung nach Artikel 13 Abs. 2 als Begründung zitieren —
   Nummer 2 gilt „soweit anwendbar" auf der Grundlage dieser Bewertung, nicht nach
   Bequemlichkeit.
4. Sanktionen (Art. 64): Verstöße gegen Anhang I / Art. 13 / Art. 14 bis zu
   15.000.000 EUR oder 2,5 % des gesamten weltweiten Jahresumsatzes, je nachdem, welcher
   Betrag höher ist.

Jurisdiktionshinweise: UK — kein CRA-Äquivalent; das PSTI-Regime (in Kraft seit
2024-04-29) erfasst vernetzte Verbraucherprodukte mit einem schmaleren Katalog.
Norwegen/EWR — der CRA ist EWR-relevant und dürfte in das EWR-Abkommen übernommen werden;
Produkte, die auf dem EU-Markt bereitgestellt werden, sind unabhängig vom Herstellersitz
im Anwendungsbereich. Deutschland — das BSI ist als Marktüberwachungsbehörde und
notifizierende Behörde für den CRA benannt; das CRA-Durchführungsgesetz (BT-Drs. 21/6134,
§ 65 BSIG-E) liegt im Juli 2026 noch im Bundestag.

---

## 1. Scope-Test — alle drei müssen zutreffen, keine der Ausnahmen

| # | Feld | Typ | Regel |
|---|---|---|---|
| 1 | `is_product_with_digital_elements` | bool | Software- oder Hardwareprodukt und seine Datenfernverarbeitungslösungen mit einer bestimmungsgemäßen oder vernünftigerweise vorhersehbaren direkten oder indirekten Datenverbindung (Art. 3 Nr. 1) |
| 2 | `placed_on_eu_market` | bool | Im Rahmen einer Geschäftstätigkeit bereitgestellt — auch kostenlose Produkte zählen, wenn sie anderweitig monetarisiert werden |
| 3 | `sectoral_exclusion` | enum | `none` / `medical_devices_mdr_ivdr` / `civil_aviation` / `motor_vehicles` / `marine_equipment` / `national_security_defence` — jeder Wert außer `none` beendet den CRA-Anwendungsbereich |
| 4 | `saas_note` | info | Reines SaaS ist außerhalb des Anwendungsbereichs, sofern es nicht die Datenfernverarbeitungslösung eines Produkts mit digitalen Elementen ist |

## 2. Klassifizierung

| Feld | Typ | Regel |
|---|---|---|
| `class1_categories` | feste Liste (19) | identity_mgmt_and_pam, browsers, password_managers, malware_detection, vpn_products, network_management, siem, boot_managers, pki_certificate_issuance, network_interfaces, operating_systems, routers_modems_switches, microprocessors_security_functions, microcontrollers_security_functions, asics_fpgas_security_functions, smart_home_virtual_assistants, smart_home_security_devices, internet_connected_toys, personal_wearables_health |
| `class2_categories` | feste Liste (4) | hypervisors_container_runtimes, firewalls_ids_ips, tamper_resistant_microprocessors, tamper_resistant_microcontrollers |
| `critical_categories` | feste Liste (3) | hardware_security_boxes (HSMs, Zahlungsterminals), smart_meter_gateways, smartcards_secure_elements |
| `core_functionality_match` | text | Die getroffene Kategorie, WENN das Produkt ALS GANZES ihrer technischen Beschreibung in CIR (EU) 2025/2392 entspricht; integrierte/nebensächliche Komponenten klassifizieren das Produkt nicht |
| `classification` | enum | `default` / `important_class_1` / `important_class_2` / `critical` — `default`, wenn kein Treffer auf Kernfunktionalitätsebene |

## 3. Ableitung der Konformitätsroute (Art. 32)

```
inputs: classification, standards_fully_applied (bool), is_foss (bool)

default            -> [module_a, module_b_c, module_h, eucc]           # Wahl des Herstellers
important_class_1  -> standards_fully_applied or is_foss(public docs)
                      ? [module_a, module_b_c, module_h, eucc_substantial]
                      : [module_b_c, module_h, eucc_substantial]
important_class_2  -> is_foss(public docs)
                      ? [module_a, module_b_c, module_h, eucc_substantial]
                      : [module_b_c, module_h, eucc_substantial]
critical           -> EUCC-Schema, wo per delegiertem Rechtsakt vorgeschrieben, sonst Klasse-2-Routen

notified_body_required = chosen_route in [module_b_c, module_h]
```

Vorbehalt Mitte 2026: Die harmonisierten CRA-Normen sind noch in Entwicklung
(Normungsauftrag M/606, 41 Normen, angenommen von CEN/CENELEC/ETSI am 2025-04-03;
horizontale Entwürfe prEN 40000-1-2 / -1-3 / -1-4). `standards_fully_applied = true`
setzt Zitierungen im Amtsblatt der EU voraus — vor dem Vertrauen auf die
Selbstbewertungsroute der Klasse I verifizieren.

## 4. Checkliste Anhang I Teil I — 14 Datensätze

Felder je Datensatz: `ref`, `requirement`, `status` (enum: `compliant` / `partial` /
`gap` / `not_applicable`), `evidence`, `owner`, `notes` (Begründung PFLICHT bei
`not_applicable`).

| ref | Anforderung (Zusammenfassung) |
|---|---|
| 1 | Dem Risiko angemessenes Cybersicherheitsniveau (verankert in der Risikobewertung nach Art. 13 Abs. 2/3) |
| 2a | Keine bekannten ausnutzbaren Schwachstellen zum Zeitpunkt des Inverkehrbringens |
| 2b | Sichere Standardkonfiguration, mit Zurücksetzen auf den Originalzustand |
| 2c | Schwachstellen über Sicherheitsupdates behebbar; automatische Sicherheitsupdates mit Opt-out als Standard, soweit anwendbar |
| 2d | Schutz vor unbefugtem Zugriff (Authentifizierung, Identitäts-/Zugriffsmanagement); Meldung möglichen unbefugten Zugriffs |
| 2e | Vertraulichkeit gespeicherter/übertragener/verarbeiteter Daten (Verschlüsselung ruhender und übertragener Daten nach Stand der Technik) |
| 2f | Integrität von Daten, Befehlen, Programmen, Konfiguration gegen unbefugte Manipulation; Meldung von Verfälschungen |
| 2g | Datenminimierung — nur angemessene, relevante, notwendige Daten werden verarbeitet |
| 2h | Verfügbarkeit wesentlicher und grundlegender Funktionen, einschl. DoS-Resilienz und -Abwehr |
| 2i | Negative Auswirkungen auf die Verfügbarkeit der Dienste anderer Geräte oder Netze minimieren |
| 2j | Angriffsflächen begrenzen, einschließlich externer Schnittstellen |
| 2k | Vorfallsauswirkungen durch Mechanismen zur Exploit-Abschwächung reduzieren |
| 2l | Sicherheitsrelevante Informationen durch Aufzeichnung/Überwachung interner Aktivität, mit Opt-out für Nutzer |
| 2m | Sichere, einfache, dauerhafte Entfernung aller Daten und Einstellungen; sichere Übertragung auf ein anderes Produkt, soweit anwendbar |

## 5. Checkliste Anhang I Teil II — 8 Datensätze

Gleiche Felder wie Teil I. `not_applicable` ist in Teil II selten vertretbar
(Prozesspflichten).

| ref | Anforderung an die Schwachstellenbehandlung (Zusammenfassung) |
|---|---|
| 1 | Schwachstellen und Komponenten im Produkt identifizieren und dokumentieren; SBOM in einem gängigen, maschinenlesbaren Format, das mindestens die Top-Level-Abhängigkeiten abdeckt |
| 2 | Schwachstellen ohne Verzögerung im Verhältnis zu den Risiken adressieren und beheben; Sicherheitsupdates getrennt von Funktionsupdates, wo technisch machbar |
| 3 | Wirksame und regelmäßige Sicherheitstests und -überprüfungen |
| 4 | Öffentliche Offenlegung behobener Schwachstellen, sobald das Update verfügbar ist (Beschreibung, Auswirkungen, Schweregrad, Informationen zur Behebung) |
| 5 | Richtlinie zur koordinierten Offenlegung von Schwachstellen (CVD) eingeführt und durchgesetzt |
| 6 | Austausch von Schwachstelleninformationen erleichtern; Kontaktadresse für Meldungen bereitstellen |
| 7 | Sichere Verteilungsmechanismen für Updates |
| 8 | Sicherheitspatches ohne Verzögerung und kostenlos verbreiten, begleitet von Advisory-Meldungen |

## 6. Bereitschaft bei Dokumentation & Meldungen

| # | Element | Regel |
|---|---|---|
| 1 | `technical_documentation` | Anhang VII: Produktbeschreibung, Informationen zu Design/Entwicklung/Schwachstellenbehandlung, Risikobewertung, Bestimmung des Unterstützungszeitraums, angewandte Normen, Testberichte, EU-Konformitätserklärung (Anhang V). Aufbewahrung ≥10 Jahre oder für den Unterstützungszeitraum, je nachdem, was länger ist |
| 2 | `support_period` | Art. 13 Abs. 8: entspricht der erwarteten Nutzungsdauer, MINDESTENS 5 Jahre, sofern keine kürzere Nutzung erwartet wird; Enddatum beim Kauf angegeben |
| 3 | `srp_access` | Registrierung bei der zentralen Meldeplattform der ENISA + interner Verantwortlicher vor dem 2026-09-11 |
| 4 | `art14_process_vulns` | 24 h Frühwarnung / 72 h Meldung / 14 Tage Abschlussbericht bei aktiv ausgenutzten Schwachstellen |
| 5 | `art14_process_incidents` | 24 h / 72 h / 1 Monat bei schwerwiegenden Vorfällen |
| 6 | `user_information` | Art. 14 Abs. 8: betroffene Nutzer informieren, gegebenenfalls in strukturiertem, maschinenlesbarem Format — siehe cra-vulnerability-advisory-template.md |
| 7 | `ce_marking` | Anbringung gemäß Art. 30 nach Abschluss der Konformitätsroute; ab dem 2027-12-11 Voraussetzung für das Inverkehrbringen |

## Hinweise für Agenten-Workflows

- GAP REPORT: Datensätze mit `status` in {`gap`, `partial`} auflisten, sortiert nach
  (Teil I vor Teil II, dann ref); Nachweiserwartungen aus dem Anforderungstext an
  `evidence` anhängen.
- ROUTE CHECK: Abschnitt 3 neu berechnen, sobald sich `classification`,
  `standards_fully_applied` oder `is_foss` ändert; Warnung, wenn die gewählte Route nicht
  mehr zulässig ist.
- N/A AUDIT: Jedes `not_applicable` in Teil I ohne Zitat der Risikobewertung in `notes`
  ist ein Befund, kein Bestehen.
- TIMELINE ALERTS: Warnen, wenn der geplante Markteintritt ≥ 2027-12-11 liegt und noch ein
  `gap` besteht; warnen, wenn `srp_access` nach dem 2026-09-11 nicht gesetzt ist.

---

Vorlage von Orbiq — https://www.orbiqhq.com/de/vorlagen/cra-konformitaets-selbstbewertung-vorlage
Version 1.0 · Aktualisiert am 27. Juli 2026 · Keine Rechtsberatung.