Inhalt

1. Einleitung: Drei Revolutionen im PKI-Management

2. Die Herausforderungen im Detail: kürzere Lebensdauer; Wildcard und Multidomain; private PKI und MS AD CS; Komplexität von SaaS; PQC; und digitale Souveränität.

3. Die drei Säulen der Zertifikatsverwaltung im Jahr 2026

4. Die Herausforderung der digitalen Souveränität angehen

5. Wie Sie dorthin gelangen: Modernisierung Ihrer PKI für 2026

6. Schlussfolgerung und Zusammenfassung

1. Drei Umwälzungen in der PKI-Welt

Drei gleichzeitige Transformationen treffen 2026 auf Ihre PKI-Infrastruktur – sie stellen Sie vor dringende Herausforderungen, betreffen Ihre PKI in der Breite und verlangen, dass Sie sie fundamental neu denken.

Erstens, dringende Herausforderung: Die Verkürzung der Zertifikatslaufzeiten

Ab 15. März 2029 laufen TLS/SSL-Zertifikate alle 47 Tage ab. Das bedeutet acht bis neun Mal mehr Erneuerungen als heute, acht Mal häufiger Zertifikate auf verschiedenen Endpoints austauschen. Für Organisationen, die Hunderte von öffentlichen Zertifikaten verwalten, ist das nicht nur unbequem – es ist ein existenzielles operatives Risiko.

Das CA/Browser Forum hat mit Ballot SC-081v3 im April 2025 einen verbindlichen Zeitplan verabschiedet:

• Ab 15. März 2026: Maximale Gültigkeit 200 Tage

• Ab 15. März 2027: Maximale Gültigkeit 100 Tage

• Ab 15. März 2029: Maximale Gültigkeit 47 Tage

Hintergründe dazu lesen Sie in unserem Blog-Artikel zur Verkürzung der Laufzeiten.

Parallel dazu verkürzen sich auch die Wiederverwendungsfristen drastisch: Ab 15. März 2029 sind Domain-Validierungsdaten nur noch 10 Tage gültig (statt bisher 398 Tage), OV-Inhaberinformationen 398 Tage (statt 825 Tage).

Zweitens, breite Herausforderung: Die explodierende Zertifikatslandschaft

Immer mehr Geräte, Anwendungen und Dienste benötigen öffentliche und vor allem private Zertifikate. DevOps und Cloud-Expansion bedeuten mehr Private-PKI-Anwendungsfälle. Maschinenidentitäten übersteigen menschliche Identitäten mittlerweile im Verhältnis 45:1 in typischen Unternehmen (Gartner 2024). In Cloud-nativen Umgebungen ist das Verhältnis noch extremer. Diese Diskrepanz beschleunigt sich mit der KI-Adoption und Automatisierung.

Drittens, fundamentale Herausforderung: Die Post-Quantum-Kryptographie-Migration

NIST IR 8547 vom November 2024 legt fest: Ab 2030 werden die klassischen Verschlüsselungsalgorithmen RSA und ECDSA als veraltet eingestuft. Ab 2035 sind sie vollständig verboten – einschliesslich für private Zertifikate mit langen Laufzeiten von 5 bis 10 Jahren.

Was auf dem Spiel steht

Bereits heute lesen wir regelmässig von Vorfällen, in denen Dienste ihren Schutz mittels Verschlüsselung verlieren und somit ausfallen – mit ernsthaften geschäftlichen und Reputationsschäden für die verantwortlichen Organisationen. Eine SwissSign-Kundenumfrage unter DACH-MPKI-Kunden im Jahr 2025 ergab: 74 Prozent der grösseren Organisationen mit über 500 Mitarbeitenden haben in den letzten fünf Jahren Serviceausfälle wegen abgelaufener Zertifikate erlebt. Die grossen anstehenden Umwälzungen erhöhen das Risiko für diese Ausfälle nochmals drastisch:

• Die Bank of England erlebte am 31. Juli 2024 einen 91-minütigen Ausfall ihres CHAPS-Zahlungssystems wegen eines abgelaufenen Zertifikats. Das System wickelt täglich über 360 Milliarden Pfund ab. Im Februar 2025 folgte ein weiterer zertifikatsbedingter Vorfall von 24 Minuten.

• Alaska Airlines musste im September 2024 Flüge in Seattle am Boden halten, weil ein abgelaufenes Zertifikat einen IT-Ausfall verursachte.

• SpaceX Starlink erlitt im April 2023 einen globalen Satellitenausfall durch ein abgelaufenes Bodenstation-Zertifikat.

• Microsoft Teams war im Februar 2020 drei Stunden lang für 20 Millionen Nutzer nicht erreichbar – Ursache war ein abgelaufenes Authentifizierungszertifikat.

Sicherheitsverletzungen wiegen noch schwerer

Über Geschäftsverluste und Vertrauenskrisen schaffen vergessene oder schlecht verwaltete Zertifikate gravierende Sicherheitslücken, die Angreifer ausnutzen. Abgelaufene oder falsch konfigurierte Zertifikate setzen Organisationen Betrug und unbefugtem Zugriff auf sensible Systeme aus.

