CRA in Energie & Smart-Metering

Wenn Ihr Zähler zur kritischen Komponente wird

Die Energiewirtschaft digitalisiert Erzeugung, Verteilung und Messung in einem Tempo, das noch vor wenigen Jahren undenkbar war: Smart-Meter-Gateways in Millionen Haushalten, Ladepunkt-Controller an jeder Straßenecke, Fernwirktechnik in Ortsnetzstationen, Wechselrichter mit dauerhafter Cloud-Anbindung. Jedes dieser Geräte ist ein „Produkt mit digitalen Elementen" (PDE) — und damit potenziell im Anwendungsbereich des Cyber Resilience Act (Verordnung (EU) 2024/2847). Für Hersteller und Importeure in diesem Sektor ist das kein akademisches Thema, sondern ein Eingriff mitten in ohnehin schon regulierungsdichte Produktentwicklung.

Der eigentliche Schmerz dieser Branche ist die Überlagerung der Regime. Ein Smart-Meter-Gateway (SMGW) durchläuft in Deutschland bereits eine BSI-Zertifizierung nach Schutzprofil und TR-03109 — ein aufwendiges, änderungsträges Verfahren. Nun tritt der CRA daneben, mit eigener CE-Kennzeichnung, eigener technischer Dokumentation, eigener Schwachstellen-Meldepflicht. Gleichzeitig sind Energieversorger als Betreiber unter NIS2 reguliert und geben Sicherheitsanforderungen an ihre Lieferanten weiter. Wer hier Geräte baut, jongliert mit mehreren Anforderungswelten, die sich überschneiden, aber nicht deckungsgleich sind.

Hinzu kommt die Realität langer Lebenszyklen: Ein Zähler oder eine Netzkomponente bleibt 10, 15 oder 20 Jahre im Feld. Der CRA verlangt Schwachstellenbehandlung über den gesamten Support-Zeitraum — bei Produkten, deren Firmware aus Zertifizierungsgründen kaum angefasst werden darf. Genau diese Spannung — hohe Sicherheitszertifizierung trifft auf CRA-Update-Erwartung — macht die Branche zu einem der anspruchsvollsten CRA-Fälle überhaupt. Dieser Beitrag ist eine fachliche Einordnung, keine Rechtsberatung.

Typische Produkte und ihre wahrscheinliche Anhang-III/IV-Einstufung

Der CRA teilt Produkte in drei Bänder: Standard (Selbstbewertung, Modul A), „wichtige" Produkte nach Anhang III (Klasse I und II) und „kritische" Produkte nach Anhang IV. Die Einordnung folgt der Sicherheitsfunktion, nicht dem Marketingnamen. Für den Energiesektor ergibt sich schematisch folgendes Bild — die konkrete Einstufung ist stets im Einzelfall zu prüfen:

Die technischen Beschreibungen der wichtigen und kritischen Kategorien präzisiert die Durchführungsverordnung (EU) 2025/2392. Der praktische Kern: Sobald eine notifizierte Stelle zwingend ist (Klasse II, Anhang IV), verlängert sich die Time-to-Market erheblich — die Kapazitätsplanung für die Konformitätsbewertung sollte früh beginnen.

Branchennormen und Abgrenzung zu angrenzenden Regimen

Der CRA formuliert Sicherheitsziele, keine Detailnormen — den Nachweis führen Sie über etablierte Standards. Für den Energiesektor sind das insbesondere:

• IEC 62443 — der Referenzrahmen für industrielle Automatisierungs- und Steuerungssysteme (Prozesse und Produktsicherheit).
• BSI TR-03109 — das deutsche Regime für Smart-Meter-Gateways inklusive Schutzprofil und technischer Richtlinie.
• IEC 62351 — Sicherheit für die Energie-Kommunikationsprotokolle (u. a. IEC 61850, DNP3).

Der CRA-Nachweis baut auf dieser Substanz auf — wer bereits nach TR-03109 zertifiziert und IEC-62443-konform entwickelt, hat einen erheblichen Vorsprung, muss aber die CRA-spezifischen Elemente (CE, EU-Konformitätserklärung, SBOM in der technischen Doku, CVD-Policy) ergänzen.

