Identitätschaos bei Dienstleistern: Warum Ihr Joiner-Mover-Leaver-Prozess für Nicht-Angestellte 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, die heute noch Zugriff haben, tatsächlich noch aktiv sind?"

Sie ziehen die Liste. Ein Name springt sofort ins Auge. Ein Entwickler, der vor neun Monaten einen dreimonatigen Auftrag abgeschlossen hat. Sein GitHub-Zugriff - Repos, interne Tools, alles - ist immer noch aktiv.

Das ist kein Gedankenexperiment. Genau solche Punkte tauchen in realen Audits auf, führen zu echten Maßnahmenplänen - und beenden gelegentlich Karrieren. Und fast immer ist die Ursache dieselbe: Die Identity Governance der Organisation wurde rund um klassische Angestellte aufgebaut. Der Dienstleister ist durch das Raster gefallen.

Das Ausmaß des Problems, über das niemand spricht

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

Contingent Worker - Dienstleister, Freelancer, Berater, Agenturkräfte - machen laut einem Bericht des U.S. Government Accountability Office inzwischen rund 30-40 % der US-Arbeitskräfte aus, und diese Zahl wird voraussichtlich bis 2050 auf etwa 50 % steigen. Gleichzeitig wissen rund 48 % der Unternehmen, dass ehemalige Mitarbeitende noch Zugriff auf Unternehmenssysteme behalten, wie von TechRepublic zitierte Forschung zeigt.

Diese beiden Fakten zusammen sind der Kern des Problems. Diese externen Kräfte sind überall - sie arbeiten an Ihren Code-Repositories, in Ihren Cloud-Umgebungen, Projekt-Tools, an Kundendaten - und die meisten Programme für Identity Governance gehen implizit davon aus, dass die Belegschaft aus Angestellten mit HRIS-Datensätzen besteht.

Tut sie aber nicht. Und dieser Mismatch hat handfeste Konsequenzen.

Der JML-Blindspot: Warum das System nie für Dienstleister gebaut wurde

Die meisten Organisationen betreiben irgendeine Form von Joiner-Mover-Leaver-(JML-)Automatisierung. 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 -> SSO wird deaktiviert -> (im Idealfall) werden angebundene Apps per SCIM deprovisioniert.

Diese Automatisierung funktioniert, solange das HR-System die "single source of truth" ist. Das Problem: Dienstleister sind in den meisten Organisationen gar nicht im HRIS erfasst.

Sie werden in einer Excel-Liste geführt. In einem Vendor-Management-Portal. In irgendeinem E-Mail-Thread. Sie werden onboardet, weil eine Führungskraft ein Ticket an IT schickt - nicht, weil HR ein Lifecycle-Event auslöst.

Wenn der Auftrag eines Dienstleisters endet, passiert deshalb: nichts. Kein Termination-Event, das durch die Systeme propagiert. Kein Workflow, der getriggert wird. Das IT-Team bekommt vielleicht Wochen später eine Slack-Nachricht - oder hört nie davon. Der Jira-Account, der Slack-Workspace, die GitHub-Mitgliedschaft und der Notion-Zugriff bleiben genauso bestehen wie am ersten Tag.

Das ist kein Versagen des IT-Teams. Es ist eine architektonische Lücke. Der JML-Prozess wurde für Angestellte konzipiert. Dienstleister waren ein Nachgedanke - und genau so sehen die Tools auch aus.

Was nach Vertragsende tatsächlich passiert

Die Folgen entlang der Kette sind vorhersehbar - aber meist unterschätzt.

Verwaiste Konten häufen sich lautlos an. Ein Veza-Report vom Dezember 2025 fand 824.000 aktive Identitäten ohne zugehörigen HR-Eigner - rund 8 % aller Users in Identity Providern - und die Zahl verwaister Konten stieg Jahr für Jahr um etwa 40 %, berichtet Help Net Security. Noch bemerkenswerter: Selbst wenn HR-Systeme Accounts als inaktiv markierten, hatten 38 % dieser Identitäten weiterhin aktive Berechtigungen in zentralen Business-Applikationen.

