Leitfaden zur Lieferkettensicherheit: Lieferantenrisiken, Vorschriften und Zugangskontrolle 2026

Noch vor wenigen Jahren war der Standardrat einfach: Prüfen Sie Ihre Anbieter, unterzeichnen Sie eine Geheimhaltungsvereinbarung, führen Sie einen jährlichen Fragebogen durch. Dann kam SolarWinds, dann MOVEit, dann XZ Utils — eine Hintertür, die über zwei Jahre legitimer Open-Source-Beiträge eingeschleust und von einem Ingenieur entdeckt wurde, dem auffiel, dass ein Prozess 500 ms langsamer lief als erwartet. Jeder dieser Angriffe erfolgte über eine vertrauenswürdige Beziehung.

Das Muster ist bei jedem größeren Vorfall gleich. Die Beteiligung von Drittanbietern macht laut Verizons 2026 DBIR mittlerweile 48 % aller Datenschutzverletzungen aus (gegenüber 30 % im Vorjahr), und die durchschnittliche Kompromittierung der Lieferkette kostet 4,91 Millionen US-Dollar und benötigt 267 Tage zur Eindämmung, laut IBMs Cost of a Data Breach Report 2025. 

Die meisten Organisationen reagieren weiterhin mit Fragebögen und jährlichen Audits. Diese haben ihren Platz. Aber ein Fragebogen verhindert keine Sicherheitsverletzung. Das Widerrufen der permanenten Berechtigungen eines Anbieters schon. Dieser Leitfaden behandelt Lieferkettensicherheit als das, was sie tatsächlich ist: ein IAM- und Credential-Control-Problem mit einer Compliance-Ebene darüber.

Wichtige Erkenntnisse

• Die Beteiligung von Drittanbietern macht mittlerweile 48 % aller Datenschutzverletzungen aus — gegenüber 30 % im Vorjahr, laut Verizons 2026 DBIR. Lieferkettenangriffe sind der dominierende Angriffsvektor.
• Die durchschnittliche Kompromittierung der Lieferkette kostet 4,91 Millionen US-Dollar und benötigt 267 Tage zur Eindämmung. Diese Verweildauer macht permanente Anbieterberechtigungen so gefährlich — Angreifer müssen sich nicht beeilen, wenn die Anmeldedaten nie ablaufen.
• Jeder größere Lieferkettenvorfall erfolgte über eine vertrauenswürdige Beziehung. SolarWinds, MOVEit, XZ Utils — in jedem Fall nutzte der Angreifer Zugriff, der bereits bereitgestellt und bereits als vertrauenswürdig eingestuft war.
• Fragebögen und jährliche Audits verhindern keine Sicherheitsverletzungen. Das Widerrufen permanenter Anbieterberechtigungen schon. Die entscheidenden Kontrollen sind technischer Natur: Credential-Vaulting, JIT-Zugriff, RBAC mit Beschränkung auf den Auftrag und Phishing-resistente MFA.
• NIS2, DORA und der EU Cyber Resilience Act machen Lieferkettensicherheit zur gesetzlichen Pflicht. NIS2 Artikel 21, DORA Artikel 28–30 und CRA-Anforderungen gelten mit gestaffelten Fristen bis 2027.
• 70 % der Top-50-Anbieter, die von Global-2000-Unternehmen gemeinsam genutzt werden, weisen mindestens eine ungepatchte KEV-Schwachstelle auf, laut Black Kites Third-Party Breach Report 2026.

Was ist Cyber Supply Chain Risk Management (C-SCRM)?

Cyber Supply Chain Risk Management (C-SCRM) ist die Disziplin der Identifizierung, Bewertung und Minderung von Cybersicherheitsrisiken, die aus dem erweiterten Netzwerk von Lieferanten, Anbietern, Dienstleistern und Software-Abhängigkeiten einer Organisation stammen. Es umfasst alles von den SaaS-Tools, die Ihre Entwickler nutzen, bis hin zum Managed Service Provider (MSP) mit Admin-Zugriff auf Ihre Produktionsumgebung.

C-SCRM liegt an der Schnittstelle von Beschaffung, IT-Sicherheit und Compliance. NIST SP 800-161 Rev. 1 bietet das detaillierteste föderale Framework dafür und definiert C-SCRM als strukturierten Prozess zur Steuerung der Exposition gegenüber Cybersicherheitsrisiken während des gesamten Lieferketten-Lebenszyklus — von der ersten Anbieterauswahl bis zur Vertragsbeendigung und Zugriffsentzug.

