DIN EN 40000: Neuer CRA-Normenrahmen für Hersteller

Stand: 26. April 2026. Die Normenreihe DIN EN 40000 ist für Hersteller vernetzter Produkte deutlich wichtiger, als ihr nüchterner Titel vermuten lässt. Sie übersetzt Teile des Cyber Resilience Act in eine Arbeitslogik: Begriffe, Risikomanagement, Produktlebenszyklus, SBOM, Schwachstellenprozesse und Update-Kommunikation.

Wichtig ist die Einschränkung gleich am Anfang: Die mir vorliegenden Dokumente sind Norm-Entwürfe. Sie sind kein finaler harmonisierter Standard. Ich behandle sie deshalb als belastbaren Richtungsgeber, nicht als fertigen Konformitätsnachweis.

Trotzdem lohnt sich der Blick. Wer Produkte mit digitalen Elementen herstellt, sieht in DIN EN 40000 ziemlich klar, welche Nachweise später gefragt sein dürften. Nicht als Folienlogik. Als Arbeitsprodukte.

Welche Teile der DIN EN 40000 vorliegen

Ich habe für diesen Beitrag drei Entwürfe ausgewertet:

• DIN EN 40000-1-1:2026-03 - Vokabular
• DIN EN 40000-1-2:2026-03 - Grundsätze für die Cyberresilienz
• DIN EN 40000-1-3:2026-02 - Vulnerability Handling

Alle drei stammen aus dem Umfeld CEN/CLC/JTC 13 “Cybersecurity and Data Protection”. Die Entwürfe wurden im Kontext eines Normungsauftrags der Europäischen Kommission erstellt. Der Bezug zum Cyber Resilience Act ist damit kein Zufall, sondern ausdrücklich angelegt.

Der Zuschnitt ist sauber getrennt:

40000-1-1 schafft gemeinsame Begriffe. Ohne gemeinsame Sprache werden CRA-Projekte schnell unscharf.

40000-1-2 beschreibt den horizontalen Rahmen: Produktkontext, Risikomanagement, Cybersecurity-Aktivitäten, sichere Entwicklung, Verifizierung, Produktion, Überwachung, Außerbetriebnahme und Drittanbieterkomponenten.

40000-1-3 geht in die Tiefe beim Umgang mit Schwachstellen. Dort wird aus “Vulnerability Management” ein vollständiger Prozess: Vorbereitung, Eingang, Prüfung, Risikobewertung, Behebung, Veröffentlichung und Nachbereitung.

40000-1-1: Das Vokabular ist klein, aber nicht egal

Teil 1-1 ist kurz. Der Entwurf enthält Begriffe, die in der Normenfamilie wiederverwendet werden. Dazu gehören unter anderem:

• akzeptables beziehungsweise hinnehmbares Risiko
• Advisory
• Asset beziehungsweise Vermögenswert
• Authentizität, Vertraulichkeit, Integrität, Verfügbarkeit
• Remediation beziehungsweise Problembehebung
• Reporter
• Restrisiko
• Security Objective beziehungsweise Cybersicherheitsziel
• Software Package

Für Hersteller wirkt das zunächst unspektakulär. In Projekten ist es aber genau der Punkt, an dem Missverständnisse entstehen. Ein “Asset” ist nicht nur ein Server. Eine “Remediation” ist nicht immer nur ein Patch. Ein “Reporter” kann auch ein externer Sicherheitsforscher, ein Kunde, ein Koordinator oder eine Organisation sein.

Meine Einordnung: 40000-1-1 ist kein Umsetzungsleitfaden. Aber ohne dieses Vokabular werden die anderen Teile schwer sauber zu lesen sein.

40000-1-2: Cyberresilienz über den Produktlebenszyklus

Teil 1-2 ist der eigentliche Rahmen für Hersteller. Der Entwurf legt allgemeine Cybersicherheitsgrundsätze und Risikomanagement-Aktivitäten für Produkte mit digitalen Elementen fest. Er betrachtet ausdrücklich alle Phasen des Produktlebenszyklus.