Dass der Account eines Dienstleisters in einem System "weg" ist, heißt gar nichts, wenn er in zwölf anderen weiterhin aktiv ist.

Overprovisioning ist die Regel, nicht die Ausnahme. Wenn Dienstleister unter Zeitdruck onboardet werden - weil eine Deadline drängt und keine Zeit für eine saubere Zugriffsüberprüfung bleibt - bekommen sie in der Praxis sehr breite Rechte. "Gib ihm/ihr erstmal dieselben Rechte wie dem Dev-Team." Diese großzügigen Berechtigungen werden selten nachgeschärft - und fast nie aufgeräumt, wenn der Vertrag endet.

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 schnell zu einem formalen Finding. Laut dem Verizon Data Breach Investigations Report 2024 sind über 22 % der Datenpannen auf Insider zurückzuführen, wobei Fehlsteuerung von Zugriffsrechten eine wiederkehrende Ursache ist. Nicht sauber deprovisionierter Zugriff von Dienstleistern fällt exakt in diese Kategorie.

Und ganz praktisch: Laut einer Untersuchung von Wing Security könnten 43 % der Unternehmen ehemalige Mitarbeitende oder Dienstleister haben, die weiterhin Zugriff auf unternehmenseigene Code-Repositories in GitHub oder GitLab besitzen. Code-Repositories. Dort, wo Ihre proprietäre Software lebt.

Warum SSO Sie hier nicht rettet

Die Standardreaktion, wenn diese Lücke angesprochen wird: "Aber wir nutzen Okta. Wenn wir jemanden in Okta deaktivieren, ist der Zugriff 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 vollständig 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 direkten Login auf GitHub, weil jemand fand, dass sich der Aufwand für das Directory nicht lohnt. Oder erhalten Zugangsdaten für eine produktive Datenbank per Slack.

Keines dieser Konten unterliegt Ihrer SSO-Steuerung. Das Deaktivieren des Corporate-Okta-Accounts bewirkt dort gar nichts. Und viele Dienstleister hatten ohnehin nie einen Corporate-Okta-Account.

Das ist das SSO-Perimeter-Problem: Ihr SSO schützt die Apps, die Sie angebunden haben - für die User, die überhaupt im System existieren. Dienstleister gehören oft in keine dieser beiden Kategorien.

Die Branchenrealität: In manchen Industrien ist es besonders kritisch

"Zugriff von Dienstleistern ist chaotisch" klingt harmlos - in einigen Branchen ist das Problem jedoch deutlich akuter.

Logistik und maritime Wirtschaft

Crew-Mitglieder, Hafenpersonal und Saisonkräfte wechseln ständig - oft ohne je in einem zentralen Verzeichnis aufzutauchen. Sie erhalten temporären Zugriff auf Dispositionssysteme, Software zur Schiffsverfolgung oder Kommunikations-Tools für eine Reise oder einen Vertragszeitraum. Wenn sie gehen, hängt der Entzug der Zugriffsrechte allein davon ab, dass jemand manuell daran denkt. In Organisationen mit kleinen IT-Teams und hochfluktuierender Belegschaft entstehen verwaiste Konten quasi automatisch.

Gesundheitswesen

Externe Leistungserbringer - Radiolog:innen, Honorarärzt:innen, spezialisierte Berater:innen - benötigen regelmäßig zeitlich begrenzten Zugriff auf EHR-Systeme und Patientendaten. Sie werden aus klinischen Gründen onboardet, nicht über standardisierte IT-Prozesse. Endet die Zusammenarbeit, enden ihre Zugriffsrechte auf diese Systeme häufig nicht. Die HIPAA Security Rule verlangt explizit, dass Zugriff auf PHI kontrolliert wird - auch für externe Parteien. Verwaiste Konten in Provider-Portalen stellen eine direkte Compliance-Lücke dar - und eine, die prüfbar ist.