Der Umfang ist größer, als den meisten Teams bewusst ist. Ihre Lieferkette umfasst:

• Softwareanbieter und Open-Source-Abhängigkeiten
• Cloud-Infrastruktur und SaaS-Anbieter
• Managed-Service- und IT-Support-Anbieter
• Hardwarehersteller und Firmware-Lieferanten
• Beratungsunternehmen mit Netzwerk- oder Datenzugriff

Jeder dieser Bereiche ist ein potenzieller Eintrittspunkt. Die Vorfälle SolarWinds, MOVEit und XZ Utils nutzten diesen Eintrittspunkt auf unterschiedliche Weise aus.

Der Stand der Lieferkettenangriffe 2025–2026

Lieferkettenangriffe erreichten 2025–2026 Rekordniveaus. Verizons 2026 DBIR verzeichnete eine Drittanbieterbeteiligung bei 48 % aller analysierten Sicherheitsverletzungen — der höchste Wert in der Geschichte des Berichts und ein Anstieg um 60 % gegenüber den 30 % des Vorjahres. IBMs Cost of a Data Breach Report 2025 beziffert die durchschnittliche Kompromittierung der Lieferkette auf 4,91 Millionen US-Dollar mit einem durchschnittlichen Lebenszyklus von 267 Tagen von der Erkennung bis zur Eindämmung.

Bedrohungsakteure haben gelernt, dass die Kompromittierung eines vertrauenswürdigen Anbieters gleichzeitig Zugang zu Dutzenden oder Hunderten von nachgelagerten Organisationen ermöglicht. Die Wirtschaftlichkeit begünstigt den Angreifer: ein erfolgreicher Einbruch, multipliziert über die gesamte Kundenbasis eines Anbieters.

Laut Black Kites Third-Party Breach Report 2026 weisen 70 % der Top-50-Anbieter, die von Global-2000-Unternehmen gemeinsam genutzt werden, mindestens eine ungepatchte Schwachstelle aus dem CISA Known Exploited Vulnerabilities (KEV) Katalog auf. Dies sind keine theoretischen Risiken — CISA kennzeichnet KEV-Einträge speziell deshalb, weil sie aktiv in freier Wildbahn ausgenutzt werden.

Lehren aus SolarWinds, MOVEit und XZ Utils

Alle drei Vorfälle haben einen gemeinsamen Nenner: Der initiale Zugriffsvektor war vertrauenswürdig. Vertrauenswürdige Software, vertrauenswürdiger Anbieter, vertrauenswürdiger Mitwirkender. Einmal drinnen, bewegte sich der Angreifer lateral mit Anmeldedaten und Zugriff, die bereits bereitgestellt waren.

SolarWinds (2020)

Angreifer kompromittierten die Build-Pipeline direkt und fügten eine Hintertür in ein signiertes Software-Update ein, das als routinemäßiger Patch an Kunden verteilt wurde. Etwa 18.000 Organisationen installierten es. Die rechtlichen Folgen zogen sich über Jahre hin: Die SEC reichte im Oktober 2023 eine zivilrechtliche Klage gegen SolarWinds und seinen CISO ein, wobei der Fall schließlich 2025 vollständig abgewiesen wurde.

Die Lehre: Kontrollen der Software-Integrität und SBOM-Transparenz (Software Bill of Materials) sind genauso wichtig wie Netzwerkperimeterkontrollen — und die Haftungsexposition durch eine Build-Pipeline-Kompromittierung reicht weit über die ursprüngliche Sicherheitsverletzung hinaus.

MOVEit (2023)

Eine Zero-Day-SQL-Injection-Schwachstelle (CVE-2023-34362) in einem Managed-File-Transfer-Produkt gab der Cl0p-Ransomware-Gruppe Zugang zu Daten von über 2.700 Organisationen — von denen viele keine direkte Beziehung zu MOVEit hatten, aber durch die Nutzung bei ihren Anbietern betroffen waren. Die endgültige Opferzahl erreichte etwa 95 Millionen Personen. 

Die Lehre: Ihre Angriffsfläche umfasst Software, die Ihre Anbieter betreiben, nicht nur Software, die Sie selbst betreiben.

XZ Utils (2024)

Eine mehrjährige Social-Engineering-Kampagne fügte eine Hintertür in eine weit verbreitete Open-Source-Kompressionsbibliothek ein. Der Angreifer trug zwei Jahre lang legitimen Code bei, bevor er die schädliche Payload einführte — und die Hintertür wurde nicht durch einen formalen Sicherheitsprozess entdeckt, sondern von einem Microsoft-Ingenieur, dem eine 500-ms-Verzögerung bei SSH-Logins auffiel. 