Vier Prinzipien stehen vorne:

• risikobasiertes Cybersecurity-Konzept
• Security by Design
• Secure by Default
• Transparenz

Das klingt bekannt. Neu ist nicht die Überschrift, sondern die Art, wie daraus dokumentierbare Anforderungen werden.

Der Entwurf verlangt, dass der Hersteller den Produktkontext beschreibt. Dazu gehören der vorgesehene und vernünftigerweise vorhersehbare Verwendungszweck, die Produktfunktionen, die Betriebsumgebung, ein Architekturüberblick und die Beschreibung der Nutzer. Besonders relevant: Wenn eine Produktfunktion von einer Remote Data Processing Solution (RDPS) abhängt, muss diese Abhängigkeit in den Produktkontext hinein. Das Produkt wird dann einschließlich RDPS als Gesamtsystem betrachtet.

Das ist für viele Hersteller unbequem. Cloud-Portale, Telemetrie, Remote-Wartung, Lizenzserver, Update-Dienste oder Datenanalyse-Backends sind dann nicht mehr “irgendwo außerhalb”. Sie gehören in die Cybersecurity-Betrachtung, wenn Produktfunktionen davon abhängen.

Risikomanagement: nicht nur Matrix, sondern Nachweis

40000-1-2 baut das Risikomanagement in mehreren Schritten auf:

1. Produktkontext bestimmen
2. Risikoakzeptanzkriterien und Methodik festlegen
3. Assets und Cybersicherheitsziele identifizieren
4. Bedrohungen identifizieren
5. Risiken abschätzen und bewerten
6. Risiken behandeln
7. Restrisiken kommunizieren
8. Risikomanagement überwachen und überprüfen

Das ist nicht als einmalige Checkliste gemeint. Der Entwurf beschreibt Risikomanagement als Tätigkeit über den Lebenszyklus. Änderungen am Produkt, an der Bedrohungslage, am Stand der Technik oder an Komponenten können eine neue Bewertung auslösen.

Bei der Risikobehandlung setzt der Entwurf eine klare Rangfolge:

1. Risikovermeidung
2. Risikominderung
3. Risikoakzeptanz
4. Risikoübertragung

Ein Hersteller soll also nicht vorschnell Risiken an den Nutzer “wegkommunizieren”, wenn Vermeidung oder Minderung möglich sind. Wenn ein Risiko dem Produkt innewohnt und nicht sinnvoll beseitigt werden kann, muss es begründet und gegenüber dem Nutzer mit geeigneten Maßnahmen kommuniziert werden.

Für Maschinenbauer und Embedded-Hersteller ist das praktisch relevant. Ein Produkt kann auf eine abgesicherte Betriebsumgebung angewiesen sein. Dann muss genau diese Annahme dokumentiert und verständlich kommuniziert werden. Sonst wird aus einer technischen Annahme später eine Nachweislücke.

Sichere Implementierung: SBOM wird Arbeitsmittel

40000-1-2 behandelt sichere Implementierung nicht nur als Coding-Thema. Der Entwurf nennt unter anderem sichere Entwicklungsumgebung, sichere Programmierpraktiken, Umgang mit kryptografischen Schlüsseln, technische Dokumentation und Informationen für Nutzer.

Die SBOM taucht hier ausdrücklich auf. Sie ist in Teil 1-2 Teil der sicheren Implementierung und später auch für Schwachstellenüberwachung wichtig. Der Entwurf spricht davon, mindestens Top-Level-Abhängigkeiten und relevante Teile abzudecken, die für Vulnerability Monitoring qualifizieren.

Teil 1-3 wird hier konkreter. Dazu gleich mehr.

Wichtig: Wer heute keine reproduzierbare Komponentenliste hat, hat kein kleines Dokumentationsproblem. Er hat ein Prozessproblem. Ohne bekannte Komponenten kann ein Hersteller nicht belastbar prüfen, ob eine gemeldete Schwachstelle das eigene Produkt betrifft.