• Der Equifax-Breach von 2017 blieb 76 Tage lang unentdeckt, weil ein abgelaufenes Zertifikat die Traffic-Inspektion deaktiviert hatte. Als das Zertifikat erneuert wurde und Administratoren den Einbruch bemerkten, hatten die Angreifer bereits 147 Millionen Personen-Datensätze exfiltriert, die Sozialversicherungsnummern, Geburtsdaten, Adressen und teilweise Kreditkartenangaben enthielten.

Auch solche Attacken gewinnen mit den drei genannten Herausforderungen deutlich an Wahrscheinlichkeit in den kommenden Jahren.

2. Die Herausforderungen

2.1 Warum traditionelles PKI-Management scheitern wird

Die Auswirkungen der Laufzeitverkürzung

Warum diese Änderung kommt: Die kürzeren Laufzeiten reduzieren das Zeitfenster, in dem kompromittierte Schlüssel missbraucht werden können. Rasche Revozierung wird weniger kritisch, da Zertifikate von selbst ablaufen. Die erzwungene Automatisierung verbessert die gesamte Sicherheitslage für eine Organisation und erhöht auch die Agilität für die Zertifikatswechsel, die nötig sind, um die Infrastruktur und das Netzwerk mit neuen quantensicheren Verschlüsselungsalgorithmen auszustatten («Krypto-Agilität»).

Was das operativ bedeutet: Manuelle Prozesse werden unmöglich.

Ausserdem müssen Organisationen alle zehn Tage die Inhaberschaft ihrer Domains neu validieren. Das CA/Browser Forum hat dieses Problem jedoch adressiert: Ballot SC-088v3 führt eine neue «Persistent DCV»-Methode ein. Domaininhaber können einen einmaligen DNS-TXT-Eintrag setzen, der über mehrere Zertifikatsausstellungen hinweg gültig bleibt, den die Certificate Authority laufend validiert. Wir von SwissSign informieren in unserem CA/B Update Newsletter über die neue Methode, sobald wir bereit sind.

Die Branche ist noch nicht bereit: Eine SwissSign-Umfrage zeigt: 90 Prozent der Organisationen mit über 500 Mitarbeitenden verwalten Zertifikate noch zumindest teilweise manuell. Mehr als 50 Prozent haben über die Vorbereitung auf die Laufzeitverkürzung nachgedacht oder konkrete Pläne gemacht. Nur etwa die Hälfte scannt ihr Netzwerk regelmässig nach Zertifikaten.

Das Wildcard- und Multi-Domain-Problem

Warum Wildcards und Multi-Domain nicht mit Automatisierung zusammengehen: Viele Organisationen sichern heute verschiedene Domain-Endpunkte über ein Wildcard-Zertifikat statt mit einzelnen Single-Domain-Zertifikaten. Das vereinfacht den Betrieb: Organisationen müssen nur ein Zertifikat erneuern, das spart Zeit und Kosten.

Bereits heute birgt dies Sicherheitsrisiken: Wenn ein Wildcard-Zertifikat kompromittiert wird, sind alle verbundenen Anwendungen gefährdet. Ähnliches gilt für Multi-Domain-Zertifikate (SAN), die zusätzlich das BygoneSSL-Problem mit sich bringen: Wechselt eine einzige Domain den Besitzer, kann der neue Inhaber das gesamte Zertifikat widerrufen lassen – und damit alle anderen Domains lahmlegen.

Künftig kommt dazu, dass sich eine automatisierte Erneuerung grundsätzlich nicht mit Wildcard-Zertifikaten realisieren lässt, weil Automatisierungsprotokolle wie ACME nur pro Domain funktionieren – die Automatisierung erfordert also dedizierte Zertifikate pro Endpunkt. Wildcards benötigen ausserdem DNS-01-Validierung mit API-Zugriff zum DNS-Provider, während Single-Domain-Zertifikate die einfachere HTTP-01-Validierung nutzen können.

Wir empfehlen Organisationen darum, Wildcards nur für bestimmte Gründe und Anwendungen zu nutzen:

• Für dynamisches DNS: Wenn Sie ständig neue Subdomains erstellen und wieder entfernen, etwa für Dev-Umgebungen oder Kunden-Sandboxes

• Load Balancer und Reverse Proxies: Ein Wildcard auf Ihrem Edge-Proxy vergrössert den Blast Radius nicht wesentlich – eine Kompromittierung des Proxys bedeutet ohnehin Zugriff auf alle Subdomains

• Aus Sicherheitserwägungen: Wenn die verschiedenen enthaltenen Sub-Domains nicht unmittelbar öffentlich sichtbar werden sollen, denn Wildcards verbergen die in öffentlichen CT-Logs

Die wachsende Private-PKI-Herausforderung