Wichtig ist die Abgrenzung zu Nachbarregimen: NIS2 adressiert den Betrieb wesentlicher/wichtiger Einrichtungen (Energieversorger) — nicht die Produkte selbst; als Hersteller sind Sie davon indirekt über Lieferantenanforderungen betroffen. Die RED-Delegierte-Verordnung 2022/30 greift für Funkgeräte (etwa funkende Zähler oder Wechselrichter mit Mobilfunkmodul) und überschneidet sich mit dem CRA — hier ist zu klären, welche Anforderungen wodurch abgedeckt werden. Kommt KI ins Spiel (z. B. Anomalieerkennung im Netz), kann perspektivisch der AI Act relevant werden. CRA, NIS2, RED und AI Act sind getrennte Rechtsakte und dürfen nicht gleichgesetzt werden.

SBOM und Lieferketten-Realität im Metering

Der typische Software-Stack eines Energiegeräts ist tief geschichtet: ein Embedded-Linux oder RTOS, eine kryptografische Bibliothek (OpenSSL, mbedTLS), ein TLS-Stack, Protokoll-Implementierungen (COSEM/DLMS, IEC 61850, OCPP bei Ladepunkten), oft ein Kommunikationsmodul mit eigenem Firmware-Blob. Genau hier lauern die Lieferketten-Risiken: End-of-Life-Komponenten, deren Upstream keine Patches mehr liefert, und Open-Source-Bibliotheken mit bekannten CVEs, die in änderungsträger, zertifizierter Firmware „eingefroren" sind.

Der CRA verlangt eine maschinenlesbare SBOM als Teil der technischen Dokumentation — mindestens auf Ebene der Top-Level-Abhängigkeiten. Konkret akzeptiert werden die Formate CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1 (BSI TR-03183-2, v2.1.0). Eine allgemeine Veröffentlichungspflicht besteht nicht — die SBOM ist gegenüber der Marktaufsicht vorzuhalten, nicht öffentlich zu publizieren.

Die Metering-Besonderheit: Jede SBOM-Aktualisierung und jedes Sicherheitsupdate muss mit dem Zertifizierungsstatus verträglich bleiben. Ein OpenSSL-Update, das anderswo eine Fingerübung ist, kann hier eine Re-Bewertung auslösen. Eine kontinuierlich gepflegte, in die CI/CD-Pipeline integrierte SBOM ist deshalb kein Bürokratie-Selbstzweck, sondern das Frühwarnsystem, das Ihnen sagt, welche der Millionen Feldgeräte von einem neuen CVE betroffen sind — die Voraussetzung für handhabbares Vulnerability-Management über 15 Jahre.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade korrekt umgesetzt

Ab dem 11.09.2026 gilt die Meldepflicht nach Artikel 14. Sie verlangt einen belastbaren PSIRT-/CVD-Prozess mit einer gestuften Kaskade — und die Fristen werden häufig falsch verkürzt:

• 24 Stunden — Frühwarnung ab Kenntnisnahme einer aktiv ausgenutzten Schwachstelle oder eines schweren Sicherheitsvorfalls.
• 72 Stunden — vollständige Meldung inklusive erster Korrektur- und Minderungsmaßnahmen.
• Abschlussbericht — hier trennt der CRA zwei Fälle: bei einer aktiv ausgenutzten Schwachstelle binnen 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme; bei einem schweren Sicherheitsvorfall binnen 1 Monat nach der 72-Stunden-Meldung.

Die pauschale Verkürzung auf „24 h / 72 h / 14 Tage" ist inhaltlich falsch — der Ein-Monats-Fall für schwere Vorfälle darf nicht untergehen. Gemeldet wird über die ENISA Single Reporting Platform (SRP) als Einmalmeldung an das zuständige CSIRT und ENISA. Die Plattform ist zum 11.09.2026 bereitzustellen; Mitte 2026 ist sie noch nicht voll operativ — der Prozess sollte trotzdem jetzt aufgesetzt und geprobt werden. Für Energiegeräte im Feld heißt das: definierte Eskalationswege zwischen Firmware-Team, Zertifizierungsverantwortlichen und Meldestelle, damit die 24-Stunden-Uhr nicht in internen Zuständigkeitsfragen verrinnt.

