Digitale Souveränität: Welche Rolle Zertifikate und europäische Zertifizierungsstellen spielen

Digitale Souveränität heißt, im digitalen Raum selbst entscheiden zu können. Bei TLS-Zertifikaten reden dabei die Browserhersteller mit, auch wenn die Zertifizierungsstelle aus Europa kommt.

Das Bundesministerium für Digitales und Staatsmodernisierung (BMDS) formuliert es deutlich: „Technologische Abhängigkeiten sind ein strategisches Risiko.“ Die EU-Kommission hat im Oktober 2025 ein Cloud Sovereignty Framework veröffentlicht, und das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat im April 2026 den Kriterienkatalog C3A vorgelegt. Beide machen bewertbar, wie souverän ein Cloud-Dienst ist.

Eine Ebene darunter liegen die Zertifikate, mit denen Websites, E-Mails und viele andere Verbindungen abgesichert werden. Auch bei ihnen stellt sich die Frage, wer über das Vertrauen entscheidet und wie viel davon ein Unternehmen selbst in der Hand hat. Die Antwort beginnt bei der Frage, was digitale Souveränität meint.

Was bedeutet digitale Souveränität?

Digitale Souveränität ist nach der Definition des Digitalverbands Bitkom „die Fähigkeit zu Selbstbestimmung im digitalen Raum“. Für Unternehmen heißt das: Sie entscheiden selbst, welche Technologien und Anbieter sie einsetzen, behalten die Kontrolle über ihre Daten und Schlüssel und können den Anbieter wechseln, wenn sich die Bedingungen ändern.

Ein verwandter Begriff ist digitale Eigenständigkeit, den auch das BMDS verwendet. Das BSI nennt in seiner Beschreibung neben Selbstständigkeit und Selbstbestimmung ausdrücklich die Sicherheit. Bitkom grenzt Souveränität nach zwei Seiten ab. Bei Fremdbestimmung entscheiden andere, und es fehlt eigene Kompetenz in digitalen Schlüsseltechnologien. Bei Autarkie macht man alles selbst und zieht eigene Technologien selbst dann vor, wenn sie weniger leistungsfähig sind. Souverän ist dagegen, wer selbst entscheidet, in zentralen Technologiefeldern eigene Fähigkeiten hat und zwischen leistungsfähigen und vertrauenswürdigen Partnern wählen kann.

Das Ziel ist also Wahlfreiheit, nicht vollständige Unabhängigkeit. Souveränität in diesem Sinn verlangt nicht, auf Anbieter aus Drittstaaten zu verzichten. Sie verlangt aber, Abhängigkeiten bewusst einzugehen und sich Alternativen offenzuhalten.

Datensouveränität und weitere Dimensionen

Datensouveränität bedeutet, die Kontrolle darüber zu behalten, wer auf Daten zugreift, wo sie verarbeitet werden und ob sie sich nachweisbar löschen lassen. Sie ist eine von mehreren Dimensionen digitaler Souveränität. Für Cloud-Dienste hat die EU-Kommission im Cloud Sovereignty Framework acht Souveränitätsziele formuliert, zunächst für eine eigene Ausschreibung. Sie betreffen Strategie, Recht und Gerichtsbarkeit, Daten und KI, Betrieb, Lieferkette und Technologie sowie Sicherheit und Compliance und die ökologische Nachhaltigkeit.

Das BSI hat die ersten sechs dieser Kategorien in die C3A (Criteria enabling Cloud Computing Autonomy) übernommen. Sicherheit und Compliance deckt das BSI über den Kriterienkatalog C5 und weitere Standards ab; Nachhaltigkeit liegt außerhalb seiner Zuständigkeit.

Ein Beispiel macht das greifbar: Ein Unternehmen speichert Daten bei einem Cloud-Anbieter, verschlüsselt sie aber mit Schlüsseln, auf die nur es selbst zugreifen kann. Das EU-Framework bewertet unter dem Ziel „Data & AI Sovereignty“ unter anderem, ob nur der Kunde und nicht der Anbieter den kryptografischen Zugriff auf die Daten wirksam kontrolliert. Zu den Voraussetzungen digitaler Souveränität gehört also neben Verträgen und Standorten auch die technische Kontrolle über die Schlüssel. Dasselbe gilt für die Identitäten und Zertifikate eines Unternehmens.