Anwendungsfälle, die täglich zunehmen: Eine Private PKI verfügt über viel Flexibilität, weil ihre Zertifikate nicht für die öffentliche Vertrauenshierarchie des Internets genutzt werden dürfen und daher nicht den Regeln des CA/Browser Forums unterliegen. Private Zertifikate, ausgegeben basierend auf einem organisationseigenen Root-Zertifikat, werden benötigt für WiFi- und VPN-Authentifizierung von Benutzern und Geräten, Microsoft-AD-Benutzerauthentifizierung, Citrix und NetScaler für VDI, Intune für MDM und Geräteverwaltung, IoT-Geräteauthentifizierung, interne Server ohne öffentlichen Zugang, Container- und Kubernetes-Workloads sowie Service Mesh mit mTLS.

Warum Governance auch hier wichtig ist: Ausfälle privater Zertifikate machen keine Schlagzeilen, legen aber kritische interne Systeme lahm, wenn sie nicht gut gemanagt werden. Schatten-PKI entsteht, wenn Teams ihre eigenen CAs ohne zentrale Sichtbarkeit aufsetzen. Fehlende Audit-Trails bedeuten zudem einen Compliance-Blindspot. Eine manuelle Revozierung von Zertifikaten, die beim Ausscheiden von Mitarbeitenden oder bei der Ausserbetriebnahme von Geräten notwendig wird, schafft Fehlerquellen und damit Sicherheitslücken. DevOps-Agilität kann dazu führen, dass Zertifikate unverwaltet bleiben, nicht rechtzeitig revoziert werden und damit Sicherheitsrisiken entstehen.

Microsoft AD CS: Weiterhin unverzichtbar, aber nicht ausreichend

Aktueller Stand: Microsoft hat im November 2025 PQC-Unterstützung (ML-KEM, ML-DSA) in Windows Server 2025 und Windows 11 über die CNG-API integriert. Für Active Directory Certificate Services (ADCS) ist die PQC-Unterstützung für Anfang 2026 angekündigt (Quelle).

Vorteile von AD CS für die Konzern-PKI: Eine SwissSign-Umfrage zeigt: 80 Prozent der grösseren Organisationen im DACH-Raum nutzen AD CS für ihre private PKI. AD CS bietet native Windows-Integration mit gruppenrichtliniengesteuerter automatischer Registrierung. Es ist tief in Windows-Unternehmensumgebungen eingebettet und perfekt für Windows-zentrierte Zertifikatsbereitstellung. Das System ist ausgereift und Windows-Administratoren gut bekannt.

Ergänzungspotenzial für AD CS für Konzerne: AD CS stellt Zertifikate aus, verfolgt aber nicht das Inventar, die Inhaberschaft oder den Lebenszyklus von privaten Zertifikaten über Ihre gesamte Infrastruktur hinweg. Die Integration mit Linux, Containern und Cloud-Workloads ist schwach. Nach Fusionen und Übernahmen fehlt die Fähigkeit, Sichtbarkeit über mehrere CAs zu konsolidieren. Moderne Protokolle wie ACME und EST erfordern zusätzliche Werkzeuge. Schema-Updates helfen bei Post-Quanten-Kryptographie, aber der Algorithmuswechsel erfordert Sichtbarkeit, die AD CS nicht bietet. Die Rechtesegregation ist sehr komplex einzurichten.

Die Realität: AD CS wird nicht verschwinden. Aber Organisationen brauchen zusätzliche Systeme wie CLM, um AD-CS-Zertifikate zusammen mit öffentlichen Zertifikaten, Cloud-Workloads und Multi-Vendor-Umgebungen zu verwalten.

Die Durchsetzung eines starken Zertifikat-Mappings (Microsoft KB5014754) im Februar 2025 hat eine weitere Konfigurationslast hinzugefügt, bei der CLM hilft. Zertifikate, die über Intune SCEP/PKCS oder Offline-Vorlagen ausgestellt werden, erfordern jetzt SID-Erweiterungen. Organisationen, die noch Legacy-Konfigurationen verwenden, erleben Authentifizierungsfehler bei VPN, WiFi und Geräteauthentifizierung.

Dezentrale Eigentümerschaft und SaaS-Komplexität

Typische Unternehmenssituation: IT Operations stellt Infrastruktur-Zertifikate aus. DevOps Anwendungszertifikate. Einzelne Geschäftsbereiche stellen eigene Zertifikate für ihre eigenen Anwendungen aus. Es gibt kein zentrales Inventar und keine einheitlichen Richtlinien – obwohl das Security Team meint, alle lägen bei ihnen.

Das SaaS-Zertifikatsproblem: Überwachen Sie die Zertifikate, die Ihr SaaS-Anbieter verwenden – auch jene, die von einzelnen Abteilungen betrieben werden –, um sicherzugehen, dass kritische SaaS-Systeme verfügbar bleiben. Auch wenn die Anbieter verantwortlich sind, fallen die Business- oder Vertrauensverluste auf Sie zurück.

Benutzerdefinierte Domains, die Sie auf SaaS-Plattformen konfiguriert haben, erfordern zudem Zertifikate, die Sie verwalten. API-Integrationszertifikate für die Authentifizierung bei Cloud-Diensten liegen auch in Ihrer Verantwortung. Ebenso mTLS-Zertifikate für den sicheren Datenaustausch mit externen Plattformen.

