EU Cyber Resilience Act: Wie Hersteller die Anforderungen erfüllen
Was ist der EU Cyber Resilience Act?
Der Cyber Resilience Act (EU-Verordnung 2024/2847) ist die europäische Rechtsgrundlage, die verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen im EU-Markt festlegt. Die vollständige Anwendbarkeit tritt im Dezember 2027 in Kraft — mit Sanktionen von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.
Welche Produkte fallen in den Anwendungsbereich?
Der CRA gilt für praktisch alle Produkte mit digitaler Konnektivität, die an Endkunden ausgeliefert werden: Mobile Apps, IoT-Firmware, On-Premise-Systeme. Reine Cloud-Dienste bleiben außen vor — es sei denn, sie enthalten installierbare Agenten oder Edge-Komponenten. Für Kraftfahrzeuge, Luftfahrt, Medizinprodukte und Marineausrüstung greifen weiterhin die jeweiligen sektorspezifischen Regelungen.
Die Kernanforderungen im Überblick
Die wesentlichen Pflichten des CRA lassen sich in zwei Bereiche auf Infrastrukturebene bündeln:
Identität, Zugriff und Datenschutz
- Identitäts- und Zugriffskontrolle: Produkte müssen „geeignete Kontrollmechanismen” implementieren, die unautorisierten Zugriff verhindern — über eindeutige kryptografische Identitäten statt geteilter Secrets.
- Verschlüsselung: Alle gespeicherten und übertragenen Daten müssen standardmäßig auf Infrastrukturebene verschlüsselt sein.
- Integritätsschutz: Systeme müssen unautorisierte Änderungen an Konfiguration, Daten und Deployment-Artefakten verhindern.
Beobachtbarkeit und Resilienz
- Angriffsflächenminimierung: Design, das externe Schnittstellen und exponierte Services konsequent begrenzt.
- Monitoring und Audit: Eingebautes operatives Monitoring, das relevante interne Aktivitäten aufzeichnet.
- Reduktion der Auswirkungen im Incident-Fall: Architektur, die den Blast-Radius eines Angriffs eindämmt.
Die Umsetzungshilfe der ENISA
Im März 2026 veröffentlichte die EU-Cybersicherheitsagentur ENISA das Security by Design and Default Playbook (v0.4). Es überführt die rechtlichen Anforderungen in 22 konkrete Sicherheitsprinzipien. Zentraler Punkt: „Jeder Nutzer, Dienst und Prozess” muss mit dem Prinzip der minimalen Berechtigung arbeiten — und Identität muss Nutzer, Geräte, Dienste und Administratoren umfassend abbilden.
Warum klassische Security-Ansätze am CRA scheitern
Fragmentierte Security-Stacks erzeugen drei typische Schwachstellenklassen:
1. Vergrößerte Angriffsfläche
Die zahlreichen Integrationspunkte zwischen VPNs, SSH-Tools, PAM-Lösungen und SIEMs multiplizieren potenzielle Fehlkonfigurationen und exponierte Credentials.
2. Statische Credentials ermöglichen Persistenz
Langlebige SSH-Keys, Datenbank-Passwörter in Environment-Variablen und ins Repo committete API-Tokens verstoßen unmittelbar gegen die CRA-Anforderung nach eindeutigen, kurzlebigen kryptografischen Identitäten.
3. Zerstreute Audit-Trails
Wenn fünf verschiedene Tools den Zugriff verwalten, verteilen sich Audit-Events auf inkompatible Formate und Retention-Policies. Die Rekonstruktion eines Vorfalls wird zur Detektivarbeit — statt zu einer Query.
Infrastruktur-Identität als zentraler Kontrollpunkt
Die CRA-Pflichten laufen auf ein einziges architektonisches Prinzip zu: Ob die Anforderungen erfüllt sind, entscheidet sich an der Identitäts- und Zugriffsschicht der Infrastruktur. Fragen wie „Wer ist am System?” und „Ist Verschlüsselung durchgängig erzwungen?” bilden CRA-Anforderungen direkt ab — und ihre Antwort hängt am Infrastrukturdesign, nicht am Applikationscode.
Merkmale einer CRA-fertigen Infrastruktur
Eine konforme Infrastruktur zeigt diese prüfbaren Eigenschaften:
- Keine statischen Credentials: Jede Verbindung nutzt kurzlebige kryptografische Identitäten, die nach kurzer Zeit ablaufen.
- Deny-by-default: Nutzer, Dienste und Prozesse benötigen für jeden Ressourcenzugriff eine explizite Berechtigung.
- Hardware-basierter Device-Trust: Verbindungen werden per TPM 2.0 oder Secure Enclave attestiert — nicht nur über Software-Agenten.
- Verschlüsselte, authentisierte Verbindungen: Mutual TLS oder Äquivalent, ohne Klartext-Fallback.
- Einheitliche Audit-Trails: Strukturierte Events in Echtzeit über SSH, Datenbanken, Kubernetes und Cloud-Konsolen hinweg.
- Einheitliche Policy: Eine Identitätsschicht, eine Policy-Engine, ein zentrales Audit-System.
Vorher / Nachher in der Praxis
Klassischer Ansatz: Engineers verbinden sich per VPN mit Shared Profiles, per SSH mit 18 Monate alten Keys und mit Datenbank-Passwörtern aus einem geteilten Vault. Credentials sind unbegrenzt gültig, drei separate Audit-Systeme liefern nicht verknüpfbare Datenspuren.
CRA-fertiger Ansatz: Engineers authentifizieren sich per SSO mit Hardware-MFA, erhalten nach erfolgreicher Device-Attestation ein zeitlich begrenztes X.509-Zertifikat, der Zugriff läuft nach 30 Minuten automatisch ab. Jede Aktion erscheint als strukturiertes, korreliertes Event in einem einheitlichen Audit-Trail — ohne persistente Credentials.
Kernaussage
Der CRA verlangt Ergebnisse, die sich nur mit einer einheitlichen Infrastruktur-Identität erreichen lassen: kryptografische Identitäten, durchgesetzte minimale Berechtigungen, attestierte Geräte-Integrität, ausnahmslose Verschlüsselung und lückenlose Audit-Trails, die „Wer hat wann von wo aus was gemacht?” mit einer einzigen Query beantworten.
Interesse an Teleport?
Think Ahead Technologies ist offizieller Teleport Reseller und Support Partner. Wir helfen Herstellern und Betreibern, ihre Infrastruktur CRA-fest zu machen — von Zero-Trust-Zugriff über Device-Attestation bis hin zu einheitlichen Audit-Trails.
Wenn Sie prüfen wollen, wie Teleport in Ihrer Infrastruktur konkret zur CRA-Compliance beiträgt: Melden Sie sich bei uns oder buchen Sie direkt ein kostenloses 30-Minuten-Gespräch.
Hinweis: Dieser Artikel dient der Information und stellt keine Rechtsberatung dar. Die EU-Verordnung 2024/2847 gilt für Produkte, die auf dem EU-Markt bereitgestellt werden; das ENISA-Playbook ist eine unverbindliche Handlungsempfehlung.