NIS2 Maßnahme 8 — Kryptografie und Verschlüsselung

NIS2 Maßnahme 8 — Kryptografie und Verschlüsselung

Letzte Aktualisierung: 21. März 2026

Die NIS2-Maßnahme 8 gemäß Art. 21 Abs. 2 Buchst. h der Richtlinie (EU) 2022/2555 verpflichtet betroffene Unternehmen, Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung zu implementieren. Für NIS2 Verschlüsselung bedeutet das praktisch: AES-256 für schutzbedürftige Daten im Ruhezustand, TLS 1.3 bevorzugt für Daten in Bewegung, dokumentiertes Schlüsselmanagement und Orientierung an der BSI TR-02102 als Stand der Technik.

Damit ist Kryptografie unter NIS2 keine isolierte IT-Einstellung, sondern ein Governance-Thema. Ihr Unternehmen muss festlegen, welche Daten und Systeme verschlüsselt werden, welche Algorithmen zulässig sind, wo Schlüssel liegen, wie Zertifikate überwacht werden und wie Sie mit veralteten Verfahren umgehen. Wer zuerst die Gesamtlogik der NIS2-Maßnahmen einordnen will, sollte ergänzend NIS2 Maßnahme 1 zur Risikoanalyse, NIS2 Maßnahme 9 zur Zugangskontrolle und die NIS2-Checkliste lesen.

Die Management-Relevanz ist hoch, weil Verschlüsselung nicht nur Vertraulichkeit schützt. Schwaches Schlüsselmanagement, abgelaufene Zertifikate oder veraltete TLS-Konfigurationen können Verfügbarkeit, Integrität und Meldefähigkeit direkt beeinträchtigen. Genau deshalb gehört Maßnahme 8 in dieselbe Steuerungslogik wie Incident Response, Zugriffsschutz und Business Continuity.

Was verlangt Art. 21(2)(h) NIS2 zur Kryptografie?

Art. 21 Abs. 2 Buchst. h NIS2 verlangt keine starre Liste einzelner Produkte, sondern "Konzepte und Verfahren für den Einsatz von Kryptografie und gegebenenfalls Verschlüsselung". Der entscheidende Punkt ist deshalb nicht, ob Sie irgendwo Verschlüsselung aktiviert haben, sondern ob ein belastbares, dokumentiertes und risikobasiertes Kryptografie-Konzept existiert.

Für die Praxis ergeben sich daraus mindestens fünf Pflichten. Erstens brauchen Sie eine schriftliche Festlegung, wann Daten im Ruhezustand und wann Daten in Bewegung verschlüsselt werden. Zweitens müssen Sie Standards definieren, die dem Stand der Technik entsprechen. Drittens müssen Schlüssel über ihren gesamten Lebenszyklus gesteuert werden. Viertens müssen Zertifikate und Vertrauensketten beherrscht werden. Fünftens müssen Ausnahmen dokumentiert, begründet und regelmäßig überprüft werden.

NIS2 ist dabei bewusst technologieneutral. Die Richtlinie schreibt nicht ausdrücklich "TLS 1.3" oder "AES-256" vor, verlangt aber state of the art, Proportionalität und Wirksamkeit. Genau an dieser Stelle werden technische Richtlinien wie die BSI TR-02102 relevant. Sie übersetzen die abstrakte Rechtsanforderung in konkrete Mindeststandards für Algorithmen, Schlüssellängen und Einsatzszenarien.

Wichtig ist auch die Abgrenzung: NIS2 Art 21 2 h verlangt nicht nur Vertraulichkeit. Kryptografie betrifft ebenfalls Integrität, Authentizität und Nachweisbarkeit. Digitale Signaturen, Hashverfahren, Zertifikatsketten und Schlüsselrotation sind deshalb genauso Teil des Themas wie klassische Festplatten- oder Datenbankverschlüsselung.

