Zertifikate von Drittanbietern: Das Lieferkettenrisiko, das sich in Ihrem Unternehmen verbirgt

Das Risiko von Drittanbieterzertifikaten stellt die Sicherheitslücke dar, die entsteht, wenn digitale Zertifikate, die einem Anbieter ausgestellt wurden, auch nach Beendigung der Geschäftsbeziehung gültig und vertrauenswürdig bleiben. Zertifikate werden im Gegensatz zu Benutzerkonten, VPN-Zugängen und API-Schlüsseln selten nach Beendigung der Geschäftsbeziehung mit einem anderen Anbieter deaktiviert. Daher zählt dieses Risiko zu den am meisten übersehenen Lieferkettenrisiken in Unternehmensumgebungen.

Wird ein Lieferant aus dem System entfernt, schließt die Beschaffungsabteilung den Vertrag, deaktiviert die Benutzerkonten und sperrt den VPN-Zugang. Das für die API-Integration ausgestellte gemeinsame TLS- Zertifikat wird in den Systemen, die im Zuge der Auslagerung betroffen sind, nicht registriert und daher auch nach Vertragsende nicht gesperrt. Es authentifiziert sich weiterhin erfolgreich.

Dies ist das Standardverhalten in den meisten Unternehmensumgebungen, da Zertifikatslebenszyklusmanagement (CLM) und Lieferantenrisikomanagement völlig getrennte Funktionen darstellen. Zertifikate, die für Drittanbieterintegrationen ausgestellt werden, einschließlich Clientzertifikate für den Zugriff und auf PKI basierende Anmeldeinformationen , befinden sich in einer Governance-Lücke, für die keines der beiden Teams verantwortlich ist.

Der Verizon DBIR 2025 stellte fest, dass sich die Beteiligung von Drittanbietern an Sicherheitsvorfällen innerhalb eines Jahres verdoppelt hat und von 15 % auf 30 % aller bestätigten Vorfälle angestiegen ist. In den meisten Fällen handelte es sich bei dem Zugriffspunkt um Anmeldeinformationen, die hätten widerrufen werden müssen, aber nicht widerrufen wurden. Dieser Blogbeitrag untersucht, wie Unternehmen diese Sicherheitslücke schließen können, bevor das Zertifikat eines ehemaligen Anbieters zu einem Einfallstor für Sicherheitslücken wird.

Wie Zertifikate Dritten Zugriff gewähren und warum dieser Zugriff anders ist

Um zu verstehen, warum Zertifikate von Drittanbietern ein besonderes und oft unterschätztes Risiko darstellen, ist es hilfreich, genauer zu betrachten, wie sie verwendet werden und was sie tatsächlich garantieren.

Gegenseitige TLS-Authentifizierung (mTLS)

Mutual TLS ist ein zertifikatsbasierter Authentifizierungsmechanismus, bei dem sowohl Client als auch Server digitale Zertifikate vorlegen, um die Identität des jeweils anderen vor Verbindungsaufbau zu bestätigen. Im Gegensatz zu Standard-TLS, bei dem nur die Identität des Servers verifiziert wird, erfordert mTLS, dass die Verbindungspartei ihre eigene Identität kryptografisch nachweist.

Dies macht es zum Authentifizierungsmechanismus der Wahl für API-Integrationen zwischen Unternehmen, die Kommunikation zwischen Diensten in Zero-Trust-Architekturen und jede Integration, bei der die Verbindungspartei auf der Transportschicht und nicht über Anmeldeinformationen auf Anwendungsschicht verifiziert werden muss.

Für Drittanbieterintegrationen wird mTLS üblicherweise durch die Ausstellung eines Zertifikats an den Anbieter oder die Partnerorganisation implementiert, das deren Systeme beim Zugriff auf Ihre APIs vorlegen. Dieses Zertifikat dient als Zugangsberechtigung. Es ist für seine gesamte Gültigkeitsdauer gültig, die ein Jahr oder länger betragen kann, und gewährt bei jeder Vorlage an jedes System, das ihm vertraut, Zugriff – unabhängig von etwaigen Änderungen der Geschäftsbeziehung nach der Ausstellung.

Clientauthentifizierungszertifikate

