Version: 1.0 Last Updated: September 2026 Owner: Nova IAM Compliance Team

1. Einführung

Der Cyber Resilience Act (EU 2024/2847) trat am 10. Dezember 2024 in Kraft. Er ist die erste EU-Verordnung, die verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen festlegt — also für Hardware und Software, die in der EU in Verkehr gebracht werden.

Die Pflichten gelten schrittweise:

11. Juni 2026: Vorschriften zur Notifizierung von Konformitätsbewertungsstellen (Kapitel IV)
11. September 2026: Meldepflichten der Hersteller nach Art. 14 (aktiv ausgenutzte Schwachstellen, schwerwiegende Sicherheitsvorfälle), auch für Produkte, die bereits auf dem Markt sind
11. Dezember 2027: alle weiteren Pflichten

Nova IAM als Softwareprodukt fällt unter den Anwendungsbereich des CRA. Dieses Dokument zeigt, welche Anforderungen heute umgesetzt sind und welche noch offen sind.

2. Anwendungsbereich und Klassifikation

2.1 Produktklassifikation

Der CRA unterscheidet drei Kategorien:

Kategorie	Definition	Nova IAM
Standard	Produkte ohne kritische Sicherheitsfunktionen	—
Klasse I	Produkte mit erhöhtem Cybersicherheitsrisiko	✅ Wahrscheinlich zutreffend (IAM-Software)
Klasse II	Hochkritische Produkte (Firewalls, IDS, PKI etc.)	Nicht zutreffend

IAM-Software verwaltet Identitäten und Zugriffsrechte und erfüllt damit eine sicherheitskritische Funktion. Nova IAM positioniert sich vorsorglich als Klasse-I-Produkt und richtet Konformitätsprozesse entsprechend aus.

2.2 Wesentliche Cybersicherheitsanforderungen (Annex I)

CRA Anforderung	Nova IAM Umsetzung
Keine bekannten Schwachstellen bei Inverkehrbringen	Abhängigkeitsprüfung manuell je Release; automatisiert (`pip-audit`, `npm audit`) geplant
Secure-by-Default-Konfiguration	Kein Default-Passwort; Auto-Provisioning deaktiviert; HTTPS-only in Production
Schutz der Vertraulichkeit	TLS 1.2+ für alle externen Verbindungen; AES-verschlüsselte Secrets
Integrität von Daten und Befehlen	Parameterized Queries; signierte Session-Cookies; Audit-Log ohne Funktion zum Ändern oder Löschen in Oberfläche und API
Minimale Angriffsfläche	Nur Port 443 extern erreichbar; Docker-Netzwerksegmentierung
Sicherheitsupdates möglich	Versioniertes Release-System; dokumentierter Update-Prozess
Sicherheitsrelevante Ereignisse protokollieren	Audit-Log mit Wer/Wann/Woher (siehe Audit Trail Documentation)

3. Prozessanforderungen (Annex I, Teil II)

3.1 Schwachstellenmanagement

Der CRA verpflichtet Hersteller zu aktivem Schwachstellenmanagement über den gesamten Produktlebenszyklus (mindestens 5 Jahre oder die erwartete Nutzungsdauer).

Anforderung	Nova IAM Prozess
Schwachstellen identifizieren und dokumentieren	Abhängigkeitsprüfung manuell je Release; automatisiert (`pip-audit`, `npm audit`) geplant
Schwachstellen ohne Verzögerung beheben	Fix-Fristen nach Schweregrad (siehe Vulnerability Disclosure Policy)
SBOM (Software Bill of Materials) bereitstellen	Abhängigkeiten mit Versionsbereichen in `requirements.txt` und `package-lock.json`; SBOM je Release geplant, Termin noch offen
Koordinierte Offenlegung unterstützen	Vulnerability Disclosure Policy aktiv (security@nova-iam.com)

3.2 Meldepflichten gegenüber CSIRT und ENISA (Art. 14 CRA)

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden, auch für Produkte, die bereits auf dem Markt sind:

