Aktualisiert am 23. Juni 2026. Die frühere Fassung bezifferte die Überschneidung mit dem CRA pauschal auf 70 % und verwies dabei auf EN 40000-1-3. Da keine amtliche Zuordnungsmatrix diese Quote belegt, wurde sie entfernt. Präzisiert wurden außerdem die Bewertungswege nach RED Anhang II und Anhang III.
Ein IoT-Gerät mit Sensorik und WLAN-Modul, eingebaut in eine Produktionslinie. Datenerfassung, drahtlose Übertragung, Auswertung auf einem Backend-System — technisch elegant, regulatorisch anspruchsvoll. Seit dem 1. August 2025 aktiviert die Delegierte Verordnung (EU) 2022/30 für bestimmte Funkanlagen die Cybersecurity-Anforderungen aus RED Artikel 3(3)(d), (e) und (f). Die harmonisierte Normenreihe EN 18031 bietet einen freiwilligen Weg, um für die erfassten Anforderungen Konformitätsvermutung zu erreichen. Die im EU-Amtsblatt veröffentlichten Einschränkungen müssen dabei berücksichtigt werden.
Solche Geräte bewerte ich regelmäßig. Was dabei an Fragen, Entscheidungen und Stolpersteinen auftaucht, beschreibe ich hier — entlang des Phasenmodells, das ich in meiner Beratungspraxis einsetze. Die Beispiele sind typisch für vernetzte Industriegeräte mit Linux-Basis und Funkschnittstelle.
Wann greift EN 18031 — und wann nicht?
Die Normenreihe gliedert sich in drei Teile mit jeweils eigener Schutzrichtung:
- EN 18031-1:2024 — Netzwerksicherheit (Art. 3(3)(d)): Absicherung von Netzwerkwerten und Sicherheitswerten gegen unbefugten Zugriff, Manipulation, Denial-of-Service
- EN 18031-2:2024 — Datenschutz (Art. 3(3)(e)): Schutz personenbezogener Daten. Greift, sobald ein Gerät potenziell Personen erfassen kann — bei Geräten mit Kamera- oder Mikrofonsensorik im Produktionsumfeld also praktisch immer
- EN 18031-3:2024 — Betrugsschutz (Art. 3(3)(f)): Nur relevant, wenn das Gerät monetäre oder virtuelle Währungswerte verarbeitet. Für reine Industriesensorik: entfällt
Für bestimmte Produktgruppen und Funktionen gelten Ausnahmen oder eigene sektorale Regelwerke, darunter Bereiche der Medizinprodukte, Luftfahrt, Fahrzeuge und elektronischen Mautsysteme. Ob eine Funkanlage tatsächlich unter Artikel 3(3)(d), (e) oder (f) fällt, hängt von Produktart, Funktion und Datenverarbeitung ab. Eine pauschale Einordnung allein anhand eines Funkmoduls reicht nicht.
Häufig unterschätzt: Der Bewertungsumfang beschränkt sich nicht auf das Funkmodul allein. Erwägungsgrund 8 der VO 2022/30 formuliert unmissverständlich — sämtliche Aspekte und Teile der Funkanlage müssen die Anforderungen erfüllen. Bei einem typischen Embedded-Linux-Gerät erstreckt sich das auf WLAN, USB, GPIO, Sensor-Interfaces, Speichermedien und Debug-Ports (UART, JTAG). Alles im Scope. Keine Ausnahme.
Acht Phasen bis zum Konformitätsdossier
Eine EN-18031-Bewertung erledigt sich nicht mit einer Nachmittags-Checkliste. Der Prozess durchläuft acht aufeinander aufbauende Phasen — jede erzeugt ein dokumentiertes Deliverable, das ins abschließende Konformitätsdossier einfließt.
Phase 0 — Scoping und Bestandsaufnahme
Was genau wird bewertet? Die Frage wirkt banal. Ist sie nicht. Systemgrenzen ziehen: Hardware, Firmware, Softwarekomponenten — was gehört zum Bewertungsgegenstand, was liegt außerhalb? Kommunikationsschnittstellen katalogisieren. Betriebsszenarien erfassen: Normalbetrieb, Wartungsmodus, Erstinbetriebnahme, Außerbetriebnahme.
Die regulatorische Weichenstellung passiert bereits hier: Reicht Modul A — also Selbstbewertung durch den Hersteller? Oder erzwingt eine der Einschränkungen der Konformitätsvermutung die Einbindung einer Benannten Stelle? Mehr dazu weiter unten.
Phase 1 — Asset-Identifikation und -Klassifikation
EN 18031 operiert mit drei Asset-Kategorien:
- Sicherheitswerte: WLAN-PSK, SSH-Keys, kryptographische Schlüssel, Firmware-Signaturen, Konfigurationsdaten
- Netzwerkwerte: WLAN-Interface, TCP/IP-Stack, DNS-Resolver, sämtliche exponierten Dienste und Ports
- Datenschutzwerte (EN 18031-2): Sensordaten — sofern personenbeziehbar —, Metadaten mit Zeitstempeln und Standortinformationen
Klassifikation nach Vertraulichkeit, Integrität, Verfügbarkeit. Klingt nach Lehrbuch-CIA-Triade. Der Unterschied: Hier entsteht eine Asset-Matrix, die jedes einzelne Element den Normteilen zuordnet. Lücken in Phase 1 pflanzen sich durch alle Folgephasen fort — blinde Flecken inklusive.
Phase 2 — Strukturierte Bedrohungsanalyse
STRIDE ist für viele Funkgeräte ein brauchbarer Strukturrahmen, aber nicht die einzige denkbare Methode. Entscheidend ist eine nachvollziehbare Bedrohungsanalyse, die Assets, Angriffswege und die relevanten EN-18031-Mechanismen vollständig verbindet. In meiner Praxis nutze ich dafür häufig diese sechs Kategorien:
| Kategorie | Bedeutung | Beispiel (Industriegerät) |
|---|---|---|
| Spoofing | Identitätsdiebstahl | Gefälschte WLAN-Zugangspunkte |
| Tampering | Datenmanipulation | Sensordaten auf dem Übertragungsweg verfälscht |
| Repudiation | Abstreitbarkeit | Konfigurationsänderungen ohne Protokollierung |
| Information Disclosure | Informationspreisgabe | Sensordaten im Klartext übertragen |
| Denial of Service | Dienstverweigerung | WLAN-Deauthentication-Flooding |
| Elevation of Privilege | Rechteeskalation | SSH-Zugriff über werksseitiges Standardpasswort |
Die identifizierten Bedrohungen werden anschließend den einschlägigen EN-18031-Sicherheitsmechanismen zugeordnet. Am Ende steht keine abstrakte Risikoliste, sondern ein Katalog konkreter Prüfpunkte.
Phase 3 — Mechanismen-Bewertung
Die eigentliche Kernarbeit. EN 18031-1 definiert über 14 Sicherheitsmechanismen, die jeweils einen normativen Entscheidungsbaum durchlaufen:
- Anwendbarkeit: Hat das Gerät die Asset-Kategorie, die den Mechanismus auslöst?
- Angemessenheit: Passt der Mechanismus zu den identifizierten Bedrohungen?
- Implementierungsbewertung: Drei Stufen — Conceptual Assessment (Dokumentation), Functional Completeness (alle Assets abgedeckt?), Functional Sufficiency (praktischer Test)
Die Mechanismen nach EN 18031-1 im Überblick:
Zugriff und Authentifizierung:
- ACM (Access Control): Rollensysteme, Berechtigungsgranularität, Zugriffskontrolle auf SSH, Web-Interface, API-Endpunkte
- AUM (Authentication, 6 Teilanforderungen): Login-Verfahren, Passwort-Policy, Brute-Force-Schutz. Hier verbirgt sich eine der kritischsten Einschränkungen der Konformitätsvermutung — Clause 6.2.5
Sichere Kommunikation und Speicherung:
- SCM (Secure Communication, 4 Teilanforderungen): TLS/DTLS für die Datenübertragung, Zertifikatsvalidierung, Schutz der Steuerkommunikation
- SSM (Secure Storage, 3 Teilanforderungen): Verschlüsselung von Credentials auf dem Speichermedium, Schutz der Firmware-Partition
- CRY (Cryptography): TLS-Versionen, Schlüssellängen, Hash-Funktionen, Zufallszahlengenerator
Updates und Resilienz:
- SUM (Secure Update, 3 Teilanforderungen): Signaturprüfung vor Installation, Rollback-Schutz, Benachrichtigung über verfügbare Updates
- RLM (Resilience): Verhalten bei WLAN-Flooding, Ressourcenlimitierung, Watchdog, Wiederanlauf nach Absturz
- TCM (Traffic Control): Firewall-Regeln, Port-Filterung, Beschränkung ausgehender Verbindungen
Monitoring und Schlüsselverwaltung:
- NMM (Network Monitoring): Protokollierung von Verbindungsversuchen, Erkennung anomaler Muster
- CCK (Credential & Key Management, 3 Teilanforderungen): Schlüsselgenerierung, -rotation, -widerruf, sichere Erstauslieferung
Grundlegende Geräteeigenschaften (GEC-1 bis GEC-6):
- GEC-1: Minimierung der Angriffsfläche — offene Ports, unnötige Dienste eliminieren
- GEC-2: Vertraulichkeit gespeicherter Daten
- GEC-3: Integrität von Software und Firmware
- GEC-4: Schutz vor Auslesen sensibler Daten
- GEC-5: Sichere Standardkonfiguration ab Werk
- GEC-6: Manipulationsschutz — Hardware wie Software
Für den Datenschutz (EN 18031-2) kommen vier Mechanismen dazu: LGM (Logging, 4 Teilanforderungen), DLM (Data Deletion — sichere Löschung personenbezogener Daten auf dem Speichermedium), UNM (User Notification, 2 Teilanforderungen — Sensorstatus-Anzeige, Transparenz der Datenerfassung) und GEC-7 (Sensor-Dokumentation). Letzteres verlangt eine vollständige Beschreibung verbauter Sensoren: Erfassungsbereich, Art der erhobenen Daten, technische Spezifikation.
Bewertungsergebnis pro Mechanismus: Implementiert / Teilweise implementiert / Nicht implementiert / Nicht anwendbar.
Phase 4 — Gap-Analyse und Maßnahmenplan
Konsolidierung. Wo klaffen Lücken? Die Priorisierung folgt einer harten Logik: Einschränkungen der Konformitätsvermutung zuerst — sie entscheiden über das Bewertungsverfahren. Dann absteigend nach Risikokritikalität. Das Ergebnis: eine Maßnahmen-Roadmap mit technischen Umsetzungsempfehlungen, Aufwandsschätzungen und Abhängigkeiten zwischen den Maßnahmen.
Phase 5 — Praktische Verifikation
Papier ist geduldig. Phase 5 prüft am realen Gerät:
- WLAN-Sicherheit: Deauthentication-Angriffe, Evil-Twin-Szenarien, Sniffing der Datenübertragung
- Authentifizierung: Brute-Force gegen SSH und Web-UI, Session-Management, Passwort-Policy-Verifikation
- Netzwerk-Scan: Port-Scan, Service-Enumeration, Abgleich exponierter Dienste gegen GEC-1
- Firmware-Analyse: Extraktion über Speichermedium, Suche nach hardcodierten Credentials, Prüfung der Update-Signaturkette
- Kryptographie-Audit: TLS-Konfiguration, Cipher-Suites, Zertifikatsvalidierung, Zufallszahlengüte
- Physische Sicherheit: GPIO-Zugriff, JTAG/UART-Debug-Schnittstellen, Boot-Manipulation
Das Deliverable: ein technischer Testbericht mit Protokollen, Screenshots und Bewertung der Functional Sufficiency — pro Mechanismus, nachvollziehbar.
Phase 6 — Konformitätsdossier
Alle Phasenergebnisse münden in ein Konformitätsdossier. Die Struktur: Jede Normanforderung → Implementierungsnachweis → Testergebnis. Dazu der Entwurf der EU-Konformitätserklärung (DoC) und die technischen Unterlagen nach RED Anhang V. Kein Prüfer soll raten müssen, ob eine Anforderung erfüllt ist — die Nachvollziehbarkeit entscheidet.
Phase 7 — CRA-Ausblick
EN 18031 übernimmt derzeit eine Übergangsrolle. Der Cyber Resilience Act (EU 2024/2847) wird am 11. Dezember 2027 vollständig anwendbar. Die EU-Kommission hat 2026 einen Rechtsakt zur Aufhebung der Delegierten Verordnung 2022/30 im Zusammenhang mit diesem Übergang vorgelegt.
Zwischen EN 18031 und CRA bestehen deutliche technische Überschneidungen, etwa bei Zugriffsschutz, sicheren Updates, Kommunikation, Speicherung und Resilienz. Eine belastbare Prozentzahl lässt sich daraus ohne offizielle Zuordnungsmatrix nicht ableiten. Der CRA ergänzt außerdem Anforderungen an Schwachstellenbehandlung, Produktlebenszyklus, Supportzeiträume und technische Dokumentation. Eine saubere EN-18031-Umsetzung ist deshalb eine gute Ausgangsbasis, aber kein CRA-Konformitätsnachweis.
Einschränkungen der Konformitätsvermutung — wo es heikel wird
Die Harmonisierung der EN 18031 kam mit Vorbehalten. Der Durchführungsbeschluss (EU) 2025/138 benennt vier Einschränkungen, und ihre Konsequenzen reichen bis zur Wahl des Konformitätsbewertungsverfahrens:
R1 — Rationale/Guidance: Die erklärenden Normabschnitte begründen keine Konformitätsvermutung. Praxisauswirkung? Gering. Aber sauber dokumentieren.
R2 — Passwort-Policy (Clause 6.2.5.1/6.2.5.2): Erlaubt der Hersteller eine passwortlose Nutzung, greift die Konformitätsvermutung für den betroffenen Authentifizierungsmechanismus nicht vollständig. Dann reicht die interne Fertigungskontrolle nach RED nicht ohne Weiteres aus; für die nicht abgedeckten Anforderungen ist ein Konformitätsbewertungsverfahren mit Benannter Stelle zu prüfen.
R3 — Elterliche Zugangskontrolle (nur EN 18031-2): Zielt auf Spielzeug und Kinderbetreuungsgeräte. Im industriellen Kontext irrelevant.
R4 — Secure Updates (nur EN 18031-3): Diese Einschränkung betrifft den Betrugsschutz bei bestimmten Geräten mit Finanzwertverarbeitung. Soweit die harmonisierte Norm die einschlägige Anforderung nicht vollständig abdeckt, ist der passende RED-Konformitätsbewertungsweg mit Benannter Stelle zu prüfen.
Für viele Industriegeräte ist R2 besonders relevant. Die konkrete Folge hängt jedoch vom Produkt, den angewendeten Normteilen und der tatsächlichen Umsetzung ab. Diese Entscheidung gehört früh ins Scoping, weil ein Verfahren mit Benannter Stelle zusätzlichen Aufwand und Vorlauf erzeugt.
Zeitleiste: Was gilt ab wann?
| Datum | Ereignis |
|---|---|
| 1. August 2025 | Delegierte Verordnung (EU) 2022/30 verpflichtend anwendbar |
| 11. September 2026 | CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen |
| 11. Dezember 2027 | CRA vollständig anwendbar; VO 2022/30 wird aufgehoben |
Zwischen August 2025 und Dezember 2027 ist EN 18031 der zentrale harmonisierte Normenweg für die betroffenen RED-Cybersecurity-Anforderungen. Die Anwendung bleibt freiwillig; wer einen anderen technischen Weg wählt, muss die Erfüllung der grundlegenden Anforderungen anderweitig nachweisen. Eine EN-18031-Bewertung schafft zugleich technische Vorarbeit für den CRA, ersetzt dessen zusätzliche Pflichten aber nicht.
Drei Gründe, jetzt zu handeln
Seit August 2025 gilt: Ohne Cybersecurity-Konformitätsbewertung kein CE-Kennzeichen. Ohne CE kein EU-Marktzugang. So einfach ist die regulatorische Arithmetik.
Viele Prüffelder aus EN 18031 werden auch für den CRA gebraucht. Der Nutzen liegt in wiederverwendbaren Assets, Bedrohungsanalysen, Testnachweisen und Architekturentscheidungen — nicht in einer pauschalen Prozentzahl.
Und unabhängig von Paragraphen: Wer sein Gerät systematisch gegen STRIDE-Bedrohungen bewertet hat, kennt die Schwachstellen seiner Architektur. Nicht aus einem Pentest-Report, der im Schrank verstaubt, sondern aus einem strukturierten Prozess, der in die Produktentwicklung zurückwirkt. Das schützt vor unangenehmen Entdeckungen im Feld — und vor den Kosten, die damit einhergehen.
Du entwickelst ein vernetztes Produkt und brauchst eine Cybersecurity-Konformitätsbewertung nach EN 18031? Ich begleite den gesamten Prozess — vom Scoping über die Mechanismen-Bewertung bis zum fertigen Konformitätsdossier. Kontakt aufnehmen →