Vom Feature zur Haftung: Warum der EU-Cyber Resilience Act Ihr Roadmap-Meeting morgen sprengt

Vom Feature zur Haftung: Warum der EU-Cyber Resilience Act Ihr Roadmap-Meeting morgen sprengt

Bis gestern haben Sie Features priorisiert, als ginge es um die Frage „Was bringt den nächsten großen Kunden, was begeistert die Presse, was macht den Vertrieb glücklich?“. Ab morgen steht eine andere Frage im Raum: „Welche dieser Funktionen können wir überhaupt noch verantworten, ohne gegen den Cyber Resilience Act (CRA) zu verstoßen – und wer haftet, wenn wir es trotzdem tun?“ Das mag dramatisch klingen, ist aber nüchtern betrachtet die neue Realität für alle, die Produkte mit digitalen Komponenten bauen, betreiben oder vertreiben. Der CRA dreht die Blickrichtung von außen nach innen: Weg von der Feature-Show, hin zur belastbaren Fähigkeit, ein Produkt über seinen gesamten Lebenszyklus sicher zu halten. Und genau deshalb sprengt er klassische Roadmap-Rituale – nicht aus Bosheit, sondern aus Notwendigkeit.

Was sich verändert, ist nicht nur eine Liste von Pflichten, sondern die Logik, nach der Sie Entscheidungen treffen. Der CRA macht Sicherheit zu einer Marktzulassungsbedingung und verknüpft sie mit nachweisbarer Sorgfalt. Wo bislang „Security“ ein Arbeitspaket im Projektplan war, wird sie zur architektonischen Grundannahme und zur Managementaufgabe, an der sich Budgets, Zeitpläne, Vertragswerke und sogar Marketingclaims ausrichten müssen. Wer Roadmaps weiterhin wie Wunschzettel behandelt, produziert in Zukunft nicht Innovationen, sondern Haftungsrisiken.

Das neue Kräftefeld im Roadmap-Meeting

Stellen Sie sich die Szene vor: Produktmanagement kommt mit einer ambitionierten Vision in den Termin, Engineering mit einem ehrgeizigen Zeitplan, Marketing mit knackigen Versprechen. Die Rechtsabteilung hat rote und gelbe Fähnchen an die Slides geheftet, Security bringt eine Liste offener CVEs, die aus dem letzten Release übrig sind, der Einkauf winkt mit Lieferantenverträgen, die bislang nichts zu SBOMs oder Patch-SLAs sagen, und der Service weist darauf hin, dass die Hälfte der installierten Basis seit Monaten kein Update gesehen hat, weil die Update-Logistik noch halb manuell läuft. Früher war das ein Koordinationsproblem. Mit dem CRA wird es zu einem Zulassungs- und Haftungsproblem.

Denn ein Produkt, das ohne nachvollziehbares Risikomanagement, ohne belastbare Update-Prozesse, ohne dokumentierte Schwachstellenbehandlung in den Markt geht, ist künftig nicht nur „unfertig“, sondern unter Umständen nicht konform. Und nicht konform bedeutet: kein rechtssicherer Marktzugang, Bußgelder, Rückrufpflichten, Vertriebsstopps, und – in der bitteren Spielfortsetzung – Shitstorms, Vertragsstrafen, Reputationsschäden. Das ist der Punkt, an dem Ihre Roadmap zerreißt, wenn sie weiterhin nur über Kundennutzen spricht, aber nicht über Sicherheitsnachweise.

Von der Feature-Fabrik zur Sorgfaltspflicht

