Risiko durch Drittanbieterzugriffe: Was in Dänemark schieflief

Das Risiko durch Drittanbieterzugriffe ist die Gefährdung, die entsteht, wenn Dienstleister, Auftragnehmer oder Integrationspartner Zugangsdaten zu Ihren Systemen oder Daten besitzen. Wie groß dieses Risiko sein kann, hat Dänemark im Oktober 2026 offengelegt: Ein Angreifer nutzte den legitimen Zugriff eines IT-Unternehmens mit zwei Mitarbeitern auf das nationale Einwohnerregister und legte Daten von rund 8,8 Millionen Menschen offen.

Die gemeldete Ursache ist alltäglich. Mindestens drei Konten beim Dienstleister Pays ApS stehen mit dem Datenleck in Verbindung, die Admins des Unternehmens verwendeten Berichten zufolge das Passwort „123456“, und der Zugriff bestand 21 Tage und 17 Stunden, bevor die Administratoren des Registers davon erfuhren.

Was in Dänemark geschah und warum es um Dienstleisterzugriffe geht

Im September 2026 nutzte ein Angreifer den legitimen Registerzugriff von Pays ApS, einem dänischen IT-Unternehmen mit zwei Mitarbeitern, um das dänische Zentrale Personenregister (CPR) abzufragen. Betroffen waren rund 8,8 Millionen seiner 11 Millionen Einträge. Der Einstiegspunkt waren die Konten eines Dienstleisters, nicht die Systeme des Registers selbst.

Cybernews berichtete, dass mindestens drei Konten bei Pays ApS mit dem Datenleck in Verbindung stehen und die Admins des Unternehmens Berichten zufolge „123456“ als Passwort verwendeten. Der Geschäftsführer des Unternehmens erklärte gegenüber dem Sender TV 2, dass dessen „legaler Zugriff für die Suche nach Informationen im CPR-System missbraucht wurde“. Laut dem dänischen Zentralen Unternehmensregister hatte das Unternehmen im Juli 2026 zwei Mitarbeiter.

Ein anonymer Angreifer sagte der dänischen Zeitung Politiken, das Eindringen habe mit dem geleakten Passwort eines ehemaligen Mitarbeiters einer kleinen dänischen Firma begonnen, danach hätten zwei Programme Daten aus dem Register abgezogen. Die dänische Datenschutzbehörde erklärte, der Angriff habe eine Form von Brute-Forcing zur Ermittlung gültiger CPR-Nummern umfasst, wie BleepingComputer berichtet.

Als Ursache und Wirkung gelesen: Ein schwaches oder geleaktes Passwort des Dienstleisters verschaffte einem Angreifer dessen Zugriff, dieser Zugriff ermöglichte drei Wochen Enumeration, und die Enumeration lieferte Datensätze zu 8,8 Millionen Menschen.

Eine CPR-Nummer allein reicht nicht aus, um sich als Bürger auszugeben, weil der zweite Faktor des dänischen MitID weiterhin im Weg steht. Cybernews weist darauf hin, dass die Daten Phishing gezielter machen und mit früheren Datenlecks abgeglichen werden können.

Warum die Größe eines Dienstleisters den Schadensradius nicht verkleinert

Die Mitarbeiterzahl eines Dienstleisters hat keinen Einfluss darauf, wie viel Schaden seine Zugangsdaten anrichten können. Der Schadensradius hängt davon ab, worauf ein Konto zugreifen kann, wie viele Daten es pro Stunde abrufen kann und wie viele Logins existieren. Ein Unternehmen mit zwei Mitarbeitern und Suchzugriff auf ein Register mit 11 Millionen Einträgen trägt dasselbe Risiko wie ein großes.

Cybernews erklärt, warum ein so kleines Unternehmen diesen Zugriff hatte: Organisationen können autorisierten Zugriff auf bestimmte Registerdaten erhalten, um Kundenadressen zu überprüfen oder Mitgliederverzeichnisse zu pflegen. Die Folge ist nach den Worten von Cybernews, dass „die Sicherheit des Registers zum Teil von den Sicherheitspraktiken der Organisationen abhängt, die es abfragen dürfen“.

