In unserem zweiten Blick auf den EU Cyber Resilience Act (CRA) müssen wir untersuchen, was unter der Haube der Produktentwicklung passiert. Im Verlauf des frühen Jahres 2026 erzwingt der CRA einen grundlegenden Wandel darin, wie Software und smarte Geräte gebaut werden. Die Ära, ein Minimum Viable Product auszuliefern und Sicherheitslücken später zu flicken, ist offiziell vorbei.

Das Mandat für „Security by Design and Default“

Historisch wurde die Last der Cybersicherheit unfairerweise auf die Verbraucher abgewälzt. Der CRA kehrt diese Dynamik um und behandelt digitale Sicherheit genauso wie die physische Produktsicherheit. Geräte müssen nun „Security by Design and by Default“ aufweisen.

Das bedeutet, Produkte mit maximalen Sicherheitseinstellungen auszuliefern, die ab Werk aktiviert sind. Herstellern ist es gesetzlich untersagt, Geräte mit bekannten ausnutzbaren Schwachstellen oder hartcodierten Standard-Zugangsdaten auszuliefern (verabschieden Sie sich von „admin/admin“). Darüber hinaus sind Hersteller nun verpflichtet, Sicherheitsupdates für einen „angemessenen Zeitraum“ bereitzustellen, der dem erwarteten Lebenszyklus des Produkts entspricht – für die meisten kommerziellen Elektronikprodukte wird in der Regel von mindestens fünf Jahren ausgegangen. Diese Updates müssen zeitnah bereitgestellt werden, nach Möglichkeit automatisch und vollständig kostenlos.

Die SBOM und die End-of-Life-(EOL)-Krise

Vielleicht die größte operative Hürde, die Engineering-Teams 2026 bewältigen müssen, ist die Anforderung an eine Software Bill of Materials (SBOM). Moderne smarte Geräte werden selten von Grund auf neu gebaut; sie werden aus Dutzenden von Drittanbieter-Bibliotheken, Open-Source-Frameworks und proprietären Abhängigkeiten zusammengefügt.

Unter dem CRA müssen Sie für jedes Produkt, das Sie in die EU liefern, eine vollständige, maschinenlesbare SBOM pflegen. Doch Transparenz ist nur Schritt eins. Die eigentliche Krise 2026 dreht sich um End-of-Life-(EOL)-Abhängigkeiten. Wenn Ihr Smart-Home-Hub auf einer veralteten Version von Node.js oder einer Legacy-C++-Bibliothek basiert, die von ihren Maintainers keine Sicherheits-Patches mehr erhält, sind Sie dennoch rechtlich dafür verantwortlich, sie zu patchen, wenn eine Schwachstelle gefunden wird.

Ein konkreter Aktionsplan für 2026

Engineering-Teams können nicht warten, bis Legal das geklärt hat. Wenn Sie heute Code ausliefern, müssen Sie diese vier Schritte sofort umsetzen:

1. Open-Source-Abhängigkeiten auditieren: Erstellen Sie eine vollständige SBOM. Identifizieren Sie jede Komponente, die das End-of-Life erreicht hat (oder erreichen wird), bevor der deklarierte Supportzeitraum Ihres Produkts endet.
2. CRA-Exposure abbilden: Fragen Sie Ihr Team für jede EOL-Komponente: Wenn morgen eine kritische CVE für diese Bibliothek veröffentlicht wird, können wir sie innerhalb von 24 Stunden patchen? Wenn die Antwort nein ist, haben Sie eine Compliance-Lücke.
3. Vulnerability-Infrastruktur etablieren: Bauen Sie den internen Workflow auf, um die Frist gemäß Artikel 14 einzuhalten. Definieren Sie strikte Eskalationspfade für aktiv ausgenutzte Schwachstellen und benennen Sie mehrere autorisierte Melder, um Vorfälle an Wochenenden oder Feiertagen abzudecken.
4. EOL-Code absichern oder ersetzen: Sie müssen entweder vom Legacy-Framework migrieren (was oft 12–24 Monate dauert), internes Know-how aufbauen, um eigene Patches für Open-Source-Code zu schreiben, oder einen kommerziellen Anbieter für Extended Support beauftragen.

Beispielkonfiguration eines SBOM-Snippets (SPDX-Format):

{
„SPDXID“: „SPDXRef-DOCUMENT“,
„spdxVersion“: „SPDX-2.3“,
„creationInfo“: {
„created“: „2026-01-15T10:00:00Z“,
„creators“: [„Organization: Kokobo Engineering“]
},
„name“: „Kokobo-Smart-Gateway-SBOM“,
„dataLicense“: „CC0-1.0“,
„packages“: [
{
„SPDXID“: „SPDXRef-Package-1“,
„name“: „OpenSSL“,
„versionInfo“: „3.1.2“,
„downloadLocation“: „NOASSERTION“,
„licenseDeclared“: „Apache-2.0“
}
]
}

Der CRA ist nicht nur eine Compliance-Checkliste; er ist eine grundlegende Neu-Engineering der Software-Lieferkette.