Der CRA zwingt zur Einsicht, dass Sie nicht Features liefern, sondern versorgbare Systeme. Was bedeutet das konkret? In der Entwicklung wird „Done“ neu definiert. Nicht nur „Ticket abgeschlossen, Tests grün“, sondern „Abhängigkeiten dokumentiert, SBOM erzeugt und versioniert, Artefakte signiert, geheimnisfreie Builds, automatische Security-Checks bestanden, Threat-Model aktualisiert, Update-Pfade getestet, Telemetrie-Hooks aktiv, Rollback möglich“. Im Betrieb heißt „ausgeliefert“ nicht „verkauft“, sondern „über den Lebenszyklus aktualisierbar, adressierbar, beobachtbar, belastbar“. Und im Management bedeutet „go to market“ nicht „Anzeigen schalten“, sondern „Erklärung zur Konformität sorgfältig untermauert und auditfest, Prozesse für Post-Market-Surveillance verankert, PSIRT mit Eskalationswegen aufgestellt“.

Das klingt nach mehr Aufwand, und das ist es auch. Aber der Aufwand ist kein bürokratischer Selbstzweck: Er ist die Voraussetzung, dass digitale Produkte beherrscht werden können. In einer Welt, in der Schwachstellen nicht die Ausnahme, sondern Alltag sind, verschiebt sich die Kunst vom „Vermeiden“ zum schnellen, kontrollierten Beheben. Wer das begriffen hat, priorisiert auf der Roadmap plötzlich ganz anders: Update-Backbone vor neuem Feature, PSIRT-Betrieb vor UI-Politur, SBOM-Automatisierung vor der nächsten Integrationsidee. Und das hat Folgen für Termine, Budgets und Verantwortlichkeiten.

Warum Ihr Backlog plötzlich anders sortiert sein muss

Die unscheinbaren technischen Schulden, die man jahrelang „später“ während der nächsten Refactoring-Runde zahlen wollte, werden unter CRA zu rechtsrelevanten Lücken. Eine Update-Pipeline ohne Signaturen? Ein Build, der nicht reproduzierbar ist? Eine Flotte, die Sie nicht zuverlässig in Wellen aktualisieren können? Das waren bisher „Qualitätsthemen“. Morgen sind es Gründe, warum Sie keine glaubwürdige Konformitätserklärung abgeben können. Und ohne die gibt es keine CE-Kennzeichnung, keine Ausschreibungsteilnahme, keine Vertriebsfreigabe. Die Reihenfolge im Backlog kehrt sich um: Dinge, die dem Vertrieb unsichtbar erscheinen, werden Top-Priorität, weil sie Ticket 1 der Compliance sind.

Diese Umdrehung tut weh, wenn die Organisation am Mythos „Speed first“ hängt. Sie wird aber erträglich, sobald Sie erkennen, dass diese Basisinvestitionen Zeit zurückgeben: weniger Firefighting, weniger Ad-hoc-Patching, weniger Vertriebs-Eskalationen, mehr planbare Releases, mehr vertrauensvolle Kundenbeziehungen. Oder in Management-Sprache: weniger Volatilität in Kosten und Terminen. Wenn Sie Roadmaps nicht nur nach „neuer Wert“ sortieren, sondern nach „neuer Wert plus gesicherte Versorgbarkeit“, arbeiten Sie zum ersten Mal CRA-kompatibel.

SBOM: aus der Nische ins Zentrum

Das Paradebeispiel dieser Verschiebung ist die Software Bill of Materials. Viele haben in den letzten Jahren SBOMs als „nice to have“ abgetan – interessant für ein paar sicherheitsaffine Kunden, aber schwierig zu pflegen. Der CRA stößt diese Tür endgültig auf. Ohne SBOM wissen Sie nicht, was Sie ausliefern. Ohne SBOM können Sie bei einer neuen CVE nicht schnell sagen, wie viele Kunden betroffen sind. Ohne SBOM können Sie nicht plausibel machen, dass eine bestimmte Schwachstelle in Ihrem Kontext nicht ausnutzbar ist. Und ohne SBOM haben Sie keine belastbare Grundlage für Ihre Erklärungen gegenüber Behörden und Kunden.