Diese Zertifikate befinden sich ausserhalb Ihrer Kerninfrastruktur, können aber dennoch Ausfälle verursachen, wenn sie ablaufen. CLM sollte auch solche Integrationszertifikate entdecken und verfolgen, nicht nur interne Infrastruktur – automatisiert und ohne zusätzlichen Aufwand für das Security-Team.

2.2 Post-Quantum-Kryptographie: Die nahende Deadline

Das Problem

Heutige Verschlüsselungsalgorithmen wie RSA und ECDSA lassen sich mit klassischen Computern nicht entschlüsseln. Quantencomputer werden diese Verschlüsselung brechen. «Harvest now, decrypt later»-Angriffe finden bereits heute statt: Gegner speichern verschlüsselte Daten für zukünftige Entschlüsselung. Neue Algorithmen erfordern ausserdem deutlich grössere Schlüssel und Signaturen.

Auswirkungen auf die Infrastruktur

Viele ältere Geräte, IoT und Netzwerkausrüstung können diese grösseren Zertifikate möglicherweise nicht händeln. Firmware-Updates über die gesamte Infrastruktur werden erforderlich. Bei zertifikatsintensiven Operationen wird gar die Netzwerkbandbreite zum Thema. Zertifikate mit den neuen Algorithmen müssen vor dem Produktiveinsatz in der gesamten Infrastruktur getestet werden.

Zeitplan gemäss NIST IR 8547 vom November 2024: Ab 2030 werden RSA, ECDSA, EdDSA, DH und ECDH auf 112-Bit-Sicherheitsniveau als veraltet eingestuft – dies gemäss der amerikanischen NIST, doch damit wird praktisch ein globaler Industriestandard gesetzt. «Veraltet» bedeutet: Nutzung einstellen, Migration beginnen, aber technisch noch erlaubt. Dies gilt für digitale Signaturen nach FIPS 186 und Schlüsseletablierung nach SP 800-56B.

Ab 2035 sind diese Algorithmen vollständig verboten. Alle RSA-Zertifikate müssen ersetzt werden, einschliesslich solcher in privaten Zertifikaten mit 5 bis 10 Jahren Laufzeit.

Was geschehen muss

Der Branchenkonsens: Gartner empfiehlt, 2029 als praktische Deadline zu behandeln, um Sicherheitsrisiken und operative Probleme zu vermeiden.

Alle Zertifikate müssen auf quantensichere Algorithmen wie ML-KEM, ML-DSA und SLH-DSA umgestellt werden. Das erfordert den Ersatz jedes einzelnen Zertifikats in Ihrer Infrastruktur. Legacy-Systeme müssen mit neuen Algorithmen getestet werden, insbesondere bezüglich Bandbreite und Firmware-Kompatibilität. Ein Zertifikatsinventar ist Voraussetzung für die Migrationsplanung. Die Migration insgesamt dauert Jahre, nicht Monate.

Warum PQC-Bereitschaft mit PKI-Modernisierung beginnt: Post-Quantum-Kryptographie ist kein fernes Thema, sondern ein 2- bis 3-jähriges Migrationsprojekt, das dieselben Fähigkeiten erfordert wie die Verwaltung kurzlebiger Zertifikate:

• Transparentes Inventar: Unbekannte Zertifikate können nicht migriert werden.

• Automatisierte Bereitstellung: Manuelles PQC-Rollout über mehr als 250 Zertifikate ist unmöglich.

• Richtliniendurchsetzung: Hybride Zertifikate mit klassischen und PQC-Algorithmen müssen während der Übergangsphase parallel laufen, dafür braucht es klare Regeln.

• Algorithmus-Agilität: Die Infrastruktur muss mehrere kryptographische Algorithmen gleichzeitig unterstützen.

• Testen in grossem Massstab: PQC-Zertifikate müssen validiert werden, damit sie Anwendungen nicht beschädigen, bevor sie in Produktion gehen.

Fazit

Organisationen, die heute die Herausforderungen der Laufzeitverkürzung lösen, werden die PQC-Migration von morgen bewältigen. Diejenigen, die das nicht tun, stehen vor zwei gleichzeitigen Krisen.

2.3 Die Herausforderung der digitalen Souveränität

NIS2-Anforderungen für CAs als kritische Lieferkette

NIS2, die Richtlinie über Netz- und Informationssicherheit 2.0 der Europäischen Union, betrachtet Certificate Authorities als kritische Lieferkettenkomponenten:

Organisationen sind rechtlich verpflichtet, «spezifische Schwachstellen jedes direkten Lieferanten» zu bewerten. Die Nutzung einer US-amerikanischen CA muss die nicht-EU-rechtliche Zuständigkeit explizit berücksichtigen. Für kritische Infrastrukturen in den Bereichen Energie, Transport, Gesundheit und öffentlicher Sektor gilt: Wenn Zertifikate widerrufen oder Kundendaten aufgrund von US-Gesetzgebung offengelegt werden, drohen EU-Bussgelder. Die Kommission ermutigt kritische Infrastrukturen zur Nutzung von EU-qualifizierten Vertrauensdiensteanbietern (QTSP, Qualified Trust Service Providers) und behält sich das Recht vor, QTSPs für bestimmte Sektoren in Zukunft vorzuschreiben.

