Identitätschaos bei Dienstleistern: Warum Ihr Joiner-Mover-Leaver-Prozess für Nicht-Mitarbeiter versagt

Stellen Sie sich Folgendes vor: Ihr SOC-2-Audit läuft, und der Auditor stellt eine scheinbar einfache Frage: "Können Sie uns zeigen, wer in den letzten 12 Monaten Zugriff auf Ihre GitHub-Organisation hatte - und bestätigen, dass alle aktuell noch eingetragenen Personen wirklich aktiv sind?"

Sie ziehen die Liste. Ein Name springt ins Auge. Eine Entwicklerin, die ein dreimonatiges Projekt gemacht hat - beendet vor neun Monaten. Ihr GitHub-Zugang - Repos, interne Tools, alles - ist immer noch aktiv.

Das ist kein theoretisches Beispiel. Solche Befunde tauchen in echten Audits auf, führen zu echten Maßnahmenplänen - und kosten im Zweifel echte Karrieren. Und fast jedes Mal ist die Ursache dieselbe: Die Identity Governance der Organisation ist rund um Festangestellte gebaut. Die Auftragnehmerin ist durch das Raster gefallen.

Das unterschätzte Ausmaß des Problems

Die unangenehme Wahrheit: Ein erheblicher Teil Ihrer tatsächlichen Belegschaft taucht in Ihrem HR-System gar nicht auf.

Contingent Worker - Dienstleister, Freelancer, Berater, Agenturpersonal - machen inzwischen rund 30-40 % der US-Arbeitskräfte aus, so ein Bericht des U.S. Government Accountability Office, und diese Zahl dürfte bis 2050 in Richtung 50 % steigen^[1]. Gleichzeitig wissen rund 48 % der Unternehmen, dass ehemalige Mitarbeitende oder Dienstleister weiterhin Zugriff auf Unternehmenssysteme behalten, wie in Forschung zitiert von TechRepublic.

Diese beiden Fakten bilden zusammen das eigentliche Risiko. Externe Kräfte sind überall - sie arbeiten an Ihren Code-Repos, in Ihren Cloud-Umgebungen, in Projekttools, an Kundendaten - und die meisten Identity-Governance-Programme gehen immer noch implizit davon aus, dass die Belegschaft aus Angestellten mit HRIS-Datensatz besteht.

Das stimmt nicht mehr. Und dieser Bruch zwischen Realität und Systemarchitektur hat konkrete Folgen: schwache Identity Governance, lückenhafte Zugriffsüberprüfung und verwaiste Konten.

Die JML-Blindstelle: Warum der Prozess nie für Dienstleister gedacht war

Die meisten Organisationen betreiben irgendeine Form von Joiner-Mover-Leaver-Automatisierung (JML). Eine Person wird eingestellt -> HR legt einen Datensatz an -> ein Workflow startet -> Konten werden bereitgestellt. Eine Person verlässt das Unternehmen -> HR schließt den Datensatz -> das SSO wird deaktiviert -> (im Idealfall) verbundene Apps werden per SCIM deprovisioniert.

Diese Automatisierung funktioniert, solange das HR-System die "Single Source of Truth" ist. Das Problem: Dienstleister tauchen in den meisten Organisationen gar nicht im HRIS auf.

Sie stehen in einer Excel-Liste. In einem Vendor-Management-Portal. In einem E-Mail-Thread. Sie werden eingebunden, weil eine Führungskraft ein IT-Ticket erstellt - nicht, weil HR ein Lifecycle-Event auslöst. Klassisches Identity Management für Dritte findet oft schlicht nicht statt.

Wenn der Einsatz eines Dienstleisters endet, passiert deshalb: nichts. Kein automatisches Offboarding, kein Beendigungs-Event, das durchs System läuft. Kein Workflow, der ausgelöst wird. Das IT-Team bekommt vielleicht Wochen später eine Slack-Nachricht - oder hört nie davon. Das Jira-Konto, der Slack-Workspace, die GitHub-Mitgliedschaft und der Notion-Zugang bleiben genau so, wie sie am ersten Tag eingerichtet wurden.

Das ist kein Versagen des IT-Teams. Es ist eine Architekturlücke im Identity Management. Der JML-Prozess wurde für Angestellte entworfen. Dienstleister waren eine Randnotiz - und die eingesetzte Identity-Governance-Tooling spiegelt das wider.

Was nach Vertragsende wirklich passiert

Die Folgen in der Fläche sind vorhersehbar - aber massiv unterschätzt.