Clientauthentifizierungszertifikate, X.509 -Zertifikate mit erweiterter Schlüsselverwendung (EKU) für Clientauthentifizierung, dienen der Identitätsprüfung eines Clients, der sich mit einem Server oder Dienst verbindet. Sie sind funktional ähnlich wie mTLS, können aber auch außerhalb vollständiger TLS-Handshakes eingesetzt werden, beispielsweise bei der VPN-Authentifizierung, der Zugriffskontrolle von Webanwendungen oder Service-Mesh-Richtlinien. Bei der Integration von Anbietern werden Clientauthentifizierungszertifikate häufig zusätzlich zu oder anstelle von Benutzername und Passwort als sichererer Zugriffsmechanismus ausgestellt.

Der Sicherheitsvorteil zertifikatsbasierter gegenüber passwortbasierter Zugriffsverwaltung ist unbestreitbar: Zertifikate bieten stärkere Anmeldeinformationen und sind resistent gegen Phishing- und Credential-Stuffing-Angriffe. Allerdings bleibt der Diebstahl oder die Kompromittierung des privaten Schlüssels am Endpunkt ein eigenständiges Risiko. Der Nachteil in puncto Verwaltung ist ebenso real: Passwörter laufen ab oder können gemäß einem Zeitplan geändert werden, der mit den Lebenszyklusereignissen des Anbieters übereinstimmt, während Zertifikate oft keinerlei Bezug zur Anbieterverwaltung aufweisen.

Zertifikate für die Code-Signatur- und Integrationspipeline

Bei einigen Drittanbieterintegrationen sind Anbieter beteiligt, die Software-Artefakte, Konfigurationspakete oder Datenpakete signieren, die Ihre Systeme verarbeiten. Das zum Signieren verwendete Zertifikat wird von Ihrer Infrastruktur als vertrauenswürdig eingestuft, um diese Artefakte zu validieren. Wird das Signaturzertifikat des Anbieters bei Beendigung der Geschäftsbeziehung nicht widerrufen, vertraut Ihre Infrastruktur weiterhin Artefakten mit der Signatur dieses Zertifikats und verarbeitet diese, einschließlich potenziell auch Artefakten, die von der Person ausgestellt wurden, die nun die Systeme oder den privaten Schlüssel des Anbieters kontrolliert.

Die Governance-Lücke: Was beim Offboarding von Anbietern übersehen wird

Die besondere Schwierigkeit bei der Verwaltung aller drei Zertifikatstypen liegt nicht in der Technologie selbst, sondern in der organisatorischen Distanz zwischen den ausstellenden Teams und denjenigen, die die Lieferantenbeziehungen pflegen. Moderne Prozesse zur Beendigung der Zusammenarbeit mit Lieferanten haben sich im letzten Jahrzehnt deutlich verbessert. Die meisten Unternehmen verfügen heute über strukturierte Prozesse zur Deaktivierung von Benutzerkonten von Lieferanten, zum Entzug von VPN- und Fernzugriffen, zur Deaktivierung von API-Schlüsseln in Systemen zur Geheimnisverwaltung und zur Überprüfung von Datenzugriffsberechtigungen. Diese Schritte sind in HR-Workflows, IAM-Systeme und Plattformen für das Lieferantenrisikomanagement integriert. Sie werden zwar nicht perfekt, aber systematisch durchgeführt.

Zertifikate scheitern in jedem dieser Prozesse. Hier die Gründe, aufgeschlüsselt nach Zertifikatstyp:

Anmeldedatentyp	Werden Sie für die Abwicklung des Lieferanten-Offboardings erfasst?	Widerruf bei Vertragsende
Benutzerkonten	Ja, das IAM-System wird beim Ausscheiden deaktiviert.	In der Regel automatisiert
VPN-Zugang	Ja, die VPN-Richtlinie entfernt den Zugriff am Vertragsende.	In der Regel automatisiert
API-Schlüssel	Teilweise, in geheimen Tresoren verfolgt, falls regiert	Oft manuell, variiert stark
mTLS-Zertifikate	Selten, wird in den meisten CLM-Systemen nicht erfasst.	Fast immer manuell oder übersehen
Integrationszertifikate	Selten herausgegeben und vergessen	Fast immer komplett verfehlt
Client-Authentifizierungszertifikate (PKI)	Fast nie, keine Lebenszyklus-Governance	In den meisten Organisationen nicht widerrufen

