Secure by Design / Secure by Default

Was ist Secure by Design / Secure by Default?

Secure by Design integriert Cybersicherheit in Konzeption, Entwicklung und Herstellung; Secure by Default sorgt für sichere Ausgangseinstellungen.

Begriffliche Einordnung: Die Prinzipien ergänzen einander, sind aber nicht identisch. Secure by Design betrifft die Sicherheitsgestaltung im Entwicklungsprozess und über den Produktlebenszyklus. Secure by Default betrifft den sicheren Ausgangszustand eines Produkts. Im Cyber Resilience Act (CRA) werden beide Prinzipien für erfasste Produkte mit digitalen Elementen risikobezogen konkretisiert.

Der Normwortlaut

„Produkte mit digitalen Elementen werden so konzipiert, entwickelt und hergestellt, dass sie angesichts der Risiken ein angemessenes Cybersicherheitsniveau gewährleisten.“

„Auf der Grundlage der Bewertung der Cybersicherheitsrisiken gemäß Artikel 13 Absatz 2 müssen Produkte mit digitalen Elementen, soweit zutreffend, mit einer sicheren Standardkonfiguration auf dem Markt bereitgestellt werden, sofern zwischen dem Hersteller und dem gewerblichen Nutzer in Bezug auf ein maßgeschneidertes Produkt mit digitalen Elementen nichts anderes vereinbart wurde, und die Möglichkeit bieten, das Produkt in seinen ursprünglichen Zustand zurückzusetzen.“

Normquelle: Verordnung (EU) 2024/2847, Anhang I Teil I Nummer 1 sowie Nummer 2 Buchstabe b. Die vertragliche Ausnahme betrifft ausschließlich die sichere Standardkonfiguration eines maßgeschneiderten Produkts. Die im selben Buchstaben verlangte Rücksetzmöglichkeit bleibt bestehen.

Für wen und für welche Produkte gelten die CRA-Vorgaben?

Rechtliche Einordnung: Der CRA gilt für Produkte mit digitalen Elementen, die auf dem Unionsmarkt bereitgestellt werden und deren Zweckbestimmung oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt. Zu den Produkten mit digitalen Elementen gehören Software- oder Hardwareprodukte sowie bestimmte Datenfernverarbeitungslösungen. Verpflichtet werden die jeweils erfassten Wirtschaftsakteure, insbesondere die Hersteller.

Der Anwendungsbereich muss vollständig anhand von Artikel 2 Absätze 1 bis 8 geprüft werden. Die Absätze 2 bis 4 und 6 bis 8 enthalten unmittelbare sektorale, sachliche und sicherheitsbezogene Ausnahmen, unter anderem für bestimmte Medizinprodukte und In-vitro-Diagnostika, Kraftfahrzeugprodukte, zertifizierte Luftfahrtprodukte, Schiffsausrüstung, identische Ersatzteile sowie ausschließlich für nationale Sicherheit, Verteidigung oder die Verarbeitung von Verschlusssachen bestimmte Produkte. Einschränkungen oder Ausschlüsse für Produkte unter sektorspezifischen Unionsvorschriften nach Artikel 2 Absatz 5 setzen die dort genannten Bedingungen, insbesondere mindestens dasselbe Schutzniveau und die Vereinbarkeit mit dem allgemeinen Rechtsrahmen, sowie einen delegierten Rechtsakt voraus.

Wann muss der Hersteller die Cybersicherheitsrisikobewertung durchführen?

Normative Pflicht: Vor dem Inverkehrbringen eines erfassten Produkts muss der Hersteller die Cybersicherheitsrisikobewertung durchführen und dokumentieren. Ihr Ergebnis ist während Planung, Konzeption, Entwicklung, Herstellung, Lieferung und Wartung zu berücksichtigen. Die Bewertung muss unter anderem Zweckbestimmung, vernünftigerweise vorhersehbare Verwendung und voraussichtliche Nutzungsdauer einbeziehen und ist erforderlichenfalls während des Unterstützungszeitraums zu aktualisieren.

Die Anforderungen aus Anhang I Teil I Nummer 2 gelten nur „soweit zutreffend“ und auf Grundlage dieser Bewertung. Hält der Hersteller eine grundlegende Anforderung für nicht anwendbar, muss er dies in der technischen Dokumentation klar begründen.

Welche Fristen, Übergangsregeln und Schwellenwerte gelten?

Zeitliche Reichweite: Der CRA gilt grundsätzlich ab dem 11. Dezember 2027. Artikel 14 gilt bereits ab dem 11. September 2026; Kapitel IV gilt ab dem 11. Juni 2026. Diese vorgezogenen Termine betreffen nur die in Artikel 71 Absatz 2 bezeichneten Bestimmungen.

Produkte, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden, unterliegen den Anforderungen des CRA grundsätzlich nur, wenn sie nach diesem Datum wesentlich geändert werden. Artikel 14 bleibt nach Artikel 69 Absatz 3 jedoch auch auf erfasste Altprodukte anwendbar. Der Unterstützungszeitraum beträgt grundsätzlich mindestens fünf Jahre. Liegt die erwartete Nutzungsdauer unter fünf Jahren, entspricht der Unterstützungszeitraum nur dieser erwarteten Nutzungsdauer.

Wie unterscheiden sich die Prinzipien technisch?