Verwaiste Konten häufen sich unbemerkt an. Ein Veza-Bericht von Dezember 2025 fand 824.000 aktive Identitäten ohne zugehörigen HR-Datensatz - etwa 8 % aller Nutzer in Identity-Providern - mit einem jährlichen Wachstum verwaister Identitäten von etwa 40 %, wie Help Net Security berichtet^[2]. Noch bemerkenswerter: Selbst wenn HR-Systeme Konten als inaktiv markierten, hielten 38 % dieser Identitäten weiterhin aktive Berechtigungen in geschäftskritischen Anwendungen.

Dass ein Dienstleister in einem System entfernt wurde, heißt gar nichts, wenn sein Konto in zwölf anderen weiterhin produktiv ist. Genau diese verwaisten Konten sind der blinde Fleck vieler Programme für Identity Governance und Zugriffsmanagement für Externe.

Überprovisionierung ist der Normalfall, nicht die Ausnahme. Wenn Dienstleister schnell onboardet werden müssen - weil eine Deadline drückt und keine Zeit für saubere Zugriffsüberprüfung bleibt - erhalten sie oft sehr breite Rechte. "Gib ihr vorerst einfach die gleichen Rechte wie dem Dev-Team." Diese großzügige Provisionierung wird später nie sauber auf das Nötigste zurückgestutzt - und schon gar nicht konsequent entfernt, wenn der Vertrag endet. Identity Management für Dritte bleibt improvisiert.

Die Audit-Lücke ist unmittelbar. Wenn ein Compliance-Framework verlangt, dass Sie nachweisen, wer zu einem bestimmten Zeitpunkt Zugriff auf ein sensibles System hatte, werden verwaiste Konten von Dienstleistern zu einem formalen Audit-Finding. Im Verizon Data Breach Investigations Report 2024 wurde festgestellt, dass über 22 % aller Datenschutzvorfälle Insider involvieren - mit mangelhafter Zugriffsteuerung als wiederkehrender Ursache, wie zahlreiche Security-Quellen hervorheben^[3]. Nie sauber deprovisionierte Dienstleisterkonten fallen genau in diese Kategorie.

Und ganz praktisch: Rund 43 % der Unternehmen haben möglicherweise ehemalige Mitarbeitende oder Dienstleister, die weiterhin Zugriff auf Code-Repos wie GitHub oder GitLab haben, so Forschung von Wing Security^[4]. Code-Repos. Der Ort, an dem Ihre proprietäre Software lebt.

Warum SSO Sie hier nicht rettet

Die typische Reaktion, wenn diese Lücke angesprochen wird: "Aber wir nutzen Okta. Wenn wir jemanden in Okta sperren, ist der Zugang weg."

Stimmt - für Apps, die per SSO an Okta angebunden sind, und nur für Logins über diesen Weg.

Dienstleister existieren jedoch häufig komplett außerhalb des Corporate-Identity-Perimeters. Sie werden mit einer privaten Gmail-Adresse in ein Projektmanagement-Tool eingeladen. Nutzen einen geteilten Team-Account für ein Kundenportal. Bekommen einen Direkt-Login zu GitHub, den jemand angelegt hat, weil die Person nicht im Verzeichnis existierte. Oder erhalten ein Produktionsdatenbank-Credential per Slack.

Keines dieser Konten wird von Ihrem SSO-Provider gesteuert. Das Deaktivieren des Unternehmens-Okta-Kontos ändert dort nichts. Und oft hatten Dienstleister überhaupt nie ein Corporate-SSO-Konto.

Das ist das Grundproblem des "SSO-Perimeters": Ihr SSO deckt nur die Apps ab, die Sie aktiv angebunden haben - und nur für Identitäten, die im Verzeichnis stehen. Dienstleister gehören oft zu keiner dieser beiden Kategorien.

Branchenrealität: In manchen Sektoren ist es besonders schlimm

Die allgemeine Aussage "Zugriff von Dienstleistern ist unübersichtlich" verharmlost, wie drastisch das Problem in einigen Branchen tatsächlich ist.

Logistik und Maritime Wirtschaft

Crew-Mitglieder, Hafenarbeiter, Saisonkräfte - die Besetzungen wechseln ständig und tauchen oft nie in einem zentralen Verzeichnis auf. Sie erhalten temporären Zugriff auf Dispositionssysteme, Schiffs-Tracking-Software oder Kommunikationsplattformen für eine einzelne Reise oder Vertragsperiode. Wenn sie gehen, hängt der Rechteentzug vollständig davon ab, ob jemand manuell daran denkt. In Organisationen mit kleinen IT-Teams und hochgradig wechselnder Belegschaft sammeln sich verwaiste Konten allein durch den Alltag an.

Gesundheitswesen

