Think Ahead
{DEVDAY.26} · DRESDEN · 04. MAI 2026

Cyber Resilience Act:
Was sich in deinem Sprint ändert.

Waldemar Kindler
Geschäftsführer, Think Ahead Technologies GmbH
In ungefähr fünf Monaten
11. September
2026.
An diesem Tag werden Hersteller von Produkten mit digitalen Elementen verpflichtet, Schwachstellen an die ENISA zu melden.
Cyber Resilience Act
02
Ab 11.09.2026 — die Uhr läuft

24 / 72 / 14.

Innerhalb von
24 h
Frühwarnung an die ENISA bei aktiv ausgenutzten Schwachstellen.
Innerhalb von
72 h
Vollständige Schwachstellenmeldung mit verfügbaren Korrekturmaßnahmen.
Nach Fix
14 Tage
Abschlussbericht nach Bereitstellung der Korrektur.
Cyber Resilience Act
03
Wo wir stehen

Drei Daten, die im Kopf bleiben.

Heute
Mai 2026
Mittendrin in der Übergangsphase. CRA in Kraft seit 10. Dezember 2024.
In ~5 Monaten
11. September 2026
Meldepflichten greifen. Die 24 / 72 / 14-Uhr läuft.
In ~20 Monaten
11. Dezember 2027
Volle Anwendbarkeit. Ohne CRA-Konformität kein CE-Zeichen, kein EU-Verkauf.
Cyber Resilience Act
05
Strafrahmen — pro Verstoß gegen wesentliche Anforderungen
15 Mio €
oder
2,5 %
vom weltweiten Jahresumsatz — was höher ist.
Aber, ehrlich:
Bußgelder ändern keine Engineering-Kultur.
Was die CRA wirklich tut: Sie macht Cybersecurity zu einem Produktfeature auf Augenhöhe mit Funktionalität. Und genau das verändert eure Sprints.
Cyber Resilience Act
07
Bevor wir in die Sprint-Mechanik gehen

Drei Sätze, mit denen die meisten Teams danebenliegen.

Ich habe in den letzten Monaten viele Engineering-Teams gefragt, was sie über die CRA wissen. Dieselben drei Missverständnisse, immer wieder. Räumen wir sie weg - dann ist klar, worauf der Rest dieses Vortrags zielt.
Mythos 01
„Das betrifft uns nicht. Wir entwickeln nur interne Software."
Sobald euer Code als Produkt an Dritte geliefert wird — auch konzernintern, auch B2B — seid ihr Hersteller im Sinne der CRA.
Mythos 02
„Wir sind SaaS, uns trifft das nicht."
Kommt drauf an. Reines SaaS meistens raus. Alles mit Agenten, On-Prem, Hardware: drin.
Mythos 03
„CE? Das macht doch der Hardware-Kollege."
Ab Dez. 2027 hängt CE mit an euren Software-Sicherheitseigenschaften.
Was die CRA wirklich ist
08
Erstens

„Intern“ schützt euch nicht.

Wirklich intern
Code läuft nur in eurem Team, eurem Repo, eurer Pipeline. Verlässt nie eure Org.
CRA-relevant
An eine andere Tochtergesellschaft, an einen B2B-Kunden, an eine Partnerfirma geliefert — ihr seid Hersteller.
Die CRA spricht von „Placed on the market“ — das umfasst auch konzerninterne und B2B-Übergabe.
Cyber Resilience Act
09
Zweitens

Der Scope ist breit.

„Produkte mit digitalen Elementen." Hat euer Produkt Software und kommuniziert direkt oder indirekt mit Gerät oder Netzwerk? Dann seid ihr drin.
✓ Drin
Hardware mit Firmware · Reine Software-Produkte · B2B-Produkte · On-Premise-Module
~ Meist raus
Reines SaaS · Nicht-kommerzielle Open-Source-Entwicklung
! Achtung
Wer OSS kommerziell weiterverwertet, ist für deren Sicherheit verantwortlich.
↗ Neuer Akteur
„Open-Source Software Steward" mit abgemilderten Pflichten. Niemand hier ist Steward — ihr seid Hersteller.
Cyber Resilience Act
10
Drittens

Das CE-Zeichen bekommt eine neue Bedeutung.