Welche Frist zuerst zählt: 11.09.2026 vs. 11.12.2027

Zwei Daten strukturieren die Vorbereitung. Der 11.09.2026 bringt die Melde- und Berichtspflichten nach Art. 14 — die erste harte Herstellerpflicht, unabhängig davon, ob Ihr Produkt schon vollständig CRA-konform ist. Der 11.12.2027 bringt die volle Anwendbarkeit aller Produktanforderungen: Security-by-Design, SBOM, technische Dokumentation, CE-Kennzeichnung, Konformitätsbewertung.

Für die Praxis heißt das: Zuerst die Meldefähigkeit. PSIRT, CVD-Policy und der Kaskaden-Prozess müssen 2026 stehen. Parallel läuft die längere Baustelle der Produktkonformität — gerade bei Anhang-IV-Produkten mit zwingender notifizierter Stelle, deren Bewertungskapazität knapp werden dürfte. Wer die Konformitätsbewertung erst 2027 startet, riskiert, keinen Slot mehr zu bekommen.

Durchgespieltes Szenario: ein SMGW-Hersteller

Ein mittelständischer Hersteller produziert ein Smart-Meter-Gateway, bereits BSI-zertifiziert nach TR-03109, im Feld bei mehreren Messstellenbetreibern. Der CRA trifft ihn an mehreren Stellen zugleich. Das SMGW ist als Anhang-IV-Produkt einzuordnen — eine notifizierte Stelle ist einzuplanen, und ein künftiges EU-Zertifizierungsschema ist im Blick zu behalten, das mit dem bestehenden BSI-Regime zu harmonisieren wäre.

Operativ baut er drei Dinge auf: Erstens eine maschinenlesbare SBOM (CycloneDX 1.6) aus dem Build-Prozess, die den vollständigen Stack von Embedded-Linux über die Krypto-Bibliothek bis zum DLMS/COSEM-Layer abbildet und in die technische Doku einfließt. Zweitens einen PSIRT-/CVD-Prozess, der die Art.-14-Kaskade (24 h / 72 h / 14 Tage bzw. 1 Monat) bedient und mit dem Zertifizierungsregime kompatibel ist — inklusive Regel, wann ein Sicherheitsupdate eine Re-Zertifizierung auslöst. Drittens die technische Dokumentation und EU-Konformitätserklärung, die er 10 Jahre aufbewahren muss. Sein Zeitplan: Meldeprozess bis September 2026 scharf, Konformitätsbewertung mit der notifizierten Stelle so früh wie möglich terminiert, damit der Dezember 2027 nicht zum Nadelöhr wird.

Was Blackfort Technology für Sie tut

Blackfort Technology begleitet Hersteller und Importeure im Energie- und Metering-Sektor entlang des gesamten CRA-Pfads — pragmatisch und auf die Eigenheiten zertifizierter, langlebiger Produkte gemünzt:

• Betroffenheits- und Scope-Analyse: Welche Ihrer Produkte sind PDE, welche fallen voraussichtlich unter Anhang III/IV, wo greifen RED oder NIS2 zusätzlich?
• SBOM-Setup: Aufbau einer maschinenlesbaren SBOM (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) direkt aus Ihrer Build-Pipeline, verträglich mit Ihrem Zertifizierungsstatus.
• PSIRT und CVD: Aufbau des Melde- und Schwachstellen-Handling-Prozesses inklusive korrekter Art.-14-Kaskade und ENISA-SRP-Anbindung.
• Risikobewertung und Threat-Modeling: die dokumentationspflichtige Risikoanalyse nach Art. 13 und Anhang I, methodisch fundiert.
• Technische Dokumentation: Struktur und Inhalte für Konformitätsbewertung und Marktaufsicht — inklusive Vorbereitung auf die notifizierte Stelle.

Ein guter erster Schritt ist unser Betroffenheits-Check. Für einen Überblick über Fristen und Pflichten siehe Cyber Resilience Act, für kleinere Hersteller die KMU-Seite. Sprechen Sie uns direkt an über Kontakt.