Das Muster ist eindeutig: Je mehr ein Benutzerkonto einem Benutzerkonto ähnelt (mit einem menschlichen Inhaber, verwaltet in einem Identitätssystem, unterliegt IAM-Richtlinien), desto wahrscheinlicher wird es beim Offboarding berücksichtigt. Je mehr ein Benutzerkonto hingegen der Infrastruktur ähnelt (ein in die Systemkonfiguration eingebettetes Zertifikat, das nicht zentral verwaltet wird und von einem PKI-Prozess ohne Integration in das Lieferantenmanagement ausgestellt wird), desto unwahrscheinlicher ist es, dass es bei Beendigung der Geschäftsbeziehung mit dem Lieferanten berührt wird.

Erschwerend kommt hinzu, dass mTLS- und Client-Authentifizierungszertifikate häufig nicht von demselben Team verwaltet werden, das auch die Lieferantenbeziehung betreut. Einkauf und Lieferantenrisikomanagement sind für die Geschäftsbeziehung zuständig. Die beiden Bereiche kommunizieren selten explizit über Ereignisse im Zertifikatslebenszyklus, die mit Ereignissen im Lieferantenlebenszyklus verknüpft sind. Eine kürzliche Änderung der öffentlichen CA-Richtlinien hat diese bestehende Governance-Lücke um eine neue technische Ebene erweitert.

Die Umstellung auf mTLS bis 2026: Neue Dringlichkeit für die Verwaltung von Drittanbieterzertifikaten

Eine bedeutende politische Änderung, die sich in den Jahren 2025 und 2026 im gesamten öffentlichen CA-Ökosystem vollzog, hat der Governance von Drittanbieterzertifikaten eine neue Dringlichkeitsdimension verliehen und eine konkrete Migrationsanforderung für jede Organisation geschaffen, die öffentliche CA-Zertifikate für mTLS verwendet.

Jahrelang nutzten Unternehmen öffentlich vertrauenswürdige TLS-Zertifikate – dieselben Zertifikate, die HTTPS-Verbindungen sichern – für mTLS und die Client-Authentifizierung bei der Integration von Drittanbietern. Dies war betrieblich vorteilhaft: Öffentliche Zertifizierungsstellen stellten Zertifikate aus, die sowohl die erweiterte Schlüsselverwendung für die Server- als auch für die Client-Authentifizierung enthielten, sodass ein einziges Zertifikat beide Zwecke erfüllen konnte.

Dieses Modell gilt nicht mehr für öffentliche Zertifikate. Das Chrome-Root-Programm schreibt vor, dass öffentliche TLS-Zertifikate ausschließlich für die Serverauthentifizierung verwendet werden dürfen. Große öffentliche Zertifizierungsstellen begannen ab September 2025, die Client-Authentifizierungs-EKU standardmäßig aus neu ausgestellten TLS-Zertifikaten zu entfernen. Die meisten schlossen die vollständige Entfernung bis Mai 2026 ab. Chrome lehnt seit dem 15. Juni 2026 neu ausgestellte öffentliche TLS-Zertifikate ab, die die Client-Authentifizierungs-EKU enthalten. DigiCerts endgültiger Stichtag für alle Ausstellungen, einschließlich Verlängerungen und Neuausstellungen, ist der 1. März 2027. Chromes Vorgabe für alle öffentlichen Endbenutzerzertifikate gilt bis zum 15. März 2027. Mit der vollständigen Umsetzung dieser Umstellung werden Organisationen, die mTLS-Integrationen von Anbietern auf Basis öffentlicher CA-Zertifikate entwickelt haben, feststellen, dass diese Zertifikate für die Clientauthentifizierung nicht mehr funktionieren. Dies geschieht oft unbemerkt während eines automatisierten Verlängerungszyklus, ohne dass eine Warnung auf Anwendungsebene angezeigt wird, bis die Verbindung fehlschlägt.

Die langfristig richtige Lösung, wie das CA-Ökosystem deutlich gemacht hat, ist die Verwendung einer privaten PKI für die Client-Authentifizierung. Client-Zertifikate für die Integration von Anbietern sollten von Ihrer eigenen internen CA ausgestellt werden, gemäß Ihren eigenen Richtlinien und mit einem von Ihnen kontrollierten Lebenszyklusmanagement. Dies ist sowohl technisch korrekt als auch betrieblich notwendig: Ein von Ihrer privaten CA ausgestelltes Zertifikat kann sofort widerrufen werden, wenn ein Anbietervertrag ausläuft, ohne auf die Widerrufsinfrastruktur einer öffentlichen CA angewiesen zu sein.