Das Wichtige dabei: Eine SBOM ist kein Dokument, das jemand „pflegt“. Sie ist ein automatisiertes Build-Artefakt. Sie entsteht im CI/CD-Prozess, nicht im Wiki. Sie verweist auf Versionen, Hashes, Signaturen, Container-Layer, Treiber, und sie lässt sich mit VEX-Informationen anreichern, die den Exploitability-Kontext abbilden. Erst dann können Sie Roadmap-Entscheidungen treffen, die Sicherheit quantifizierbar machen: Welche Bibliotheksupdates verschieben den Release? Welche Kompatibilitätstests müssen neu gefahren werden? Wer ist für die Abhängigkeitslandschaft einer Komponente verantwortlich? Es ist eine neue Art von Produktwissen – weniger glamourös, aber essenziell.

Updates: Vom Patch zum Plan

Viele Teams spüren intuitiv, dass der Umgang mit Updates der Hebel ist, an dem der CRA sie messen wird. Ein einzelnes „Patch ist fertig“ genügt nicht mehr. Es geht um beherrschte Flotten. Sie brauchen nicht nur signierte Images, sondern auch Wellen, Stop-Kriterien, Rollback und Telemetrie, die Ihnen zeigt, ob die Aktualisierung in der realen Welt hält, was sie im Test versprach. Das verschiebt den Fokus: Sie investieren in Staging-Umgebungen, die echten Kundenlandschaften ähneln. Sie definieren Abbruchregeln, wenn Crash-Rates oder Boot-Zeiten explodieren. Sie planen Wartungsfenster in kritischen Umgebungen, in denen ein Reboot nicht „mal eben“ geht. Und Sie bauen eine Schlüssel-Hygiene auf, die verhindert, dass ein durchgesickerter Signierschlüssel zur Systemkatastrophe wird.

All das kostet Sprints. Aber es lässt sich intelligent staffeln. Nicht jedes Produkt braucht über Nacht den gleichen Reifegrad. Was die Roadmap morgen sprengt, ist weniger der Umfang als die Einsicht, dass Sie diese Hausaufgaben nicht länger nach hinten schieben können. Wenn die erste große Kundenchance von einer Konformitätszusage abhängt, die Sie ohne Update-Backbone nicht ehrlich geben können, fällt die Verschiebung des Features nicht unter „nice to have“, sondern unter „business critical“.

PSIRT: die neue Orchestrierungsschicht

In der alten Welt hat jede Abteilung „ihr Ding“ getan, und beim Launch gab es einen großen Schulterschluss. In der neuen Welt fehlt dieses Orchestrierungszentrum für Sicherheitsereignisse – bis Sie ein PSIRT etablieren. Dieser Produkt-Security-Einsatztrupp ist keine Security-Taskforce im Hinterzimmer, sondern die Schaltstelle, die Hinweise entgegennimmt, bewertet, Fixes koordiniert, Advisories formuliert, Kunden informiert und Meldepflichten bedient. Ein gut aufgestelltes PSIRT hat klare Reaktionszeiten, eine Priorisierungsmethodik, definierte Eskalationspfade in Engineering, Produkt, Recht, PR und Customer Success, und es führt Post-Mortems durch, die tatsächlich Verbesserungen auslösen.

Was hat das mit Roadmaps zu tun? Alles. Ein PSIRT sieht, wo Sicherheitslücken systemisch entstehen: an nicht gehärteten Schnittstellen, in unklaren Verantwortlichkeitszonen, in Komponenten, die niemand „besitzt“. Es bringt diese Erkenntnisse früh in die Planung, bevor Sie erneut dieselben Fehler in Version n+1 gießen. Und es verhindert, dass eine Krise die Roadmap komplett sprengt, weil die Reaktion prozessual verankert ist, statt heroisch improvisiert.

Der Einkauf wird zum Sicherheitsbeschaffer