Unternehmen sollten Maßnahme 8 außerdem nicht isoliert umsetzen. Kryptografie greift unmittelbar in NIS2 Maßnahme 1 zur Risikoanalyse ein, weil nur eine saubere Klassifizierung zeigt, welche Daten und Systeme besonders schutzbedürftig sind. Ebenso besteht eine enge Verbindung zu NIS2 Maßnahme 9 zur Zugangskontrolle, denn verschlüsselte Daten helfen wenig, wenn Schlüssel und Zertifikate unkontrolliert zugänglich sind.

Verschlüsselungsstandards: AES-256, TLS 1.3, Ende-zu-Ende

Für NIS2 Kryptografie brauchen Unternehmen einen klaren technischen Mindeststandard. In der Praxis hat sich für ruhende Daten AES-256 als robuster Standard etabliert. Das gilt für Datenbanken, Dateiserver, Backups, virtuelle Maschinen, Endgeräte und portable Medien. Entscheidend ist jedoch nicht nur der Algorithmus, sondern auch der sichere Betriebsmodus, die Schlüsselverwaltung und die Frage, ob die Verschlüsselung tatsächlich den relevanten Datenpfad schützt.

Für Daten in Bewegung ist TLS heute der Kernstandard. TLS 1.2 ist in vielen Umgebungen noch das absolute Minimum, TLS 1.3 sollte aber bevorzugt werden, weil es veraltete Verfahren entfernt, Konfigurationen vereinfacht und die Angriffsfläche reduziert. Wer 2026 noch auf TLS 1.0 oder TLS 1.1 angewiesen ist, hat kein Stand-der-Technik-Niveau mehr erreicht.

Auch die Cipher Suites sind kein Detailthema. Schwache Verfahren wie RC4, DES, MD5 oder SHA-1 in Signaturkontexten gehören nicht mehr in eine NIS2-konforme Umgebung. Empfehlenswert sind moderne Verfahren wie TLS_AES_256_GCM_SHA384 oder TLS_CHACHA20_POLY1305_SHA256 unter TLS 1.3 sowie ECDHE-basierte Suites mit Forward Secrecy unter TLS 1.2.

Ende-zu-Ende-Verschlüsselung ist nicht überall Pflicht, aber in besonders sensiblen Kommunikationsszenarien oft sinnvoll. Bei E-Mail-Kommunikation mit vertraulichen Inhalten, bei Austausch personenbezogener Sonderkategorien oder bei externen Freigabeprozessen kann reine Transportverschlüsselung zu wenig sein. Dann kommen S/MIME oder OpenPGP sowie ende-zu-ende abgesicherte Kollaborationskanäle ins Spiel.

Für die Praxis hilft eine einfache Hierarchie:

1. Transportverschlüsselung ist der Mindeststandard für alle sensiblen externen und internen Verbindungen.
2. Speicherverschlüsselung ist der Mindeststandard für vertrauliche Daten, Backups und mobile Endgeräte.
3. Ende-zu-Ende-Verschlüsselung ist dort sinnvoll, wo Transport- und Plattformverschlüsselung allein nicht ausreichen.
4. Hashverfahren und digitale Signaturen sind erforderlich, wenn Integrität und Authentizität abgesichert werden müssen.

Die typische Fehlannahme lautet, dass "HTTPS aktiv" bereits das Kryptografie-Konzept ersetzt. Das ist fachlich zu kurz. Ein belastbares Konzept beschreibt auch interne APIs, Administratorzugänge, VPNs, Datenbankverbindungen, Mailserver, Backup-Prozesse, Maschinenkommunikation und Altanwendungen. Gerade in mittelständischen Landschaften liegen hier oft die größten Lücken.

Key Management: Schlüsselerzeugung, Rotation, Speicherung

Schlüsselmanagement ist der eigentliche Reifegradtest für NIS2 Verschlüsselung. Ein Unternehmen kann starke Algorithmen benennen und trotzdem an der Praxis scheitern, wenn Schlüssel in Skripten liegen, gemeinsam genutzt werden, nie rotiert werden oder nach Personalwechseln unkontrolliert fortbestehen.