Doch gerade Clientzertifikate, die von privaten Zertifizierungsstellen ausgestellt werden, sind für die meisten Organisationen nicht einsehbar, werden nicht über ihren gesamten Lebenszyklus verwaltet und sind nicht in die Prozesse zur Abmeldung von Anbietern eingebunden. Der Wandel, den das Ökosystem der Zertifizierungsstellen vorantreibt, zwingt gleichzeitig zu den Verbesserungen der Governance, die im Management von Drittanbieterzertifikaten schon immer notwendig waren. Bleiben diese Verbesserungen aus, manifestieren sich die Risiken in der Branche bereits dokumentierter Weise.

Konsequenzen in der Praxis: Wenn der Anbieterzugriff über das Vertragsende hinaus Bestand hat.

Bleiben die vom CA-Ökosystem forcierten Verbesserungen der Governance aus, folgen die Folgen einem bekannten Muster. Das Risiko nicht widerrufener Anbieterzertifikate ist nicht hypothetisch. Das übergreifende Muster, bei dem Zugangsdaten von Drittanbietern die Geschäftsbeziehung, die sie rechtfertigte, überdauern, ist ein wiederkehrender Faktor bei realen Sicherheitsvorfällen. Branchenzahlen belegen, wie häufig Angreifer über Zugangsdaten eindringen.

Der Verizon-Bericht zu Datenpannen 2025 identifizierte gestohlene oder missbrauchte Zugangsdaten als häufigsten ersten Zugriffsweg, der in 22 % aller Datenschutzverletzungen vorkam. Der IBM X-Force Threat Intelligence Index 2025 stellte fest, dass der Missbrauch gültiger Zugangsdaten zu den beiden häufigsten ersten Zugriffswegen bei Sicherheitsvorfällen zählte, gleichauf mit der Ausnutzung öffentlich zugänglicher Anwendungen. Angreifer setzen dabei zunehmend auf legitime Zugangsdaten anstatt auf neuartige Schadsoftware.

Ein Anbieterzertifikat, das nie widerrufen wurde, ist genau das: ein gültiges Berechtigungsdokument, das sich im Besitz eines Angreifers befindet oder einfach in einem unüberwachten Zustand ist und Zugriff gewährt, der nicht mehr bestehen sollte.

Die Lücke schließen: Ein 5-stufiger Ansatz für die Verwaltung von Drittanbieterzertifikaten

Um die Lücke in der Governance von Drittanbieterzertifikaten zu schließen, müssen zwei Funktionen miteinander verknüpft werden, die bisher unabhängig voneinander agierten: das Zertifikatslebenszyklusmanagement und das Lieferantenrisikomanagement. Der folgende Fünf-Schritte-Ansatz zeigt, wie Organisationen mit ausgereiften Programmen diese Verknüpfung hergestellt haben.

1. Entdecken Sie alle Drittanbieterzertifikate in Ihrer Umgebung
   Automatisierte Zertifikatsausführung Entdeckung in allen Umgebungen: Windows Stores, IIS, Linux-Server, Load Balancer, API-Gateways und BehälterFiltern Sie die Ergebnisse, um Zertifikate zu identifizieren, die an externe Organisationen ausgestellt wurden, indem Sie Subject CN, SANs und die ausstellende Zertifizierungsstelle prüfen. Dies ist die grundlegende Bestandsaufnahme, die Sie wahrscheinlich noch nie hatten.

2. Ordnen Sie jedes Zertifikat einer Lieferantenbeziehung zu.
   Ermitteln Sie für jedes gefundene Zertifikat eines Drittanbieters die zugehörige Geschäftsbeziehung: für welchen Lieferanten oder Auftragnehmer es ausgestellt wurde, wem die Geschäftsbeziehung gehört, wann der Vertrag ausläuft oder verlängert wird und auf welche Systeme das Zertifikat Zugriff gewährt.

   Von Anbietern gehaltene Codesignaturzertifikate erfordern in dieser Phase besondere Aufmerksamkeit: Anders als TLS-Zertifikate, die nach dem Widerruf ihre Gültigkeit vollständig verlieren, validiert ein Anbieterzertifikat weiterhin zuvor signierte Dokumente, selbst nachdem die Geschäftsbeziehung zum Anbieter beendet wurde, es sei denn, diese Dokumente werden entfernt oder das Zertifikat wird als nicht vertrauenswürdig eingestuft. Zertifikate ohne identifizierbare Geschäftsbeziehung sollten als risikoreiche, verwaiste Zertifikate behandelt und umgehend untersucht werden.