Die Lehre: Das Risiko von Open-Source-Abhängigkeiten ist real, SBOMs sind der einzige systematische Weg, es zu verfolgen, und Ihre Erkennungskontrollen müssen Verhalten abdecken, nicht nur Signaturen.

Die größten Anbieterrisiken in der modernen Lieferkette

Die fünf häufigsten Kategorien von Lieferkettenrisiken sind:

• Geteilte Anmeldedaten und mangelhafte Zugangskontrolle
• Schwachstellen in Software-Abhängigkeiten
• Hardware- und Komponenten-Manipulation
• Shadow AI und Datenexposition durch Dritte
• Anbieter-Konzentrationsrisiko

Jede erfordert eine eigene Kontrollmaßnahme. Fehler bei geteilten Anmeldedaten sind ein Prozessproblem. Hardware-Manipulation erfordert physische Herkunftsverifizierung.

Geteilte Anmeldedaten und mangelhafte Zugangskontrolle

Das häufigste und am leichtesten vermeidbare Lieferkettenrisiko ist auch das am wenigsten spektakuläre: gemeinsam genutzte Konten. Ein Anbieter-Support-Team erhält einen einzigen Satz Anmeldedaten für den Zugriff auf Ihre Umgebung. Diese Anmeldedaten werden unter den Mitarbeitern des Anbieters geteilt, in einer Tabelle oder E-Mail-Kette gespeichert und nach Ende des Auftrags nie rotiert.

Wenn dieser Anbieter kompromittiert wird oder ein verärgerter Mitarbeiter das Unternehmen verlässt, haben Sie keine Möglichkeit zu wissen, wer diese Anmeldedaten wann verwendet hat oder worauf zugegriffen wurde. Sie haben keinen Audit-Trail. Sie haben keine Möglichkeit, den Zugriff für eine einzelne Person zu widerrufen, ohne die Anmeldedaten für alle zu ändern.

Verizons 2026 DBIR identifiziert Authentifizierungsfehler (fehlende oder umgangene MFA, gestohlene Anmeldedaten) als den primären Mechanismus bei Drittanbieter-Sicherheitsverletzungen. Dies ist ein Prozessfehler.

Schwachstellen in der Software-Lieferkette und die Notwendigkeit von SBOMs

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten eines Softwareprodukts: Bibliotheken, Abhängigkeiten, Versionen und ihre bekannten Schwachstellen. Die U.S. Executive Order 14028 (2021) schrieb SBOMs für Software vor, die an Bundesbehörden verkauft wird. Der EU Cyber Resilience Act (CRA) erweitert ähnliche Anforderungen auf Produkte, die auf dem europäischen Markt verkauft werden, wobei Schwachstellen-Meldepflichten ab September 2026 und vollständige Produktanforderungen ab Dezember 2027 gelten.

Ohne eine SBOM können Sie die Frage „Nutzen wir die verwundbare Version von Log4j?" nicht innerhalb von 24 Stunden beantworten. Mit einer schon. Dieser Geschwindigkeitsunterschied ist die Lücke zwischen einem eingedämmten Vorfall und einer Sicherheitsverletzung, deren Behebung 267 Tage dauert.

Hardware- und Komponenten-Manipulation

Das Hardware-Lieferkettenrisiko unterscheidet sich vom Softwarerisiko und wird oft unterschätzt. Gefälschte oder manipulierte Komponenten — Netzwerkausrüstung, Server-Hardware, Firmware — können persistente Hintertüren einführen, die eine Betriebssystem-Neuinstallation überleben und für Software-Layer-Sicherheitskontrollen unsichtbar sind.

Der EU Cyber Resilience Act adressiert explizit Hardwareprodukte mit digitalen Elementen und verlangt von Herstellern, die Lieferkettensicherheit für physische Komponenten zu bewerten und zu dokumentieren. Für Organisationen, die Netzwerkinfrastruktur oder industrielle Steuerungssysteme beschaffen, bedeutet dies die Verifizierung der Komponentenherkunft, das Anfordern von Firmware-Integritätsnachweisen von Lieferanten und die Führung eines Inventars von Hardware-Versionen, das einer Software-SBOM entspricht.

Shadow AI und Datenexposition durch Dritte