Verifizierung, Validierung und Tests

40000-1-2 beschreibt Verifizierung und Validierung als wiederkehrende Aktivität. Es geht nicht nur um den finalen Test kurz vor Release.

Genannt werden unter anderem:

• Review von Design- und Implementierungsartefakten
• Abgleich mit Anforderungen und Bedrohungsmodell
• Behandlung bekannter Schwachstellen in eigenen und Drittanbieterkomponenten
• Eingabevalidierung und Fehlerbehandlung
• Tests externer Schnittstellen und Protokolle
• Fuzzing
• Stresstests
• Penetrationstests
• Prüfung technischer Dokumentation und Nutzeranleitungen
• wiederkehrende Validierung und Verifizierung über den Lebenszyklus

Die Botschaft ist klar: CRA-Readiness entsteht nicht am Ende durch einen Bericht. Sie entsteht, wenn Security-Anforderungen, Architektur, Implementierung, Tests und Dokumentation zusammenpassen.

Drittanbieterkomponenten: Sorgfaltspflicht wird konkret

Ein starker Teil von 40000-1-2 ist Abschnitt 7.11 zu Drittanbieterkomponenten. Der Entwurf fordert, dass Auswahl und Integration solcher Komponenten mit gebotener Sorgfalt erfolgen, begründet und dokumentiert werden.

Dabei geht es nicht nur um Open Source. Gemeint sind auch kommerzielle Komponenten, Dienste und andere externe Bestandteile. Der Hersteller soll unter anderem prüfen, ob bekannte Schwachstellen vorliegen, ob regelmäßige Patches verfügbar sind, ob Schwachstellen offengelegt und behandelt werden, ob Supportzeiträume passen und ob zusätzliche Tests nötig sind.

Der informative Anhang B enthält dafür ein Beispiel eines Cybersecurity Supplier Agreement (CSSA). Dieses Beispiel ordnet Verantwortlichkeiten zwischen Hersteller und Lieferant zu: Komponenteninventar, Schwachstellenberichte, Restrisiken, Supportzeitraum, Teststrategie, CVD-Konzept, Update-Konzept, Schnittstellen zu CSIRT und Außerbetriebnahme.

Meine Einschätzung: Genau hier wird es im Mittelstand knirschen. Viele Hersteller kaufen Komponenten ein, aber sie kaufen nicht automatisch Security-Nachweise, Supportzusagen und Schwachstellenkommunikation mit ein. DIN EN 40000 zieht diese Lücke nach vorne.

40000-1-3: Vulnerability Handling als Pflichtprozess

Teil 1-3 ist der operativste Entwurf der drei Dokumente. Er stützt sich auf ISO/IEC 29147, ISO/IEC 30111 und ISO/IEC TR 5895, hebt aber bestimmte Empfehlungen auf Anforderungsebene, um CRA-Pflichten zu unterstützen.

Der Ablauf ist in Phasen gegliedert:

• Applicability
• Preparation
• Receipt
• Verification
• Remediation
• Release
• Post-Release

Das klingt trocken, ist aber für Hersteller sehr konkret.

In der Preparation-Phase verlangt der Entwurf eine interne Vulnerability-Handling-Policy und eine veröffentlichte CVD-Policy. Diese CVD-Policy muss einen Kontaktmechanismus enthalten und Erwartungen zur laufenden Kommunikation setzen. Außerdem wird operative Sicherheit behandelt: Nicht öffentliche Schwachstelleninformationen sollen geschützt und nur nach Bedarf zugänglich gemacht werden.

Ebenso in dieser Phase: Produktidentifikation, Softwarekomponenten, Hardwarekomponenten, SBOM, regelmäßige Tests und Reviews sowie Mechanismen für sichere Update- und Informationsverteilung.

SBOM nach 40000-1-3

Teil 1-3 macht die SBOM greifbarer:

• alle Softwarekomponenten im Produkt identifizieren und dokumentieren
• pro Komponente mindestens Hersteller beziehungsweise Producer, Name und Version erfassen
• eine SBOM mit mindestens Top-Level-Abhängigkeiten erstellen
• die SBOM strukturiert und maschinenlesbar bereitstellen
• bei neuem Build oder Release eine neue SBOM erzeugen
• SBOM-Metadaten wie Autor, Version und Zeitstempel erfassen
• pro Komponente Beziehungen und eindeutige Identifier erfassen, zum Beispiel CPE, PURL oder SWHID

Für riskantere Produkte sieht der Entwurf sogenannte Requirement Enhancements vor. Dann kann eine vollständigere SBOM inklusive transitiver Abhängigkeiten und Hash-Informationen relevant werden, soweit technisch machbar beziehungsweise vom Lieferanten bereitgestellt.

Das ist kein Nebensatz. Für Hersteller bedeutet es: SBOM muss in Build-, Release- und Schwachstellenprozesse integriert werden. Eine einmalig manuell gepflegte Excel-Liste wird diesen Anspruch kaum tragen.

Monitoring, Triage und Behebung

In der Receipt-Phase fordert 40000-1-3, dass interne und externe Quellen überwacht werden. Als externe Quelle nennt der Entwurf die EU Vulnerability Database und eingehende Reports. Intern verweist er auf regelmäßige Tests und Reviews. Außerdem sollen Drittanbieterkomponenten auf Supportende und Nutzung überwacht werden.

Bei eingehenden Informationen muss der Hersteller prüfen, ob Software- oder Hardwarekomponenten betroffen sein könnten. Die SBOM kann dafür als Automatisierungsbasis dienen.

In der Verification-Phase werden gemeldete Schwachstellen bewertet: Ist der Bericht ausreichend? Ist die Schwachstelle echt, reproduzierbar und auf das Produkt anwendbar? Danach wird das Risiko nach dem Rahmen aus 40000-1-2 bewertet und priorisiert. Wenn ein definierter Risikoschwellenwert überschritten wird, soll die Behebung beschleunigt werden.

In der Remediation-Phase entscheidet der Hersteller über die Behebung, plant die Maßnahmen, entwickelt die Remediation und testet sie. Sicherheitsupdates sollen, soweit technisch machbar, getrennt von Funktionsupdates bereitgestellt werden.

Release: Updates und Advisories

Die Release-Phase ist für CRA besonders wichtig. Der Entwurf fordert, dass Security Updates kostenlos bereitgestellt werden, sofern bei maßgeschneiderten Produkten zwischen Hersteller und gewerblichem Nutzer nichts anderes vereinbart wurde. Sobald ein Update bereitsteht, soll es zeitnah verteilt werden.

Der Update-Mechanismus muss Authentizität und Integrität sicherstellen. Wenn die Verteilung nicht vollautomatisch erfolgt, braucht der Nutzer Installationsanweisungen.

Zu behobenen Schwachstellen müssen Informationen veröffentlicht werden. Der Entwurf nennt dafür unter anderem Beschreibung, Vulnerability Identifier, betroffene Produkte, potenzielle Auswirkungen, Schweregrad, Remediation-Informationen sowie Release- und Update-Datum. Menschlich lesbar ist Pflicht. Maschinenlesbare Advisories sind als risikobasiertes Enhancement vorgesehen, mit CSAF als genanntem Format.

Auch hier gilt: Das ist kein reines PR-Thema. Wer Advisories veröffentlichen will, braucht vorher Produktidentifikation, Versionierung, SBOM, Tracking, Risikobewertung und Update-Mechanismen.

Was EN 40000 nicht ist

Ein Punkt darf im Blog über DIN EN 40000 nicht falsch dargestellt werden.

40000-1-2 sagt in Anhang C ausdrücklich, dass der Entwurf nicht mit der Absicht erstellt wurde, durch bloße Übereinstimmung mit seinen normativen Abschnitten eine Konformitätsvermutung mit den wesentlichen CRA-Anforderungen auszulösen. Für den Nachweis der Konformität sind weitere Maßnahmen erforderlich, etwa vertikale Normen oder ein Ansatz nach Anhang A.