3. Integration des Zertifikatslebenszyklus in das Onboarding und Offboarding von Lieferanten
   Richten Sie in Ihrem Lieferanten-Onboarding-Prozess einen formalen Kontrollpunkt ein, an dem alle dem Lieferanten ausgestellten Zertifikate in einer Certificate Lifecycle Management (CLM)-Plattform mit Angabe des Vertragsendes, des zuständigen Teams und des Zugriffsumfangs registriert werden.

   Wenn Ihre Organisation noch keine CLM-Plattform betreibt, ist Schritt 3 der Punkt, an dem sich diese Investition am deutlichsten auszahlt: Das in Schritt 1 erstellte automatisierte Inventar ist nur dann in großem Umfang nutzbar, wenn es in einem System gespeichert ist, das Warnungen und Workflow-Automatisierungen auslösen kann, wenn sich Vertragsdaten oder Zertifikatsattribute ändern.

   Erstellen Sie einen entsprechenden Offboarding-Checkpoint, der die Zertifikatssperrung als Teil des Lieferantenaustrittsprozesses auslöst, zusammen mit den bereits bestehenden Schritten zur Entfernung des Benutzerkontos und des VPN.

4. Kurze Gültigkeitsdauern für alle Lieferantenzertifikate durchsetzen
   Vermeiden Sie die Ausstellung von langlebigen Zertifikaten für Anbieterintegrationen aus Gründen der betrieblichen Bequemlichkeit. Kurze Gültigkeitsdauern Eine Gültigkeitsdauer von 90 Tagen oder weniger schafft einen natürlichen Revalidierungszyklus, der bestätigt, dass die Geschäftsbeziehung zum Anbieter weiterhin besteht und das Zertifikat weiterhin erforderlich ist. Läuft ein Zertifikat ohne Verlängerung ab, wird der Zugriff automatisch beendet und bleibt nicht unbegrenzt bestehen.

5. Prüfen Sie regelmäßig, ob Zertifikate ihre Vertragslaufzeit überschritten haben.
   Selbst mit verbesserter Governance werden bestehende Umgebungen noch Zertifikate aus früheren Lieferantenbeziehungen enthalten. Planen Sie vierteljährliche Prüfungen ein, die speziell darauf abzielen, Zertifikate mit abgelaufenen Verträgen zu identifizieren. Diese stellen unbefugte Sicherheitslücken dar, die vor der Einführung der Governance entstanden sind.

Sicherheitsüberlegungen

Eine verbesserte Verwaltung von Drittanbieterzertifikaten verringert eine reale und oft unterschätzte Angriffsfläche. Der Übergang erfordert zudem Sicherheitsentscheidungen, die sorgfältige Beachtung verdienen.

Bei der Migration von Client -Authentifizierungszertifikaten öffentlicher Zertifizierungsstellen auf Zertifikate privater Zertifizierungsstellen ist eine sorgfältige Abstimmung mit jedem einzelnen Anbieter unerlässlich. Ein Zertifikat, das aufgrund einer Änderung der Zertifizierungsstellenrichtlinien unerwartet und nicht im Rahmen einer geplanten Umstellung nicht mehr funktioniert, führt sowohl zu Betriebsunterbrechungen als auch zu einem erhöhten Aufwand für die Sicherheitsmaßnahmen.

Kurze Gültigkeitsdauern für Anbieterzertifikate dienen der Sicherheit und stellen keine administrative Belastung dar. Anträge von Anbietern auf Verlängerung der Zertifikatsgültigkeit aus betrieblichen Gründen sollten abgelehnt werden. Der Aufwand für die Erneuerung ist der Alternative – einem Zertifikat, das zwei Jahre lang ohne Überprüfung gültig bleibt – vorzuziehen.

Richten Sie ein formelles Verfahren zur Notfallentziehung von Lieferantenzertifikaten ein, das innerhalb von Stunden, nicht Tagen, umgesetzt werden kann. Wenn eine Lieferantenbeziehung unter ungünstigen Umständen endet oder ein Lieferant Sie über einen Sicherheitsvorfall informiert, ist die Möglichkeit, alle mit diesem Lieferanten verbundenen Zertifikate unverzüglich zu widerrufen, eine entscheidende Maßnahme zur Reaktion auf Sicherheitsvorfälle.

