NIS2 ist eine Richtlinie, die in vielen Organisationen vor allem als eine prozedurale Anforderung wahrgenommen wurde: Richtlinien, Register, Klassifikationen, Audits. Doch ihre tatsächliche Wirkung ist deutlich tiefgreifender – erst auf der Ebene der Kryptografie beginnt echte Compliance. Genau hier erwartet die Richtlinie den Nachweis, dass die Organisation moderne Bedrohungen versteht und in der Lage ist, die technische Sicherheit auf einem „State-of-the-Art“-Niveau zu halten.

Warum?
Weil TLS, Zertifikate, Schlüssel und Verschlüsselungsprotokolle die direkte Verbindungslinie zwischen der Organisation und ihren Nutzern, Partnern, Kunden und internen Systemen darstellen. Wenn diese Schicht schwach ist, schützt keine Dokumentation die Organisation vor einem Vorfall – und schon gar nicht vor regulatorischer Verantwortung. NIS2 sagt nicht ausdrücklich „verwende TLS 1.3“, aber das Endergebnis ist klar: Unternehmen müssen nachweisen, dass ihre Kryptografie dem aktuellen Bedrohungsniveau entspricht.

SSL/TLS als Bestandteil der Compliance, nicht als Serverkonfiguration.

In vielen Unternehmen ist SSL/TLS etwas, das „irgendwann einmal jemand konfiguriert hat“. Das Zertifikat wurde installiert, die Kommunikation funktioniert, das Schlosssymbol ist da – Thema erledigt. NIS2 kehrt diese Logik um: SSL/TLS ist keine technische Nebensächlichkeit mehr, sondern wird zu einem Maß für operative Reife. Das bedeutet die Notwendigkeit der kontinuierlichen Überwachung, Wartung und Überprüfung, ob die verwendeten Konfigurationen:

• keine veralteten Algorithmen nutzen,
• vollständig mit aktuellen Branchenempfehlungen übereinstimmen,
• eine ausreichende Widerstandsfähigkeit gegenüber modernen Bedrohungen gewährleisten,
• zukunftsfähig sind – denn NIS2 richtet den Blick ebenfalls auf kommende Entwicklungen.

Wichtig: Compliance ist nicht binär. Ein Auditor sucht nicht nach einer Liste von Protokollen, sondern nach dem Nachweis, dass das Unternehmen einen Prozess und Kontrolle über die Kryptografie besitzt.

Das minimale SSL/TLS-Profil für NIS2.

Organisationen fragen häufig: „Welches SSL/TLS-Profil ist NIS2-konform?“ Es gibt keine offizielle Vorlage, aber es existiert eine Art Marktstandard, der sich aus CA/B Forum, BSI, ENISA, OWASP und der Praxis des Finanzsektors ableitet.

Ein Mindestset, das sich realistisch in einem Audit verteidigen lässt:

• TLS 1.3 als Hauptprotokoll, TLS 1.2 nur für Kompatibilität.
• Deaktivierung von TLS 1.0-1.1, da sie modernen Angriffen nicht standhalten.
• AEAD-Algorithmen (AES-GCM, ChaCha20-Poly1305), da sie Integrität und Vertraulichkeit gewährleisten.
• RSA ab 3072 Bit oder ECDSA P-256/P-384, da kürzere Schlüssel praktisch nicht vertretbar sind.
• Kein SHA-1 in irgendeinem Teil der Kette – auch nicht in Zwischenzertifikaten.
• Pflicht-SAN, da CN von Browsern seit Jahren ignoriert wird.

Beachten Sie, dass jede dieser Positionen eine konkrete Begründung hat. Ein NIS2-Auditor fragt nicht „was ist aktiviert?“, sondern:

• „warum?“
• „wie überwachen Sie das?“
• „können Sie es ändern, wenn ENISA morgen eine neue Empfehlung veröffentlicht?“

TLS/PKI-Inventarisierung – das Fundament, ohne das jede Compliance zusammenbricht.

NIS2 verlangt, dass Organisationen vollständige Transparenz darüber haben, was in ihrer Umgebung aktiv ist. Im Kontext von SSL/TLS bedeutet das die Erkennung nicht nur öffentlicher Websites, sondern der gesamten verschlüsselten Kommunikation, einschließlich:

• interner und externer APIs,
• Mikroservices,
• Partnerintegrationen,
• B2B-Lösungen,
• Admin-Panels,
• Tunneln und Kommunikationsbrokern,
• Legacy-Diensten, an die sich „niemand erinnert“.

Eine vollständige PKI/TLS-Karte ermöglicht es:

• risikoreiche Konfigurationen zu erkennen,
• Zertifikatslaufzeiten zu kontrollieren,
• zu bewerten, welche Systeme dringende Maßnahmen erfordern,
• einen realistischen Migrationsplan zu erstellen.

Dieser Schritt ist unverzichtbar – ohne ihn bewegt sich jede Organisation „blind“.

Zertifikatsverwaltung: Unter NIS2 ist der Prozess wichtiger als das Tool.