Der Lebenszyklus eines kryptografischen Schlüssels beginnt bei der Erzeugung. Schlüssel müssen mit kryptografisch sicheren Zufallsquellen erstellt werden, dürfen nicht aus einfachen Passwörtern abgeleitet sein und sollten nur in kontrollierten Umgebungen entstehen. Bereits hier muss dokumentiert sein, wofür der Schlüssel dient, wer Eigentümer ist, welches Verfahren genutzt wird und welche Laufzeit vorgesehen ist.

Die Speicherung ist der zweite kritische Punkt. Hochwertige Schlüssel gehören in Hardware Security Modules, spezialisierte Key-Management-Systeme oder etablierte Cloud-KMS-Dienste. Was nicht akzeptabel ist: produktive Schlüssel im Quellcode, in ungeschützten Konfigurationsdateien, in allgemeinen Wiki-Seiten oder in gemeinsam genutzten Postfächern.

Die Rotation ist der dritte Prüfstein. Symmetrische Schlüssel sollten mindestens regelmäßig und anlassbezogen erneuert werden, API-Secrets deutlich häufiger. Asymmetrische Schlüssel und Zertifikate folgen längeren Zyklen, müssen aber bei Kompromittierung, Personalwechsel oder technischer Schwächung sofort ersetzt werden können. Ein Schlüssel, der zwar "stark" ist, aber fünf Jahre lang unangetastet bleibt, erzeugt unnötiges Risiko.

Die Vernichtung und der Entzug sind der vierte Prüfstein. Wenn ein Administrator das Unternehmen verlässt, ein Dienst außer Betrieb geht oder ein Verdacht auf Kompromittierung besteht, muss klar sein, wie Schlüssel widerrufen, ausgetauscht und sicher entfernt werden. Auch Backup-Schlüssel und Archivkopien müssen in diesen Prozess einbezogen werden.

Ein praxistaugliches Minimalmodell für KMU umfasst:

Wer Schlüsselmanagement sauber organisiert, verbessert nicht nur Compliance, sondern auch Wiederherstellbarkeit im Vorfall. Genau hier schließt sich der Kreis zur NIS2-Checkliste, weil Kryptografie ohne dokumentierte Prozesse nicht auditierbar ist.

Daten im Ruhezustand vs. Daten in Bewegung verschlüsseln

Die Unterscheidung zwischen Daten im Ruhezustand und Daten in Bewegung ist für Verschlüsselung Pflicht NIS2 zentral. Beide Schutzformen adressieren unterschiedliche Risiken und ersetzen sich nicht gegenseitig.

Daten im Ruhezustand umfassen alles, was gespeichert ist: Datenbanken, Dateifreigaben, Endgeräte, Sicherungen, Archivsysteme, Cloud-Speicher und virtuelle Maschinen. Hier schützt Verschlüsselung vor unbefugtem Zugriff nach Diebstahl, Verlust, Fehlkonfiguration oder Medienkompromittierung. Typische Maßnahmen sind Vollverschlüsselung von Notebooks, Datenbankverschlüsselung, verschlüsselte Backups und Schutz sensibler Dateiserver.

Daten in Bewegung umfassen alle Übertragungswege: Webverkehr, APIs, E-Mail-Transport, VPN-Verbindungen, Maschinenkommunikation, Datenbankreplikation und administrative Fernzugriffe. Hier schützt Verschlüsselung gegen Mitlesen, Manipulation und Man-in-the-Middle-Angriffe. Typische Maßnahmen sind TLS für Web- und API-Kommunikation, IPsec oder TLS-basierte VPNs, SSH mit modernen Schlüsseln und abgesicherte Mail-Transportwege.

