EU Cyber Resilience Act: Wie Hersteller die Anforderungen erfüllen
Viele Hersteller halten den Cyber Resilience Act für ein Thema der Softwareentwicklung. Ein großer Teil der Pflichten betrifft aber gar nicht den Code, sondern die Frage, wie eine Infrastruktur mit Identität, Zugriff und Verschlüsselung umgeht. Genau dort entscheidet sich, ob ein Produkt konform ist.
Was ist der EU Cyber Resilience Act?
Der Cyber Resilience Act (EU-Verordnung 2024/2847) legt verbindliche Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, die auf dem EU-Markt bereitgestellt werden. Vollständig anwendbar wird er im Dezember 2027. Wer die Anforderungen dann nicht erfüllt, riskiert Bußgelder von bis zu 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.
Welche Produkte fallen in den Anwendungsbereich?
Betroffen ist praktisch alles mit digitaler Konnektivität, das an Endkunden ausgeliefert wird: mobile Apps, IoT-Firmware, On-Premise-Systeme. Reine Cloud-Dienste sind ausgenommen, solange sie keine installierbaren Agenten oder Edge-Komponenten enthalten. Für Kraftfahrzeuge, Luftfahrt, Medizinprodukte und Marineausrüstung gelten weiterhin die sektorspezifischen Regelungen.
Die Kernanforderungen im Überblick
Fast alle wesentlichen Pflichten des CRA setzen an der Infrastruktur an. Produkte müssen unbefugten Zugriff über geeignete Kontrollmechanismen verhindern, idealerweise über eindeutige kryptografische Identitäten statt geteilter Secrets. Gespeicherte und übertragene Daten gehören standardmäßig verschlüsselt, und Änderungen an Konfiguration, Daten und Deployment-Artefakten dürfen nicht unbemerkt möglich sein.
Dazu kommen Anforderungen an Beobachtbarkeit und Resilienz: eine klein gehaltene Angriffsfläche, ein Monitoring, das sicherheitsrelevante Aktivitäten aufzeichnet, und ein Aufbau, der die Auswirkungen eines Vorfalls begrenzt. Welche dieser Punkte Teleport im Detail abdeckt, zeigt die Tabelle weiter unten.
Die Umsetzungshilfe der ENISA
Im März 2026 hat die EU-Cybersicherheitsagentur ENISA das Security by Design and Default Playbook (v0.4) veröffentlicht. Es übersetzt die rechtlichen Vorgaben in 22 konkrete Sicherheitsprinzipien. Im Zentrum steht das Prinzip der minimalen Berechtigung für jeden Nutzer, Dienst und Prozess. Der Identitätsbegriff schließt dabei Nutzer, Geräte, Dienste und Administratoren gleichermaßen ein.
Warum klassische Security-Ansätze am CRA scheitern
Fragmentierte Security-Stacks bringen immer wieder dieselben Schwachstellen mit sich.
Vergrößerte Angriffsfläche
Jeder Integrationspunkt zwischen VPNs, SSH-Tools, PAM-Lösungen und SIEMs ist eine mögliche Fehlkonfiguration und eine weitere Stelle, an der Credentials liegen. Je mehr Werkzeuge, desto größer die Fläche, die ein Angreifer abtasten kann.
Statische Credentials ermöglichen Persistenz
Langlebige SSH-Keys, Datenbank-Passwörter in Environment-Variablen und ins Repo committete API-Tokens stehen im direkten Widerspruch zur CRA-Anforderung nach eindeutigen, kurzlebigen kryptografischen Identitäten. Wer ein solches Credential erbeutet, behält den Zugang oft über Monate.
Zerstreute Audit-Trails
Wenn fünf verschiedene Tools den Zugriff verwalten, landen die Audit-Events in unterschiedlichen Formaten und mit unterschiedlichen Aufbewahrungsfristen. Einen Vorfall zu rekonstruieren wird damit zur mühsamen Suche über mehrere Systeme hinweg statt zu einer einzelnen Abfrage.
Infrastruktur-Identität als zentraler Kontrollpunkt
So unterschiedlich diese Pflichten wirken, sie laufen an einer Stelle zusammen: an der Identitäts- und Zugriffsschicht der Infrastruktur. Ob die Verschlüsselung durchgängig erzwungen ist und wer gerade auf einem System arbeitet, entscheidet sich im Infrastrukturdesign, nicht im Applikationscode.
CRA-Anforderungen und die Teleport-Antwort im Überblick
Die folgende Tabelle ordnet die wesentlichen Anforderungen aus Annex I des CRA den konkreten, prüfbaren Eigenschaften einer Teleport-basierten Infrastruktur zu:
| CRA-Anforderung (Anhang I, Teil I, Nr. 2) | Was gefordert ist | Teleport-Antwort |
|---|---|---|
| 2(d) Zugriffskontrolle & Authentifizierung | Unbefugten Zugriff durch geeignete Kontrollmechanismen verhindern und melden | Identitätsbasierter Zugriff nach dem Prinzip deny-by-default, kurzlebige X.509-Zertifikate statt statischer Credentials, jeder Zugriffsversuch im Audit-Log |
| 2(e) Verschlüsselung | Vertraulichkeit gespeicherter und übertragener Daten | Mutual TLS ohne Klartext-Fallback verschlüsselt jeden Zugriff Ende-zu-Ende und die Session-Aufzeichnungen; die Verschlüsselung ruhender Produktdaten ergänzt das Produkt selbst |
| 2(f) Integritätsschutz | Daten, Befehle und Konfigurationen vor unbefugter Manipulation schützen | Mutual TLS sichert Befehle und Daten im Transit gegen Manipulation, Hardware-Device-Trust (TPM 2.0/Secure Enclave) lässt nur integre Geräte zu, und jede Änderung ist im Audit-Trail nachweisbar |
| 2(j) Angriffsflächenminimierung | Externe Schnittstellen und exponierte Services begrenzen | Eine einheitliche Zugriffsschicht statt vieler exponierter Protokoll-Endpunkte |
| 2(k) Reduktion der Incident-Auswirkungen | Blast-Radius eines Vorfalls eindämmen | Zeitlich befristeter Just-in-Time-Zugriff, der nach Minuten automatisch abläuft |
| 2(l) Monitoring & Audit | Sicherheitsrelevante Aktivitäten aufzeichnen | Einheitlicher, korrelierter Audit-Trail über SSH, Datenbanken, Kubernetes und Cloud-Konsolen |
Statt fünf getrennter Werkzeuge mit fünf getrennten Audit-Formaten steht dahinter eine einzige Identitätsschicht mit einer Policy-Engine und einem zentralen Audit-System.
Bei der Umsetzung unterstützt Sie Think Ahead Technologies als offizieller Teleport-Reseller und -Partner. Kostenloses 30-Minuten-Gespräch buchen.
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. Die Credentials gelten unbegrenzt, und drei separate Audit-Systeme liefern Datenspuren, die sich nicht zusammenführen lassen.
CRA-fertiger Ansatz: Engineers authentifizieren sich per SSO mit Hardware-MFA und 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. Persistente Credentials gibt es nicht.
Fazit
Die Ergebnisse, die der CRA verlangt, lassen sich zuverlässig nur über eine einheitliche Infrastruktur-Identität erreichen: kurzlebige kryptografische Identitäten, erzwungene minimale Berechtigungen, attestierte Geräte und durchgängige Verschlüsselung. Dazu ein Audit-Trail, der die Frage, wer wann von wo aus was getan hat, mit einer einzigen Abfrage beantwortet.
Interesse an Teleport?
Think Ahead Technologies ist offizieller Teleport-Reseller und Support-Partner. Wir helfen Herstellern und Betreibern, ihre Infrastruktur CRA-fest aufzustellen: Zero-Trust-Zugriff, Device-Attestation und einheitliche 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.