Warum digitale Souveränität für Unternehmen wichtig ist

Digitale Souveränität ist für Unternehmen wichtig, weil Abhängigkeiten Folgen haben: Wer auf einen einzelnen Anbieter oder eine fremde Rechtsordnung angewiesen ist, kann Entscheidungen anderer oft nur schwer ausweichen. An drei Stellen wird das konkret:

• Zugriff aus Drittstaaten: Nach dem US-amerikanischen CLOUD Act müssen Anbieter von Kommunikations- und Cloud-Diensten, die der US-Gerichtsbarkeit unterliegen, Daten in ihrem Besitz, Gewahrsam oder unter ihrer Kontrolle auf eine gültige Anordnung hin herausgeben, unabhängig davon, wo die Daten gespeichert sind. So beschreibt es das Weißbuch des US-Justizministeriums vom April 2019. Entscheidend ist damit, wer die Daten kontrolliert, und nicht allein, wo sie liegen.
• Sicherheit der Lieferkette: Die NIS2-Richtlinie zählt die Sicherheit der Lieferkette zu den Risikomanagementmaßnahmen im Bereich der Cybersicherheit (Art. 21 Abs. 2 Buchst. d). In Deutschland gilt mit der NIS2-Umsetzung § 30 des BSI-Gesetzes (BSIG): Die Maßnahmen besonders wichtiger und wichtiger Einrichtungen müssen zumindest die „Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern“ umfassen (Abs. 2 Satz 2 Nr. 4). Dazu kommen Konzepte und Prozesse für den Einsatz kryptografischer Verfahren (Nr. 8).
• Beschaffung: Das Cloud Sovereignty Framework und die C3A machen die Souveränität von Cloud-Angeboten vergleichbar. Nach ihrem Framework hat die EU-Kommission im April 2026 vier europäische Anbieter ausgewählt, bei denen die Einrichtungen der EU über sechs Jahre souveräne Cloud-Dienste für bis zu 180 Millionen Euro beziehen können. Das BSI bezeichnet die C3A als richtungsweisenden Handlungsrahmen, der von sich aus nicht verbindlich ist. Als Maßstab für eigene Ausschreibungen und für Fragen an Anbieter eignen sie sich trotzdem.

Digitale Souveränität ist in Deutschland und Europa damit auch ein politisches Ziel: Die Bundesregierung will laut BMDS technologische Abhängigkeiten von Anbietern aus Drittstaaten verringern.

Zertifikate: Wer über digitales Vertrauen entscheidet

Zertifikate verknüpfen einen öffentlichen Schlüssel mit einer Domain, einer E-Mail-Adresse, einem Softwarehersteller oder einem Gerät. Je nach Zertifikatstyp bestätigen sie auch die Organisation dahinter, und sie ermöglichen verschlüsselte Verbindungen. Ob ein Browser einem TLS-Zertifikat vertraut, entscheidet allerdings weder das Unternehmen, das es einsetzt, noch die Zertifizierungsstelle allein. Drei Ebenen wirken zusammen:

• Die Zertifizierungsstelle prüft den Antrag und stellt das Zertifikat aus. Ihre Root-Zertifikate bilden den Anfang der Vertrauenskette.
• Die Root-Programme der Browser- und Betriebssystemhersteller Google, Apple, Microsoft und Mozilla legen fest, welche Root-Zertifikate in ihre Vertrauensspeicher, die Root Stores, aufgenommen werden. Das 2022 gestartete Chrome Root Program zum Beispiel bestimmt, welchen Website-Zertifikaten Chrome standardmäßig vertraut.
• Das CA/Browser Forum, in dem Zertifizierungsstellen und Hersteller von Browsern und Betriebssystemen zusammenarbeiten, beschließt die Baseline Requirements, also die gemeinsamen Mindestanforderungen an öffentliche TLS-Zertifikate. Das Chrome Root Program verlangt, dass Zertifizierungsstellen die jeweils aktuelle Fassung einhalten, und verschärft einzelne Anforderungen.

