MaKo-Sicherheit zum 1. April 2027: Warum Stadtwerke jetzt ein Zertifikatsinventar brauchen

Die Antwort zuerst: Zertifikate müssen als Betriebsobjekte geführt werden

Stadtwerke sollten die für den 1. April 2027 angekündigten Änderungen am sicheren Übertragungsweg nicht als kurzfristigen Austausch einzelner Dateien behandeln. Belastbar wird die Vorbereitung mit einem Zertifikatsinventar, das technische Identität, Marktpartner, Kommunikationsadresse, Verwendungszweck, unterstützte Merkmale, Laufzeit, verantwortliche Rolle und letzten erfolgreichen Test zusammenführt.

Die Bundesnetzagentur hat mit Mitteilung Nr. 58 am 1. Oktober 2026 die für den Umsetzungstermin 1. April 2027 relevanten Dokumente veröffentlicht. Für EDIFACT und API-Webdienste nennt die Mitteilung keinen neuen fachlichen Dokumentenstand. Beim XML-Redispatch beschreibt sie einen nur geringen Anpassungsbedarf. Die wesentliche betriebliche Änderung liegt in den Regeln zum sicheren Austausch von EDIFACT- und Redispatch-2.0-Prozessdaten, insbesondere bei der Zertifikatsnutzung für mTLS. Nach der Mitteilung kann dabei auch ein bereits für S/MIME eingesetztes Zertifikat relevant werden, sofern es die erforderliche Client-Authentication-EKU besitzt.

Das klingt zunächst nach einer technischen Detailfrage. In der Praxis berührt es jedoch Identitäten, Kommunikationsbeziehungen, Laufzeiten, Verantwortlichkeiten und Testfenster. Genau deshalb sollte die Vorbereitung nicht erst mit dem Einspielen eines Zertifikats beginnen.

S/MIME und mTLS erfüllen unterschiedliche Aufgaben

Für eine saubere Planung muss der Zweck getrennt werden. S/MIME schützt typischerweise Inhaltsdaten in der Nachricht: Signatur und Verschlüsselung helfen, Absender und Vertraulichkeit des Inhalts abzusichern. mTLS wirkt dagegen beim Aufbau der Transportverbindung. Beide Seiten weisen sich dabei über Zertifikate aus, bevor Daten übertragen werden.

Ein Zertifikat kann technisch mehrere Verwendungszwecke unterstützen. Daraus folgt jedoch nicht automatisch, dass jede bestehende S/MIME-Konfiguration ohne weitere Prüfung für Client-Authentifizierung geeignet ist. Entscheidend sind unter anderem die enthaltenen Merkmale, die Zuordnung zur technischen Identität, die Vertrauenskette, die Konfiguration der Gegenstelle und die vereinbarte Kommunikationsbeziehung.

Für Stadtwerke ist deshalb eine einfache Frage hilfreich: Welches Zertifikat beweist gegenüber welchem Marktpartner auf welcher Strecke welche Identität? Wenn diese Frage nur durch mehrere Teams und unverbundene Tabellen beantwortet werden kann, ist die Betriebsfähigkeit zum Stichtag unnötig fragil.

Was in ein Zertifikatsinventar gehört

Das Inventar sollte nicht zum geheimen Schlüsselspeicher werden. Private Schlüssel oder Passwörter gehören nicht in eine Arbeitsliste. Dokumentiert werden die für Betrieb und Steuerung notwendigen Metadaten. Dazu gehören mindestens:

• eindeutige Zertifikatskennung oder Fingerabdruck, ohne private Schlüssel offenzulegen,
• ausstellende Stelle und Vertrauenskette,
• gültig ab, gültig bis und geplanter Wechseltermin,
• unterstützte Verwendungszwecke, insbesondere die relevante Client-Authentifizierung,
• Marktrolle, Marktpartner-ID und technische Kommunikationsadresse,
• Einsatz für EDIFACT, Redispatch oder weitere klar abgegrenzte Strecken,
• verantwortliche interne Rolle und technischer Betreiber,
• Status in Test, Abnahme und Produktion,
• Datum und Ergebnis des letzten End-to-End-Tests.

Wichtig ist die Beziehung zwischen den Feldern. Ein Zertifikat ohne Partnerzuordnung ist ebenso wenig ausreichend wie eine Kommunikationsadresse ohne verantwortliche Rolle. Erst die Verknüpfung macht sichtbar, welche Strecke bei einem Ablauf, Austausch oder Konfigurationsfehler betroffen wäre.

Die Partnermatrix zeigt den tatsächlichen Umfang

Viele Unternehmen unterschätzen Umstellungen, weil sie Zertifikate zählen statt Kommunikationsbeziehungen. Ein einzelnes Zertifikat kann auf mehreren Strecken genutzt werden; zugleich können für dieselbe Marktrolle unterschiedliche Gegenstellen, Protokolle oder Betriebsdienstleister existieren. Eine Partnermatrix ergänzt deshalb das Inventar.

