CRA: Was bis September fertig sein muss. Und was nicht.

Zwei Fristen, eine Verwechslungsgefahr

Der Cyber Resilience Act, kurz CRA, ist seit Dezember 2024 als EU-Verordnung 2024/2847 in Kraft. Seitdem kursiert viel zum Thema. Meistens vermischt als ein großer Block: „CRA kommt, alles muss sicher sein, sonst Bußgeld.“ Das stimmt technisch, hilft aber niemandem bei der Priorisierung.

Tatsächlich hat der CRA einen gestaffelten Zeitplan. Der erste Meilenstein: Ab dem 11. September 2026 werden Melde- und Schwachstellenmanagement-Pflichten verbindlich. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb festgelegter Fristen an die zuständige Behörde melden. Der zweite, deutlich größere Meilenstein: Ab dem 11. Dezember 2027 gilt der vollständige Anforderungskatalog für alle betroffenen Produkte.

Das ist der Kern, den viele Artikel zum Thema unterschlagen. Zwischen September 2026 und Dezember 2027 liegen 15 Monate Vorlauf. Wer die verstreichen lässt, weil er September und Dezember 2027 für dasselbe Datum hält, bringt sich um genau diese Vorbereitungszeit.

Was ab September 2026 wirklich verlangt wird

Konkret heißt die September-Pflicht: Ein Meldeweg muss stehen. Sobald ihr Kenntnis davon habt, dass eine Schwachstelle in eurem Produkt aktiv ausgenutzt wird, läuft eine 24-Stunden-Frist. Wichtig: Art. 14 verlangt keine Suche. Die Pflicht knüpft an die Kenntnis an, nicht an ein Monitoring. Die Produktbeobachtungspflichten stehen in Anhang I Teil II und greifen erst 2027.

Und: Kenntnis entsteht nicht automatisch mit dem Eingang eines Hinweises. Erst eine Erstbewertung, die mit hinreichender Gewissheit eine aktive Ausnutzung bestätigt, setzt die Uhr in Gang. Diese Erstbewertung muss aber zügig erfolgen — wer Hinweise liegen lässt, riskiert im Streitfall, dass die Behörde die Kenntnis dorthin verlegt, wo eine prompte Prüfung sie ergeben hätte.

Für die meisten Dev-Teams läuft das auf drei Fragen hinaus:

• Ist klar, wer im Ernstfall die Erstbewertung vornimmt und wer anschließend meldet?
• Ist die Frist bekannt, und ist der Meldeweg an CSIRT und ENISA vorbereitet?
• Landet ein Hinweis von außen überhaupt zügig bei jemandem, der ihn bewertet?

Die dritte Frage ist keine Pflicht im Sinne von Art. 14 selbst, sondern gesunder Menschenverstand: Ohne einen Prozess, der Hinweise zügig prüft, entsteht die maßgebliche Kenntnis spät oder unter Zeitdruck — und genau dann drohen die 24 Stunden zu reißen.

Ergänzender Hinweis: appsoluts empfiehlt hier zusätzlich, den Single Point of Contact aus Art. 13 / Anhang I Teil II Nr. 5-6 (zentrale Anlaufstelle für Schwachstellenmeldungen) schon jetzt einzurichten und zu kommunizieren. Geringer Aufwand, klarer Nutzen: Hinweise laufen dort auf, wo sie zügig bewertet werden.

Was bis Dezember 2027 noch dazukommt

Der breite Katalog, der 2027 vollständig greift, verlangt strukturell mehr. Vier Bausteine bilden den Kern.

1. 1) Security by Design und by Default. Cybersicherheit gehört in die Produktentwicklung, nicht als nachträglicher Patch. Praktisch heißt das: Standardkonfigurationen ohne Default-Passwörter, Zugriffskontrollen von Anfang an mitgedacht, Kryptographie nicht als Feature, sondern als Grundzustand.

2. 2) Software Bill of Materials (SBOM). Jedes Produkt braucht eine aktuell gehaltene Stückliste seiner Software-Komponenten und Bibliotheken. Das betrifft ausdrücklich auch Fremdkomponenten und Open-Source-Abhängigkeiten. Ohne SBOM lässt sich im Ernstfall nicht sagen, welche eigenen Produkte von einer Schwachstelle in einer bestimmten Library betroffen sind.

