Mit dem Cyber Resilience Act der EU wird Security-by-Design ab 2027 für Produkte mit digitalen Elementen zur Pflicht. Um diesen Entwicklungs- und Betriebsansatz ranken sich viele Mythen, die einer kritischen Prüfung nicht standhalten.
Der Security-by-Design-Ansatz wird mit dem Inkrafttreten des Cyber Resilience Act von einer freiwilligen Best Practice zur verbindlichen Anforderung über den gesamten Produktlebenszyklus. Gleichzeitig halten sich in vielen Organisationen hartnäckig vereinfachte oder überholte Vorstellungen darüber, was Sicherheit in der Entwicklung eigentlich bedeutet. Nicht zuletzt mit Blick auf Kosten, Innovation oder Verantwortlichkeiten. Open Systems stellt fünf zentrale Mythen auf den Prüfstand und konfrontiert sie mit der Realität.
Mythos 1: Security kann man später ergänzen.
Faktencheck: Nein, genau das ist das Problem.
Die Vorstellung, Sicherheitsfunktionen erst nachträglich zu integrieren, ist weit verbreitet. In der Praxis entstehen sicherheitskritische Entscheidungen jedoch bereits im Design: etwa bei Datenflüssen, Schnittstellen oder Identitätsmodellen. Werden diese Aspekte ohne Security-Perspektive umgesetzt, entstehen strukturelle Schwachstellen, die sich später nur mit großem Aufwand oder gar nicht beheben lassen. Security nachträglich hinzuzufügen, führt daher meist zu doppelten Kosten oder einem dauerhaften Risiko.
Mythos 2: Security ist eine reine IT-Aufgabe.
Faktencheck: Nein, echte Sicherheit wird ganzheitlich gedacht.
Wer sagt, Sicherheit liege primär bei IT- oder Security-Teams, verschiebt damit Verantwortung an die falsche Stelle im Lebenszyklus. In der Praxis entstehen viele Risiken bereits bei grundlegenden Produktentscheidungen. Etwa, welche Daten überhaupt gesammelt werden, wie einfach sich ein Konto anlegen lässt oder welche Funktionen für Nutzer offen zugänglich sind. Diese Entscheidungen wirken oft harmlos, bestimmen aber maßgeblich die Angriffsfläche eines Produkts. Die IT kann solche Vorgaben später nur noch absichern, aber nicht mehr grundlegend ändern. Security-by-Design bedeutet deshalb, Sicherheit von Anfang an mitzudenken – nicht erst, wenn das Produkt technisch umgesetzt ist.
🟧 Vertiefendes Webinar Security by Design erfordert mehr als technische Maßnahmen. Neue Anforderungen müssen frühzeitig in Prozesse, Verantwortlichkeiten und die Unternehmenskultur integriert werden. Genau hier entscheidet sich, ob Veränderungen dauerhaft erfolgreich sind oder an fehlender Akzeptanz scheitern. Jochen Wannicke, Senior Consultant & Business Coach bei der Trovarit AG, zeigt, wie Unternehmen Veränderungsprozesse strukturiert begleiten, Mitarbeiter einbinden und neue Anforderungen nachhaltig in der Organisation verankern.Change Management in Business-Software-Projekten
Faktencheck: Kurzfristig ja, bewirkt aber langfristig oft das Gegenteil.
Wahr ist, dass komplexe Sicherheitsanforderungen zunächst den Aufwand erhöhen und die Entwicklung verlangsamen können. Fehlt diese Grundlage allerdings, müssen Funktionen nachträglich überarbeitet werden, Systeme können instabil laufen und Teams sind mit Fehlerbehebung statt mit neuen Features beschäftigt. Innovation findet dann nicht mehr im Produkt, sondern im Krisenmodus statt. Security-by-Design sorgt deshalb nicht für weniger Innovation, sondern dafür, dass sie dauerhaft tragfähig bleibt.
Mythos 4: Security ist ein Kostenfaktor.
Faktencheck: Nur kurzfristig, strategisch ist sie Risikomanagement.
Security erscheint oft als zusätzlicher Budgetposten für Tools, Prozesse und Audits. Die eigentlichen Kosten entstehen jedoch erst durch fehlende Sicherheit: Kritische Events, Ausfälle, Datenverluste oder Reputationsschäden sind meist deutlich teurer und kaum kalkulierbar. Security-by-Design verschiebt den Fokus von reaktiven Kosten zu proaktiver Absicherung von Geschäfts- und Markenwerten.
Mythos 5: Compliance bedeutet Sicherheit.
Faktencheck: Nein, Compliance ist ein Mindeststandard.
Angreifer orientieren sich nicht an Checklisten, sondern an realen Schwachstellen. Sicherheit ist zudem kein statischer Zustand. Sie verändert sich mit der Nutzung, mit Systemänderungen und der sich entwickelnden Bedrohungslage. Ein Security-by-Design-Ansatz, der mit dem Produkt-Launch endet, erzeugt daher auch eine Scheinsicherheit; wirklich wirksam ist nur ein kontinuierlicher Ansatz im Betrieb. Der Cyber Resilience Act adressiert diese Notwendigkeit und fordert ein Lifecycle-Denken inklusive Entwicklung, Betrieb, Updates und Reaktion.
Insgesamt ist Security-by-Design kein Dokumentationsprojekt, sondern eine dauerhafte Management-Aufgabe. Der Cyber Resilience Act macht klar, dass sich Sicherheit nicht in Audits entscheidet, sondern im Zusammenspiel aus Architektur, Betrieb und Verantwortung über den gesamten Produktlebenszyklus hinweg. jf
Der Autor
Stefan Keller ist Chief Product Officer bei Open Systems, einem Spezialisten für Security Access Service Edge.