Die wenig glamouröse, dafür extrem wirksame Veränderung findet im Einkauf statt. Wer Komponenten, Bibliotheken, SDKs oder SaaS-Zutaten beschafft, muss künftig nicht nur Preis, Funktion und Lieferzeit verhandeln, sondern Sicherheitszusagen: SBOMs je Release, CVE-Mitteilungen in definierten Fristen, Patch-SLAs, Audit-und Nachweispflichten, Schlüsselmanagement, Support-Dauer. Diese Dinge gehören in Verträge, sonst stehen Sie im Ereignisfall alleine da. Und sie gehören früh in die Roadmap-Diskussion, denn sie beeinflussen make-or-buy-Entscheidungen und Integrationstiefe. Der vermeintlich billige Anbieter ohne SBOM kann unter CRA zum teuersten werden – weil er Ihr Haftungsrisiko skaliert.

Secure Development als Taktgeber, nicht als Bremser

Viele Teams fürchten, dass Security-Gates die Produktivität strangulieren. Das Gegenteil ist der Fall, wenn Sie sie taktgerecht einbauen. Automatisierte Analysen in CI/CD, verpflichtende Peer-Reviews, Geheimnis-Scanner, Fuzzing an kritischen Schnittstellen, Threat-Modeling bei Architekturänderungen – all das kostet Minuten und spart Wochen. Der Trick liegt in der Integration: Security ist nicht der „andere“ Workflow, sondern dieselbe Pipeline mit ein paar ernst gemeinten Gates. Und sie ist sichtbar in Kennzahlen, die für Roadmap-Entscheidungen relevant sind: mean time to remediate, Fix-Rate je Release, Anteil signierter Artefakte, Abdeckung von SBOM/VEX, Einhaltung von Disclosure-SLAs. Das sind Zahlen, mit denen Sie gegenüber Management und Aufsicht glaubwürdig steuern.

Dokumentation ohne Papierlawine

Der CRA verlangt Nachweise, aber er verlangt keinen Papierfriedhof. Die Herausforderung besteht darin, ein leichtes, lebendiges Rückgrat aufzubauen, das Ihre Praxis abbildet: produktbezogene Risikoanalysen, begründete Sicherheitsziele, design-relevante Entscheidungen, ein Update-Konzept, PSIRT-Prozesse, Lieferkettenkontrollen, Post-Market-Surveillance, Kommunikationsbausteine für Advisories. Das ist kein Schönschreiben, sondern das Betriebshandbuch Ihres Produkts. Und es gehört nicht ins Archiv, sondern neben die Roadmap: Jede Phase des Produktzyklus – Konzept, Entwicklung, Launch, Betrieb, End-of-Life – hat ihre Sicherheits-Artefakte. Wenn Sie sie entlang der Roadmap erzeugen, sind sie kostengünstig und authentisch. Wenn Sie sie am Schluss nachreichen, sind sie teuer und hohl.

Marketing unter Beweislast

Auch das Marketing spürt den Wandel. „End-to-End sicher“ war gestern eine Phrase. Morgen ist sie eine prüfbare Behauptung. Was Sie versprechen, müssen Sie unterfüttern: Mit Support-Zeiträumen, in denen Sicherheitsupdates garantiert werden. Mit Informationen, wie schnell Sie in der Vergangenheit reagiert haben. Mit klaren Anleitungen, wie Kunden Updates erhalten und installieren. Mit einem Sicherheitskontakt, der erreichbar ist. Das ist weniger knallig als „KI-gestützt und revolutionär“, aber in einer CRA-Welt kaufentscheidend. Denn Kunden, Beschaffungsstellen und Auditoren lesen inzwischen das Kleingedruckte vor dem Kauf – und sie fragen nach, wenn Versprechen unklar bleiben.

Preispolitik und Geschäftsmodell