CE
Bisher. Elektrische Sicherheit. EMV. Maschinensicherheit.
CE
Ab Dez. 2027. Plus Cybersecurity nach Anhang I CRA.
Cyber Resilience Act
11
„
Wer liest am Sonntag um 3 Uhr eure security@-Adresse?
Geschweige denn: wer formuliert in 24 Stunden eine ENISA-Meldung, gibt sie frei und sendet sie ab?
Wenn ihr aus diesem Vortrag eine Sache mitnehmt
„
Cybersecurity wechselt von „Security-Team kümmert sich" zu Definition of Done.
Der eine Shift
12
Wo Security im Prozess sitzt

Vom Gate zum Akzeptanzkriterium.

Heute · in den meisten Teams
Security ist ein Gate. Am Ende.
  • Pentest kommt rein, findet was, schreibt Tickets, blockt Release.
  • Oder, häufiger: kommt nie — alle hoffen das Beste.
Unter der CRA
Security ist ein Akzeptanzkriterium.
  • Kriterium nicht erfüllt → Story nicht done.
  • Story nicht done → geht nicht in den Release.
  • Trotzdem im Release → Compliance-Verstoß mit Bußgeldrisiko.
Der eine Shift
13
04
Was sich konkret
im Sprint ändert.
Sechs Stellen. Sechs sehr konkrete Änderungen.
4.1 · Neue DoD-Kriterien

Was zu „done" dazukommt: Secure by Design & Secure by Default

  • Threat-Model-Review für neue Komponenten oder neue externe Schnittstellen.
  • Keine neuen Default-Credentials, keine offenen Ports ohne Begründung.
  • Kein neues Logging von Secrets, Tokens oder personenbezogenen Daten.
  • Dependencies gegen bekannte CVEs geprüft.
  • SBOM aktualisiert und mit dem Artefakt versioniert.
Klingt nach viel. Nach drei Sprints Routine. Nach sechs vergesst ihr, dass es früher anders war.
Im Sprint · 4.1
16
4.2 · Neue Backlog-Items

Was ins Refinement wandert.

Threat Models
Pro signifikanter Komponente.
SBOM-Pipeline
Generierung & Versionierung.
VR Runbook
Vulnerability Response mit benannten Owner-Rollen.
CVD Policy
security.txt · echtes Postfach · SLA.
Update Hardening
Signierte Updates, Channels, Rollback.
Secret-Scanning
Pipeline + Logging-Audit.
Wenn der PO sagt:
„Machen wir nächstes Quartal."
Klartext-Übersetzung: „Wir nehmen das Bußgeldrisiko in Kauf."
Im Sprint · 4.2
17
4.3 · Pipeline

SBOM. Bei jedem Build. Versioniert.

Anhang I CRA verlangt explizit eine Stückliste der enthaltenen Komponenten — pro Produkt. CycloneDX oder SPDX, beide anerkannt.
Tooling — heute, kostenlos
Syft
SBOM-Generierung
Grype
Vulnerability-Scan gegen DBs
Kunnus Scanner
SBOM-Generierung, auch für Windows
OSV
Ergänzende Vulnerability-DB
Setup-Aufwand
Ein Nachmittag, wenn jemand weiß, was er tut.
Drei Tage, wenn nicht.
Zweiter Schritt — SCA
Kritische CVE? Notification. Nicht aus den Tagesnachrichten erfahren.
Im Sprint · 4.3
18
Sprint-Aufgabe für die nächsten 14 Tage

Tabletop Exercise.
Donnerstag, 14 Uhr. Eine Stunde.

Szenario
„Es ist Sonntag, 3 Uhr morgens. Ein Sicherheitsforscher meldet per E-Mail eine Remote-Code-Execution in eurem Produkt — mit Proof-of-Concept und Hinweisen, dass die Schwachstelle bereits ausgenutzt wird."
  • Wer macht was?
  • Wer wird wann geweckt?
  • Wer schreibt die ENISA-Meldung — in welcher Sprache?
  • Wer gibt sie frei? Wer informiert eure Kunden?
4.4 · Support-Window
5
Jahre.
Mindestens. Oder die erwartete Produktlebensdauer, falls kürzer.

Was ihr heute baut, müsst ihr 2031 noch patchen können.

  • Drittanbieter-SDKs, die nächstes Jahr abgekündigt werden.
  • Sprach-Versionen, die 2027 EOL gehen.
  • Build-Pipelines, die in zwei Jahren niemand mehr versteht.
  • Container-Basisimages, die 2029 keine Security-Updates mehr bekommen.
Bei jeder Architektur-Entscheidung fragen: „Können wir das in fünf Jahren noch sicher patchen?"
Im Sprint · 4.4
20
4.5 · Update-Mechanism

Updates: standardmäßig automatisch.
Mit Opt-out — nicht andersherum.