Pro Zeile wird eine konkrete Verbindung geführt: sendende Rolle, empfangende Rolle, technische Adresse, Transportweg, Prozessfamilie, produktives Zertifikat, Testzertifikat, Wechseltermin und Ansprechpartner auf beiden Seiten. Dadurch wird sichtbar, welche Gegenstellen früh getestet werden müssen und wo Abhängigkeiten zu Dienstleistern bestehen.

Die Matrix hilft auch bei der Priorisierung. Hohe Transaktionsmengen, betriebsrelevante Redispatch-Strecken, kurze Zertifikatslaufzeiten und mehrere beteiligte Betreiber erhöhen den Testbedarf. Seltene Verbindungen dürfen trotzdem nicht verschwinden; sie benötigen möglicherweise gerade deshalb einen geplanten Testfall, weil Fehler im Alltag lange unbemerkt bleiben.

Der Stichtag beginnt mit Rückwärtsplanung

Ein belastbarer Plan startet beim 1. April 2027 und arbeitet rückwärts. Vor dem Produktivwechsel braucht es ausreichend Zeit für Bestandsaufnahme, technische Bewertung, Beschaffung oder Ausstellung, Konfiguration, Partnerabstimmung, Test, Fehlerbehebung und erneuten Test. Zusätzlich sollte ein Sperrfenster definiert werden, in dem nur noch kontrollierte Änderungen an Kommunikationsadressen und Zertifikatszuordnungen erfolgen.

Die Rückwärtsplanung sollte nicht allein von der IT geführt werden. Marktkommunikation kennt die fachlichen Beziehungen und kritischen Nachrichtenwege. Informationssicherheit bewertet Zertifikats- und Vertrauensfragen. Betrieb und Dienstleister verantworten Konfiguration und Überwachung. Fachbereiche können beurteilen, welche Ausfälle besonders zeitkritisch wären.

Ein gemeinsamer Meilensteinplan verhindert, dass jede Rolle nur ihren eigenen Teil als erledigt meldet. Technische Installation ohne Partnerabnahme ist kein Ende. Ebenso wenig beweist ein erfolgreicher Verbindungsaufbau, dass der fachliche Datenaustausch vollständig funktioniert.

Kommunikationstests brauchen klare Beweise

Ein Test sollte mehr nachweisen als die Erreichbarkeit eines Endpunkts. Zweckmäßig ist eine gestufte Prüfung:

1. Zertifikat und Vertrauenskette werden von beiden Seiten erkannt.
2. Die mTLS-Verbindung wird mit der vorgesehenen technischen Identität aufgebaut.
3. Eine definierte Testnachricht wird übertragen und technisch quittiert.
4. Die Nachricht erreicht den vorgesehenen Folgeprozess und wird dort korrekt zugeordnet.
5. Fehlerfälle wie abgelaufenes, unbekanntes oder falsch zugeordnetes Zertifikat erzeugen die erwartete Meldung und Eskalation.

Als Nachweis genügen PII-arme technische Protokolle mit Zeit, Strecke, Testfall und Ergebnis. Echtdaten sind dafür nicht erforderlich. Entscheidend ist, dass ein späterer Prüfer erkennen kann, was getestet wurde und welche Aussage der Test erlaubt. Ein bloßer Screenshot mit grünem Symbol ist dafür meist zu schwach.

Wechsel und Rückfall müssen geübt werden

Zertifikatswechsel sind wiederkehrende Betriebsereignisse. Deshalb sollte der Rollout nicht nur den ersten Einsatz, sondern auch Erneuerung und Rückfall behandeln. Was passiert, wenn die Gegenstelle das neue Zertifikat noch nicht akzeptiert? Wie lange dürfen altes und neues Zertifikat parallel bekannt sein? Wer entscheidet über einen Rückfall, und wie wird verhindert, dass die Änderung auf einer Strecke andere Beziehungen beeinflusst?

Ein kontrollierter Wechsel besitzt ein Wartungsfenster, definierte Prüfschritte, Überwachung und eine klar begrenzte Rückfalloption. Nach dem Wechsel wird nicht nur die Verbindung, sondern auch der fachliche Eingang kontrolliert. Anschließend werden Inventar und Partnermatrix aktualisiert. Damit wird die Dokumentation Teil des Betriebs und nicht zur nachträglichen Rekonstruktion.

Fazit: mTLS ist ein Identitätsprozess

Die Änderungen zum 1. April 2027 lassen sich technisch umsetzen. Das größere Risiko liegt in unvollständigen Zuordnungen zwischen Zertifikat, Marktpartner, Adresse, Prozess und Verantwortung. Ein versioniertes Zertifikatsinventar, ergänzt um eine Partnermatrix und belegte End-to-End-Tests, macht diese Beziehungen beherrschbar.

Die Aussagegrenze bleibt wichtig: Welche konkrete Konfiguration für eine einzelne Verbindung erforderlich ist, muss anhand der geltenden Dokumente, der eingesetzten Systeme und der Partnervereinbarung geprüft werden. Der organisatorische Kern ist dennoch allgemein: Sichere Marktkommunikation entsteht nicht durch ein Zertifikat allein, sondern durch eine nachvollziehbare Identitäts- und Betriebsroutine.