Ja, Sicherheit kostet Geld. Der Unterschied liegt darin, ob Sie sie als Kostenstelle oder als Leistungsmerkmal begreifen. Wer offen kommuniziert, dass die Produktpflege über einen definierten Zeitraum Sicherheitsupdates umfasst, wer Wartungsmodelle transparent macht, wer die Vorteile eines gemanagten Flotten-Betriebs erklärt, der kann Preis und Marge rechtfertigen. Und wer Zusatzleistungen wie verlängerten Support, Compliance-Reports oder Flotten-Management anbietet, erschließt neue Erlösquellen. In der Roadmap bedeutet das: nicht nur Technik, sondern auch Leistungspakete planen, die CRA-Pflichten in Kundennutzen übersetzen.

End-of-Life als strategischer Akt

Eine der unangenehmsten, unter CRA aber unaufschiebbaren Entscheidungen betrifft das Ende des Supports. Wenn Sie Produkte abkündigen, endet nicht automatisch die Haftung. Je nach Zusage und Produktkategorie müssen Updates über einen definierten Zeitraum bereitgestellt werden. EOL-Strategien gehören daher früh auf die Roadmap: Welche Migrationspfade bieten Sie? Wie unterstützen Sie den Wechsel? Wie informieren Sie? Welche Alternativen stehen bereit? Wer diese Fragen vertagt, vererbt sie in die Krise. Wer sie plant, reduziert Haftung – und schafft Platz für Neues, ohne Kunden und Partner zu verprellen.

Kommunikation in der Krise

Egal, wie gut Sie sind: Es wird Vorfälle geben. Die Qualität Ihrer Reaktion entscheidet über Bußgeldhöhe, Kundentreue und Social-Media-Tonlage. Gute Kommunikation ist handwerklich: Betroffenheit klar benennen, Schweregrad einordnen, kurzfristige Workarounds nennen, Zeitplan für den Fix liefern, Update-Anleitung geben, Timeline offenlegen, Fragen antizipieren, zentrale Kanäle bündeln. Das lässt sich vorbereiten. Legen Sie Templates an, schulen Sie Sprecher, fahren Sie Trockenübungen. Wer das tut, nimmt der Krise den Überraschungseffekt – und schützt die Roadmap, weil die Organisation weiterarbeiten kann, statt im Chaos zu versinken.

Synergien mit anderen Regimen

Fast niemand muss „nur“ den CRA erfüllen. NIS2, Funkanlagenrecht, branchenspezifische Vorgaben, demnächst der AI Act – alles greift ineinander. Es ist eine schlechte Idee, für jeden Regulierungsrahmen eigene Prozesse zu erfinden. Besser: Sie definieren Bausteine, die mehrere Pflichten abdecken – SBOM/VEX, Update-Backbone, PSIRT/CVD, Post-Market-Surveillance, Secure Development, Lieferkettenkontrolle – und mappen die Anforderungen darauf. Das senkt Komplexität, reduziert Widersprüche und macht Roadmaps überschaubar. Statt fünf Listen pflegen Sie ein System, das verschiedene Häkchen gleichzeitig setzt.

Führung zeigt sich in der Priorisierung

Am Ende entscheidet die Führung, ob die Roadmap morgen implodiert oder sich neu sortiert. Wenn die Spitze Sicherheit als Chefsache begreift, Budgets freigibt, Ziele setzt und die Konsequenz unterstützt, Releases zu stoppen, wenn Risiken nicht vertretbar sind, dann wird aus dem CRA keine „Katastrophe“, sondern ein Modernisierungsprogramm. Dazu gehört, klare Verantwortlichkeiten zu benennen, ein Lenkungsgremium aufzusetzen, Sicherheitsziele in OKRs zu verankern und die Taktung der Organisation anzupassen. Es ist Führung, die aus „Sprengstoff“ Schubkraft macht.

Was Sie sofort tun können – ohne den Sprintplan zu ruinieren

