Der Cyber Resilience Act ist seit dem 10. Dezember 2024 in Kraft. Ab dem 11. September 2026 gelten die Melde- und Schwachstellenpflichten, die vollständige Konformität mit CE-Kennzeichnung ist ab dem 11. Dezember 2027 fällig. Betroffen ist jedes Produkt mit digitalen Elementen, das in der EU auf den Markt gebracht wird, also die Steuerung im Maschinenbau genauso wie ein Medizingerät mit Embedded Linux, eine On-Premises-Software oder ein Gateway mit Yocto-Image. Wer bisher davon ausging, dass ihn Cybersicherheitsregulierung nur im eigenen Rechenzentrum trifft, verwechselt den CRA mit NIS2.
Der erste Schock ist meist die Rollenfrage. Hersteller im Sinne der Verordnung ist, wer ein Produkt unter eigenem Namen oder eigener Marke in Verkehr bringt, und dazu gehört auch der komplette Open-Source-Anteil im Auslieferungsstand. Ein Kernel, eine BusyBox, eine OpenSSL-Version oder ein Python-Paket aus dem Build kommen zwar von außen, die Verantwortung für Schwachstellenmanagement und Updates bleibt aber beim Inverkehrbringer. Für rein nicht-kommerzielle Open-Source-Entwicklung sieht der CRA Ausnahmen vor, und für Open-Source-Software-Verwalter gilt ein abgeschwächtes Regime, das entlastet dich als Produkthersteller jedoch nicht.
Typische Fehler sehen wir immer an denselben Stellen: Die SBOM wird einmalig als PDF erzeugt statt maschinenlesbar in CycloneDX oder SPDX aus dem Build-Prozess, sie deckt nur die direkten Abhängigkeiten der Applikation ab und ignoriert das Basis-Image oder das Root-Dateisystem, und niemand kann sagen, welche Firmware-Version bei welchem Kunden läuft. Wenn dann eine aktiv ausgenutzte Schwachstelle bekannt wird, fehlt der Nachweis der Betroffenheit, und die 24-Stunden-Frist für die Erstmeldung an ENISA und das zuständige CSIRT läuft trotzdem.