DORA-Anforderungen für den Finanzsektor

DORA, der Digital Operational Resilience Act der EU, der seit Januar 2025 für europäische Finanzfirmen gilt, ist strenger und behandelt CAs als «ICT-Drittanbieter»:

Finanzunternehmen müssen ein detailliertes Register aller ICT-Drittanbieter einschliesslich CAs führen. DORA verlangt die Vermeidung einer «Überabhängigkeit» von einem einzelnen Anbieter oder einer einzelnen Nicht-EU-Jurisdiktion. Finanzunternehmen müssen alle Unterauftragnehmer ihrer CAs kartieren. Im November 2025 haben die Europäischen Aufsichtsbehörden kritische ICT-Drittanbieter benannt, mit einem im Juli 2025 veröffentlichten Aufsichtsleitfaden.

Sanktions- und Widerrufsrisiko

Direktes Risiko: US-amerikanische CAs können gezwungen werden, Geschäftsbeziehungen mit durch die US-Regierung sanktionierten Organisationen zu beenden, wenn letztere direkt auf eine «Black List» gesetzt werden. Ein Beispiel: der Chefankläger des International Criminal Court Karim Khan verlor gemäss Medienberichten nach Sanktionen der Trump-Administration den Zugang zu seinen Arbeits-E-Mails (wobei Microsoft dies bestreitet). Russische Finanz- und Verteidigungsorganisationen verloren nach den Sanktionen von 2022 den Zugang zu Zertifikaten.

Kollateralschadenrisiko: Wenn ein Teil einer Organisation versehentlich gegen US-Massnahmen gegen Länder, Branchen oder Personen verstösst, kann die gesamte Einheit auf eine Black List gelangen, woraufhin US-Organisationen ihre Dienste einstellen könnten.

Vertrauen und Reputation

Viele europäische und Schweizer Bürger bevorzugen lokale Lösungen für sensible Infrastruktur, das Thema der «digitalen Souveränität» gewinnt an Raum in der öffentlichen Debatte angesichts der geopolitischen Umwälzungen, die wir erleben. Das ist besonders relevant für Organisationen, die Bürger- oder Kundendaten verarbeiten.

3. Die drei Säulen des Certificate Lifecycle Managements

3.1 Discovery: Was Sie nicht sehen, können Sie nicht managen

Was es ist: Umfassendes Scannen der gesamten Infrastruktur, um ein vollständiges Zertifikatsinventar aufzubauen.

Discovery-Methoden: Aktives Probing und Netzwerk-Discovery umfasst HTTPS, LDAPs und andere Ports über Netzwerkbereiche hinweg. Lokale Client-Discovery bedeutet Dateisystem- und Zertifikatsspeicher-Inspektion auf Servern, Workstations und mobilen Geräten. Drittanbieter-Importe erfolgen API- und integrationsbasiert von Cloud-Diensten wie AWS, Azure und GCP, Load Balancern wie F5 und anderen Anwendungen. Certificate-Transparency-Monitoring ermöglicht Echtzeit-Beobachtung öffentlich ausgestellter Zertifikate.

Wie Sie es umsetzen: Richten Sie Scan-Kampagnen nach Zeitplan ein, wöchentlich oder täglich für kritische Segmente. Installieren Sie kleine leichte Agenten auf relevanten Endpunkten für kontinuierliche Sichtbarkeit. Integrieren Sie mit Cloud-Plattformen und Infrastruktur-Tools. Verbinden Sie Ihr Certificate Lifecycle Management mit MDM-Plattformen wie Intune, Jamf und Workspace ONE.

Warum es wichtig ist: Sie können die Erneuerung unbekannter Zertifikate nicht automatisieren. Compliance erfordert Audit-Trails für alle kryptographischen Assets. Eine Risikobewertung und eine umfassende Security Posture ist ohne vollständiges Inventar unmöglich. Die PQC-Migrationsplanung erfordert die Kenntnis jedes Zertifikats und seines Algorithmus. Mit einer umfassenden Discovery können zudem nicht autorisierte CAs und selbstsignierte Zertifikate – die Schatten-PKI – erkannt werden.

Idealbild: Ein Echtzeit-Inventar mit vollständiger Lifecycle-Verfolgung zeigt, wann jedes Zertifikat entdeckt, ausgestellt und erneuert wurde und mit welcher Methode. Sofortige Identifikation schwacher Algorithmen, ablaufender Zertifikate und Richtlinienverstösse ist möglich. Zertifikatsqualität wird basierend auf NIST-, ANSSI- und CA/B-Forum-Standards bewertet. Zentralisiertes Monitoring mit Eigentümer-Verantwortlichkeit und proaktive Warnungen vor dem Ablauf kritischer Zertifikate runden das Bild ab.

3.2 Governance: Richtlinien, die skalieren

