Ein IoT-Gerät mit Sensorik und WLAN-Modul, eingebaut in eine Produktionslinie. Datenerfassung, drahtlose Übertragung, Auswertung auf einem Backend-System — technisch elegant, regulatorisch ein Minenfeld. Denn seit dem 1. August 2025 verlangt die Delegierte Verordnung (EU) 2022/30 von jedem Hersteller vernetzter Funkgeräte den Cybersecurity-Nachweis nach RED Artikel 3(3)(d), (e) und (f). Die harmonisierte Normenreihe EN 18031 definiert, wie dieser Nachweis aussieht.
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
Medizinprodukte, Luftfahrtausrüstung, Kfz-Komponenten und elektronische Mautsysteme sind explizit ausgenommen — für sie gelten eigene Regelwerke. Der Rest? Fällt unter EN 18031. Und dieser Rest ist breiter, als die meisten Entwicklungsabteilungen vermuten.
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 — Bedrohungsanalyse nach STRIDE
Das Bedrohungsmodell ist nicht frei wählbar. EN 18031 schreibt STRIDE vor, normativ verankert in Annex A. Sechs Kategorien, angewendet auf jeden identifizierten Asset:
| 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 |
Jede Bedrohung wird auf die zugehörigen EN-18031-Sicherheitsmechanismen gemappt — Tabelle A.2 der Norm liefert die Zuordnung. 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 hat ein Verfallsdatum. Der Cyber Resilience Act (EU 2024/2847) wird am 11. Dezember 2027 vollständig anwendbar — zeitgleich will die EU-Kommission die Delegierte Verordnung 2022/30 aufheben. Den Entwurf dafür hat sie im Februar 2026 vorgelegt.
Rund 70 % der EN-18031-Anforderungen finden sich im CRA wieder. Die Delta-Anforderungen — Vulnerability Handling Process nach EN 40000-1-3, SBOM-Pflicht, Lifecycle-Management mit definierten Supportzeiträumen — kommen obendrauf. Wer EN 18031 sorgfältig umsetzt, schafft sich eine belastbare Ausgangsbasis für den CRA. Wer abwartet, holt beides gleichzeitig nach. Ob das realistisch ist, darf bezweifelt werden.
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): Hier liegt der Sprengstoff. Erlaubt der Hersteller eine passwortlose Nutzung des Geräts, entfällt die Konformitätsvermutung für den gesamten Authentifizierungsmechanismus. Konsequenz: Eine Benannte Stelle muss eingebunden werden, Modul A reicht nicht mehr. Die Designentscheidung — erzwungene Passwortvergabe bei Erstinbetriebnahme — bestimmt den gesamten Zertifizierungspfad.
R3 — Elterliche Zugangskontrolle (nur EN 18031-2): Zielt auf Spielzeug und Kinderbetreuungsgeräte. Im industriellen Kontext irrelevant.
R4 — Secure Updates (nur EN 18031-3): Betrifft Geräte mit Finanzwertverarbeitung. Drittzertifizierung zwingend — für Industriegeräte typischerweise nicht einschlägig.
Für Industriegeräte steht und fällt alles mit R2. Verbietet der Hersteller die passwortlose Nutzung, bleibt Modul A (Selbstbewertung, RED Anhang II) möglich. Tut er es nicht, führt kein Weg an Anhang III oder IV vorbei — mit allem, was eine Benannte Stelle an Aufwand und Vorlaufzeit bedeutet.
Die EU-Kommission hat im Februar 2025 klargestellt: Normänderungen zur Beseitigung dieser Einschränkungen sind nicht geplant. Die Restrictions bleiben.
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 verbindliche Bewertungsmaßstab für Cybersecurity-Anforderungen vernetzter Funkgeräte. Wer seine Bewertung in diesem Fenster sauber abschließt, nimmt den Großteil der CRA-Anforderungen gleich mit. Wer auf den CRA wartet, steht ab Dezember 2027 vor der doppelten Aufgabe — unter Zeitdruck.
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.
Der zweite Aspekt wiegt schwerer als die meisten denken: 70 % der EN-18031-Bewertung fließen direkt in die spätere CRA-Konformität ein. Das ist keine Doppelarbeit — das ist Investitionsschutz.
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 →