Autoritative technische Einordnung: Das NIST Secure Software Development Framework beschreibt sichere Entwicklungspraktiken als Bestandteil des jeweils verwendeten Softwareentwicklungsprozesses. Secure by Design setzt damit beim fortlaufenden Entwicklungsprozess an. Secure by Default ergänzt diesen Ansatz durch sichere Voreinstellungen bei der Bereitstellung.

Beide Prinzipien ersetzen weder regelmäßige wirksame Tests noch die Ermittlung, Dokumentation, Behandlung und Behebung von Schwachstellen oder die Bereitstellung von Sicherheitsaktualisierungen. Der CRA regelt diese Aufgaben zusätzlich in Anhang I Teil II.

Welche Grenzen haben Aussagen zu Secure by Design und Secure by Default?

Abgrenzung: Außerhalb des CRA richten sich Adressaten und Auslöser nach dem jeweiligen Entwicklungs-, Beschaffungs- oder Regelungskontext. Aus dem CRA lässt sich keine allgemeine Rechtspflicht für jede digitale Technik ableiten. Innerhalb des CRA hängen die konkreten Maßnahmen vom erfassten Produkt, seiner Risikobewertung, der Anwendbarkeit einzelner Anforderungen und den Ausnahmen des Artikels 2 ab.

Auch die Vereinbarung über eine abweichende Standardkonfiguration ist eng begrenzt: Sie ist nur zwischen Hersteller und gewerblichem Nutzer und nur für ein maßgeschneidertes Produkt vorgesehen. Sie beseitigt weder die Pflicht zu einem angesichts der Risiken angemessenen Cybersicherheitsniveau noch die Rücksetzmöglichkeit.

Häufige Fehlannahmen

• „Beide Begriffe bedeuten dasselbe.“ Nein. Secure by Design betrifft die Sicherheitsgestaltung; Secure by Default den sicheren Ausgangszustand.
• „Der CRA macht die Prinzipien für jede digitale Technik verbindlich.“ Nein. Artikel 2 begrenzt den sachlichen Anwendungsbereich und enthält unmittelbare sowie bedingte sektorale Ausnahmen.
• „Secure by Design garantiert Fehlerfreiheit.“ Nein. Gefordert ist ein risikogerechtes Cybersicherheitsniveau, keine absolute Fehlerfreiheit.
• „Sichere Voreinstellungen ersetzen Tests, Updates und Schwachstellenbehandlung.“ Nein. Diese Aufgaben bestehen eigenständig fort.
• „Bei maßgeschneiderten Produkten kann Anhang I vollständig abbedungen werden.“ Nein. Die besondere Vereinbarung betrifft nur die sichere Standardkonfiguration; die Rücksetzmöglichkeit und das angemessene Cybersicherheitsniveau bleiben unberührt.
• „Alle CRA-Pflichten beginnen am selben Tag.“ Nein. Die allgemeine Anwendung beginnt am 11. Dezember 2027, während Artikel 14 und Kapitel IV vorgezogen gelten.

Was die Geschäftsleitung tun sollte

Praxisempfehlung: Die folgenden Schritte sind Managementempfehlungen. Innerhalb des CRA unterstützen sie die Erfüllung konkreter Herstellerpflichten; außerhalb seines Anwendungsbereichs sind sie keine aus dem CRA abgeleitete allgemeine Rechtspflicht.

• Für jedes Produkt dokumentiert prüfen lassen, ob Artikel 2 des CRA einschließlich aller Ausnahmen und sektoralen Begrenzungen einschlägig ist.
• Einen risikobasierten Secure-Development-Prozess mit klaren Verantwortlichkeiten für Planung, Konzeption, Entwicklung, Herstellung, Lieferung und Wartung etablieren.
• Cybersicherheitsrisikobewertungen vor dem Inverkehrbringen dokumentieren, erforderlichenfalls im Unterstützungszeitraum aktualisieren und nicht anwendbare Anforderungen nachvollziehbar begründen.
• Sichere Standardkonfigurationen und Rücksetzverfahren festlegen; Abweichungen für maßgeschneiderte Produkte nur unter den engen Voraussetzungen des Anhangs I dokumentieren.
• Regelmäßige wirksame Tests, geregelte Schwachstellenbehandlung und eine sichere Verteilung von Sicherheitsaktualisierungen organisatorisch und technisch absichern.
• Nachweise aus Risikobewertung und Umsetzung in die technische Dokumentation und, bei CRA-erfassten Produkten, in die Konformitätsbewertung einbinden.

Für die Geschäftsleitung

Entscheidend ist zuerst die Reichweitenprüfung: Der CRA erfasst nicht jedes digitale Angebot. Für erfasste Produkte muss der Hersteller vor dem Inverkehrbringen risikobasiert handeln und die anwendbaren Anforderungen nachweisbar in den Produktlebenszyklus integrieren. Die Leitung sollte deshalb über Anwendungsbereich, sichere Ausgangskonfiguration und Unterstützungsprozess entscheiden lassen und Risikobewertung, Ausnahmen, Tests, Schwachstellenbehandlung, Updates und Konformitätsnachweise revisionsfähig dokumentieren.

Quellen

• Verordnung (EU) 2024/2847 (Cyber Resilience Act), amtlicher Volltext: insbesondere Artikel 2, Artikel 3 Nummern 1, 2 und 8 bis 10, Artikel 13, Artikel 69, Artikel 71 und Anhang I.
• NIST SP 800-218, Secure Software Development Framework (SSDF): autoritative technische Einordnung sicherer Entwicklungspraktiken.