40000-1-3 ist anders formuliert: Dort beschreibt Anhang ZA, dass nach einer Referenzierung im Amtsblatt der EU innerhalb des Normumfangs eine Konformitätsvermutung für die entsprechenden Anforderungen entstehen kann. Das ist aber an die spätere Amtsblatt-Listung gebunden.

Praktisch heißt das: Die Entwürfe sind heute sehr wertvoll für Vorbereitung und Gap-Analyse. Sie sind aber kein Freifahrtschein.

Was Hersteller jetzt vorbereiten sollten

Ich würde bei Herstellern nicht mit “Norm vollständig erfüllen” starten. Zu früh. Sinnvoller ist ein belastbarer Readiness-Block:

1. Produktkontext dokumentieren: inklusive RDPS, Betriebsumgebung, Nutzergruppen und vernünftigerweise vorhersehbarer Nutzung.
2. Risikomethodik festlegen: Risikoakzeptanzkriterien, Bewertungsmethode, Bedrohungsmodellierung und Dokumentationslogik.
3. SBOM-Prozess aufbauen: nicht als Einmaldokument, sondern als Teil von Build, Release und Monitoring.
4. Drittanbieter sauber erfassen: Komponenten, Supportzeiträume, Patchfähigkeit, Schwachstellenkommunikation und vertragliche Verantwortlichkeiten.
5. CVD und Vulnerability Handling einrichten: Kontaktweg, Tracking, Triage, Risikobewertung, Remediation, Advisory und Post-Release.
6. Update-Mechanismus prüfen: Authentizität, Integrität, Installationshinweise, automatische oder manuelle Verteilung.
7. Nachweise sammeln: technische Dokumentation, Testprotokolle, Architekturentscheidungen, Risikobehandlung und Nutzerinformationen.

Das ist für viele Hersteller der eigentliche Arbeitsumfang des CRA. Die Normenreihe macht ihn sichtbarer.

Meine Einschätzung

DIN EN 40000 verschiebt die Diskussion vom Gesetzestext in die Werkstatt. Nicht alles ist final. Nicht alles löst Konformitätsvermutung aus. Aber die Richtung ist klar genug, um nicht mehr zu warten.

Für Maschinenbauer, Embedded-Hersteller, IoT-Anbieter und Softwarehersteller ist der wichtigste Punkt nicht “Welche Normnummer muss ich zitieren?”. Der wichtigste Punkt ist: Kann ich belegen, dass mein Produktkontext, meine Risiken, meine Komponenten, meine Schwachstellenprozesse und meine Updates zusammenpassen?

Wenn die Antwort heute nein lautet, ist das kein Grund zur Panik. Aber es ist ein Grund, anzufangen.

---

Wenn Sie DIN EN 40000, CRA, SBOM und Vulnerability Handling für Ihre Produkte sauber einordnen wollen, finden Sie meine Leistung unter CRA & Maschinenverordnung. Ich unterstütze Hersteller und Maschinenbauer in Ulm, Neu-Ulm, Günzburg, Augsburg, Bayern und deutschlandweit.

---

Häufige Fragen zur DIN EN 40000

Quellenstand

Dieser Beitrag basiert auf den mir vorliegenden Norm-Entwürfen:

• DIN EN 40000-1-1:2026-03, insbesondere Abschnitte 1 bis 3
• DIN EN 40000-1-2:2026-03, insbesondere Abschnitte 1, 4, 5, 6, 7.2 bis 7.11 sowie Anhänge A, B, C und D
• DIN EN 40000-1-3:2026-02, insbesondere Abschnitte 1, 4, 5.1 bis 5.7 und Anhang ZA

Normtexte sind urheberrechtlich geschützt. Deshalb fasse ich die Inhalte hier fachlich zusammen und gebe keine längeren Normauszüge wieder.