Die häufigste Fehlentscheidung ist einseitiger Fokus. Manche Unternehmen verschlüsseln Festplatten, lassen aber interne APIs oder Datenbankverbindungen im Klartext laufen. Andere aktivieren TLS nach außen, speichern Backups jedoch unverschlüsselt auf externen Medien. Beides ist unter NIS2 zu schwach, weil das Schutzniveau entlang des gesamten Datenlebenszyklus konsistent sein muss.

Eine praktikable Priorisierung sieht so aus:

1. Kritische Endgeräte und mobile Datenträger vollständig verschlüsseln.
2. Backups mit demselben oder höherem Schutzniveau wie Produktionsdaten sichern.
3. Externe und interne Verbindungen mit TLS 1.2 mindestens, möglichst TLS 1.3 absichern.
4. Besonders sensible Kommunikationsinhalte zusätzlich Ende-zu-Ende schützen.
5. Unverschlüsselte Legacy-Verbindungen identifizieren, bewerten und mit Migrationsplan hinterlegen.

Die Risikoperspektive bleibt entscheidend. Nicht jede Datei braucht dieselbe Schutzklasse, aber jede Ausnahme braucht eine nachvollziehbare Begründung. Gerade bei Altanwendungen sollten Sie dokumentieren, warum eine Übergangslösung noch besteht, welche kompensierenden Maßnahmen greifen und bis wann die Ablösung erfolgt.

Zertifikatsmanagement und PKI

Zertifikatsmanagement ist der Bereich, in dem viele technisch grundsätzlich gut abgesicherte Umgebungen im Alltag scheitern. Abgelaufene Zertifikate, unklare Zertifikatseigentümer, unbekannte Subdomains oder fehlende Widerrufsprozesse können Dienste lahmlegen und Sicherheitsrisiken erzeugen, obwohl die eigentliche Verschlüsselung korrekt konzipiert war.

Für NIS2 ist deshalb nicht nur der Einsatz von X.509-Zertifikaten relevant, sondern deren Lebenszyklus. Unternehmen sollten jederzeit wissen, welche Zertifikate im Einsatz sind, für welche Systeme sie gelten, wann sie ablaufen, welche Schlüssellänge genutzt wird, wer Eigentümer ist und wie eine Erneuerung erfolgt. Ohne Inventar gibt es keine verlässliche Steuerung.

Eine Public Key Infrastructure muss außerdem organisatorisch eingebettet sein. Es reicht nicht, Zertifikate "durch die Infrastruktur" erneuern zu lassen, wenn niemand die Vertrauenskette, die Laufzeiten, die betroffenen Dienste und die Abhängigkeiten versteht. Zertifikatsmanagement gehört daher in Betrieb, Informationssicherheit und Change-Prozesse.

Besonders wichtig sind fünf Kontrollpunkte:

1. Vollständiges Zertifikatsinventar mit Verantwortlichen und Ablaufdaten.
2. Automatisierte Warnungen vor Ablauf und möglichst automatisierte Erneuerung.
3. Mindeststandards für Schlüssellängen, Signaturalgorithmen und Zertifikatslaufzeiten.
4. Widerrufs- und Ersatzprozess bei Kompromittierung.
5. Dokumentation interner und externer Vertrauensketten.

Bei internen PKIs wird das Thema oft unterschätzt. Interne APIs, Maschinenzertifikate, VPN-Gateways, MDM-Infrastrukturen oder interne Mail-Systeme sind genauso relevant wie öffentliche Websites. Wenn interne Zertifikate unstrukturiert ausgestellt werden, entsteht eine unsichtbare Schatten-PKI mit hohem Ausfall- und Missbrauchsrisiko.

Post-Quantum-Kryptografie: warum Sie jetzt vorbereiten sollten