Externe Leistungserbringer - Radiologen, Honorarärzte, spezialisierte Berater - brauchen regelmäßig zeitlich begrenzten Zugriff auf KIS/EHR-Systeme und Patientendaten. Sie werden aus klinischen Gründen "schnell mal" onboardet, nicht über die standardisierten IT-Prozesse. Wenn ihr Einsatz endet, tun es ihre Zugänge zu diesen Systemen oft nicht. Die HIPAA Security Rule^[5] verpflichtet betroffene Einrichtungen ausdrücklich dazu, den Zugriff auf PHI - einschließlich für Externe - zu kontrollieren. Verwaiste Konten im Provider-Portal sind hier ein direkter Compliance-Verstoß - und im Audit leicht nachweisbar.

Produktion und M&A

Subunternehmer bei Werkserweiterungen oder in Akquisitionsprojekten erhalten nicht selten Zugriff auf Produktionssysteme, OT-Umgebungen und operative Tools ohne SCIM-Support und mit eingeschränkten API-Möglichkeiten. Im M&A-Kontext - mit mehreren Tenants und fragmentierten Systemlandschaften - tauchen Dienstleister-Konten aus dem akquirierten Unternehmen möglicherweise gar nicht in den Identity-Systemen des Käufers auf. Sie "schweben" einfach weiter - verknüpft mit einem System, das faktisch niemand mehr verantwortlich besitzt.

Tech- und SaaS-Unternehmen

Schnell wachsende Tech-Teams holen regelmäßig Dienstleister für Engineering-Sprints, Security-Reviews oder Produktarbeit an Bord. Der Stack ist modern - GitHub, Linear, Notion, Figma, Jira - aber der Zugang wird informell und häufig über private Accounts gewährt, weil der Dienstleister nicht im Firmenverzeichnis steht. Viele dieser Apps verlangen ein Enterprise-Pricing, um SCIM zu aktivieren (die "SCIM-Tax"). Das Ergebnis: Die SCIM-basierte Deprovisionierung, die für Angestellte funktioniert, greift bei genau den Tools nicht, die das Team täglich nutzt. Identity Governance ohne universelle Abdeckung bleibt hier lückenhaft, insbesondere beim Zugriffsmanagement für Externe.

Das Audit-Finding, das alles verändert

Meist gibt es einen Moment, in dem das Thema von "bekanntes Problem, geringe Priorität" zu "wir müssen das jetzt lösen" kippt. Typischerweise sieht er so aus:

• Ein Auditor entdeckt ein aktives Konto eines gekündigten Dienstleisters in einem System mit regulierten Daten. Der Fund wandert in den Audit-Report. Das Unternehmen bekommt eine Auflage zur Abstellung.
• Ein Sicherheitsvorfall wird auf Credentials zurückgeführt, die zu jemandem gehören, dessen Einsatz schon vor Monaten endete. Die Frage lautet dann: Wie viele weitere verwaiste Konten gibt es noch?
• Eine routinemäßige, manuelle Zugriffsüberprüfung per Spreadsheet zeigt, dass niemand wirklich beantworten kann, "wer hat aktuell Zugriff auf dieses System?" - zumindest nicht für Identitäten von Dienstleistern. Die ehrliche Antwort lautet: "Wir glauben, diese Personen - aber sicher sind wir nicht."

In einem Fall bei der FinWise Bank im September 2025 konnte ein ehemaliger Mitarbeitender nach Ende seines Arbeitsverhältnisses noch auf sensible Kundeninformationen von fast 700.000 Personen zugreifen - kein hochkomplexer Hack, sondern schlicht ein Konto, das nie deaktiviert wurde, wie öffentlich dokumentiert^[3]. Szenarien mit Dienstleistern folgen exakt demselben Muster - mit dem zusätzlichen Problem, dass es häufig gar kein formales Beendigungs-Event gibt, das irgendwen zum Nachschauen veranlassen würde.

Der Auslöser für moderne Identity-Governance-Lösungen ist fast immer einer dieser Momente. Die Organisation spürt die Lücke schmerzhaft - nicht nur theoretisch. Und dann wird klar: Die vorhandenen Tools - SSO, SCIM-verbundene Apps, manuelle Offboarding-Checklisten - sind schlicht nicht für Identity Management für Dritte gebaut worden.

Was dieses Problem tatsächlich löst

Keine einzelne Richtlinie schließt die Identitätslücke für Dienstleister. Aber Organisationen, die sie im Griff haben, eint ein paar zentrale Ansätze im Identity Management und Zugriffsmanagement für Externe.

