Secure-by-Design: Vom Prinzip zur gesetzlichen Pflicht?

Vor sechs Jahren hieß es, für Secure-by-Design zu argumentieren, zunächst die Mehrkosten gegenüber Entscheidungsträgern zu rechtfertigen, die das Risiko noch nicht als real anerkannt hatten. Heute schreibt der EU Cyber Resilience Act sichere Standardkonfigurationen gesetzlich vor. NIS2 macht das Management persönlich haftbar für die Art und Weise, wie Software entwickelt und beschafft wird. ISO/IEC 27001:2022 nennt „Security-by-Design” wörtlich beim Namen.

Das Argument für Secure-by-Design ist längst gemacht. Durch Regulatoren, aber vor allem durch seinen nachgewiesenen Erfolg. Für C-Level-Führungskräfte hat sich die Frage damit verschoben: nicht mehr ob SbD für ihr Unternehmen gelten wird, sondern wie gut sie aufgestellt sind, wenn die regulatorische Durchsetzung beginnt.

Secure by Design bevor es zur Pflicht wurde

Wir haben unsere Secure-by-Design Services vor sechs Jahren aufgebaut. Damals war das eine Wette: Sicherheit, die von Anfang an in ein System eingebaut wird, verursacht weniger Schwachstellen, niedrigere Remediation-Kosten und weniger architektonische Überraschungen im Nachhinein. Die meisten Kunden haben das verstanden, aber ihre Procurement-Teams zu überzeugen hat länger gedauert.

Was sich nicht verändert hat, ist das Prinzip selbst. Regulatoren haben Secure-by-Design nicht erfunden. Sie sich angeschaut, was passierte, wenn Organisationen es konsequent angewenden und was passierte, wenn nicht. CRA, NIS2 und ISO 27001:2022 spiegeln diese Erkenntnisse wider. Compliance hat begonnen, Secure-by-Design-Prinzipien vorauszusetzen, weil sie funktionieren. Nicht umgekehrt.

Was CRA, NIS2 und ISO 27001 konkret fordern

EU Cyber Resilience Act: „Secure-by-Default” als Produktanforderung

Seit Dezember 2024 in Kraft, verpflichtet der CRA Hersteller von Produkten mit digitalen Elementen dazu sicherzustellen, dass diese Produkte „entworfen, entwickelt und produziert” werden und dabei grundlegende Cybersicherheitsanforderungen erfüllen (Art. 13, Anhang I). Konkret: Produkte müssen mit einer „sicheren Standardkonfiguration” ausgeliefert werden, „Angriffsflächen einschließlich externer Schnittstellen begrenzen” und Mechanismen enthalten, um die Auswirkung von Exploits zu minimieren.

Nicht konforme Produkte dürfen kein CE-Kennzeichen tragen. Sie dürfen nicht in den EU-Markt gebracht werden. Meldepflichten beginnen im September 2026, die vollständige Durchsetzung im Dezember 2027. Bußgelder erreichen 15 Millionen Euro oder 2,5 % des weltweiten Jahresumsatzes.

NIS2 und seine DACH-Umsetzungen: Wo SbD zur Haftung auf Vorstandsebene wird

Art. 21(2)(e) verpflichtet wesentliche und wichtige Einrichtungen dazu, „Sicherheit in Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen” zu berücksichtigen. Art. 21(3) bezieht Lieferanten ein: Organisationen müssen prüfen, ob ihre Anbieter „sichere Entwicklungsverfahren” einhalten. Sicherheit im Entwicklungsprozess ist damit ein Beschaffungskriterium geworden.

Die Haftung ist persönlich. Art. 20 verlangt, dass Leitungsorgane Cybersicherheitsmaßnahmen genehmigen, und macht sie verantwortlich, wenn diese Maßnahmen unzureichend sind. Das überarbeitete deutsche BSIG (§38, in Kraft seit Dezember 2025) konkretisiert dies auf nationaler Ebene. Österreichs NISG 2026 folgt im Oktober 2026.

ISO/IEC 27001:2022, Control A.8.27: Der Standard, gegen den die meisten Organisationen bereits zertifiziert sind, nennt es jetzt beim Namen

Die Revision von 2022 hat Control A.8.27 „Sichere Systemarchitektur und Engineering-Prinzipien” eingeführt. Seine Leitlinien listen „Security-by-Design” und „Security-by-Default” als erforderliche Architekturprinzipien auf — neben Least Privilege, Defence in Depth und Fail Securely. Controls A.8.25 und A.8.28 decken den sicheren Entwicklungslebenszyklus bzw. Secure Coding ab.

Die Übergangsfrist endete im Oktober 2025. Zertifikate, die nach diesem Datum ausgestellt werden, beinhalten eine formelle Verpflichtung zu diesen Controls. Die entscheidendere Frage ist, ob die Engineering-Praxis dahinter das auch tut.