Die meisten Unternehmen haben dieselbe Struktur in ihrem eigenen Stack: einen Zahlungsdienstleister mit API-Schlüsseln für Kundendaten, einen Managed Service Provider mit Domain-Admin-Rechten, eine Agentur mit Zugriff auf das Produktiv-CMS. Bewerten Sie jeden davon anhand von vier Kriterien, bevor Sie irgendeinen Zugriff gewähren.

„Für ein Programm zur Steuerung von Dienstleisterzugriffen sind wir zu klein“ ist der Einwand, den dieser Fall beantwortet. Der Umfang des Programms sollte sich danach richten, wie weit der Dienstleister in Ihre Daten hineinreicht, nicht nach Ihrer Mitarbeiterzahl oder seiner. Was die Größe des Dienstleisters tatsächlich verändert, ist, wie viel Sicherheitspraxis Sie voraussetzen können: Ein Unternehmen mit zwei Mitarbeitern hat selten eine eigene Sicherheitsabteilung, also liegt die Überprüfung bei Ihnen.

Wie schnell das Risiko durch Drittanbieterzugriffe wächst

Der 2026 Data Breach Investigations Report von Verizon ergab, dass Drittanbieter an 48 % der Datenlecks beteiligt waren, nach 30 % ein Jahr zuvor, ein Anstieg um 60 %. Dieser frühere Wert hatte sich gegenüber der Ausgabe 2024 bereits verdoppelt. Dänemark ist ein Beispiel für ein Muster, das inzwischen fast die Hälfte der mehr als 22.000 im Bericht analysierten Datenlecks betrifft.

Verizon unterteilt die Gefährdung durch Drittanbieter in drei Archetypen: einen Dienstleister in Ihrer Software-Lieferkette, einen Dienstleister, der Ihre Daten hostet, und einen Dienstleister, der mit Ihrer Umgebung verbunden ist. Pays ApS gehört zur dritten Gruppe. Derselbe Bericht zeigt, wie langsam Dienstleister die Lücken hinter dieser Schlagzeile schließen.

Die Hälfte der Befunde zu schwachen Passwörtern und übermäßigen Berechtigungen ist nach fast acht Monaten noch offen. Der Zugriff in Dänemark dauerte drei Wochen.

Auch die Kosten steigen weiter. Der Cost of a Data Breach Report 2026 von IBM beziffert den weltweiten Durchschnitt auf 4,99 Millionen US-Dollar pro Datenleck, ein Rekordwert und ein Anstieg um 12 %.

Warum eine MFA-Pflicht für Dienstleisterkonten nicht ausreicht

MFA schützt die Anmeldeoberflächen, die Sie kontrollieren. Dienstleisterkonten liegen oft außerhalb Ihres SSO, außerhalb Ihrer MFA-Durchsetzung und außerhalb Ihres HR-gesteuerten Offboardings, daher sagt eine strenge Richtlinie auf Ihrer Seite wenig über das Passwort auf der anderen Seite aus. Prüfen Sie bei Dienstleisterzugriffen die Kontohygiene an der Grenze, statt sie vorauszusetzen.

Weder Cybernews noch BleepingComputer erwähnen einen zweiten Faktor bei den kompromittierten Konten. Die gemeldeten Versäumnisse liegen eine Ebene unterhalb von MFA: ein triviales Passwort für Admin-Konten und das geleakte Passwort eines ehemaligen Mitarbeiters, das laut dem Angreifer den Weg hinein öffnete.