Verizons 2026 DBIR identifiziert Shadow AI als eines der drei größten Insider-Verhaltensweisen — Mitarbeiter, die nicht autorisierte KI-Tools nutzen, die Organisationsdaten außerhalb genehmigter Kanäle verarbeiten. Der Lieferkettenaspekt: Viele dieser Tools sind Drittanbieter-SaaS-Produkte mit eigenen Datenaufbewahrungsrichtlinien, Unterauftragnehmervereinbarungen und Sicherheitslagen, die Ihre Organisation nie überprüft hat.

Wenn ein Entwickler Datenbank-Anmeldedaten in einen KI-Assistenten einfügt, um eine Abfrage zu debuggen, können diese Anmeldedaten aufbewahrt, protokolliert oder für das Modelltraining verwendet werden. Das Anbieterrisiko ist nicht nur der KI-Anbieter — es ist jeder Unterauftragnehmer in deren Kette.

Verfügbarkeitsunterbrechungen und Anbieter-Konzentrationsrisiko

Ein Sicherheitsversagen in der Lieferkette bedeutet nicht immer eine Datenschutzverletzung. Anbieterausfälle, Ransomware-Angriffe auf kritische Lieferanten und Single Points of Failure in gemeinsam genutzter Infrastruktur können den Betrieb vollständig unterbrechen. DORAs Mandat zur operativen Resilienz existiert genau deshalb, weil der EU-Finanzsektor erkannt hat, dass Verfügbarkeitsrisiken durch ICT-Drittanbieter ebenso wesentlich sind wie Vertraulichkeitsrisiken.

Konzentrationsrisiko verstärkt dies: Wenn 70 % der Forbes Global 2000-Unternehmen dieselben Top-50-Anbieter nutzen, verbreitet sich eine einzelne Kompromittierung in großem Maßstab. Die Kartierung Ihrer kritischen Anbieterabhängigkeiten und die Pflege dokumentierter Kontinuitätspläne für Tier-1-Lieferantenausfälle ist eine Anforderung von DORA Artikel 28 für Finanzunternehmen.

Europäische und internationale regulatorische Anforderungen für Lieferkettensicherheit

NIS2, DORA und der EU Cyber Resilience Act bilden zusammen den verbindlichen regulatorischen Rahmen für Lieferkettensicherheit auf dem europäischen Markt. NIST CSF 2.0 und SP 800-161 sind US-Frameworks — keine EU-Rechtsverpflichtungen — werden aber von multinationalen Organisationen weitgehend referenziert und bieten operatives Detail, das die EU-Anforderungen ergänzt.

NIS2-Richtlinie (Artikel 21)

NIS2 Artikel 21 verlangt von den betroffenen Einrichtungen die Implementierung von „Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen jeder Einrichtung und ihren direkten Lieferanten oder Dienstleistern." Dies ist eine rechtliche Verpflichtung für wesentliche und wichtige Einrichtungen in 18 Sektoren, deren Durchsetzung die EU-Mitgliedstaaten Ende 2024 begonnen haben.

In der Praxis bedeutet Artikel 21, dass Sie die Sicherheitslage Ihrer direkten Anbieter bewerten, Sicherheitsanforderungen in Verträge aufnehmen und einen dokumentierten Prozess für das Management von anbieterbezogenen Vorfällen pflegen müssen. Für das Credential-Management bedeutet dies konkret: keine gemeinsam genutzten Konten, dokumentierte Verfahren für Zugriffsbereitstellung und -entzug sowie Audit-Protokolle, die bei einer Aufsichtsprüfung vorgelegt werden können.

Eine detaillierte Aufschlüsselung, wie NIS2 auf Zugangskontrollanforderungen abbildet, finden Sie im NIS2-Compliance-Leitfaden von Passwork.

DORA (Digital Operational Resilience Act)

DORA gilt für Finanzunternehmen und ihre ICT-Drittanbieter, die in der EU tätig sind. Die Artikel 28 bis 30 etablieren ein detailliertes ICT-Drittanbieter-Risikomanagement-Framework, einschließlich der Anforderungen, ein Register aller ICT-Anbieter zu führen, Risikobewertungen vor dem Onboarding durchzuführen und sicherzustellen, dass Verträge Bestimmungen für Auditrechte und Vorfallsmeldungen enthalten.

DORA führt auch das Konzept der „kritischen ICT-Drittanbieter" (CTPPs) ein, die von den europäischen Aufsichtsbehörden für direkte Überwachung designiert werden können. Wenn Ihre Organisation ein CTPP ist — oder von einem abhängt — ist die Prüfung Ihrer Lieferketten-Sicherheitskontrollen erheblich strenger. Das oben beschriebene Verfügbarkeitsunterbrechungsrisiko ist ebenso ein DORA-Anliegen wie ein Sicherheitsanliegen: Artikel 28 verlangt ausdrücklich dokumentierte Kontinuitätspläne für kritische Drittanbieterabhängigkeiten.