Wie viel Gewicht diese Ebenen haben, zeigen zwei Beispiele. Mit dem Ballot SC-081v3 hat das CA/Browser Forum im April 2025 beschlossen, die Laufzeit öffentlicher TLS-Zertifikate schrittweise zu verkürzen. Zertifikate, die seit dem 15.03.2026 ausgestellt werden, dürfen höchstens 200 Tage gelten; ab dem 15.03.2027 sind es 100 Tage und ab dem 15.03.2029 noch 47 Tage. Die kürzere Laufzeit von SSL-Zertifikaten betrifft jede Website mit einem öffentlichen TLS-Zertifikat, gleich bei welcher Zertifizierungsstelle sie es bezieht.

Noch deutlicher zeigt das der Fall Entrust. Am 27.06.2024 kündigte Google an, neuen TLS-Zertifikaten der Zertifizierungsstelle in Chrome nicht mehr zu vertrauen. Nach einer Verschiebung am 10.09.2024 galt das ab Chrome 131 für Zertifikate, deren frühester Signed Certificate Timestamp (SCT) nach dem 11.11.2024 lag; Chrome unter iOS war ausgenommen. Ältere Zertifikate blieben bis zum Ende ihrer Laufzeit vertrauenswürdig. Auch Mozilla, Apple und Microsoft setzten eigene Stichtage zwischen November 2024 und April 2025; der Entzug des Vertrauens gegenüber Entrust galt damit in allen vier genannten Root-Programmen.

Zwischen Ankündigung und Stichtag lagen rund viereinhalb Monate. Wer danach ein Zertifikat erneuern oder neu beantragen musste, brauchte dafür eine andere ausstellende Zertifizierungsstelle. Souveränität bei Zertifikaten heißt deshalb vor allem, auf solche Entscheidungen schnell reagieren zu können.

Welche Rolle europäische Zertifizierungsstellen spielen

Eine Zertifizierungsstelle mit Sitz in der EU unterliegt dem Recht ihres Mitgliedstaats und der EU. Ob daneben auch das Recht anderer Staaten eine Rolle spielt, kann davon abhängen, wem sie gehört. Ist sie als qualifizierter Vertrauensdiensteanbieter anerkannt, kommt mehr hinzu: Eine nationale Aufsichtsstelle beaufsichtigt sie, eine Konformitätsbewertungsstelle prüft sie nach Art. 20 Abs. 1 der eIDAS-Verordnung mindestens alle 24 Monate, und ihr Mitgliedstaat führt sie mit ihren qualifizierten Diensten in seiner Vertrauensliste. Je nach anerkanntem Dienst stellt sie qualifizierte Zertifikate für Signaturen, Siegel oder Websites aus. Die Vertrauenslisten lassen sich im eIDAS Dashboard der EU-Kommission durchsuchen.

Eines ändert der Sitz in Europa allerdings nicht: Auch die öffentlichen TLS-Zertifikate einer europäischen Zertifizierungsstelle gelten in Browsern nur dann als vertrauenswürdig, wenn sie sich auf ein Root-Zertifikat zurückführen lassen, das in die Root Stores aufgenommen ist, und für sie gelten dieselben Regeln des CA/Browser Forums. Das gilt auch für den Entzug des Vertrauens. Am 30.05.2025 kündigte Google an, dass Chrome ab Version 139 TLS-Zertifikaten der Zertifizierungsstelle NetLock aus Budapest standardmäßig nicht mehr vertraut, sofern der früheste SCT eines Zertifikats nach dem 31.07.2025 liegt.

Bei der Auswahl einer europäischen Zertifizierungsstelle helfen prüfbare Kriterien. Wo hat sie ihren Sitz, und wem gehört sie? Wer beaufsichtigt und prüft sie, und in welchen Root Stores ist sie vertreten? Ist sie für die benötigten Dienste in einer EU-Vertrauensliste als qualifiziert geführt? Vier Anbieter und ihre Unterschiede stellt der Überblick über europäische Zertifizierungsstellen vor.

Qualifizierte Website-Zertifikate nach eIDAS 2.0

