CRA-Normen 2026: Was die Verzögerung für Ihre SBOM- und Schwachstellenarbeit bedeutet
| Interlynk
Die harmonisierten Normen der CRA sind verzögert, Ihre SBOM- und Schwachstellenpflichten jedoch nicht. Hier der aktuelle Stand und was zu tun ist, während die Normen aufholen.
Überblick
Der EU Cyber Resilience Act ist in Kraft und weit in seiner Umsetzungsphase. Die Meldepflichten gelten seit dem 11. September 2026, und die vollständigen grundlegenden Anforderungen samt CE-Kennzeichnung gelten ab dem 11. Dezember 2027. Dazwischen sitzt die Maschinerie, die Compliance planbar machen soll: die harmonisierten Normen, die Herstellern eine Konformitätsvermutung verschaffen. Diese Maschinerie hängt hinterher.
Stand Oktober 2026 ist keine harmonisierte CRA-Norm im Amtsblatt zitiert, und die Entwurfsfristen sind bereits einmal verrutscht. Es ist verlockend, eine Normverzögerung als Verschnaufpause zu lesen. Für die Teile der CRA, die Softwareteams am meisten betreffen, die SBOM- und Schwachstellenpflichten, ist sie das nicht. Diese Anforderungen hängen nicht von einer fertigen Norm ab, die Melduhr läuft bereits, und die Arbeit, sie zu erfüllen, dauert Monate.
Dieser Beitrag legt dar, wo die Normen tatsächlich stehen und was sich erledigen lässt, während sie aufholen.
Wo die CRA im Oktober 2026 steht
Eine kurze Orientierung, denn die Daten führen die Argumente.
Kapitel IV, das die Notifizierung von Konformitätsbewertungsstellen regelt, gilt seit dem 11. Juni 2026. Die Meldepflichten folgten am 11. September 2026: Hersteller müssen nun aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an die ENISA und ihr nationales CSIRT melden, und die zentrale Meldeplattform der ENISA ist live.
Die vollständige Anwendung beginnt am 11. Dezember 2027. Ab diesem Datum müssen auf dem EU-Markt bereitgestellte Produkte die grundlegenden Anforderungen erfüllen und die CE-Kennzeichnung tragen.
Die grundlegenden Anforderungen selbst sind in der Verordnung festgelegt, in Anhang I. Sie sind der feste Punkt in all dem. Die harmonisierten Normen schaffen diese Anforderungen nicht. Sie bieten einen eingeübten Weg, nachzuweisen, dass Sie sie erfüllt haben.
Die Verzögerung bei den Normen
Im Juli 2026 veröffentlichte die Kommission einen Entwurf zur Änderung des Normungsauftrags hinter der CRA, Mandat M/606, mit dem Vorschlag, die Entwurfsfristen um etwa zwei Monate nach hinten zu verschieben. Dem Vorschlag zufolge rücken die ersten horizontalen Kernnormen zu sicherer Entwicklung und Schwachstellenbehandlung vom 30. August auf den 31. Oktober 2026, die produktspezifischen vertikalen Normen vom 30. Oktober auf den 31. Dezember 2026, und ein weiterer Satz horizontaler Normen wird für Oktober 2027 erwartet.
Behandeln Sie diese als vorgeschlagene, revidierte Daten und nicht als feststehende, und prüfen Sie den Status der Änderung, bevor Sie darauf planen.
Zwei Punkte zählen mehr als die genauen Daten. Erstens sind dies Fristen für Normungsgremien, der Kommission Entwürfe zu liefern, nicht die Daten, ab denen eine Norm für die Compliance nutzbar wird. Ein gelieferter Entwurf muss noch bewertet und dann im Amtsblatt zitiert werden, bevor er Ihnen etwas bringt. Zweitens durchlaufen die von ETSI entwickelten vertikalen Produktnormen noch die öffentliche Anhörung, deren Kommentierungsfenster bis Mitte November 2026 schließen. Das Bild ist eines aktiver Entwurfsarbeit, nicht fertiger Normen.
Was die Konformitätsvermutung tatsächlich verlangt
Hier ist der Mechanismus, den die Verzögerung betrifft, und der Grund, warum sie weniger dramatisch ist, als es klingt.
Nach Artikel 27 erhält ein Hersteller eine Konformitätsvermutung nur für Anforderungen, die von einer harmonisierten Norm abgedeckt sind, deren Fundstelle im Amtsblatt veröffentlicht wurde. Keine CRA-Norm hat diesen Punkt erreicht. Bis das geschieht, gibt es keine zitierte Norm, gegen die sich eine Vermutung stützen ließe, was eine praktische Folge dafür hat, wie manche Produkte Konformität nachweisen.
Für wichtige Produkte der Klasse I stützt sich der Selbstbewertungsweg nach Artikel 32 auf die Anwendung einer harmonisierten Norm, einer gemeinsamen Spezifikation oder eines qualifizierenden europäischen Cybersicherheits-Zertifizierungsschemas, das die grundlegenden Anforderungen abdeckt. Eine harmonisierte Norm ist nur eine dieser Grundlagen, sodass das Fehlen einer zitierten Norm diesen Weg einschränkt, ohne jeden Hersteller der Klasse I automatisch in eine Drittbewertung zu zwingen. Steht für ein Produkt keine dieser Grundlagen zur Verfügung, kann stattdessen ein Weg der Drittkonformitätsbewertung erforderlich sein.
Fallen Ihre Produkte in eine wichtige oder kritische Kategorie, klären Sie jetzt Ihre Klassifizierung und Ihren beabsichtigten Konformitätsweg, denn die Antwort prägt Zeitplan, Kosten und Nachweise. Beobachten Sie sowohl das Amtsblatt als auch die CRA-Normungsseite der Kommission auf die Fundstelle, die Ihre Optionen tatsächlich verändert.
Warum die Verzögerung Ihre SBOM-Arbeit nicht pausiert
Eine fehlende Norm ändert, wie Sie Konformität nachweisen. Sie ändert nicht, was die Verordnung von Ihnen verlangt zu bauen.
Die grundlegenden Anforderungen der CRA verlangen bereits, die Komponenten in Ihren Produkten zu identifizieren und zu dokumentieren. Anhang I, Teil II, Nummer 1 verlangt eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Teil II verlangt zudem, Schwachstellen unverzüglich zu behandeln, auch durch Sicherheitsupdates, und eine koordinierte Offenlegung von Schwachstellen vorzuhalten.
Nichts davon wartet auf eine EN-nummerierte Norm. Die Normen werden beschreiben, wie man es so umsetzt, dass es die Konformitätsvermutung begründet, aber die Pflicht, es zu tun, steht heute schon in der Verordnung.
Hier lohnt es, die Formulierung „mindestens die Abhängigkeiten der obersten Ebene" genau zu lesen. Sie ist eine Untergrenze, kein Ziel. Ein SBOM, das bei den Abhängigkeiten der obersten Ebene aufhört, erfüllt das wörtliche Minimum und übersieht dennoch das meiste, was ein Angreifer erreichen kann, weil die verwundbare Komponente meist tiefer im Abhängigkeitsbaum liegt. Teams, die das CRA-Minimum als Ziel behandeln, erzeugen konforme SBOMs, die die Schwachstellenbehandlung nicht wirklich stützen, die andere Pflicht gleich nebenan.
Die Arbeit, die normunabhängig und daher jetzt gefahrlos möglich ist, ist die substanzielle Arbeit: Produktrisikobewertung, genaue SBOM-Generierung, technische Dokumentation und ein funktionierender Prozess für Schwachstellenbehandlung und Meldung. Früh damit zu beginnen, ist der einzige Weg, bereit zu sein, denn nichts davon lässt sich in den Wochen vor Dezember 2027 aufbauen.
Die Meldepflicht gilt bereits
Die eine CRA-Pflicht, die überhaupt keinen Aufschub bietet, ist die Meldung. Seit dem 11. September 2026 löst eine aktiv ausgenutzte Schwachstelle in Ihrem Produkt eine Meldepflicht an die ENISA und Ihr nationales CSIRT aus, mit enger Uhr, über die ENISA-Plattform.
Diese Pflicht unter Druck zu erfüllen, hängt davon ab, schnell zu wissen, ob eine neu offengelegte Schwachstelle in einem ausgelieferten Produkt vorhanden und ausnutzbar ist und welche Versionen betroffen sind. Das ist eine SBOM-Frage und eine Frage der Ausnutzbarkeit, bevor es eine Meldefrage ist. Ein gepflegtes SBOM zusammen mit Ausnutzbarkeitsbewertungen, als VEX festgehalten, ist es, was Ihnen erlaubt, in Stunden zu antworten, statt die Analyse von Grund auf neu zu rekonstruieren, während die Uhr bereits läuft.
Das Inventar und die Bewertungen stützen die Analyse. Sie brauchen weiterhin einen Prozess, der entscheidet, wann Artikel 14 ausgelöst wird, Verantwortung zuweist und die Meldung fristgerecht einreicht.
Was jetzt zu tun ist
Während die Normen finalisiert werden, sind die produktiven Schritte diejenigen, die unabhängig vom endgültigen Text Bestand haben:
Erstellen Sie ein genaues SBOM für jedes Produkt im Geltungsbereich und gehen Sie über die Untergrenze der obersten Ebene hinaus zu den transitiven Komponenten, wo die echte Gefährdung sitzt.
Richten Sie einen Schwachstellenbehandlungsprozess ein und verbinden Sie ihn mit dem bereits aktiven ENISA-Meldeweg.
Halten Sie Ausnutzbarkeitsbewertungen aktuell, damit eine neue CVE nicht zur Hauruckaktion wird.
Prüfen Sie die vertikalen ETSI-Entwürfe und reichen Sie Kommentare ein, bevor die Anhörungsfenster schließen, sofern Ihre Produkte betroffen sind.
Klären Sie Ihre Produktklassifizierung und Ihren beabsichtigten Konformitätsweg.
Verfolgen Sie das Amtsblatt statt des Entwurfskalenders, denn die Fundstelle ist der Moment, in dem sich Ihre Optionen ändern.
Wo Interlynk hilft
Interlynk arbeitet an den beiden Teilen davon, die am schwersten richtig zu machen und am zeitaufwendigsten aufzubauen sind.
Der erste ist die Generierung. lynkctl erzeugt build-bewusste SBOMs für eingebettete und Firmware-Software und erfasst die eingebundenen, statischen und SDK-Komponenten, die ein Manifest der obersten Ebene nie aufzeichnet. Diese Tiefe ist es, die aus einem CRA-Minimal-SBOM eines macht, das die Schwachstellenbehandlung wirklich stützen kann.
Der zweite ist der Betrieb. Die Interlynk-Plattform nimmt SBOMs und CBOMs auf, bewertet sie auf Vollständigkeit und Qualität, führt eine Risikobewertung der Komponenten gegen Schwachstellendaten durch, verwaltet VEX-Aussagen und benachrichtigt Beteiligte, wenn sich die Gefährdung ändert. Das ist die Fähigkeit, die die Meldepflicht aus Artikel 14 stillschweigend voraussetzt.
Die Plattform arbeitet mit dem SBOM und CBOM, das ihr übergeben wird, und hält Generierung und Bewertung sauber getrennt.
Fazit
Die harmonisierten Normen der CRA sind spät dran, und das zählt für die Mechanik des Konformitätsnachweises. Es ändert nicht die Substanz dessen, was die Verordnung Softwareteams abverlangt, und es pausiert keine Meldepflicht, die bereits in Kraft ist.
Die Hersteller, die gut durch die nächsten vierzehn Monate kommen, werden die sein, die die Verzögerung als Zeit genutzt haben, die Grundlagen richtig zu legen: vollständige SBOMs, echte Schwachstellenbehandlung, einen funktionierenden Meldeweg. Die Normen werden kommen und den bevorzugten Weg beschreiben, es nachzuweisen. Die Arbeit, die sie beschreiben, ist Arbeit, die es wert ist, jetzt zu beginnen.
Quellen
cyberresilienceact.eu, „Current State of Play and Timeline (2026)"
cyberresilienceact.eu, „CRA standardisation deadlines pushed back two months"
Über Interlynk. Interlynk hilft Teams, SBOMs entlang der Software-Lieferkette zu erzeugen, zu verwalten und zu operationalisieren. lynkctl erzeugt build-bewusste SBOMs für eingebettete und Firmware-Software und erfasst eingebundene, statische und SDK-Komponenten mit präzisen Bezeichnern. Die Interlynk-Plattform nimmt SBOMs und CBOMs auf, bewertet sie auf Vollständigkeit und Qualität, führt Risikobewertungen von Komponenten durch, verwaltet VEX-Aussagen und benachrichtigt Teams, wenn sich die Gefährdung ändert.
Demo buchen · Kostenlos starten
Dieser Artikel dient der Information und stellt keine Rechts- oder Compliance-Beratung dar. Umsetzung, Normen und offizielle Leitlinien der CRA entwickeln sich weiter; prüfen Sie die aktuellen Anforderungen, Fristen und Ihre Produktklassifizierung anhand der Primärquellen und mit Ihrer eigenen Rechtsberatung.