Frist	Meldung	Vorgesehener Ablauf bei Nova IAM
24 Stunden	Frühwarnung bei aktiv ausgenutzter Schwachstelle	Incident Response Plan aktivieren; ENISA Early Warning
72 Stunden	Vollständige Meldung inkl. Erstmaßnahmen	Strukturierter IRP-Bericht; Kundenkommunikation
14 Tage	Abschlussbericht mit Root Cause	Post-Incident Review; Maßnahmenplan

Den Meldeprozess (Verantwortliche, Kontaktwege, Ablauf) richten wir derzeit ein; Status siehe Abschnitt 7.

3.3 Transparenzpflichten

Pflicht	Umsetzung
Produktidentifikation	Versionsnummer, Release-Datum im Changelog öffentlich
Kontaktdaten für Schwachstellenmeldungen	security@nova-iam.com; security.txt unter /.well-known/
Unterstützungszeitraum	Mindestens 5 Jahre ab erstem Release kommuniziert
End-of-Support-Mitteilung	12 Monate Vorlaufzeit für EOS-Ankündigung

4. Konformitätserklärung (Declaration of Conformity)

Hersteller müssen vor Inverkehrbringen eine EU-Konformitätserklärung ausstellen und das CE-Kennzeichen anbringen.

Nova IAM Zeitplan:

In Arbeit: Interne Konformitätsbewertung (Klasse I, Selbstbewertung möglich)
Q4 2026: Erstellung der technischen Dokumentation gemäß Annex VII
Q1 2027: Ausstellung der Konformitätserklärung; CE-Kennzeichnung

5. Secure Development Lifecycle

Der CRA verlangt, dass Sicherheit in den gesamten Entwicklungsprozess integriert ist.

Phase	CRA-Anforderung	Nova IAM Praxis
Design	Security-by-Design	Threat Modeling; minimale Angriffsfläche als Designprinzip
Entwicklung	Sichere Coding-Standards	Ruff Linter; Parameterized Queries als Pflicht; Code Review
Test	Sicherheitstests	Automatisierte Testsuite; manuelle Security Reviews für Auth-Änderungen
Release	Schwachstellenprüfung	Abhängigkeitsprüfung manuell je Release; automatisiert (`pip-audit`, `npm audit`) geplant
Betrieb	Patch-Management	Quarterly Updates; Emergency Patches innerhalb 48h (Critical)
EOL	Sicherer Ausstieg	Quellcode-Hinterlegung laut Vertrag; Datenlöschung; Migrationsunterstützung

6. Kundenrelevanz: CRA und On-Premise-Deployment

6.1 Verantwortungsteilung

Verantwortung	Nova IAM (Hersteller)	Kunde (Betreiber)
Produktsicherheit	✅ Vollständig	—
Deployment-Härtung	Anleitung (Deployment Security Guide)	✅ Umsetzung
Patch-Management	✅ Patches bereitstellen	✅ Patches einspielen
Netzwerksicherheit	—	✅ Vollständig
Zugangskontrolle zur Infrastruktur	—	✅ Vollständig

6.2 Vorteile des On-Premise-Modells unter CRA

Datensouveränität: Keine Übermittlung an Drittanbieter, solange die KI aus ist oder lokal läuft
Kontrolle über Patch-Zeitpunkt: Kunde entscheidet, wann Updates eingespielt werden
Keine Cloud-Abhängigkeit: CRA-Anforderungen an Cloud-Dienste treffen Nova IAM nicht als Hoster
Quellcode-Hinterlegung: Betrieb auch bei Herstellerausfall gesichert

7. Zusammenfassung: CRA Readiness

Bereich	Status	Fälligkeit
Secure-by-Default	✅ Implementiert	—
Vulnerability Disclosure Policy	✅ Aktiv	—
Abhängigkeitsprüfung	🔄 Manuell je Release; Automatisierung geplant	—
SBOM-Erstellung	🔄 Geplant	Termin noch offen
Meldeprozess nach Art. 14	🔄 In Arbeit	Pflicht gilt seit 11.09.2026
Konformitätserklärung (CE)	🔄 Geplant	Q1 2027
Technische Dokumentation (Annex VII)	🔄 Geplant	Q4 2026

8. Kontakt

Sicherheitsmeldungen: security@nova-iam.com
Compliance-Anfragen: trust@nova-iam.com
Vulnerability Disclosure: siehe Vulnerability Disclosure Policy

Cyber Resilience Act (CRA)