EU Cyber Resilience Act (CRA)

Der CRA wurde 2024 verabschiedet und gilt mit gestaffeltem Zeitplan. Schwachstellen- und Vorfallsmeldepflichten treten ab dem 11. September 2026 in Kraft. Vollständige Produktanforderungen — einschließlich SBOM-Mandate und Konformitätsbewertungen für Produkte mit digitalen Elementen — gelten ab dem 11. Dezember 2027. Organisationen, die vernetzte Hardware oder Software auf dem EU-Markt verkaufen, müssen jetzt mit der Compliance-Arbeit beginnen; die Frist 2027 kommt schneller, als die meisten Produktentwicklungszyklen zulassen.

NIST CSF 2.0 und NIST SP 800-161

NIST CSF 2.0, veröffentlicht im Februar 2024, fügte „Govern" als sechste Kernfunktion hinzu. Die GV.SC-Unterkategorie adressiert explizit das Lieferketten-Risikomanagement und verlangt von Organisationen, C-SCRM in die unternehmensweite Risiko-Governance zu integrieren — es nicht als separates IT-Projekt zu behandeln. Für EU-Organisationen ist CSF 2.0 keine rechtliche Anforderung, bietet aber eine nützliche operationelle Struktur, die gut auf NIS2- und DORA-Verpflichtungen abbildet.

NIST SP 800-161 Rev. 1 liefert das operationelle Detail: wie Lieferantenbewertungen durchzuführen sind, welche Kontrollen in Verträgen verlangt werden sollen und wie ein C-SCRM-Programm über den gesamten Beschaffungslebenszyklus strukturiert werden kann. Für US-Bundesauftragnehmer wird die Ausrichtung an SP 800-161 zunehmend zur Beschaffungsanforderung.

So sichern Sie den Anbieterzugriff: Der technische Bauplan

Die vier wirkungsvollsten Kontrollen für die Sicherheit des Anbieterzugriffs sind RBAC mit Beschränkung auf den Auftrag, Just-in-Time-Zugriff auf privilegierte Ressourcen, zentralisiertes Credential-Vaulting und Phishing-resistente MFA. In dieser Reihenfolge angewendet, adressieren sie die häufigsten Fehlermodi — permanente Berechtigungen, gemeinsam genutzte Konten und Authentifizierungslücken — ohne in den meisten Umgebungen neue Infrastruktur zu erfordern.

Strikte rollenbasierte Zugriffskontrolle (RBAC) durchsetzen

Rollenbasierte Zugriffskontrolle (RBAC) weist Berechtigungen Rollen zu, nicht Einzelpersonen. Ein Support-Ingenieur des Anbieters erhält die Rolle „Nur-Lese-Produktionsüberwachung", nicht ein persönliches Admin-Konto. Wenn der Auftrag endet, entfernen Sie die Rollenzuweisung. Wenn der Anbieter sein Personal wechselt, müssen Sie keine einzelnen Konten verfolgen — die Rolle definiert, worauf zugegriffen werden kann.

Für den Anbieterzugriff sollte RBAC auf das Minimum beschränkt sein, das für den Auftrag erforderlich ist. Ein Datenbankanbieter, der ein Performance-Audit durchführt, benötigt keinen Schreibzugriff auf die Anwendungskonfiguration. Definieren Sie die Rolle vor der Zugriffsbereitstellung, nicht danach.

Just-in-Time (JIT) privilegierten Zugriff implementieren

Just-in-Time (JIT) Zugriff bedeutet, dass privilegierte Anmeldedaten für ein definiertes Zeitfenster ausgestellt und automatisch widerrufen werden, wenn dieses Fenster geschlossen wird. Ein Anbieter-Ingenieur fordert Zugriff für ein zweistündiges Wartungsfenster an; das System gewährt ihn, protokolliert die Sitzung und widerruft ihn nach zwei Stunden, unabhängig davon, ob der Ingenieur daran denkt, sich abzumelden.

JIT-Zugriff eliminiert permanente Berechtigungen: den persistenten, immer aktiven Zugriff, den Angreifer während der durchschnittlich 267 Tage dauernden Verweildauer einer Lieferketten-Sicherheitsverletzung ausnutzen. Es gibt nichts zu stehlen, wenn die Anmeldedaten ablaufen, bevor der Angreifer sie nutzen kann. JIT ist besonders wirksam für Break-Glass-Szenarien: Notfall-Anbieterzugriff während eines Vorfalls, bei dem Geschwindigkeit wichtig ist, aber auch Verantwortlichkeit.