3. 3) Vulnerability- und Incident-Management. Über den gesamten Support-Zeitraum hinweg, nicht nur beim Launch. Das Risiko-Assessment eines Produkts muss laufend aktualisiert werden, nicht einmalig vor der Markteinführung erstellt.

4. 4) Update-Pflichten. Hersteller müssen für die selbst definierte Support-Dauer, mindestens aber fünf Jahre, kostenlose Sicherheitsupdates bereitstellen. Das ist eine Verpflichtung, die über den typischen Projektabschluss hinausreicht und beim Aufsetzen von Wartungsverträgen mitgedacht werden sollte.

Wie tief diese vier Bausteine im Einzelfall greifen, hängt von der Risikoklasse des Produkts ab. Dazu gleich mehr.

Was sich im Entwicklungsalltag konkret ändert

Für Entwicklungsteams landet der CRA am Ende in der CI/CD-Pipeline, nicht in einem Compliance-Dokument.

Dependency-Scanning wird zur Pflichtübung statt zur Kür. Wer heute schon Tools wie Dependabot, Snyk oder OWASP Dependency-Check im Einsatz hat, ist strukturell näher an der SBOM-Pflicht als Teams, die Abhängigkeiten manuell im Blick behalten.

Die SBOM selbst lässt sich am saubersten automatisiert aus dem Build-Prozess generieren, nicht nachträglich von Hand pflegen. Formate wie CycloneDX oder SPDX haben sich dafür etabliert.

Das Vulnerability-Management braucht einen klaren Eskalationsweg. Nicht nur „wer testet“, sondern „wer entscheidet, ob eine gefundene Schwachstelle aktiv ausgenutzt wird, und wer meldet fristgerecht“. Das ist eher eine Prozessfrage als eine Tool-Frage.

Und: Dokumentation wird zum Nebenprodukt der Entwicklung, nicht zur separaten Fleißarbeit danach. Risikobewertungen, Architekturentscheidungen und Update-Historie gehören dort hin, wo ohnehin schon dokumentiert wird, etwa ins Repository selbst.

Betrifft uns das? Einordnung nach Risikoklasse

Der CRA unterscheidet Produktkategorien nach Risiko. Für die meisten Softwareprojekte im deutschen Mittelstand ist das relevant, weil sich daraus der tatsächliche Prüfaufwand ergibt.

Wer B2B-Software für den Mittelstand baut, landet in der Regel in der Standard-Kategorie. Das bedeutet weniger großen Prüfaufwand, aber es befreit nicht von den technischen Anforderungen selbst. Die Konformitätserklärung muss trotzdem inhaltlich stimmen, nur eben ohne externe Zertifizierungsstelle im Nacken. Dafür bieten viele spezialisierte Software-Agenturen Audits und Prüfungen an.

Was jetzt Priorität hat und was noch Zeit hat

Ehrlich eingeordnet, nicht alarmistisch: Nicht alles muss bis September stehen.

Hat jetzt Priorität:

• Ein funktionierender Meldeprozess für aktiv ausgenutzte Schwachstellen.
• Klarheit darüber, wer im Ernstfall entscheidet und meldet.
• Ein relevanter Überblick über die eigenen Software-Abhängigkeiten, auch wenn er noch nicht die finale SBOM ist.

Hat noch etwas Zeit bis 2027:

• Die vollständige, automatisiert gepflegte SBOM für jedes Produkt.
• Die komplette Neuaufstellung der Update- und Supportverträge.

Diese Trennung ist keine Ausrede, um das Thema zu verschieben. Sie ist der Unterschied zwischen einer machbaren Aufgabe für die nächsten acht Wochen und einem Zwei-Jahres-Programm, das man jetzt anfängt, statt es im November 2027 in Panik zu starten.

Fazit

Der CRA wird oft als ein einziges großes Deadline-Ereignis verkauft. Das stimmt nicht. Er ist ein gestaffelter Prozess mit einem kleinen, konkreten ersten Schritt und einem großen zweiten. Wer im September nur den Meldeprozess für aktiv ausgenutzte Schwachstellen sauber aufgesetzt hat, hat genau das getan, was die Frist verlangt. Der Rest, Security by Design, SBOM, Update-Pflichten, ist ein Umbau, der Zeit braucht und Zeit bekommt. Die eigentliche Aufgabe ist nicht, alles gleichzeitig zu tun, sondern jetzt mit dem Richtigen anzufangen.

Ihr wollt wissen, wo eure Software heute steht?

Kostenlosen Discovery Call mit Christian buchen