Was es ist: Etablierung und Durchsetzung von Richtlinien für Zertifikatsnutzung in der gesamten Organisation: Wer kann welche Zertifikate anfordern, mit welchen Vertrauensstufen und Algorithmen, durch welche Workflows, wer muss welche Zertifikate autorisieren.

Stakeholder-RACI für ein typisches DACH-Unternehmen: Unsere Empfehlung: Erstellen Sie eine Stakeholder-Matrix und wenden Sie die RACI-Logik (Responsible, Accountable, Consulted, Informed) für Zertifikate an.

Zentrale Governance-Elemente:

• Definieren Sie genehmigte Certificate Authorities und Zertifikats-Vertrauensstufen pro Anwendungsfall. Zum Beispiel: SwissSign OV TLS für alle öffentlich zugänglichen Domains, SwissSign Private Certificates für interne Systeme.

• Legen Sie kryptographische Standards fest: Schlüssellänge, Algorithmen und Gültigkeit für jeden Zertifikatstyp.

• Etablieren Sie Namenskonventionen und Metadaten-Anforderungen.

• Definieren Sie Genehmigungsworkflows: Wer kann was anfordern, mit welchen Genehmigungen.

• Weisen Sie Eigentümerschaft zu auf Ebene von Geschäftsbereich, Team oder Einzelperson.

• Erstellen Sie Ersetzungsworkflows: Wenn ein Benutzer aus einer Gruppe entfernt wird, wird das Zertifikat gesperrt.

• Legen Sie Erneuerungszeitrichtlinien fest, beispielsweise 5 Tage vor Ablauf, nicht in letzter Minute.

• Definieren Sie Incident Response: Was passiert bei einem zertifikatsbedingten Ausfall?

Integration zur Richtliniendurchsetzung: Ihr Certificate Lifecycle Management sollte mit folgenden Systemen integriert werden, um seine volle Wirkung entfalten zu können: ITSM- und Ticketing-Systeme wie ServiceNow und Jira ermöglichen es, Zertifikate-Policies direkt in ihre bestehenden Workflows einzubauen. CMDB bietet Asset-Korrelation und Eigentümer-Mapping. SIEM-Systeme wie Splunk und QRadar ermöglichen Security-Event-Forwarding. Active Directory ermöglicht gruppenbasierte Richtliniendurchsetzung und automatische Sperrung, wenn Benutzer oder Geräte aus Gruppen entfernt werden. SCIM automatisiert Benutzer- und Gruppensynchronisation. Identity Provider mit OpenID Connect steuern den CLM-Zugriff.

Idealbild: Business- oder IT-User können ihre eigenen Zertifikate ordern – mit der passenden Sicherheitsstufe. Nicht-konforme Zertifikatsanfragen werden automatisch mit verständlichen Erklärungen blockiert. Jedes Zertifikat ist somit eindeutig einem Eigentümer, einer Abteilung, einem Zweck zugeordnet und bietet dafür das geeignete Vertrauensniveau. Digital signierte Audit-Logs sind manipulationssicher und bieten forensisches Detailniveau. Automatisierte Compliance-Berichte werden planmässig an die Verantwortlichen in der Organisation geliefert.

3.3 Automatisierung: 47-Tage-Zertifikate möglich machen

Was es ist: End-to-End-Zertifikatsoperationen – Ausstellung, Erneuerung, Bereitstellung, Revokation – ohne manuelle Eingriffe.

Was sind Agenten? Agenten sind kleine Softwarekomponenten, die auf Servern oder Workstations installiert werden und mit Ihrer CLM-Plattform kommunizieren. Sie entdecken Zertifikate in lokalen Speichern und Dateisystemen. Sie fordern automatisch neue Zertifikate an und installieren sie. Sie händeln die rechtzeitige Erneuerung vor dem Ablauf des Zertifikats und melden den Status an das zentrale Dashboard zurück. Sie übersetzen zwischen modernen CLM-APIs und Legacy-Protokollen, die Ihre Geräte bereits sprechen. Der Agent kommuniziert in der Regel nativ per HTTPS mit dem zentralen CLM.

Agenten sind oft die beste Option, weil sie einen einfachen Weg bieten, Automatisierung auf Legacy-Systemen zu etablieren.

Wie Reife aussieht: Geplante Zertifikatserneuerungen basieren auf Ihrer Governance und Ihren Policies. Die automatische Bereitstellung auf allen Endpunkten erfolgt ohne Serviceunterbrechung. Massenoperationen für Massenrevokationen oder Richtlinienaktualisierungen sind problemlos möglich. Native Integrationen mit Cloud-Key-Vaults wie Azure Key Vault, AWS Certificate Manager und Google Certificate Manager erleichtern das Zertifikatsmanagement in der Cloud. Moderne DevOps-Tools wie Ansible, Kubernetes cert-manager und Terraform werden unterstützt, um Ihre DevOps agil und sicher zu halten.

4. Die Souveränitäts-Herausforderung adressieren

Europäische Anbieter wählen

Für regulierte Branchen im DACH-Raum unterstützt die Wahl einer europäischen Certificate Authority und eines lokalen CLM-Anbieters NIS2- und DORA-Lieferantenbewertungsanforderungen, Datenresidenz-Bedenken und mindert geopolitische Risiken.