Sicheres Anbieter-Credential-Vaulting

Gemeinsam genutzte Anbieterkonten sind eine Haftung. Die Alternative ist ein Credential-Vault: ein zentralisierter, verschlüsselter Speicher, in dem Anbieter-Anmeldedaten von Ihrer Organisation gehalten werden, nicht vom Anbieter. Der Anbieter authentifiziert sich am Vault, checkt Anmeldedaten für seine Sitzung aus, und der Vault protokolliert jedes Zugriffsereignis.

Dieser Ansatz gibt Ihnen einen vollständigen Audit-Trail darüber, wer wann auf was zugegriffen hat, die Möglichkeit, Anmeldedaten ohne Abstimmung mit dem Anbieter zu rotieren, automatischen Widerruf bei Ende der Anbieterbeziehung und Compliance-Nachweise für die Auditrechtsanforderungen von NIS2 Artikel 21 und DORA Artikel 30.

Passworks Enterprise-Passwort- und Secrets-Manager unterstützt zeitlich begrenztes Credential-Sharing, Sitzungsprotokollierung und Integration mit AD/LDAP- und SSO-Infrastruktur — mit AES-256-Client-seitiger Verschlüsselung und einer vollständigen REST API für die Integration in bestehende Bereitstellungs-Workflows.

Phishing-resistente MFA für Dritte vorschreiben

MFA ist die einzelne Kontrolle mit dem höchsten ROI für den Drittanbieterzugriff. Verizons 2026 DBIR ordnet die Mehrheit der Drittanbieter-Sicherheitsverletzungsszenarien Authentifizierungsfehlern zu — und die meisten dieser Fehler sind fehlende MFA, nicht umgangene MFA.

Für privilegierten Anbieterzugriff auf Produktionssysteme sollte der Standard Phishing-resistente MFA sein: FIDO2/WebAuthn-Hardwareschlüssel oder Passkeys, nicht SMS OTP. SMS-basierte MFA ist anfällig für SIM-Swapping und Echtzeit-Phishing-Proxies. Fordern Sie Phishing-resistente MFA von Anbietern vertraglich als Zugangsbedingung. Nehmen Sie es in Ihren Anbieter-Sicherheitsanhang auf, nicht nur in Ihre interne Richtlinie.

Die meisten der in diesem Leitfaden beschriebenen Zugangskontrollfehler haben dieselbe Ursache: Anbieter-Anmeldedaten, die nie richtig in einem Vault gespeichert, begrenzt oder widerrufen wurden. Passwork adressiert das direkt — zentralisiertes Credential-Vaulting, rollenbasierter Zugriff, zeitlich begrenztes Teilen und ein vollständiger Audit-Trail, der an benannte Identitäten gebunden ist. Verfügbar als Self-hosted oder als Cloud-Bereitstellung, integriert es sich mit AD/LDAP und SAML SSO und ist ISO 27001 zertifiziert.

Aufbau eines Anbieter-Risikobewertungs-Frameworks

Ein Anbieter-Risikobewertungs-Framework klassifiziert Dritte nach Zugangslevel und wendet verhältnismäßige Sicherheitsanforderungen auf jede Stufe an. Das 5-Stufen-Modell unten skaliert von Tier-1-Anbietern mit privilegiertem Produktionszugriff, die vollständige Sicherheitsbewertungen und jährliche Reviews erfordern — bis hin zu Tier-5-Anbietern ohne Daten- oder Systemzugriff, bei denen Standard-Beschaffungs-Due-Diligence ausreicht.

Das 5-Stufen-Anbieter-Risikoklassifizierungsmodell:

Die Klassifizierung bestimmt den verhältnismäßigen Aufwand. Sie benötigen keinen vollständigen Penetrationstestbericht von Ihrem Bürobedarfslieferanten. Von dem MSP mit Admin-Zugriff auf Ihr Active Directory schon.

Checkliste für Anbieterzugangskontrolle

Die folgende Pre-Audit-Checkliste für Anbieterzugriff bildet direkt auf die Anforderungen von NIS2 Artikel 21, DORA Artikel 28 und NIST SP 800-161 ab. Verwenden Sie sie beim Anbieter-Onboarding und bei jeder jährlichen Überprüfung.

Vor der Zugriffsbereitstellung:

•  Anbieter nach Stufe basierend auf Zugangslevel klassifiziert
•  Minimaler notwendiger Zugriffsumfang schriftlich definiert
•  Benannte Personen identifiziert (keine gemeinsam genutzten/generischen Konten)
•  MFA-Anforderung bestätigt und getestet
•  Zugriff über Credential-Vault bereitgestellt, nicht durch direkte Weitergabe von Anmeldedaten
•  Sitzungsprotokollierung aktiviert

Während des Auftrags:

•  Zugriffsumfang überprüft, wenn sich der Auftragsumfang ändert
•  Ungewöhnliche Zugriffsmuster zur Überprüfung gekennzeichnet
•  Anbieter-Vorfallsbenachrichtigungsklausel im Vertrag aktiv

Zugriffsentzug:

•  Offboarding-Auslöser definiert (Vertragsende, Personalwechsel, Vorfall)
•  Anmeldedaten sofort beim Offboarding rotiert
•  Vault-Zugriff widerrufen und Audit-Protokoll exportiert
•  Zugriffsüberprüfung für Compliance-Unterlagen dokumentiert

Fazit: Lieferkettensicherheit operationalisieren

Organisationen, die dies gut handhaben, haben nicht weniger Anbieter; sie haben strengere Kontrollen darüber, wie sich diese Anbieter authentifizieren, worauf sie zugreifen können und für wie lange.

Der technische Bauplan ist klar: Anbieter nach Zugriffsstufe klassifizieren, gemeinsam genutzte Konten eliminieren, Anmeldedaten zentral in einem Vault speichern, JIT-Zugriff für privilegierte Sitzungen durchsetzen und Phishing-resistente MFA verlangen. NIS2, DORA und der CRA bieten die Governance-Struktur und die vertragliche Hebelwirkung, um Anbieter am selben Standard zu messen.

Beginnen Sie mit Ihren Tier-1-Anbietern — denen mit privilegiertem Zugriff auf Produktionssysteme. Prüfen Sie deren aktuellen Zugriffsumfang, bestätigen Sie die Zuweisung einzelner Konten und verifizieren Sie, dass MFA aktiv ist. Dieser einzelne Durchgang wird mehr handlungsfähiges Risiko aufdecken als ein Jahr voller Fragebögen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Lieferkettensicherheit und Anbieter-Risikomanagement?

Anbieter-Risikomanagement (Vendor Risk Management, VRM) ist die breitere Disziplin, die finanzielle, operative, reputationsbezogene und Cyber-Risiken von Dritten abdeckt. Lieferkettensicherheit ist die cybersicherheitsspezifische Untermenge: der Schutz von Systemen, Daten und Software-Integrität vor Bedrohungen, die über Lieferantenbeziehungen eintreten. VRM informiert Beschaffungsentscheidungen; Lieferkettensicherheit regelt technische Zugriffskontrollen und Software-Integrität.

Welche Vorschriften erfordern Lieferketten-Sicherheitskontrollen in 2025–2026?

NIS2-Richtlinie Artikel 21 verlangt von wesentlichen und wichtigen EU-Einrichtungen, Lieferantensicherheitsrisiken zu bewerten und zu managen. DORA Artikel 28–30 erlegt EU-Finanzunternehmen ICT-Drittanbieter-Risikomanagement-Verpflichtungen auf. Der EU Cyber Resilience Act verlangt Schwachstellenmeldungen ab September 2026 und vollständige SBOM- und Konformitätsanforderungen ab Dezember 2027. In den USA setzen NIST SP 800-161 und Executive Order 14028 C-SCRM-Erwartungen für Bundesauftragnehmer.

Was ist Just-in-Time (JIT) Zugriff und warum ist er für Anbietersicherheit wichtig?

JIT-Zugriff stellt privilegierte Anmeldedaten für ein definiertes Zeitfenster aus und widerruft sie automatisch, wenn dieses Fenster geschlossen wird. Er eliminiert permanente Berechtigungen — persistenten Zugriff, den Angreifer während der für Lieferketten-Sicherheitsverletzungen typischen verlängerten Verweildauer ausnutzen. IBMs Daten von 2025 zeigen, dass Lieferkettenkompromittierungen durchschnittlich 267 Tage benötigen, um identifiziert und eingedämmt zu werden; JIT-Zugriff reduziert das ausnutzbare Fenster auf Stunden, nicht Monate.