Sie steuern Dienstleister-Identitäten getrennt von den JML-Flows für Angestellte. Der Zugriff von Dienstleistern wird in einem System geführt, das nicht von HRIS-Events abhängt. Start- und Enddatum des Engagements steuern die automatisierte Provisionierung und Deprovisionierung - unabhängig von Workday oder BambooHR. Freelancer Onboarding ist damit ein eigener, klar definierter Prozess der Identity Governance.

Sie vergeben grundsätzlich zeitlich befristete Zugriffe statt offener Zugänge. Zugriff für Dienstleister hat von Anfang an ein Ablaufdatum. Wenn dieses Datum erreicht ist, wird der Zugang automatisch entzogen - ohne dass jemand daran denken muss. Das ist die wirksamste einzelne Kontrollmaßnahme gegen verwaiste Konten bei Dienstleistern.

Sie decken den gesamten App-Stack ab, nicht nur SCIM-fähige Anwendungen. Die Tools, auf die Dienstleister typischerweise zugreifen - Projektmanagement, Code-Repos, Kommunikationsplattformen, Kundenportale, interne Wikis - sind oft genau die, die im Standard-Tarif keinen SCIM-Support bieten. Identity Governance, die bei SCIM endet, lässt den kritischen Teil des Zugriffsmanagements für Externe ungeregelt. (Was JML-Automatisierung über Apps ohne APIs konkret bedeutet, erklären wir ausführlich in unserem Leitfaden automating JML for apps without APIs.)

Sie haben eine einheitliche Sicht auf alle Identitäten - Angestellte, Dienstleister, Service-Accounts. Die Audit-Frage "Wer hat jetzt gerade Zugriff auf dieses System?" muss in Sekunden beantwortbar sein, nicht nach wochenlanger Tabellen-Forensik.

Plattformen, die dieses Problem direkt adressieren - statt Dienstleister-Verwaltung nachträglich an ein "Employee-First"-IGA-Modell anzubauen - achten deshalb auf Dinge wie: universelle App-Abdeckung (SCIM, API oder keins von beidem), Policy-gesteuerte Lifecycle-Automatisierung, die an Vertragsdaten statt an HR-Events hängt, zeitlich begrenzte Zugriffsrechte und automatisiertes Offboarding ohne manuelle Übergabe. Genau so sieht modernes Identity Management für Dritte aus.

Der Unterschied zu Legacy-IGA oder rein SCIM-basierter Tooling lohnt einen genaueren Blick:

Iden wurde genau für diese Lücke gebaut - universelle Connectors, die jede App im Stack erreichen, zeitlich begrenzte Zugriffe, die automatisch auslaufen, und Lifecycle-Automatisierung, die nicht voraussetzt, dass Dienstleister zuerst im HRIS existieren. Wenn Identity Governance für Dienstleister die Lücke ist, die Sie schließen wollen, sollten Sie sich ansehen, wie vollständige Abdeckung in der Praxis aussieht.

Fazit

Das Identitätsproblem bei Dienstleistern ist nicht neu. Neu ist der Maßstab. Je mehr Contingent Work zum Standard wird - und nicht zur Ausnahme -, desto größer wird die Governance-Lücke proportional. Klassisches JML ohne ergänzendes Identity Management für Dritte skaliert hier einfach nicht.

Die Quintessenz:

• Dienstleister erzeugen keine HR-Events. Ihre JML-Automatisierung basiert auf HR-Events. Das ist die eigentliche Ursache.
• SSO schützt nur, was es sieht. Dienstleister liegen oft von Tag eins an außerhalb des SSO-Perimeters.
• Verwaiste Konten sind eine statistische Gewissheit, wenn es kein System gibt, das speziell darauf ausgelegt ist, sie zu verhindern.
• Das kritische Audit-Finding ist eine Frage des Wann, nicht des Ob - insbesondere in regulierten Branchen.
• Die Lösung muss den gesamten Stack abdecken - nicht nur SCIM-Apps -, mit zeitlich begrenzten Zugriffsrechten und Automatisierung, die unabhängig von HRIS-Triggern funktioniert.

Die Unternehmen, die hier vor die Lage kommen, handeln, bevor der Auditor die Frage stellt, die niemand beantworten kann. Die anderen lernen die Lektion auf die harte Tour.

Stoppen Sie veraltete Zugänge von Dienstleistern - buchen Sie eine Demo und sehen Sie, wie Iden den gesamten Lifecycle für Dienstleister vom Freelancer Onboarding bis zum automatisierten Offboarding abdeckt^[6]. So wird Identity Governance und Zugriffsmanagement für Externe zu einem geschlossenen System, nicht zu einer Sammlung von Workarounds.

Häufig gestellte Fragen