Sind Zugangsdaten erst einmal geleakt, erfolgt der Widerruf langsam. Der State of Secrets Sprawl 2026 von GitGuardian verfolgte gültige Secrets, die 2022 in öffentlichen GitHub-Commits gefunden wurden, und stellte fest, dass 2026 noch 64 % nicht widerrufen waren. Geleakte Zugangsdaten eines Dienstleisters bleiben gültig, bis jemand die Verantwortung für den Widerruf übernimmt.

„Unsere Dienstleister sind zertifiziert“ schließt diese Lücke nicht. Ein Zertifikat beschreibt das Programm eines Dienstleisters. Es verrät Ihnen nicht, ob das Konto, das ein Auftragnehmer heute eröffnet, ein eindeutiges, generiertes Passwort verwendet oder einen Login, den das ganze Unternehmen teilt. Gemeinsam genutzte Logins machen zudem den Audit-Trail unlesbar: Das Log zeigt das Unternehmen, nicht die Person.

Wenn die Logins Ihrer Dienstleister heute in Tabellen und Chatverläufen liegen, verschieben Sie sie in einen Tresor, in dem alle Zugangsdaten generiert, begrenzt und protokolliert werden. Starten Sie eine kostenlose Testversion von Passwork und testen Sie sie zunächst mit einem Dienstleister.

Der Schadensradius-Check für Dienstleisterzugriffe: Sechs Maßnahmen für Drittanbieterzugriffe

Der Schadensradius-Check für Dienstleisterzugriffe ist eine Routine aus sechs Maßnahmen, mit der Sie bewerten und begrenzen, worauf die Zugangsdaten eines Dienstleisters zugreifen können: Zugriff auf die Aufgabe beschränken, Zugriff zeitlich begrenzen, eindeutige Zugangsdaten ausgeben, MFA an Ihrer Grenze durchsetzen, Dienstleistersitzungen überwachen und das Offboarding zum Vertragsende verbindlich prüfen. Führen Sie ihn vor jeder Zugriffsfreigabe und bei jeder Überprüfung durch.

Die NIS2-Richtlinie der EU deckt diese Ebene ab. Die NIS2-Richtlinie (EU) 2022/2555 nennt in Artikel 21(2)(d) die Sicherheit der Lieferkette als eine der Risikomanagementmaßnahmen, die wesentliche und wichtige Einrichtungen umsetzen, einschließlich sicherheitsbezogener Aspekte der Beziehungen zu ihren unmittelbaren Anbietern oder Diensteanbietern.