Wie reduzieren SBOMs das Lieferkettenrisiko?

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Softwarekomponenten und ihrer Versionen. Wenn eine neue Schwachstelle offengelegt wird — wie Log4Shell 2021 — ermöglicht Ihnen eine SBOM, innerhalb von Minuten festzustellen, ob eines Ihrer Systeme oder eine vom Anbieter bereitgestellte Software die betroffene Komponente enthält. Ohne SBOM kann dieselbe Feststellung Tage oder Wochen dauern, während derer die Schwachstelle ungepatcht und ausnutzbar bleibt.

Was sollte ein Anbieter-Sicherheitsvertragsanhang enthalten?

Mindestens: eine Anforderung für benannte einzelne Konten (keine gemeinsam genutzten Anmeldedaten), Phishing-resistente MFA für privilegierten Zugriff, Benachrichtigungspflichten innerhalb von 24–72 Stunden nach einem Sicherheitsvorfall, Auditrechte, die Ihrer Organisation die Überprüfung von Zugriffsprotokollen ermöglichen, und ein definierter Offboarding-Prozess einschließlich Credential-Rotation. NIS2 Artikel 21 und DORA Artikel 30 verlangen beide vertragliche Sicherheitsbestimmungen — der Anhang ist Ihr Compliance-Nachweis.

Wie sollten Organisationen Anbieter für Risikobewertungszwecke klassifizieren?

Klassifizieren Sie nach Zugangslevel, nicht nach Vertragswert oder Anbietergröße. Ein kleines Beratungsunternehmen mit Admin-Zugriff auf Ihre Produktionsumgebung ist risikoreicher als ein großer Softwareanbieter ohne direkten Systemzugriff. Das oben dargestellte 5-Stufen-Anbieter-Risikoklassifizierungsmodell bietet eine praktische Struktur: Tier 1 (privilegierter Produktionszugriff) bis Tier 5 (kein Daten- oder Systemzugriff), mit entsprechend skalierten Bewertungsanforderungen und Überprüfungshäufigkeiten.

Was ist der häufigste Zugangskontrollfehler bei Drittanbieter-Sicherheitsverletzungen?

Gemeinsam genutzte Anmeldedaten ohne individuelle Verantwortlichkeit. Ein einzelner Satz Anmeldedaten, der einem Anbieterteam ausgestellt, außerhalb eines Vaults gespeichert, nie rotiert und nie widerrufen wird, wenn der Auftrag endet. Verizons 2026 DBIR identifiziert Authentifizierungsfehler als den primären Mechanismus bei Drittanbieter-Sicherheitsverletzungsszenarien. Die Lösung sind einzelne benannte Konten, Credential-Vaulting und ein dokumentierter Offboarding-Prozess — nicht komplexere Technologie.

Was ist Hardware-Lieferkettenrisiko und wie unterscheidet es sich vom Software-Lieferkettenrisiko?

Hardware-Lieferkettenrisiko umfasst gefälschte oder manipulierte physische Komponenten — Netzwerkausrüstung, Server-Hardware, Firmware — die persistente Hintertüren einführen können, die für Software-Layer-Sicherheitskontrollen unsichtbar sind. Im Gegensatz zu Software-Schwachstellen überlebt Hardware-Manipulation eine Betriebssystem-Neuinstallation. Der EU Cyber Resilience Act adressiert dies direkt und verlangt von Herstellern, die Lieferkettensicherheit für Hardwareprodukte mit digitalen Elementen zu dokumentieren.

Einblick in reale Lieferkettenangriffe: Bitwarden CLI, Axios und Vercel

Warum Ihr Netzwerk kompromittieren, wenn Angreifer eine vertrauenswürdige Abhängigkeit mit Millionen von Downloads kompromittieren und sich lautlos in Tausende von Organisationen gleichzeitig einschleichen können? Drei Kampagnen aus 2026 beweisen, dass Lieferkettenangriffe keine Einzelfälle mehr sind.

Passwork BlogAlex Muntyan

Shadow IT vs. Shadow AI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. Hier erfahren Sie, wie das Risiko tatsächlich aussieht und was die Governance adressieren muss.

Passwork BlogAlex Muntyan

NIS2-Zugriffskontrollen für Lieferkettensicherheit

48 % der Sicherheitsverletzungen betreffen jetzt Dritte. NIS2 Artikel 21 macht die Lieferanten-Zugriffs-Governance zur gesetzlichen Pflicht. Hier erfahren Sie, wie Sie den Anbieterzugriff kartieren, MFA und Least Privilege durchsetzen und die Audit-Nachweise aufbewahren, die beweisen, dass Ihre Kontrollen funktionieren.

Passwork BlogAlex Muntyan