Produktion und M&A

Subunternehmer bei Werkserweiterungen oder Übernahmen erhalten häufig Zugriff auf Produktionssysteme, OT-Umgebungen und Operations-Tools, die weder SCIM-Unterstützung noch ausgereifte APIs haben. Im M&A-Kontext - mit mehreren Tenants und fragmentierter Systemlandschaft - taucht der Zugriff von Dienstleistern der übernommenen Einheit womöglich gar nicht in den Identity-Systemen des Käufers auf. Er schwebt einfach weiter - an einem System hängend, das offiziell niemand mehr verantwortet.

Tech- und SaaS-Unternehmen

Schnell wachsende Tech-Teams holen laufend Dienstleister für Engineering-Sprints, Security-Assessments oder Produktarbeit an Bord. Der Stack ist modern - GitHub, Linear, Notion, Figma, Jira - aber Zugriffsrechte werden informell vergeben und oft über private Accounts, weil der Dienstleister nicht im Directory steht. Viele dieser Apps bieten SCIM nur in Enterprise-Plänen an (die "SCIM Tax"), weshalb SCIM-basierte Deprovisionierung, die für interne Mitarbeitende gut funktioniert, auf genau jene Tools nicht anwendbar ist, die das Unternehmen täglich nutzt.

Das Audit-Finding, das alles verändert

Meist gibt es einen Auslöser-Moment, an dem das Thema von "bekanntes Problem, niedrige Priorität" zu "wir müssen das jetzt lösen" springt. Typischerweise sieht er so aus:

• Ein Auditor findet den aktiven Account eines gekündigten Dienstleisters in einem System mit regulierten Daten. Der Punkt landet im Bericht. Das Unternehmen erhält eine formale Remediation-Auflage.
• Ein Sicherheitsvorfall wird auf Zugangsdaten zurückgeführt, die zu jemandem gehören, dessen Engagement vor Monaten endete. Die Frage lautet: Wie viele andere veraltete Konten gibt es noch?
• Eine routinemäßige Zugriffsüberprüfung, mühsam per Excel-Liste durchgeführt, zeigt, dass niemand verlässlich beantworten kann: "Wer hat aktuell Zugriff auf dieses System?" - zumindest nicht für Identitäten von Dienstleistern. Die ehrliche Antwort ist: "Wir glauben, diese Personen - sicher sind wir nicht."

In einem öffentlich dokumentierten Fall bei der FinWise Bank im September 2025 konnte ein ehemaliger Mitarbeitender nach Ende seines Arbeitsverhältnisses weiterhin auf sensible Kundendaten von fast 700.000 Personen zugreifen - nicht durch einen ausgefeilten Hack, sondern schlicht über einen Account, der nie deaktiviert wurde. Szenarien mit Dienstleistern folgen exakt demselben Muster - mit der zusätzlichen Komplikation, dass es häufig gar kein Termination-Event gibt, das jemanden zum Nachschauen veranlassen würde.

Der eigentliche Kaufimpuls für moderne Identity Governance entsteht fast immer in so einem Moment. Die Organisation spürt die Lücke am eigenen Leib, nicht nur theoretisch. Und sie erkennt: Die vorhandenen Tools - SSO, SCIM-angebundenen Apps, manuelle Offboarding-Checklisten - wurden für dieses Problem nie entworfen.

Was dieses Problem tatsächlich löst

Kein einzelner Policy-Schwenk schließt die Identitätslücke bei Dienstleistern. Aber Organisationen, die das Thema im Griff haben, haben einige Gemeinsamkeiten.