Nicht alles braucht einen Strategieworkshop. Manche Weichen stellen Sie in Tagen. Veröffentlichen Sie eine security.txt mit Kontakt und CVD-Hinweisen. Erzeugen Sie für eine Hauptproduktlinie automatisch eine SBOM und prüfen Sie, wie viele installierte Systeme Sie innerhalb von 48 Stunden adressieren könnten. Skizzieren Sie einen Staging-Plan für Updates, inklusive Stop-Regeln und Rollback. Entwerfen Sie eine Einkaufs-Klausel, die SBOM, CVE-Mitteilungen und Patch-SLAs vertraglich verankert. Benennen Sie ein kleines PSIRT-Kernteam mit Erreichbarkeit und Eskalationsliste. Diese Schritte ändern die Gespräche im nächsten Roadmap-Meeting – und sie zeigen den Teams, dass es nicht um Papier, sondern um Beherrschbarkeit geht.

Der ökonomische Case

Wer nur Kosten sieht, hat den Business Case nicht gerechnet. Jede Stunde, die Sie in Automatisierung, Telemetrie und koordinierte Reaktion investieren, sparen Sie mehrfach beim nächsten Vorfall: weniger ungeplante Downtime, weniger Nachtschichten, weniger Kundenärger, weniger Vertriebsrabatte. Dazu kommt die positive Selektion: Kunden, die CRA-reife Lieferanten suchen, entscheiden sich häufiger für diejenigen, die belegen können, wie sie mit Schwachstellen umgehen. Das senkt die Akquisitionskosten und stärkt die Verhandlungsposition. Sicherheit ist nicht der Feind der Marge – sie ist ihr Schutz.

Der eigentliche Kulturwandel

Vielleicht ist das Wichtigste, was der CRA mit Roadmaps macht, nicht die Verschiebung der Tickets, sondern die Verschiebung der Haltung. Sie verabschieden sich vom Projektdenken („Nach Release ist vor Urlaub“) und werden zum Betreiber Ihres Produkts. Sie messen Erfolg nicht nur in Feature-Counts, sondern in Mean Time to Remediate, in Update-Adoption, in Offenheit gegenüber Hinweisen von außen. Sie begreifen Lieferantenbeziehungen als Sicherheitsallianzen. Und Sie erzählen Kunden nicht mehr, dass alles perfekt ist, sondern dass Sie fähig sind, mit Imperfektion professionell umzugehen. Diese Ehrlichkeit ist der Stoff, aus dem Vertrauen gemacht ist – und Vertrauen ist die härteste Währung, wenn Sie einmal einen Fehler erklären müssen.

Fazit: Der CRA sprengt nicht – er räumt auf

„Vom Feature zur Haftung“ klingt wie eine Drohung. In Wahrheit ist es eine Einladung, das zu tun, was digitale Produktteams ohnehin brauchen: eine verlässliche Grundlage, auf der Innovation nicht implodiert, sobald die erste Schwachstelle trendet. Der CRA zwingt Sie, die unsichtbaren Teile Ihrer Roadmap sichtbar zu machen – SBOM, Updates, PSIRT, Lieferketten, Dokumentation. Ja, das kostet Anstrengung. Aber es verwandelt Ihr Produkt von einem Versprechen in eine verantwortbare Leistung. Und genau deshalb ist morgen nicht das Ende Ihrer Roadmap, sondern der Anfang einer besseren: weniger Glitzer, mehr Substanz; weniger Angst, mehr Handlungsfähigkeit; weniger „später“, mehr „jetzt“.

Wenn Sie diesen Text bis hierher gelesen haben, sind Sie bereits weiter als viele. Nehmen Sie die erste Entscheidung mit in Ihr Meeting: Welche drei Basisfähigkeiten schaffen wir zuerst, damit jedes kommende Feature tragfähig wird? Sobald diese Frage ernsthaft beantwortet ist, hat der CRA Ihre Roadmap nicht gesprengt – er hat sie befreit.