1. Zugriff auf die Aufgabe beschränken. Wenden Sie das Prinzip der geringsten Privilegien (Least Privilege) pro Dienstleister an: Gewähren Sie genau die Tresore, Systeme oder API-Scopes, die der Vertrag erfordert, bewerten Sie sie anhand der vier oben genannten Kriterien und trennen Sie Admin-Konten von Konten für Routineaufgaben. Rollenbasierter Zugriff macht das wiederholbar, und der RBAC-Leitfaden zeigt, wie Sie den Zugriffsumfang an die Tätigkeit koppeln. In Dänemark konnte ein einziger Satz Zugangsdaten Millionen von Einträgen enumerieren.
2. Zugriff zeitlich begrenzen. Koppeln Sie jedes Dienstleisterkonto an das Vertrags- oder Projektende, entfernen Sie dauerhafte Zugriffe, wenn die Arbeit ruht, und genehmigen Sie sie bei jedem Meilenstein im Rahmen einer geplanten Zugriffsüberprüfung neu. Ein geleaktes Passwort funktioniert nur, solange das Konto aktiv ist. Falls das geleakte Passwort in Dänemark von einem ehemaligen Mitarbeiter stammte, wäre das Offboarding die Maßnahme gewesen, die es unschädlich gemacht hätte.
3. Eindeutige, persönlich zuordenbare Zugangsdaten ausgeben. Ein Konto pro Person, niemals eines pro Unternehmen. Generieren Sie Passwörter, statt sie von Benutzern wählen zu lassen, und lehnen Sie bekannt unsichere Werte wie „123456“ schon bei der Erstellung ab. Inventarisieren Sie zuerst die Zugangsdaten, die Dienstleister besitzen; wie das geht, zeigt der Leitfaden zur Verwaltung von SaaS-Zugangsdaten.
4. MFA an der Grenze durchsetzen, die Sie kontrollieren. Setzen Sie den zweiten Faktor auf Ihr Gateway, Ihr Portal oder die Anmeldung an Ihrem Tresor, unabhängig vom Sicherheitsniveau des Dienstleisters. Ein erratenes oder geleaktes Passwort öffnet dann für sich allein nichts. Dienstleisterkonten in Ihren Systemen unterliegen derselben Regel wie Mitarbeiterkonten.
5. Dienstleistersitzungen wie privilegierte Mitarbeitersitzungen überwachen. Protokollieren Sie jede Sitzung, lösen Sie Alarme bei Volumenspitzen, Zugriffen außerhalb der Arbeitszeiten und sequenziellen Abfragen aus und überprüfen Sie die Aktivitäten von Dienstleistern nach einem festen Zeitplan. Privileged Access Management umfasst Sitzungsaufzeichnung und Just-in-Time-Rechteerweiterung. Der nächste Abschnitt liefert eine Messlatte dafür, wie schnell diese Alarme auslösen müssen.
6. Offboarding von Dienstleistern zum Pflichtschritt bei Vertragsende machen. Der Vertrag gilt erst als beendet, wenn die Dienstleisterkonten deaktiviert, gemeinsam genutzte Zugangsdaten rotiert und eine abschließende Zugriffsüberprüfung unterzeichnet sind. Ein Konto zu deaktivieren ist nicht dasselbe, wie die Zugangsdaten zu rotieren, die es kannte, denn Passwörter, API-Schlüssel und Tokens, die der Dienstleister bereits gesehen hat, bleiben gültig, bis sie geändert werden. Der Leitfaden zum Offboarding von Mitarbeitern wendet dieselbe Logik auf eigenes Personal an und lässt sich direkt auf Auftragnehmer übertragen.

Wie schnell Sie auffällige Dienstleisterzugriffe erkennen würden

Im dänischen Fall dauerte der gemeldete Zugriff 21 Tage und 17 Stunden, bevor die Registerverwaltung am 2. Oktober von dem Datenleck erfuhr. Nutzen Sie dieses Zeitfenster als Messlatte: Wenn ein Dienstleisterkonto morgen beginnen würde, Datensätze in Ihren Systemen zu enumerieren, würde Ihr Monitoring es früher melden?

Das gemeldete Muster liefert Signale, die Sie testen können. Eine Brute-Force-Enumeration erzeugt eine hohe Zahl von Abfragen über ein einzelnes Konto, viele davon nach Kennungen, die nicht existieren, und der Angreifer verschob zudem Daten auf einen Speicher außerhalb des Registers.

Dauerhafte Zugriffe erschweren die Feinabstimmung dieser Alarme, denn ein Konto ohne Enddatum hat keine Projektgrenze, an der sich seine Aktivität messen ließe. Zeitlich begrenzter Zugriff verkleinert den Bereich, den Sie überwachen müssen. Führen Sie eine Tabletop-Übung durch: Wählen Sie das Dienstleisterkonto mit der größten Reichweite, simulieren Sie das Enumerationsmuster und messen Sie, wie lange es dauert, bis jemand alarmiert wird.

Wie Passwork hilft, Dienstleister- und Drittanbieterzugriffe zu kontrollieren

Mit Passwork kann ein Team jedem Dienstleister genau die Zugangsdaten geben, die sein Vertrag erfordert, und sie mit einer einzigen Aktion wieder entziehen. Berechtigungen auf Tresor- und Ordnerebene begrenzen den Zugriff, die rollenbasierte Zugriffskontrolle trennt Administratoren von Mitgliedern, und das Aktivitätsprotokoll erfasst, wer was wann geöffnet hat. Passwork steuert die im Tresor gespeicherten Zugangsdaten.