Sie steuern Dienstleister-Identitäten getrennt von den Employee-JML-Flows. Der Zugriff von Dienstleistern wird in einem System geführt, das nicht von HRIS-Events abhängt. Start- und Enddaten des Engagements treiben die automatisierte Provisionierung und Deprovisionierung - unabhängig von Workday oder BambooHR. Das ist echtes Identity Management für Dritte.

Sie arbeiten mit zeitlich begrenztem Zugriff, nicht mit offenen Berechtigungen. Zugriffsrechte für Dienstleister erhalten bereits beim Provisioning ein Ablaufdatum. Wenn dieses Datum erreicht ist, wird der Zugriff automatisch entzogen - ohne dass jemand daran denken muss. Das ist die mit Abstand wirksamste Kontrolle gegen verwaiste Konten von Dienstleistern.

Sie decken den kompletten App-Stack ab - nicht nur SCIM-Apps. Die Tools, die Dienstleister typischerweise nutzen - Projektmanagement, Code-Repositories, Kommunikations-Plattformen, Kundenportale, interne Wikis - sind oft genau die Apps, die in Standard-Tarifen keine SCIM-Unterstützung bieten. Identity Governance, die bei SCIM endet, lässt den Zugriff von Externen dort ungeregelt, wo er am kritischsten ist. (Eine tiefere Einordnung, was JML-Automatisierung für Apps ohne APIs in der Praxis bedeutet, finden Sie in unserem Guide zu automating JML for apps without APIs.)

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

Plattformen, die dieses Thema direkt adressieren - statt Dienstleisterverwaltung nur an ein Employee-zentriertes IGA-Modell anzuflanschen - achten auf Dinge wie: universelle App-Abdeckung (SCIM, API oder gar nichts davon), policy-gesteuerte Lifecycle-Automation, die von Vertragsdaten statt von HR-Events getriggert wird, zeitlich begrenzte Zugriffsrechte und automatisiertes Offboarding ohne manuellen Staffelstab. Genau hier setzt modernes Zugriffsmanagement für Externe an.

Der Unterschied zu klassischem IGA oder reinen SCIM-Tools ist deutlich - und sollte klar verstanden werden:

Iden wurde genau für diese Lücke gebaut - mit universellen Connectors, die jede App im Stack erreichen, zeitlich begrenztem Zugriff, der automatisch ausläuft, und Lifecycle-Automation, die nicht voraussetzt, dass ein Dienstleister zuerst in Ihrem HRIS existiert. Wenn Sie die Identity Governance für Dienstleister-Lebenszyklen schließen wollen, sehen Sie sich an, wie vollständige Abdeckung konkret aussieht.

Fazit

Das Identitäts-Problem rund um Dienstleister ist nicht neu. Geändert hat sich der Maßstab. Je stärker contingent work zu einem normalen Bestandteil der Organisationen wird - nicht mehr nur eine Randerscheinung -, desto größer wird die Lücke in der Identity Governance.

Die Kurzfassung:

• Dienstleister erzeugen keine HR-Events. Ihre JML-Automatisierung basiert auf HR-Events. Das ist die Wurzelursache.
• SSO kann nur schützen, was es sieht. Dienstleister existieren oft von Tag eins an außerhalb des SSO-Perimeters.
• Verwaiste Konten sind statistisch unvermeidlich, wenn Sie kein System haben, das genau diese Lücke adressiert.
• Das 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 begrenztem Zugriff und Automatisierung, die unabhängig von HRIS-Triggern funktioniert.

Organisationen, die hier proaktiv handeln, tun das, bevor der Auditor die eine Frage stellt, die sie nicht beantworten können. Die anderen lernen die Lektion auf die harte Tour - über Findings, Incident-Reports und manuelle Aufräumaktionen.

Verhindern Sie, dass der Zugriff von Dienstleistern veraltet und unsichtbar wird - buchen Sie eine Demo und sehen Sie, wie Iden den kompletten Lifecycle im Freelancer Onboarding und Offboarding abdeckt.

Häufig gestellte Fragen