Signiert
Keine ungesignten Binaries. Keine ungesicherten Channels.
Roll-out
In Stunden. Nicht in Wochen.
Embedded
A/B-Slots. Damit ein fehlerhaftes Update nicht 10.000 Geräte bricked.
Patch-SLAs
Critical: 7 Tage · High: 30 Tage. Schreibt eure SLAs auf.
Im Sprint · 4.5
21
Was kein Compliance-Tool-Hersteller verkauft
„
Das Schwerste an der CRA ist nicht SBOM. Nicht ENISA. Nicht Threat Modelling.
Das ist alles solides Engineering — in einem Quartal aufgebaut.
Das Schwerste ist die Verhandlung mit eurem Stakeholder.
Capacity
23
Die Mathematik

60 Story Points → 6 in CRA-Themen.

Wenn ihr es später macht
  • Q3 2027, unter Panik.
  • Doppelter Aufwand.
  • Kein Puffer für die Sachen, die schiefgehen werden.
  • (Und es werden Sachen schiefgehen.)
  • Faktor 3 höhere Kosten durch Beraterheer.
Mein Vorschlag — diese Woche
„Wir reservieren ab dem nächsten Quartal 10 % unserer Sprint-Capacity für CRA-Themen, bis wir audit-ready sind. Das wird ungefähr drei bis vier Quartale dauern. Hier ist die Liste der Items. Hier ist das Risiko, wenn wir es nicht tun."
Capacity
24
06
Was ihr nächsten
Montag tun könnt.
Fünf Sprints. Konkrete Items. Nehmt die mit.
Sprint 1 · 2 Wochen
01
Sprint 1
Inventur.
Was sind eure Produkte mit digitalen Elementen? Welche fallen in Anhang III (wichtige Produkte mit strengeren Konformitätsbewertungen)? Welche eventuell in Anhang IV (kritische Produkte)? Eine Confluence-Seite reicht. Aber macht sie. Ohne diese Inventur ist alles Weitere Raten.
Nächste 10 Wochen
26
Sprint 2 · 2 Wochen
02
Sprint 2
SBOM und SCA.
Syft + Grype in der Pipeline. SBOM-Artefakt mit jedem Build. Erste CVE-Reports. Erstmal nur Reports — kein Blocking. Ihr werdet entsetzt sein über das, was eure transitiven Dependencies machen. Das ist normal. Das ist der Sinn der Übung.
Nächste 10 Wochen
27
Sprint 3 · 2 Wochen
03
Sprint 3
Vulnerability Disclosure.
security.txt online. security@ mit echtem, überwachtem Postfach. Triage-Prozess auf einer A4-Seite — eine Seite, mehr nicht. Tabletop Exercise im Kalender für die folgende Woche.
Nächste 10 Wochen
28
Sprint 4 · 2 Wochen
04
Sprint 4
Definition of Done.
Neue DoD-Kriterien beschlossen. Im Team verankert. Erste Stories nach neuer DoD durchgezogen. Es wird länger dauern. Ihr werdet weniger Story Points abschließen. Das ist okay. Es wird nach drei Sprints aufholen.
Nächste 10 Wochen
29
Sprint 5 · 2 Wochen
05
Sprint 5
Threat Modelling.
Eine Komponente, ein Threat Model. STRIDE oder Trike, was eurem Team passt. Eine Stunde Workshop, dokumentiert im Repo neben dem Code. Beim nächsten Mal seid ihr schneller. Beim dritten Mal ist es Routine.
Nächste 10 Wochen
30
Nach 10 Wochen
Ihr seid nicht CRA-konform.
Aber ihr seid auf einem Weg, der euch bis Dezember 2027 zur Konformität führt.
Ohne Panik. Ohne Beraterheer im Q4 2027. Ohne dass eure Roadmap explodiert.
Nächste 10 Wochen
31
Schluss
Die CRA ist die größte Veränderung im EU-Cybersecurity-Recht seit der DSGVO. Aber im Gegensatz zur DSGVO trifft sie nicht eure Datenschutzbeauftragten.
Sie trifft eure Sprints.
Sicherheit wandert vom Rand in die Mitte eurer Definition of Done. Und das ist die Stelle, an der sie schon immer hingehört hat.
Cyber Resilience Act
32
Think Ahead
Q&A
Vielen
Dank.
Waldemar Kindler
waldemar.kindler@think-ahead.tech · think-ahead.tech
Think Ahead Technologies GmbH
Stuttgart · Cloud · Platform · Security · CI/CD