SSL-Zertifikate im Audit: ISO 27001, NIS-2, DORA und KRITIS
SSL-Zertifikate sind längst nicht mehr nur ein technisches Thema. ISO 27001, NIS-2, DORA und KRITIS/BSI-Grundschutz verlangen alle – in unterschiedlicher Tiefe – nachweisbare Prozesse für das Ausstellen, das Erneuern, den Widerruf und die Inventur von Kryptografie-Material. Wer diese Nachweise nicht sauber aufsetzt, riskiert im schlimmsten Fall die ganze Zertifizierungen bei einem Audit zu gefährden. Diese Seite ordnet die vier zentralen Rahmenwerke für SSL-Compliance ein und zeigt, welche konkreten Nachweise ein Auditor tatsächlich sehen will.
Sie brauchen ein Zertifikats-Inventar, das Sie einem Auditor mit einem Klick zeigen können?
LEMARIT liefert zur Automation die Basis für die Nachweisdaten gleich mit
Warum SSL-Zertifikate zunehmend in den Prüfungs-Scope rücken
Bis vor wenigen Jahren waren SSL-Zertifikate für viele Auditoren eher ein Randthema: „HTTPS ist da, Haken dran.“ Das hat sich grundlegend geändert. Drei Entwicklungen sind zusammengekommen und haben Zertifikatsprozesse in den Scope der Kern-Prüfung gehievt.
Erstens: Ausfälle sind durch verkürzte Laufzeiten wahrscheinlicher geworden. Die 200-Tage-Regel ab Oktober 2026 – und die weitere Verkürzung auf 47 Tage bis 2029 – verwandelt das SSL-Management von einer jährlichen Übung in eine laufende Betriebs-Aufgabe. Ein ausgelaufenes Zertifikat auf einem produktiven System ist ein klassischer Verfügbarkeits-Incident, der in vielen Frameworks meldepflichtig oder zumindest dokumentationspflichtig ist.
Zweitens: Die regulatorischen Rahmenwerke wurden konkretisiert. ISO 27001:2022 hat mit A.8.24 den Kryptografie-Prozess explizit adressiert, NIS-2 verlangt seit Oktober 2024 in fast allen mittelständischen und großen Unternehmen der EU nachweisbare Cybersecurity-Prozesse, und DORA verpflichtet den gesamten Finanzsektor seit Januar 2025 zu einer Art digitaler operationaler Resilienz – inklusive kryptografischer Kontrollen.
Drittens: Zertifikate sind zunehmend Angriffsziel. Die Auditoren-Community hat verstanden, dass ein kompromittiertes Zertifikat, ein gefälschter Widerruf oder ein nicht dokumentierter CA-Wechsel Sicherheits-Konsequenzen hat, die weit über den einzelnen Server hinausreichen. Die technischen Grundlagen dazu behandelt unsere Website SSL-Zertifikate-Sicherheit im Detail.
Das Zusammenspiel dieser drei Entwicklungen bedeutet: Ein Auditor, der 2026 auf ein Unternehmen zukommt, erwartet einen dokumentierten, nachvollziehbaren, wiederholbaren Prozess für den gesamten Zertifikats-Lebenszyklus. Wer das nicht liefern kann, wird Audit-Feststellungen bekommen.
ISO 27001 – konkrete Anforderungen an Zertifikatsprozesse
Annex A.8.24 – Nutzung von Kryptografie
Das ist die zentrale Norm für Zertifikatsprozesse. Sie verlangt eine dokumentierte Kryptografie-Richtlinie, die unter anderem regelt: welche Algorithmen und Schlüssellängen zulässig sind (siehe RSA vs. ECDSA und weitere kryptografische Grundlagen), wie Schlüssel erzeugt und geschützt werden, unter welchen Bedingungen Zertifikate widerrufen werden, und wer für die Ausstellung und Verlängerung verantwortlich ist.
Was ein Auditor dazu sehen will: eine schriftlich fixierte Richtlinie, die auf einer bestimmten Version steht und regelmäßig überprüft wird. Kein „das machen wir schon irgendwie“-Prozess, sondern ein Dokument mit Freigabe-Historie.
Annex A.8.25 – Lebenszyklus der Kryptografie-Objekte
Hier geht es explizit um Ausstellung, Erneuerung, Speicherung, Archivierung und Vernichtung von kryptografischem Material – also genau den Zertifikats-Lebenszyklus. Der Auditor will sehen: gibt es einen definierten Prozess für jede dieser Phasen, und wird er dokumentiert eingehalten?
Das schließt insbesondere den Widerruf ein. Wenn ein privater Schlüssel kompromittiert wird, muss das Zertifikat schnell zurückgezogen werden können – mit Nachweis, wer wann welchen Widerruf ausgelöst hat.
Annex A.5.10 und A.8.9 – Bestands-Inventar
Weniger offensichtlich, aber genauso wichtig: Ein Auditor erwartet ein aktuelles Zertifikats-Inventar. Nicht als Beiwerk, sondern als operationalisierte Grundlage der Kryptografie-Kontrolle. Was er sehen will: welche Zertifikate sind produktiv im Einsatz, wo sind sie deployed, wann laufen sie ab, wer ist verantwortlich?
Die Umsetzung eines solchen Inventars – insbesondere in gewachsenen Umgebungen – ist genau das, was ein Certificate Discovery-Tool leistet. Details dazu in Enterprise Certificate Lifecycle Management.
Was ISO 27001 nicht explizit fordert, aber praktisch verlangt
NIS-2 – die Erweiterung des Prüfungs-Scopes
Die NIS-2-Richtlinie der EU ist seit Oktober 2024 in nationalen Gesetzen umgesetzt (in Deutschland durch das NIS-2-Umsetzungsgesetz) und verpflichtet mittelständische und große Unternehmen in fast 20 Sektoren zu nachweisbaren Cybersecurity-Kapazitäten.
Für Zertifikatsprozesse relevant sind vor allem Artikel 21 (Risikomanagement) und Artikel 23 (Meldepflichten):
Artikel 21 – Kryptografie als Risikomanagement-Baustein
Absatz 2 nennt explizit „Kryptografie und gegebenenfalls Verschlüsselung“ als eine der zehn Mindest-Maßnahmen, die betroffene Unternehmen umsetzen und dokumentieren müssen. Was das konkret heißt: eine dokumentierte Kryptografie-Policy, die technisch und organisatorisch belastbar ist. Die Anforderung überschneidet sich hier stark mit ISO 27001 A.8.24 – wer eine ISO-27001-konforme Kryptografie-Richtlinie hat, erfüllt weitgehend auch die NIS-2-Kryptografie-Anforderung.
Neu und über ISO 27001 hinausgehend ist die Verpflichtung zur Wirksamkeits-Überprüfung. Es reicht nicht, eine Richtlinie zu haben – die Umsetzung muss regelmäßig auf Wirksamkeit geprüft werden. In der Praxis bedeutet das: ein Zertifikats-Inventar, das nicht nur existiert, sondern aktiv gepflegt und überwacht wird, mit Alarmierung bei drohenden Abläufen.
Artikel 23 – Meldepflicht bei Zertifikats-Incidents
Wenn ein SSL-Zertifikat auf einem produktiven System ausläuft und dadurch ein Dienst nicht mehr erreichbar ist, kann das unter NIS-2 als „erheblicher Vorfall“ meldepflichtig werden. Die Meldefristen sind knapp: Frühwarnung binnen 24 Stunden, ausführliche Meldung binnen 72 Stunden. Wer diese Meldungen abgeben muss, braucht saubere Dokumentation darüber, welche Zertifikate mit welchen Diensten verbunden sind und warum es zum Ausfall kam.
Das macht die Verbindung zwischen Zertifikats-Inventar und CMDB (Configuration Management Database) audit-relevant: Ein Zertifikat ohne bekannten Deployment-Kontext ist im Incident-Fall ein Problem.
NIS-2 in der Auditor-Praxis
NIS-2 wird nicht klassisch „zertifiziert“ wie ISO 27001. Die Prüfung findet aber statt – und zwar entweder durch die zuständige Behörde (in Deutschland: BSI und BNetzA) oder durch die für das Unternehmen verantwortlichen Geschäftsführer, die persönlich haften. Beide Prüfungs-Ebenen erwarten dokumentierte Prozesse und funktionierende Kontrollen.
DORA – Digital Operational Resilience für den Finanzsektor
Kryptografische Kontrollen als Pflicht-Baustein
DORA verlangt in Artikel 9 explizit „angemessene kryptografische Kontrollen“, die auf einer dokumentierten Richtlinie basieren. Was das für Zertifikate bedeutet: Der Finanzsektor muss nicht nur eine Kryptografie-Policy haben (wie NIS-2), sondern deren technische Angemessenheit fortlaufend nachweisen. Das schließt insbesondere die Beobachtung der kryptografischen Landschaft ein – der Übergang zu Post-Quantum-Kryptografie ist beispielsweise ein Thema, das DORA-verpflichtete Institute in ihren Roadmaps abbilden müssen.
Third-Party-Risiko und CAs
Neu ist die explizite Regulierung des IT-Dienstleister-Risikos. Certificate Authorities sind aus DORA-Sicht kritische Dienstleister, wenn ihre Zertifikate produktive Kernsysteme absichern. Das führt zu zwei Konsequenzen: erstens muss die Auswahl der CA dokumentiert und begründet sein (nicht: „das hat der Sysadmin damals eingerichtet“), zweitens muss eine Ausweich-Strategie existieren, falls die primäre CA ausfällt oder aus dem Markt austritt.
Genau diese Ausweich-Strategie ist die Multi-CA-Fähigkeit, die wir in Enterprise Certificate Lifecycle Management ausführlich beschrieben haben. Für DORA-verpflichtete Institute ist Multi-CA nicht mehr optional – sie ist ein Baustein der operationalen Resilienz.
Testing und Nachweis
DORA verlangt in Artikel 24-27 regelmäßige Digital Operational Resilience Testing – inklusive Threat-Led Penetration Testing für die größten Institute. In diesen Tests werden Zertifikatsprozesse mitgeprüft: Wie schnell kann das Institut ein kompromittiertes Zertifikat widerrufen? Wie schnell kann eine neue CA aktiviert werden, falls die aktuelle ausfällt? Die Antwortzeiten müssen dokumentierbar sein.
KRITIS und BSI-Grundschutz – der deutsche Rahmen
BSI IT-Grundschutz – Baustein CON.1
Der Baustein CON.1 „Kryptokonzept“ definiert konkret, was ein deutsches Kryptokonzept beinhalten muss. Das reicht von der Auswahl der Verfahren (siehe die technische Diskussion in SSL-Zertifikats-Sicherheit) über die Schlüssel-Erzeugung bis hin zur Notfall-Kryptografie. Für Zertifikate relevant sind besonders die Anforderungen CON.1.A5 (Sichere Konfiguration der Kryptomodule) und CON.1.A8 (Reaktion auf kryptografische Schwachstellen).
Ein deutsches KRITIS-Audit prüft zusätzlich die konkrete Algorithmen-Konformität: Es wird nicht nur geprüft, ob es eine Kryptografie-Richtlinie gibt, sondern ob sie den BSI-Empfehlungen zu Algorithmen entspricht (Technische Richtlinie TR-02102). Wer heute noch SHA-1 im Einsatz hat, wird bei einer BSI-Prüfung Feststellungen ernten.
KRITIS-Meldepflicht
Ähnlich wie unter NIS-2 sind Ausfälle in KRITIS-Sektoren meldepflichtig – teils sogar mit noch strengeren Fristen. Ein Zertifikats-bedingter Ausfall eines Energie-Steuerungssystems oder eines Krankenhaus-Portals ist immer ein KRITIS-Vorfall. Die Dokumentations-Anforderungen sind entsprechend hoch.
Praktische Konsequenz für Zertifikatsprozesse
Wer in Deutschland als KRITIS-Betreiber operiert, kann eine manuelle Zertifikats-Bewirtschaftung fast nicht mehr rechtfertigen. Nicht weil das BSI sie verbietet, sondern weil die Fehler-Toleranz zu gering ist. Die 200-Tage-Regel ab Oktober 2026 verstärkt diesen Druck weiter.
Was der Auditor sehen will – die typischen Nachweise
Regulatorische Rahmenwerke bleiben abstrakt, wenn sie nicht in konkrete Auditor-Fragen übersetzt werden. In Zertifikats-relevanten Audits – ob ISO 27001, NIS-2-Vorbereitung, DORA oder KRITIS – wiederholen sich vier Nachweis-Kategorien:
Erstens: die Kryptografie-Richtlinie selbst. Ein Dokument, das die zulässigen Algorithmen, Schlüssellängen, Ausstellungs-Prozesse und Verantwortlichkeiten definiert. Mit Freigabe-Historie und regelmäßiger Review. Ohne dieses Dokument ist jedes Kryptografie-Audit sofort gescheitert.
Zweitens: das Zertifikats-Inventar. Eine aktuelle, vollständige Liste aller produktiven Zertifikate mit Deployment-Ort, Verantwortlichen, Ablaufdatum und Ausstellungs-CA. Der Auditor will das Inventar in der Prüfungs-Situation live sehen können – nicht als exportierte PDF von letzter Woche.
Drittens: der Renewal-Nachweis. Wie viele Zertifikate wurden in den letzten zwölf Monaten erneuert, wie viele davon rechtzeitig, wie viele mit Verzögerung, wie viele überhaupt nicht (also ausgelaufen)? Der Auditor sucht Muster: 100% rechtzeitig ist verdächtig glatt, 15% verspätet ist ein Prozess-Problem, ausgelaufene Zertifikate sind Feststellungs-Material.
Viertens: der Widerrufs-Prozess. Was passiert, wenn ein privater Schlüssel kompromittiert wird? Wer entscheidet, wer widerruft, wie schnell? Der Auditor will einen dokumentierten Ablauf sehen – im Idealfall einen Testfall, in dem der Prozess einmal geübt wurde.
Wer diese vier Nachweise sauber liefern kann, hat 80% der Zertifikats-relevanten Audit-Fragen bereits im Griff. Alles darüber hinaus ist Detail-Vertiefung.
Automation als Compliance-Enabler – wo Technik und Nachweisführung zusammenkommen
Diese Seite hat mehrfach auf die technischen Grundlagen der Zertifikatsverwaltung verwiesen. Der Grund: Compliance ist nicht ein separates Thema neben der technischen Zertifikatsverwaltung, sondern deren Nebenprodukt – wenn die Verwaltung sauber aufgesetzt ist.
Konkret bedeutet das:
Das Zertifikats-Inventar entsteht automatisch, wenn eine Certificate-Automation-Plattform alle Ausstellungen zentral verwaltet. Es muss nicht als separate Excel-Tabelle gepflegt werden. Die technische Grundlage dazu ist in Enterprise Certificate Lifecycle Management beschrieben.
Die Renewal-Nachweise sind Log-Einträge der Automation. Jede Ausstellung, jedes Renewal, jeder Widerruf hinterlässt einen Zeitstempel und einen auslösenden Prozess. Das ist genau der Audit-Trail, den ein Prüfer sehen will.
Die Validierungsstufe je Zertifikat – siehe DV, OV und EV im Vergleich – ist im Inventar mitgeführt und lässt sich auf Compliance-Anforderungen prüfen. Beispiel: Wenn die Kryptografie-Richtlinie für kundenfacing Systeme mindestens OV verlangt, ist eine Inventar-Abfrage ausreichend, um Compliance-Abweichungen zu identifizieren.
Die technischen Sicherheits-Kontrollen – CAA-Records, ECDSA-Schlüssel, sauberer Widerruf, siehe SSL-Zertifikats-Sicherheit – sind in einer Automations-Plattform als Policy hinterlegt und werden systematisch angewendet. Das erfüllt Kryptografie-Richtlinien-Anforderungen strukturell.
Die zentrale Compliance-Erkenntnis lautet damit: Wer Zertifikate technisch sauber und automatisiert bewirtschaftet, hat die relevanten Compliance-Nachweise als Nebenprodukt. Wer sie manuell und ohne Systemunterstützung bewirtschaftet, muss die Nachweise separat produzieren – und wird an diesem Punkt in der Regel scheitern.
Sie stehen vor einem Audit – ISO 27001, NIS-2-Vorbereitung, DORA oder KRITIS?
Im Gespräch liefert LEMARIT belastbare Nachweise zu Ihren Zertifikatsprozessen
Häufige Fragen (FAQ)
Was verlangt ISO 27001 konkret zu SSL-Zertifikaten?
ISO 27001:2022 verlangt in Annex A.8.24 eine dokumentierte Kryptografie-Richtlinie sowie in A.8.25 einen definierten Lebenszyklus-Prozess für kryptografisches Material. Für SSL-Zertifikate heißt das: schriftliche Regeln zu Algorithmen, Schlüssellängen, Ausstellung, Renewal und Widerruf.
Zusätzlich erwartet der Auditor praktisch immer ein aktuelles Zertifikats-Inventar mit Deployment-Ort, Ablaufdatum und Verantwortlichem – auch wenn das nicht wortwörtlich in der Norm steht. Die Praxis-Interpretation ist mittlerweile Standard geworden.
Wie erfüllt NIS-2 die Anforderungen an Zertifikatsprozesse?
NIS-2 nennt Kryptografie in Artikel 21 als eine der zehn Mindest-Maßnahmen und verlangt eine dokumentierte, wirksamkeits-geprüfte Policy. Zusätzlich greift die Meldepflicht in Artikel 23, wenn Zertifikats-bedingte Ausfälle als „erhebliche Vorfälle“ gelten.
Eine ISO-27001-konforme Kryptografie-Richtlinie deckt die inhaltliche NIS-2-Anforderung weitgehend ab. Neu ist die Verpflichtung zur regelmäßigen Wirksamkeits-Überprüfung – Richtlinie im Ordner reicht nicht, es muss überwacht und geprüft werden.
Sind SSL-Zertifikate ein Prüfpunkt in DORA?
Ja. DORA verlangt in Artikel 9 explizit angemessene kryptografische Kontrollen und in Artikel 28-30 ein dokumentiertes Third-Party-Risiko-Management, das auch Certificate Authorities einschließt. Multi-CA-Fähigkeit wird im Finanzsektor damit zunehmend erwartet.
Zusätzlich prüft das Resilience Testing (Art. 24-27) konkret die Reaktionsfähigkeit bei kompromittierten Zertifikaten und CA-Ausfällen. DORA-verpflichtete Institute müssen Widerrufs- und CA-Wechsel-Zeiten dokumentieren und begründen können..
Was fordert BSI-Grundschutz zum Zertifikatsmanagement?
Der Baustein CON.1 „Kryptokonzept“ definiert die Anforderungen an ein deutsches Kryptografie-Framework – inklusive Algorithmen-Auswahl gemäß BSI TR-02102 und dokumentiertem Umgang mit kryptografischen Schwachstellen.
Für KRITIS-Betreiber gilt zusätzlich die Meldepflicht bei Zertifikats-bedingten Ausfällen. Ein deutsches KRITIS-Audit prüft zusätzlich die konkrete Algorithmen-Konformität – nicht nur die Existenz einer Kryptografie-Richtlinie.
Welche Nachweise verlangt ein Auditor typischerweise?
Vier Kategorien wiederholen sich in fast allen Zertifikats-relevanten Audits: die schriftliche Kryptografie-Richtlinie mit Freigabe-Historie, das aktuelle Zertifikats-Inventar, die Renewal-Historie der letzten zwölf Monate und ein dokumentierter Widerrufs-Prozess.
Alle vier Nachweise sollten live in der Prüfungs-Situation gezeigt werden können – nicht als exportierte PDF von letzter Woche. Automatisierte Systeme liefern diese Daten aus dem laufenden Betrieb; manuelle Prozesse tun sich hier regelmäßig schwer.
Reicht ein Excel-Sheet als Zertifikats-Inventar für den Auditor?
Grundsätzlich ja, in kleinen Umgebungen mit wenigen Zertifikaten. Der Auditor prüft nicht die Technologie, sondern die Aktualität und Vollständigkeit der Daten.
In der Praxis ist ein Excel-basiertes Inventar ab etwa 50 Zertifikaten kaum aktuell zu halten. Diskrepanzen zwischen Excel-Liste und produktiver Realität sind der häufigste Grund für Audit-Feststellungen im Bereich Zertifikatsmanagement. Ein automatisch gepflegtes Inventar löst dieses Problem strukturell.
Wie oft muss die Compliance-Dokumentation aktualisiert werden?
Die Richtlinie selbst wird typischerweise jährlich reviewt und ggf. angepasst – so verlangt es ISO 27001 explizit und NIS-2 implizit. Bei größeren Änderungen der Kryptografie-Landschaft (z. B. Post-Quantum-Migration) auch häufiger.
Das Inventar dagegen muss laufend aktuell sein. In der Praxis heißt das: Änderungen der Zertifikats-Bestände dürfen keine manuellen Update-Schritte erfordern, sondern sollten aus dem operativen System heraus dokumentiert werden.