Post-Quantum-Kryptografie ist noch kein flächendeckendes Sofortprojekt, aber für NIS2-relevante Unternehmen ein aktuelles Vorbereitungsthema. Der Grund ist nicht nur die technische Entwicklung, sondern die Langlebigkeit sensibler Daten. Informationen, die heute abgegriffen und archiviert werden, können in einigen Jahren mit leistungsfähigeren Verfahren nachträglich entschlüsselbar werden.

Für die Praxis ist deshalb nicht die sofortige Komplettmigration entscheidend, sondern die Krypto-Agilität. Ihr Unternehmen sollte wissen, wo asymmetrische Verfahren eingesetzt werden, welche Zertifikatsketten kritisch sind, welche Systeme algorithmische Umstellungen unterstützen und welche Daten eine lange Schutzdauer haben. Ohne diese Transparenz wird ein späterer Wechsel teuer und langsam.

NIST hat 2024 erste Post-Quantum-Standards veröffentlicht. Das bedeutet jedoch nicht, dass jedes Unternehmen sofort produktiv auf PQC umstellen muss. Sinnvoll ist zunächst eine Bestandsaufnahme: Wo nutzen Sie RSA oder ECC? Welche Hardware- und Software-Komponenten sind langfristig gebunden? Wo bestehen zehnjährige oder längere Vertraulichkeitsanforderungen, etwa in Forschung, kritischer Infrastruktur, Verträgen oder Gesundheitsdaten?

Ein pragmatischer Vorbereitungsplan umfasst:

1. Kryptografie-Inventar erstellen und asymmetrische Abhängigkeiten identifizieren.
2. Schutzdauer kritischer Daten bewerten.
3. Bei Neubeschaffungen auf krypto-agile Produkte und Lieferanten achten.
4. Entwicklungen von BSI, NIST und Herstellern regelmäßig beobachten.
5. Für 2027 bis 2029 erste Migrationspfade skizzieren, statt später unter Zeitdruck zu reagieren.

Die relevante Management-Botschaft lautet deshalb: Post-Quantum-Kryptografie ist heute vor allem ein Architektur- und Beschaffungsthema. Wer jetzt vorbereitet, vermeidet spätere teure Parallelprojekte in Zertifikatsmanagement, Identitätsinfrastruktur und Geräteflotten.

Umsetzung für KMU: pragmatische Schritte

KMU brauchen für NIS2 Maßnahme 8 kein überdimensioniertes Kryptografie-Programm, aber einen klar priorisierten Mindeststandard. Der wirtschaftlichste Einstieg ist fast immer, zuerst die groben Lücken zu schließen und danach Governance und Sonderfälle zu verfeinern.

Ein realistischer Start in sechs Schritten sieht so aus:

1. Bestandsaufnahme: Erfassen Sie Datenbanken, Backups, Endgeräte, Webdienste, APIs, E-Mail-Systeme, VPNs und Cloud-Dienste mit aktuellem Verschlüsselungsstatus.
2. Mindeststandard definieren: Legen Sie schriftlich fest, welche Verfahren zulässig sind, etwa AES-256 für sensible ruhende Daten, TLS 1.3 bevorzugt für Übertragung und SHA-256 oder stärker für Integritätsfunktionen.
3. Schlüssel und Zertifikate ordnen: Führen Sie ein Register für Schlüssel, Secrets und Zertifikate mit Eigentümern, Laufzeiten und Rotationsregeln.
4. Altlasten entfernen: Deaktivieren Sie TLS 1.0/1.1, ersetzen Sie schwache Cipher Suites und beenden Sie unsichere manuelle Schlüsselablagen.
5. Nachweise schaffen: Dokumentieren Sie Richtlinie, Verantwortlichkeiten, Ausnahmen, Rotationen, Tests und Alarmierungen.
6. Regelbetrieb etablieren: Planen Sie vierteljährliche Reviews und einen Notfallprozess für Schlüssel- oder Zertifikatsvorfälle.

Besonders hilfreich ist für KMU die Orientierung an einer Mapping-Tabelle. Sie übersetzt rechtliche Pflicht, Normbezug und Technikempfehlung in ein kontrollierbares Raster:

Für viele mittelständische Teams ist das größte Hindernis nicht Technik, sondern Zuständigkeit. Wenn Infrastruktur, Fachanwendungen, Cloud-Betrieb und Security getrennt arbeiten, bleiben Schlüssel und Zertifikate oft "irgendwo zwischen den Teams" hängen. Genau deshalb braucht auch Maßnahme 8 einen eindeutigen Owner.

Wenn Sie Kryptografie, Rollenverständnis und Compliance-Grundlagen unternehmensweit sauber verankern wollen, ist unsere NIS2-Schulung für Unternehmen der direkte nächste Schritt. Für die operative Einordnung im Zusammenspiel mit anderen Maßnahmen helfen zusätzlich NIS2 Maßnahme 1 zur Risikoanalyse, NIS2 Maßnahme 9 zur Zugangskontrolle und die NIS2-Checkliste.

Häufig gestellte Fragen (FAQ)

Welche Verschlüsselung fordert NIS2?

NIS2 nennt keine einzelne Pflicht-Technologie, verlangt aber dokumentierte Konzepte und Verfahren für Kryptografie und gegebenenfalls Verschlüsselung. In der Praxis heißt das: moderne Standards für ruhende und übertragene Daten, nachvollziehbares Schlüsselmanagement und regelmäßig überprüfte Konfigurationen.

Reicht AES-256 für NIS2?

AES-256 ist ein starker Baustein, aber kein vollständiges Compliance-Programm. Ohne saubere Schlüsselverwaltung, abgesicherte Übertragungswege, Zertifikatskontrolle und dokumentierte Prozesse reicht auch ein starker Algorithmus allein nicht aus.

Muss ich E-Mails nach NIS2 verschlüsseln?

Ja, jedenfalls auf Transportebene sollte geschäftliche E-Mail-Kommunikation mit aktuellen TLS-Standards abgesichert sein. Bei besonders sensiblen Inhalten kann zusätzlich Inhaltsverschlüsselung erforderlich sein, etwa mit S/MIME oder OpenPGP.

Was fordert NIS2 zum Schlüsselmanagement?

Gefordert sind belastbare Verfahren für Erzeugung, Speicherung, Zugriff, Rotation, Widerruf und Vernichtung von Schlüsseln. Ihr Unternehmen muss nachweisen können, dass Schlüssel nicht unkontrolliert verteilt, unbegrenzt genutzt oder ohne Protokoll eingesetzt werden.

Gilt NIS2 Kryptografie auch für Cloud-Dienste?

Ja. Die Nutzung von Cloud-Diensten entbindet nicht von der Pflicht, Verschlüsselung, Schlüsselhoheit, Zertifikatsmanagement und Backup-Schutz zu prüfen. Entscheidend ist, dass das Risiko Ihres konkreten Einsatzes beherrscht wird.

Fazit: NIS2 Verschlüsselung ist ein Führungs- und Betriebsthema

NIS2 Verschlüsselung bedeutet nicht nur "mehr Technik", sondern ein belastbares Steuerungsmodell für Algorithmen, Schlüssel, Zertifikate und Migrationspfade. Art. 21 Abs. 2 Buchst. h verlangt von Unternehmen, dass Kryptografie geplant, dokumentiert, umgesetzt und überprüft wird. Wer nur punktuell einzelne Systeme verschlüsselt, erfüllt diese Logik nicht.

Der sinnvollste nächste Schritt ist deshalb kein blindes Tool-Shopping, sondern ein sauberes Kryptografie-Basisprogramm. Identifizieren Sie schutzbedürftige Daten, legen Sie technische Mindeststandards fest, ordnen Sie Schlüssel und Zertifikate organisatorisch zu und dokumentieren Sie Ausnahmen. So wird aus Maßnahme 8 ein beherrschbarer Bestandteil Ihres gesamten NIS2-Risikomanagements.