Das Modell der Zugriffsverwaltung von Passwork lässt sich den sechs oben genannten Maßnahmen zuordnen.

Fassen Sie die Mitarbeiter jedes Dienstleisters in einer Gruppe zusammen und koppeln Sie die Deaktivierung der Gruppe in Ihrer Offboarding-Checkliste an das Vertragsende. Das ist ein einziger Schritt statt einer Suche Konto für Konto.

Ein Tresor steuert die Zugangsdaten, die Sie speichern und ausgeben. Er kann keine Passwortregeln in den eigenen Systemen eines Dienstleisters oder in einem staatlichen Register durchsetzen, daher hängen diese Maßnahmen weiterhin von Vertragsbedingungen, Auditrechten und der Überwachung aus Maßnahme 5 ab. Ein Widerruf des Zugriffs löscht auch nicht, was ein Auftragnehmer bereits gesehen hat: Rotieren Sie alles, was er geöffnet hat.

Was in diesem Quartal gegen das Risiko durch Drittanbieterzugriffe zu tun ist

Das dänische Register wurde über die Logins eines Dienstleisters offengelegt, und die Größe des Dienstleisters änderte nichts am Ergebnis. Behandeln Sie das Risiko durch Drittanbieterzugriffe zuerst als Bewertungsproblem: Erfassen Sie, worauf jedes Dienstleisterkonto zugreifen kann, geben Sie jeder Person eigene generierte Zugangsdaten und versehen Sie jedes Konto mit einem Enddatum und einem Überwachungsalarm.

Nächster Schritt: Erfassen Sie noch diese Woche alle Konten von Dienstleistern und Auftragnehmern mit dauerhaftem Zugriff und führen Sie dann den Schadensradius-Check für die drei mit der größten Reichweite durch.

Wenn Ihr Team Dienstleistern oder Auftragnehmern Zugriff auf gemeinsam genutzte Zugangsdaten gewährt, starten Sie eine kostenlose Testversion von Passwork: Begrenzen Sie diesen Zugriff pro Tresor, teilen Sie einmalig benötigte Zugangsdaten über zeitlich begrenzte Links und widerrufen Sie eine Dienstleistergruppe in einem Schritt, mit einem Audit-Trail hinter jeder Aktion.

Häufig gestellte Fragen zum Risiko durch Drittanbieterzugriffe

Was ist RBAC und wie es Ihr Zugriffsproblem löst

Wildwuchs bei Berechtigungen entsteht nicht über Nacht, er wächst mit jeder ungeprüften Neueinstellung. Dieser Leitfaden zeigt, wie die rollenbasierte Zugriffskontrolle (RBAC) Onboarding, Offboarding und Audits in Ordnung bringt und wie Passwork dasselbe Modell auf gemeinsam genutzte Passwörter und Secrets anwendet.

PassworkAlex Muntyan

Leitfaden zur Lieferkettensicherheit: Dienstleisterrisiken, Vorschriften und Zugriffskontrolle 2026

An 48 % der Datenlecks ist inzwischen ein Drittanbieter beteiligt. Dieser Leitfaden behandelt die Angriffsmuster hinter SolarWinds, MOVEit und XZ Utils – und die Zugriffskontrollen, Verfahren zur Verwaltung von Zugangsdaten und regulatorischen Anforderungen, die sie tatsächlich stoppen.

PassworkAlex Muntyan

Verwaltung von SaaS-Zugangsdaten: 5 Schritte zur Zentralisierung Ihres App-Stacks

Die Verwaltung von SaaS-Zugangsdaten macht aus verstreuten Passwörtern und API-Schlüsseln ein einziges Inventar, das Sie gezielt teilen und beim Ausscheiden widerrufen können. Das Modell in fünf Schritten: Inventarisierung, Struktur, Migration, Zugriffskontrolle und Automatisierung.

PassworkAlex Muntyan