Überwachen Sie die Nutzung von Herstellerzertifikaten außerhalb der Geschäftszeiten oder von unerwarteten Quelladressen. Ein gültiges Zertifikat, das von einer IP-Adresse aus eine Verbindung herstellt, die nicht dem Hersteller gehört, ist nicht zwangsläufig ein Verschulden des Herstellers; es kann darauf hindeuten, dass das Zertifikat gestohlen oder die Systeme des Herstellers kompromittiert wurden.

Bei Anbieterintegrationen mit Zugriff auf sensible Systeme oder regulierte Daten sollten jährliche Zertifikatsprüfungen in die Vertragsverlängerungsprozesse integriert werden. Die Zertifikatsverlängerung sollte als bewusste Entscheidung und nicht als passive Standardeinstellung betrachtet werden.

Wie Verschlüsselungsberatung hilft

Encryption Consulting arbeitet mit Unternehmen zusammen, um die Governance-Lücke zwischen Zertifikatslebenszyklusmanagement und Lieferantenrisikomanagement zu schließen. Dabei werden Programme entwickelt, die sicherstellen, dass Zertifikate von Drittanbietern im Rahmen des standardmäßigen Lieferantenlebenszyklus erkannt, verwaltet und widerrufen werden und nicht erst im Nachhinein berücksichtigt werden.

Unsere Beratungsleistungen beginnen mit einer Bewertung der Zertifikate von Drittanbietern: Wir ermitteln alle Zertifikate, die sich derzeit in Ihrer Umgebung befinden und an oder für externe Parteien ausgestellt wurden, ordnen sie aktiven und abgelaufenen Lieferantenbeziehungen zu und erstellen ein priorisiertes Risikoinventar der Zertifikate, die überprüft, erneuert oder widerrufen werden sollten.

Für Organisationen, die bereit sind, CertSecure Manager einzusetzen , integriert unser Implementierungsteam den Zertifikatslebenszyklus in Ihre bestehenden Offboarding-Workflows für Anbieter, baut die für die Clientauthentifizierung benötigte private CA-Infrastruktur auf und richtet die Überwachung und Alarmierung ein, die eine nachhaltige, fortlaufende Governance gewährleisten.

CertSecure Manager

CertSecure Manager ist die Enterprise-Zertifikatslebenszyklusmanagement-Plattform von Encryption Consulting. Sie wurde entwickelt, um Sicherheits- und Betriebsteams eine zentrale Übersicht und Kontrolle über ihren gesamten Zertifikatsbestand zu ermöglichen, einschließlich der Zertifikate von Drittanbietern und Integrationszertifikate, die von externen Tools nicht erreicht werden können.

Speziell für die Verwaltung von Drittanbieterzertifikaten bietet CertSecure Manager Funktionen zur Erkennung und Durchsetzung von Richtlinien, die das Zertifikatslebenszyklusmanagement (CLM) mit dem Anbieterlebenszyklusmanagement verbinden. Die Erkennung identifiziert alle aktuell in der Umgebung vorhandenen Zertifikate, einschließlich der an externe Organisationen ausgestellten, und normalisiert sie in einem einheitlichen Inventar mit Eigentümerzuordnung und Ablaufverfolgung.

Die Durchsetzung von Richtlinien kann so konfiguriert werden, dass Zertifikate, die mit abgelaufenen Lieferantenverträgen verknüpft sind, gekennzeichnet werden, Widerrufs-Workflows ausgelöst werden, wenn Ereignisse der Abmeldung von Lieferanten auftreten, und eine Warnung ausgegeben wird, wenn sich ein Zertifikat dem Ablaufdatum nähert, ohne dass eine Verlängerungs- oder Widerrufsentscheidung in Bearbeitung ist.