Unternehmen konzentrieren sich häufig darauf, ob sie ACME nutzen, Zertifikate überwachen oder ein Erneuerungspanel haben. Das ist wichtig, aber NIS2 geht tiefer – es verlangt den Nachweis, dass die Organisation den Lebenszyklus von Schlüsseln und Zertifikaten beherrscht.

Ein reifer Prozess sollte daher enthalten:

• ein Register aller Zertifikate,
• Überwachung von Ablauf, Kettenfehlern und Konfigurationen,
• eine Nutzungsrichtlinie (wann Wildcard, wann EV, wann internes Zertifikat),
• Automatisierung dort, wo menschliche Fehler das größte Risiko darstellen,
• regelmäßige TLS-Konfigurationsüberprüfungen.

Das ist keine „gute Praxis“ mehr – es ist eine Compliance-Voraussetzung.

Private Schlüssel – der Abschnitt, den NIS2-Auditoren besonders streng prüfen.

Kein Element der PKI ist so kritisch wie der private Schlüssel. NIS2 behandelt seinen Schutz als absolutes Fundament, denn seine Kompromittierung bedeutet:

• Übernahme der Domainidentität,
• Möglichkeit von Echtzeit-MITM-Angriffen,
• Verlust des Vertrauens von Partnern und Regulatoren,
• Meldepflicht eines Vorfalls,
• finanzielle und operative Konsequenzen.

Daher müssen Organisationen nachweisen:

• wo die Schlüssel generiert werden,
• wie sie gespeichert werden,
• welche Berechtigungen sie haben,
• wie die Rotation erfolgt,
• wer Zugriff hat,
• welche Mechanismen eine unautorisierte Nutzung erkennen.

Hier gibt es keinen Platz für halbe Lösungen – Auditoren prüfen diesen Bereich sofort.

Crypto Agility und PQC – NIS2 blickt weiter in die Zukunft als jede frühere Regulierung.

Hier beginnt der spannendste Teil. NIS2 verlangt noch keine post-quantenfesten Zertifikate, aber es verlangt, dass Organisationen Sicherheit in einer jahrelangen Perspektive – nicht in Monaten planen.

Das bedeutet die Berücksichtigung von:

• Widerstand gegen „harvest now, decrypt later“,
• Migrationsplänen zu ECDHE + ML-KEM (hybrides SSL/TLS),
• Einführungszeitplänen für PQTLS in hochsensiblen Systemen,
• Übereinstimmung mit Roadmaps von CAs, CDNs und Cloud-Anbietern,
• Infrastrukturbereitschaft (OpenSSL 3.x, PQC-fähige TLS-Bibliotheken).

Crypto Agility – die Fähigkeit, Algorithmen schnell auszutauschen – wird zu einer der zentralen Compliance-Anforderungen.

Ein realer NIS2-Aktionsplan.

Die erfolgreichsten Organisationen verfolgen ein Fünf-Phasen-Modell:

1. Discovery: vollständige TLS/PKI-Karte, alle Endpunkte, alle Zertifikate, gesamte Kommunikation.
2. Assessment: Analyse von Risiken, Schlüssellängen, Protokollen, Ketten, Konfigurationen.
3. Baseline: Erstellung eines einheitlichen TLS-Profils für das gesamte Unternehmen.
4. Automation: ACME, CA-APIs, Schlüsselrotation, Konfigurations- und Ablaufüberwachung.
5. PQC Ready: Roadmap zu ECDHE + ML-KEM, Vorbereitung auf PQTLS und hybride Zertifikate.

Das ist genau das, was NIS2 erwartet – unabhängig von der Unternehmensgröße.

Die häufigsten Fehler von Organisationen.

Dies sind keine theoretischen Fehler – es sind reale Beispiele, die zu negativer Compliance geführt haben:

• Fokus auf Dokumentation statt Serverkonfiguration,
• Ignorieren von APIs und internen Diensten, die mit TLS 1.0/1.1 laufen,
• fehlende Zertifikatsautomatisierung und wiederkehrende Ablaufvorfälle,
• private Schlüssel, die in Serververzeichnissen gespeichert sind,
• keine Kryptostrategie für die nächsten 5 Jahre,
• vollständige Blindheit gegenüber PQC und HNDL-Bedrohungen.

Jeder dieser Punkte untergräbt die Compliance.

Man kann vorbildliche Verfahren, Risikoanalysen und Sicherheitsrichtlinien haben – aber wenn TLS, Zertifikate und Schlüssel vernachlässigt werden, wird ein NIS2-Audit dies aufdecken. Kryptografie wird zum Beweis dafür, ob eine Organisation Sicherheit wirklich lebt oder nur behauptet. NIS2 übertreibt nicht – es verlangt lediglich, dass Kryptografie ernst genommen wird. Und das bedeutet:

• reifes SSL/TLS,
• sichere Schlüssel,
• Automatisierung,
• Monitoring,
• Krypto-Agilität,
• Vorbereitung auf PQC.