Mit eIDAS 2.0, der Änderung der eIDAS-Verordnung durch die Verordnung (EU) 2024/1183, regelt die EU auch die Rolle der Browser bei qualifizierten Zertifikaten für die Website-Authentifizierung (QWAC). Nach Art. 45 Abs. 1a der eIDAS-Verordnung werden QWACs von Anbietern von Webbrowsern anerkannt, und die Browser stellen die bescheinigten Identitätsdaten benutzerfreundlich dar. Sie gewährleisten außerdem die Unterstützung von QWACs und die Interoperabilität mit ihnen; davon ausgenommen sind Kleinst- und Kleinunternehmen in den ersten fünf Jahren ihrer Tätigkeit als Browseranbieter. Über die Anforderungen des Abs. 1 hinaus dürfen für QWACs keine verbindlichen Anforderungen gelten (Abs. 1b). Vorsorgemaßnahmen in Bezug auf ein bestimmtes Zertifikat oder einen Satz von Zertifikaten erlaubt Art. 45a Abs. 2 nur bei begründeten Bedenken wegen Sicherheitsverletzungen oder eines Integritätsverlusts.

Erwägungsgrund 65 der Verordnung (EU) 2024/1183 ordnet diese Pflicht ein. Sie „berührt nicht die Freiheit der Anbieter von Webbrowsern“, Websicherheit, Domänenauthentifizierung und die Verschlüsselung des Webverkehrs so sicherzustellen, wie sie es für am besten geeignet halten. Die Nutzung von QWACs soll für Websites freiwillig sein. Nach dem Erwägungsgrund sollen QWACs Vertrauen in die Identität der Einrichtung hinter einer Website schaffen, während die Browser Websicherheit, Domänenauthentifizierung und Verschlüsselung weiterhin auf ihre Weise sicherstellen.

Digitale Souveränität bei Zertifikaten stärken

Welchen Zertifizierungsstellen die Browser ihrer Kunden vertrauen, können Unternehmen nicht beeinflussen. Sie können aber dafür sorgen, dass solche Entscheidungen sie nicht unvorbereitet treffen. Fünf Ansatzpunkte helfen dabei:

• Bestand erfassen: Wer weiß, welche Zertifikate von welchen Zertifizierungsstellen wo im Einsatz sind und wo die zugehörigen privaten Schlüssel liegen, kann bei einem erzwungenen Wechsel gezielt handeln. Diesen Überblick schafft ein Certificate Lifecycle Management.
• Wechselfähig bleiben: Eine zweite Zertifizierungsstelle mit eingerichteten Zugängen und abgeschlossenen Validierungen verkürzt einen Wechsel. Mit der automatisierten Ausstellung über ACME lassen sich Zertifikate auch bei einer anderen Zertifizierungsstelle mit wenig Handarbeit beziehen.
• Schlüsselhoheit sichern: Besonders wichtige private Schlüssel, etwa für Signaturen oder eine eigene Zertifizierungsstelle, sollten in eigenen Hardware-Sicherheitsmodulen (HSM) liegen oder bei Diensten, bei denen nur der Kunde auf die Schlüssel zugreifen kann.
• Interne Anwendungen unabhängig absichern: Server, Geräte und Benutzer im eigenen Netz lassen sich mit Zertifikaten aus einer privaten Public-Key-Infrastruktur (PKI) absichern. Eine private PKI hängt nicht von den Root-Programmen der Browser ab, weil das Unternehmen selbst festlegt, welchen Root-Zertifikaten seine Systeme vertrauen. Eine Managed PKI mit eigener Root-CA bietet diese Unabhängigkeit, ohne dass das Unternehmen die Infrastruktur selbst betreiben muss.
• Qualifizierte Dienste gezielt wählen: Für elektronische Signaturen, Siegel und eine geprüfte Website-Identität kommen qualifizierte Vertrauensdiensteanbieter infrage, die in den EU-Vertrauenslisten geführt sind.

Zur Wechselfähigkeit gehört auch Krypto-Agilität, also die Fähigkeit, Algorithmen und Schlüssel ohne großen Umbau auszutauschen. Gefragt ist sie etwa beim Umstieg auf Post-Quanten-Kryptografie, die Verbindungen und Signaturen auch gegen künftige Quantencomputer absichern soll.

Die PSW GROUP berät Sie bei der Auswahl europäischer Zertifizierungsstellen, bei einer Managed PKI für öffentliche Zertifikate und beim Aufbau einer eigenen Root-CA. Sprechen Sie uns an.