• Automatische Erkennung: Erkennung von Zertifikaten Dritter in allen Umgebungen, mit Subjekt- und ausstellender CA-Analyse zur Identifizierung von Zertifikaten, die an externe Entitäten ausgestellt wurden.
• Zuordnung der Eigentumsverhältnisse der Lieferanten: Zuordnung der Eigentumsrechte, die jedes gefundene Zertifikat mit einer Lieferantenbeziehung, dem Vertragsinhaber und dem Ablaufdatum verknüpft und so die CLM-Daten mit dem Lieferantenmanagementkontext verbindet.
• Offboarding-Integration: Integration eines Widerrufs-Workflows, der durch Ereignisse im Zusammenhang mit dem Ausscheiden von Anbietern ausgelöst werden kann, um sicherzustellen, dass der Zertifikatswiderruf als Teil des standardmäßigen Vertragsaustrittsprozesses und nicht als separater, leicht zu vergessender Schritt erfolgt.
• Durchsetzung der Gültigkeit: Durchsetzung kurzer Gültigkeitsdauern für alle anbieterseitigen Zertifikate mit automatisierten Verlängerungsanfragen und Benachrichtigungen, wenn sich Zertifikate dem Ablaufdatum nähern, ohne dass eine klare Entscheidung über Verlängerung oder Widerruf vorliegt.
• Private CA-Integration für Client-Authentifizierung: Unterstützung für die Bereitstellung oder Integration mit privater CA-Infrastruktur zur Ausstellung von Client-Authentifizierungszertifikaten für Anbieterintegrationen, wodurch sichergestellt wird, dass die mTLS-Anmeldeinformationen des Anbieters den eigenen Richtlinien Ihres Unternehmens unterliegen und nicht von öffentlichen CA-Richtlinien abhängig sind, die sich ständig weiterentwickeln.

Das Lieferkettenrisiko innerhalb Ihres Netzwerks ist keine neue Bedrohungskategorie. Es handelt sich vielmehr um eine Governance-Lücke im Bereich der Zugangsdaten, die die meisten Organisationen bisher nicht systematisch verwaltet haben. Diejenigen Organisationen, die diese Lücke jetzt schließen, werden sich später nicht mehr erklären müssen, warum ein Lieferant, dessen Vertrag vor einem Jahr ausgelaufen ist, immer noch Zugriff auf ein Produktionssystem hatte.

Fazit

Bei Beendigung einer Geschäftsbeziehung mit einem Lieferanten wird die Checkliste für das Offboarding abgearbeitet: Benutzerkonten werden deaktiviert, der VPN-Zugang widerrufen und API-Schlüssel deaktiviert. Das Zertifikat (die gegenseitige TLS-Berechtigung, die die Systeme des Lieferanten zur Authentifizierung an Ihrem API-Gateway, Ihren internen Diensten und Ihren Integrationsendpunkten verwenden) bleibt jedoch gültig und aktiv, ohne dass es in einen Offboarding-Prozess eingebunden oder in einem System erfasst wird, das der Sicherheit oder dem Lieferantenrisikomanagement unterliegt.

Dies ist keine seltene Konfiguration. Sie ist die Norm in Unternehmensumgebungen, in denen Zertifikatslebenszyklusmanagement und Lieferantenrisikomanagement bisher nicht miteinander verknüpft waren. 85 % der CISOs können Bedrohungen durch Drittanbieter nur innerhalb ihres direkten Lieferantennetzwerks erkennen, 70 % erlebten im letzten Jahr einen schwerwiegenden Vorfall mit einem Drittanbieter, und 61 % waren von einem Sicherheitsvorfall durch einen Drittanbieter betroffen: Die Lücke bei den Anmeldeinformationen innerhalb des Netzwerkperimeters trägt maßgeblich und unterschätzt zu all diesen Zahlen bei.

Die Umstellung der Richtlinien öffentlicher Zertifizierungsstellen für die Clientauthentifizierung zwischen 2025 und 2026, die die Client Authentication EKU aus öffentlich vertrauenswürdigen TLS-Zertifikaten entfernte, wirkte als erzwungener Schritt. Organisationen, die bisher auf Zertifikate öffentlicher Zertifizierungsstellen für herstellerspezifisches mTLS angewiesen waren, müssen auf private PKI umsteigen. Und genau diese Art von Anmeldeinformationen erfordert ein umfassendes Lebenszyklusmanagement, das die meisten Organisationen noch nicht implementiert haben.

Um mehr darüber zu erfahren, wie CertSecure Manager Unternehmen bei der Ermittlung und Verwaltung von Drittanbieterzertifikaten unterstützt, oder um eine Bewertung von Drittanbieterzertifikaten mit unserem Team zu besprechen, wenden Sie sich bitte an Encryption Consulting.