Geopolitisches Risiko mindern: Für regulierte Branchen im DACH-Raum ist dies eine strategische Entscheidung.

EU-basierte CAs unterliegen EU-Recht und bieten DSGVO-Alignment sowie reduziertes Sanktionsrisiko innerhalb europäischer Operationen – sanktioniert eine US-Regierung Ihre Organisation oder Teile Ihrer Organisation, müssen europäische CAs ihre Dienste für Sie nicht einstellen.

Schweizer Certificate Authorities geniessen mit ihrer Schweizer Jurisdiktion die Wahrnehmung der traditionellen Schweizer Neutralität, die in geopolitischen Auseinandersetzungen von Vorteil sein mag.

Der Status der Schweiz als «sicheres Drittland» für Datenschutz, kombiniert mit ETSI- und eIDAS-Compliance, bietet europäischen Organisationen sowohl Souveränität als auch regulatorische Kompatibilität.

Unabhängig von Ihrer Wahl: Dokumentieren Sie die Jurisdiktion Ihrer CA und das Sanktionsrisiko als Teil Ihrer NIS2/DORA-Drittanbieter-Risikobewertung.

Für einen detaillierten CA-Vergleich: Siehe unsere Analyse «Vertrauenswürdige Zertifizierungsstellen für Deutschland, die Schweiz und Österreich».

5. Wie Sie vorankommen: Ihre PKI für 2026 modernisieren

Den Business Case intern aufbauen

Strategische Einordnung: Zertifikatsausfälle bedeuten ein Risiko für Ihre Business Continuity: Quantifizieren Sie vergangene Vorfälle, wenn möglich, um deren Konsequenzen greifbar zu machen. Zitieren Sie Compliance-Anforderungen wie NIS2 und DORA für den Finanzsektor, die ein ordnungsgemässes Drittanbieter-Management vorschreiben. Führen Sie die 47-Tage-Deadline an. Die Frage ist, wann Sie mit der Automatisierung beginnen, nicht ob. März 2026 mit maximal 200 Tagen ist der erste Meilenstein.

TCO-Analyse-Überlegungen: Berechnen Sie grob Ihre aktuellen Kosten: Manuelle Stunden für das Zertifikatsmanagement mal Stundensatz mal Anzahl der Erneuerungen. Berechnen Sie Ihre künftige Situation ohne Automatisierung: Dieselbe Rechnung bei achtfacher Erneuerungsfrequenz. Zertifikatsbedingte Ausfälle kosten Unternehmen bereits heute sehr viel Geld und beeinträchtigen die Sicherheit und Operabilität Ihres Unternehmens, führen Sie bekannte Beispiele an, wie oben im Beitrag beschrieben. Vergleichen Sie: CLM-Investition versus Risiko fortgesetzter manueller Verwaltung.

Single-Domain-Zertifikate sind für Automatisierung erforderlich, vergleichen Sie Preismodelle sorgfältig – wenn Sie künftig nur noch Single-Domain-Zertifikate nutzen können, kann dies je nach CA deutlich mehr kosten.

Anbieter evaluieren

CA-Auswahlkriterien: Technische Fähigkeiten sind bei allen grossen CAs ähnlich. Hinsichtlich digitaler Souveränität und Support-Qualität müssen Sie auf die Standorte von Hauptquartier, Ansprechpartnern und Daten achten.

Hinzu kommen die Preismodelle, ein Beispiel: 9 Single-Domain-Zertifikate für 9 Anwendungsschichten bedeuten anderswo 9-fache Kosten. Bei SwissSign kostet dasselbe Szenario etwa das 3-Fache, da wir pro Inhaber abrechnen, nicht pro Seriennummer. Lesen Sie unseren detaillierten Vergleich der Certificate Authorities für regulierte Organisationen im DACH-Raum.

CLM-Auswahlkriterien: Discovery-Fähigkeiten für Netzwerk, Cloud, Endpunkte und Drittanbieter-Integrationen sind entscheidend, es braucht Protokollunterstützung für ACME, SCEP, EST, WCCE und Agenten. Cloud-Konnektoren für AWS, Azure und GCP werden benötigt. MDM-Konnektoren für Intune, Jamf und andere via SCEP sind wichtig.

Das gesamte Integrations-Ökosystem muss zu Ihrem Stack passen: AD, Intune, F5, Kubernetes, SIEM, ITSM, CMDB. Multi-CA-Support ermöglicht die Verwaltung von Zertifikaten aller Aussteller an einem Ort. Europäische Souveränität ist besonders für regulierte Branchen wichtig. Deployment-Flexibilität für On-Premises, Cloud oder Hybrid sollte gegeben sein.

Proof of Concept in Betracht ziehen

Einfache POCs (in der Regel kostenlos): Ein bis zwei Anwendungsfälle in einer Testumgebung. Sie können Ihre eigene Infrastruktur nutzen, zum Beispiel eine Windows-Maschine: Agent installieren, scannen, Ersetzungsworkflow demonstrieren. Das zeigt Kernfähigkeiten ohne Verpflichtung.