Der regulatorische Rückenwind hinter Secure-by-Design

CRA, NIS2 und ISO 27001 sind die sichtbarsten Druckpunkte aber die Richtung ist tiefer verankert. DORA verlangt von Unternehmen des Finanzsektors, ICT-Sicherheit „von Grund auf zu entwerfen, zu beschaffen und zu implementieren”. Der EU AI Act schreibt vor, dass Hochrisiko-KI-Systeme mit eingebetteter Cybersicherheit „konzipiert und entwickelt” werden müssen. Die überarbeitete EU-Produkthaftungsrichtlinie macht eine Cybersicherheitsschwachstelle zu einem hinreichenden Grund für einen Produktfehleranspruch. IEC 62443 listet Secure-by-Design als explizite Entwicklungspraxis für industrielle Systeme auf.

Diese Regelwerke gelten für unterschiedliche Sektoren und stammen von verschiedenen Regulatoren, aber die zugrunde liegende Logik bleibt konsistent: Sicherheit muss von Anfang an eingebaut werden.

Secure-by-Design als Compliance-Risiko auf C-Level-Ebene

Drei Konsequenzen reichen weit über das Security-Team hinaus:

Persönliche Haftung ist nicht mehr theoretisch. NIS2 Art. 20, Deutschlands §38 BSIG und DORA Art. 5 begründen direkte Managementverantwortung für Cybersicherheitsversäumnisse. Diese kann nicht an einen CISO delegiert werden. Ein Budget zu genehmigen, ohne die damit finanzierten Sicherheitsmaßnahmen zu genehmigen, ist keine tragfähige Position mehr.

Die Supply Chain ist jetzt der eigene Compliance-Perimeter. NIS2 Art. 21(3) und CRA Art. 13 verlangen, dass Organisationen prüfen, ob Lieferanten sichere Entwicklungsverfahren einhalten. Vendor-Fragebögen, die nach Zertifizierungen fragen, aber nicht nach Entwicklungspraktiken, werden einem Audit nicht standhalten. Was Lieferanten bauen, und wie sie es bauen, ist Teil des eigenen Risikoprofils.

Zertifizierung ohne gelebte Praxis schafft eine neue Risikoklasse. Ein ISO-27001-Zertifikat, das nach Oktober 2025 ausgestellt wurde, impliziert die Konformität mit Control A.8.27. Wenn Entwicklungsteams nicht nach diesen Prinzipien bauen, ist die Lücke zwischen Zertifikat und Praxis eine Haftung im Audit und möglicherweise vor Gericht im Rahmen der überarbeiteten EU-Produkthaftungsrichtlinie.

Secure-by-Design als Wettbewerbsvorteil

Den regulatorischen Mindeststandard für Secure-by-Design zu erfüllen ist jedoch nicht dasselbe wie es gut zu tun. Organisationen, die CRA und NIS2 als Checkliste behandeln, werden mehr für Remediation ausgeben als jene, die SbD als Designprinzip verstehen. Denn Compliance nachträglich in eine bestehende Architektur einzubauen ist teurer als von Anfang an danach zu bauen.

Organisationen, die früh handeln, durchlaufen Audits in der Regel schneller, bestehen Sicherheitsbewertungen von Lieferanten sauberer und müssen ihre Security-Posture seltener neu aufbauen, wenn sich Regulatorik verschiebt. Aber während Compliance den Mindeststandard setzt, liegt die echte Wettbewerbsposition darüber hinaus.

Warum wir auf Secure by Design gesetzt haben, bevor es Gesetz wurde

Als wir vor sechs Jahren begonnen haben, Secure-by-Design-Beratung anzubieten, gab es keinen CRA, kein überarbeitetes ISO 27001, keine Managementhaftung unter NIS2. Wir haben uns früh zu SbD bekannt, weil die Logik bereits klar war: Sicherheitsentscheidungen, die auf Architekturebene getroffen werden, sind günstiger, effektiver und leichter zu validieren als Entscheidungen, die später unter Druck getroffen werden. Daran hat sich nichts geändert.

Secure-by-Design ist nicht der regulatorische Standard geworden, weil Gesetzgeber entschieden haben, dass er es sein soll. Er wurde zum Standard, weil Organisationen, die ihn angewendet haben, Systeme gebaut haben, die unter Angriffen, Audits und Druck standgehalten haben. Gesetzgeber haben sich diese Bilanz angeschaut und sie in Gesetze geschrieben.

Für Organisationen, die bereit sind, vom Prinzip zur Praxis überzugehen, liefert das ENISA-Playbook „Security by Design and Default” (März 2026) die operative Tiefe: 22 Engineering-Checklisten, die den vollständigen Produktlebenszyklus abdecken – konzipiert für Teams, die SbD implementieren statt nachträglich einbauen wollen. Das Playbook gibt es hier.