Komplexe POCs (möglicherweise kostenpflichtig): Einschliesslich Intune, Azure und komplexer AD-Umgebungen. Erfordert individuelle Tenant-Konfiguration, was Tage in Anspruch nimmt. Die Konfiguration ist bei guten Anbietern wie SwissSign und Evertrust exportierbar und lässt sich damit einfach in Ihre Produktionsumgebung übertragen. Das reduziert Bereitstellungszeit und -kosten für die finale Implementierung.

Cloud versus On-Premises CLM-Entscheidung

Wann Cloud-CLM sinnvoll ist

Bei begrenzter Infrastrukturkomplexität, wenn nur öffentliche Zertifikate verwaltet werden und keine tiefe AD- oder F5-Integration nötig ist. Bei ACME- und API-basierten Workflows, die keinen privilegierten Zugriff erfordern. Wenn Kosteneffizienz wichtig ist und keine On-Premises-Infrastruktur gewartet werden soll.

Wann On-Premises sinnvoll ist

Das Integrationsproblem mit Cloud-CLM: Cloud-CLM muss interne Systeme erreichen, sich mit Active Directory verbinden über LDAP oder LDAPS für Benutzersynchronisation. F5 Load Balancer für Zertifikatsbereitstellung erreichen, interne Zertifikatsagenten auf Servern installieren.

Wie erreicht Cloud-CLM diese Systeme? Die Optionen sind begrenzt. Sie könnten eine Verbindung via Internet herstellen, doch das sähe Ihr Sicherheitsteam sicher kritisch. VPN-Tunnel: Wollen Sie eine permanente VPN-Verbindung zwischen dem CLM-Anbieter und Ihren internen Systemen? Das bedeutet, dass ein externer Anbieter 24/7 Netzwerkzugriff auf kritische Systeme hat. Dies ist aus Compliancegründen schwierig, Ihre Auditoren würden sicher Fragen stellen.

Das Credential-Problem mit Cloud-CLM: Cloud-CLM benötigt privilegierten Zugriff. Für F5 heisst das: Admin-Credentials für die Zertifikatsbereitstellung. Für Intune: ein privilegiertes Konto zum Pushen von Zertifikaten. Für AD: ein Service-Account mit Schreibrechten. SSH-Schlüssel für Linux-Server. API-Tokens für Kubernetes-Cluster. All diese Zugriffe müssten auf eine SaaS-Plattform – viele Organisationen fühlen sich damit aus Sicherheitsgründen nicht wohl.

Vorteile eines On-Premise-Deployment: CLM läuft innerhalb Ihres Netzwerkperimeters, es gibt einen direkten LDAP-Zugang ohne VPN. Die nötigen Admin-Credentials verlassen nie Ihre Infrastruktur. Dieses Vorgehen entspricht Zero-Trust-Prinzipien und sichert Ihnen volle Datensouveränität, zumal in Kombination mit Schweizer Zertifikaten.

Der Schwellenwert: Ab etwa 5'000 Zertifikaten wird ein On-Premises-Deployment typischerweise kosteneffizienter und operativ sinnvoller für regulierte Organisationen.

6. Fazit und Aktion

Zusammenfassung

Das Zusammentreffen dreier grosser Umwälzungen in der PKI-Welt – 47-Tage-Zertifikatslaufzeiten, expandierende private PKI und die kommende PQC-Migration – zwingt Organisationen, ihr Zertifikatsmanagement zu automatisieren. Organisationen, die jetzt handeln, gewinnen:

• Operative Resilienz: Zertifikatsausfälle verhindern, bevor sie passieren

• PQC-Grundlage: Agilität für die Quantenmigration aufbauen

• Compliance: Volle digitale Souveränität mit den richtigen CA- und CLM-Anbietern wie SwissSign und Evertrust

• Kostenkontrolle: Budgetexplosion durch erhöhte Erneuerungsfrequenz vermeiden mit der richtigen CA

• Wettbewerbsvorteil: Reibungslos operieren, während andere improvisieren

Ihre nächsten Schritte

Erstens: Mit Sichtbarkeit beginnen. Sie können nicht automatisieren, was Sie nicht sehen. Discovery ist der erste Schritt. Wissen Sie, welche Zertifikate Sie haben, wo sie sich befinden, wann sie ablaufen und wem sie gehören.

Zweitens: Ihre CA-Beziehung evaluieren und einen CLM-Anbieter wählen. Berücksichtigen Sie Souveränität, Preismodell (kritisch für Automatisierungsökonomie) und Support-Qualität – nicht nur technische Funktionen. Für Ihren CLM-Anbieter sind moderne Discovery-Methoden und eine gute Bedienbarkeit auch für Business User wichtig. Ausschlaggebend sind für viele grosse Organisationen zudem das Integrationsökosystem, das zu Ihrer Infrastruktur passen muss.

Drittens: Es geht JETZT los. Die erste Deadline für eine TLS/SSL-Lebensdauer von maximal 200 Tagen Gültigkeit ist im März 2026. Starten Sie jetzt – auf der richtigen Schiene für digitale Souveränität.