Von 50 auf 500 Mitarbeitende: Wie Tech-Unternehmen Identity Management skalieren, ohne zusätzliches Personal aufzubauen

Management-Zusammenfassung. Die meisten Tech-Unternehmen in der Wachstumsphase prallen zwischen 50 und 500 Mitarbeitenden gegen eine "Identity-Mauer". Manuelles Zugriffsmanagement und reine SSO-Lösungen, die bei 40 Personen noch funktionierten, brechen unter der Last eines SaaS-Stacks mit 150-250 Apps, steigenden Compliance-Anforderungen und einer verteilten Belegschaft zusammen.

Unternehmen, die sauber skalieren, starten nicht damit, ein IAM-Team aufzubauen. Sie gestalten ihre Identity Governance neu - rund um Automatisierung, Abdeckung und kontinuierliche Kontrolle -, sodass ein dreiköpfiges IT-Team 500 Nutzende sicher und effizient unterstützen kann.

Die Identity-Mauer zwischen 50 und 500 Mitarbeitenden

Unsere Kundinnen und Kunden erzählen immer wieder dieselbe Geschichte: "Bei 40 Leuten war alles okay. Bei 200 sind wir untergegangen." Es geht nicht nur um die Anzahl der Köpfe - sondern um die Struktur eures Stacks und um das Risikoniveau:

• HR hat ein richtiges HRIS eingeführt.
• Die Entwicklung arbeitet in GitHub, Linear, Jira, Feature-Flag-Systemen, mehreren Clouds.
• Go-to-Market-Teams hängen an Salesforce oder HubSpot, Outreach-Tools, CS-Plattformen und je einem Dutzend "kleiner" SaaS-Lizenzen.
• Finanzen und Rechtsabteilung ergänzen NetSuite, Spesen-Tools, E-Signatur-Anwendungen, Portale.

Aktuelle Daten zeigen: KMU mit ≤500 Personen betreiben im Schnitt etwa 160 SaaS-Apps, Unternehmen im Midmarket-Segment (501-2.500) rund 245. Darum wächst eure IT-Ticket-Warteschlange ständig.

Typische Symptome zwischen 50 und 500 Mitarbeitenden:

• Langsames Onboarding - Neue Mitarbeitende warten Tage auf vollen Zugriff; für jede App braucht es ein eigenes Ticket.
• Unvollständiges Offboarding - HR deaktiviert SSO und HRIS, aber direkte Logins für Finanztools, Dev-Services oder Nischen-Apps werden vergessen.
• Zugriffsprüfungen in Tabellen - Führungskräfte "bestätigen" Zugriffe anhand von CSV-Dateien, denen sie nicht trauen und die sie kaum lesen.
• Tickets überall - Die IT wird zur menschlichen Provisioning-API.

In dieser Phase reichen SSO und ein paar Ad-hoc-Skripte nicht mehr aus. Aber ein komplettes IAM-Team einzustellen - und über 12-18 Monate eine Legacy-IGA-Lösung auszurollen - passt nicht zur Realität der meisten skalierenden Tech- und Finanzunternehmen.

Warum Identity Management nach Kopfzahl scheitert

Die erste Reaktion lautet fast immer: "Wir brauchen einfach mehr Leute." Mehr Admins. Mehr Security Engineers. Vielleicht ein eigenes IAM-Team.

Oberflächlich wirkt das flexibel. In der Praxis scheitert es, weil:

1. Die SaaS-Basis zu breit ist. Selbst ein dreiköpfiges IT-Team kann nicht 200+ Apps manuell verantworten - jede mit eigenem Admin-Interface, eigenem Rollenmodell und eigenem Login-Muster.
2. Die SCIM-Mauer real ist. Der Großteil eures Stacks lässt sich nicht automatisch über euren IdP bereitstellen.
3. Audit - nicht Tickets - legt die Messlatte fest. Prüferinnen und Prüfer interessiert konsistente, nachweisbare Kontrolle überall - nicht, wie hart euer Team arbeitet.

Kommen wir zu SCIM. Es ist die versteckte Ursache hinter vielen dieser Schmerzen.

In einer Studie von 2026 mit 721 SaaS-Apps hatten 57 % in keiner Preisstufe SCIM; 43 % versteckten SCIM hinter einem Enterprise-Upgrade. Nur 1,2 % boten SCIM im Basistarif an. Kurz gesagt: Euer IdP kann nur einen winzigen Bruchteil der genutzten Tools "sauber" automatisieren.

"Identity nach Kopfzahl skalieren" heißt also in Wahrheit zu wetten:

"Wir werfen Menschen auf die 98,8 % der Apps, die Automatisierung nicht erreicht, und hoffen, dass sie nichts übersehen."

Das ist keine Strategie. Das ist ein Unfallbericht in Zeitlupe.

Warum das für Finanz- und Professional-Services-Anbieter noch schmerzhafter ist

Die SCIM-Lücke ist nicht überall gleich groß. Am schlimmsten ist sie in Kategorien, die für Finanzen, Recht und Professional Services geschäftskritisch sind:

Dieselbe Studie fand eine SCIM-Lücke von 89 % bei Finanz- und Buchhaltungstools und 75 % bei Passwortmanagern - zwei Kategorien mit den höchsten Compliance-Anforderungen.

Für technologiegestützte Finanz- oder Professional-Services-Unternehmen gilt:

• Eure Kronjuwelen - Hauptbuch, Abrechnung, Zahlungen, Steuern, Mandantenportale - haben oft keine ausgereiften Provisioning-APIs.
• Externe Portale für Kundinnen, Kunden und Partner liegen außerhalb eures SSO- und IGA-Radius.
• Passwortmanager sind in Standardplänen oft nicht per SCIM anbindbar.

Und genau dort:

• Haken Prüferinnen nach (SoD, Journalfreigaben, Zugriff auf Mandantendaten).
• Schauen Aufsichtsbehörden besonders hin (SEC, FCA, BaFin, DSGVO, HIPAA, DORA).
• Suchen Angreifende nach leichten Zielen (verwaiste Konten, unüberwachte Admin-Rollen).

Diese Lücken mit mehr Menschen und Tabellenkalkulationen zu stopfen, vergrößert lediglich die manuelle Angriffsfläche - und die Wahrscheinlichkeit für Fehler.

Die versteckten Kosten: SaaS-Wildwuchs, SCIM-Aufpreis und Zombie-Zugriffe

Identity-Defizite sind nicht nur ein Sicherheitsproblem. Sie schlagen sich auch in der Gewinn- und Verlustrechnung und in jedem Audit nieder.

SaaS-Wildwuchs und verschwendete Ausgaben

Vergleichswerte zeigen: Organisationen nutzen heute im Schnitt etwa 112 SaaS-Apps und verschwenden 30-50 % der SaaS-Ausgaben für ungenutzte Lizenzen und schlecht gesteuerte Verlängerungen.

Bei manueller Governance gilt:

• Es gibt kein verlässliches Inventar, wer was nutzt.
• Abgemeldete Nutzende behalten Lizenzen in Finanz-, CRM- oder Dev-Tools, weil lokale Admins sie übersehen.
• Fachbereiche kaufen sich überlappende Tools, weil die IT nicht hinterherkommt.

Das Ergebnis sind "Zombie-Sitze" - genau die Geldvernichtung, die CFOs in Tech und Finanzen stoppen wollen.

Verwaiste Konten und Audit-Risiko

Die SCIM-Lückendaten untermauern das:

Laut Stitchflow verursacht jede Nicht-SCIM-App in einem Unternehmen mit 500 Mitarbeitenden im Schnitt 7 verwaiste Konten, 12 ungenutzte Lizenzen und 101 IT-Stunden manuellen Aufwand pro Jahr - über 12.000 US-Dollar pro App jährlich.

Multipliziert mit 20-30 geschäftskritischen Apps bedeutet das:

• Hunderte veraltete Konten, die kompromittiert werden können.
• Versteckte Betriebs- und Lizenzkosten im sechsstelligen Bereich.
• Mit hoher Wahrscheinlichkeit einen "Access-Management"-Befund bei SOC 2-, ISO 27001-, SOX-, HIPAA- oder DORA-Audits.

Prüfgesellschaften berichten übereinstimmend, dass IAM-Schwächen - etwa fehlende Zugriffsrezertifizierungen und unzureichende Lifecycle-Kontrollen - zu den Hauptursachen für Compliance-Befunde gehören.

Ihr setzt eure Audits auf die Heldentaten einzelner Menschen. Das ist nicht skalierbar.

Manuell vs. teilweise vs. vollständig: Was sich bei 500 Mitarbeitenden ändert

Identity Governance entwickelt sich typischerweise so:

Die meisten Unternehmen stecken im Modus "teilweise" fest - IdP-verbundene Apps sind okay, aber der Rest wird wie 2010 manuell verwaltet.

Das Ziel: Schrittweise in Automatisierung, agentische Workflows und ein Abdeckungsmodell wechseln, das zu schlanken IT-Teams passt.

Prinzipien, um Identity zu skalieren, ohne Personal aufzustocken

1. Mit verlässlichen Datenquellen beginnen

Schlechte oder zersplitterte Identity-Daten? Automatisierung beschleunigt nur das Chaos.

Für Organisationen mit 50-500 Personen bedeutet das:

• HRIS als führendes System für Joiner, Mover, Leaver (Mitarbeitende, Externe).
• IdP/SSO als Haustür (Okta, Entra usw.).
• Governance-Schicht, die HR, IdP und alle Apps - ob mit oder ohne SCIM - über konsistente Richtlinien und Workflows verbindet.

Best Practices:

• Eine Mitarbeitenden-ID aus dem HRIS konsequent bis in IdP und Apps durchziehen.
• HR-Ereignisse als Trigger für Provisioning und Deprovisioning nutzen.
• Jobdaten normalisieren, um Richtlinien zu steuern.

2. Den vollständigen Lifecycle für 100 % der Apps automatisieren

Nur SCIM-fähige Apps zu automatisieren, lässt Identity-Blindspots in Finanztools, Nischen-SaaS und Legacy-Systemen.

Die Messlatte sollte lauten:

"Alles, was Zugriff auf Kunden- oder Unternehmensdaten vergibt oder hält, wird über den Lifecycle automatisiert gesteuert."

Das heißt konkret:

• Standardzugriff aus HR + Rolle am ersten Arbeitstag.
• Rollenbasierter Zugriff nach Abteilung/Funktionsbezeichnung.
• Änderungsereignisse aktualisieren Zugriffe automatisch und stoßen bei Bedarf Genehmigungen an.
• Offboarding durch ein einziges HR-Ereignis; alles (Legacy, Nicht-SCIM, externe Portale) wird entzogen.

Dafür braucht es Konnektoren und Workflows jenseits von SCIM. Bei Iden ist genau das der Kern: universelle Konnektoren und feingranulare Berechtigungssteuerung für 175+ Apps - inklusive Long-Tail- und No-API-Tools.

3. Von statischen Kontrollen zu kontinuierlicher Governance wechseln

Vierteljährliche Zugriffsreviews passen nicht zu:

• laufender SaaS-Einführung,
• schnellen organisatorischen Veränderungen,
• permanenten Angriffsversuchen.

Moderne Teams nutzen kontinuierlichen, richtliniengesteuerten Zugriff:

• Automatische Prüfungen, wenn Zugriff angefordert wird (Risiko, SoD, Datenkritikalität).
• Zeitlich begrenzte Berechtigungen für besonders sensible Rechte.
• Rollierende Rezertifizierungen - Führungskräfte sehen Änderungen und Deltas, nicht jedes Mal komplette Listen.

Hier spielen AI-native, agentische Workflows (durch KI gesteuerte, autonome Abläufe) ihre Stärken aus. Agenten klassifizieren Risiken vor, schlagen Entzüge vor, sammeln Nachweise, jagen fehlenden Genehmigungen hinterher - ohne Tabellenkalkulations-Marathon.

4. Menschliche und nicht-menschliche Identitäten gleichrangig steuern

Die am schnellsten wachsenden Identitäten sind nicht Menschen - sondern Servicekonten, Bots, Integrationsuser und externe Dienstleistende.

Eine einheitliche Identity Governance (Menschen + Maschinen) reduziert Sicherheitsvorfälle um 47 % und beschleunigt die Incident Response um 62 %.

Die Marktentwicklung geht in Richtung eine Governance-Ebene für alles und alle:

• klare Eigentümerschaft,
• definierter Nutzungszweck,
• Least-Privilege-Prinzip,
• automatisierte Rotation/Deprovisionierung.

Wenn eure IAM-Lösung diese Identitäten nicht sehen oder steuern kann, löst ihr weder die Probleme der Prüfer noch der Angreifenden.

5. Wirkung messen, nicht nur Konfigurationen

Fragt euch, was sich tatsächlich verändert hat - nicht nur, wie viele Richtlinien ihr definiert habt:

• Manuelle Access-Tickets - Wie viele pro 100 Mitarbeitende und Monat?
• Onboarding-Zeit - Wie lange dauert es, bis eine neue Person 90 % der benötigten Zugriffe hat?
• Offboarding-Abdeckung - Wie viele Konten blieben nach den letzten 10 Abgängen aktiv?
• Review-Aufwand - Wie viele Stunden haben Führungskräfte/IT im letzten Review-Zyklus verbraucht?
• Lizenzverschwendung - Welcher %-Anteil der Sitze in Schlüssel-Apps liegt bei <10 % Nutzung?

Dann: Welche dieser Aufgaben kann ein automatisierter, agentischer Workflow jedes Mal besser erledigen?

Wie vollständige Identity-Automatisierung bei 500 Mitarbeitenden aussieht

Beispiel: Ein SaaS- oder Fintech-Unternehmen mit 400 Personen und:

• einem dreiköpfigen IT-Team,
• 200-250 SaaS-Apps plus einigen Legacy-/On-Prem-Systemen,
• SOC 2 und ISO 27001 im Scope; DORA/SOX stehen vor der Tür.

Statt ein eigenes IAM-Team aufzubauen, entscheidet sich das Unternehmen für eine vollständige Identity-Governance-Plattform für schlanke Teams - sie bindet HRIS/IdP an, erreicht jede App (mit oder ohne SCIM) und nutzt agentische Workflows für Provisioning, Reviews und Lizenzrückgewinnung.

Nach dem Go-Live:

• HR legt eine neue Person im HRIS an -> Standard- und Rollenrechte werden automatisch über 30+ Apps hinweg vergeben.
• Zusätzliche Zugriffe werden über Slack oder ein ITSM-System angefragt -> KI-Agenten genehmigen die meisten Standardanforderungen vorab; Sonderfälle gehen an Menschen.
• Externe erhalten zeitlich begrenzte Konten mit automatischem Ablaufdatum und Benachrichtigungen an die Eigentümer.
• Ein Vorgang in HR oder IdP meldet eine Person ab -> Zugriff wird aus SSO-Apps und Nicht-SCIM-Tools entzogen, gemeinsame Postfächer werden bereinigt, Lizenzen zurückgewonnen.
• Reviews laufen im Hintergrund - Führungskräfte bearbeiten kleine, überschaubare Genehmigungspakete statt vierteljährlicher Tabellenpanik.
• Unveränderliche Protokolle halten fest, wer wann welchen Zugriff hatte, warum und wer genehmigt hat.

Teams, die vollständige Automatisierung einführen, reduzieren manuelle Access-Tickets um 80 %, gewinnen pro Quartal 120 Compliance-Stunden zurück und senken SaaS-Kosten um 30 %.

Das wird möglich, wenn ihr:

• Menschen von 80 % der IAM-Fleißarbeit entlastet,
• Offboarding-Checklisten abschafft,
• die SCIM-Lücke konsequent schließt.

Iden ist genau für diesen Moment gebaut: 50-500 Mitarbeitende, wo SSO alleine nicht mehr reicht und klassische IGA-Lösungen überdimensioniert sind.

Konkrete nächste Schritte für wachstumsstarke Teams

Wenn ihr zwischen 50 und 500 Mitarbeitenden liegt, hilft euch diese fokussierte Reihenfolge - ganz ohne IAM-Team.

Schritt 1: Das Problem quantifizieren

• Listet jede App mit Benutzerkonten auf (SaaS/On-Prem).
• Markiert, welche Apps an den IdP angeschlossen sind, SCIM unterstützen oder nur manuell verwaltet werden.
• Zählt:
  • Anzahl der Joiner-/Mover-/Leaver-Tickets pro Monat,
  • durchschnittliche Onboarding-Zeit,
  • Anzahl der Systeme pro Offboarding-Vorgang.

So schafft ihr eine Ausgangsbasis und erkennt Momente vom Typ "Wir wissen nicht, wem diese App gehört".

Schritt 2: Eure Apps nach Risiko einstufen

Teilt Apps in Gruppen ein:

• Tier 1 - Hohes Risiko: Finanzen, Kundendaten, Produktiv-Infra, HR, Legal, Handel.
• Tier 2 - Mittel: Kollaboration, Produktivität, Engineering.
• Tier 3 - Niedrig: Nicht-sensitive Tools, Marketing, Experimente.

Tier-1-Apps müssen durch Automatisierung abgedeckt sein - mit oder ohne SCIM.

Schritt 3: Euren Ziel-Lifecycle skizzieren

Definiert auf einer Seite, wie "gut" aussieht:

• Wer legt Identitäten an und wo (HRIS vs. direkt in Apps)?
• Wie werden Rollen von HR über IdP zu App-Berechtigungen gemappt?
• Wie sehen die Standard-Genehmigungspfade aus für:
  • Hochrisiko-Zugriffe?
  • Externe Nutzende?
  • Nicht-menschliche Identitäten?

Wenn ihr es nicht zeichnen könnt, könnt ihr es auch nicht automatisieren.

Schritt 4: Automatisierung wählen, die alle Apps abdeckt

Bewertet IAM-Werkzeuge nach:

1. Abdeckung - Kann das System jede relevante App anbinden (SCIM, API oder gar keine Schnittstelle)?
2. Steuerung - Lässt sich damit feingranular steuern (z. B. Kanäle, Repositories, Projekte) und nicht nur "Nutzer in Gruppe X"?
3. Kosten/Geschwindigkeit - Könnt ihr in Tagen live gehen, ohne IAM-Team, und ohne für jede App einen SCIM-Aufpreis zu zahlen?

Nur die 20-40 % mit SSO zu automatisieren, ist kein Fortschritt. Es ist nur Kosmetik im Dashboard.

Schritt 5: Dort starten, wo Audit und CFO den Unterschied merken

Für die meisten Tech- und Finanzorganisationen funktioniert diese Reihenfolge:

1. Offboarding - Schluss mit teilweisem Offboarding und verwaisten Konten.
2. Governance für Tier-1-Apps - Finanzen, HR, Kundendaten, Produktion.
3. Zugriffsreviews/Nachweise - Von Tabellenpanik zu kontinuierlicher, auditfester Rezertifizierung wechseln.
4. Lizenzrückgewinnung - Zombie-Ausgaben stoppen und den ROI belegen.

So erzielt ihr schnelle Erfolge und sichert euch die Unterstützung für den nächsten Schritt.

Häufig gestellte Fragen

Woran erkenne ich, dass wir die "Identity-Mauer" erreicht haben?

Ihr seid darüber hinaus, wenn:

• die IT den Großteil der Woche mit Access-Tickets und Checklisten verbringt,
• neue Mitarbeitende regelmäßig länger als einen Tag auf ihre Tools warten,
• Offboarding nur eine gemeinsame Google-Tabelle ist,
• Zugriffsreviews zur Last-Minute-Aktion werden.

Ihr braucht nicht mehr Prozess - ihr braucht Identity-Automatisierung.

Reicht SSO bei 200-500 Mitarbeitenden nicht aus?

SSO ist notwendig - aber nicht hinreichend.

SSO regelt die Authentifizierung - also die Tür. Es deckt aber nicht ab:

• detaillierte Berechtigungen innerhalb der Apps,
• Lifecycle-Automatisierung für Nicht-SCIM-/abgekoppelte Apps,
• kontinuierliche Zugriffsprüfungen und Nachweise.

SSO beantwortet "Wie melden sich Nutzende an?" Governance beantwortet "Wer hat wann mit welchen Rechten worauf Zugriff - und womit belegen wir das?"

Kann ich durch Automatisierung auf IAM-Spezialistinnen und -Spezialisten verzichten?

Für Unternehmen mit 50-500 Personen: ja - wenn ihr ein IAM wählt, das für schlanke Teams entwickelt wurde:

• Plug-and-Play-Konnektoren, keine Entwicklungsarbeit beim Setup,
• richtlinienbasierte, agentische Workflows,
• eine intuitive Konfigurationsoberfläche ohne Eigenentwicklungen.

Jemand muss Governance verantworten (oft IT- oder Security-Leitung). Aber ihr braucht kein IAM-Großteam, nur um den Betrieb aufrechtzuerhalten.

Wie hilft das bei SOC 2, ISO 27001, SOX oder DORA?

Moderne Rahmenwerke verlangen:

• dokumentierte Joiner-/Mover-/Leaver-Prozesse,
• regelmäßige Zugriffsreviews mit Nachweisen,
• Durchsetzung von Least-Privilege und SoD,
• zeitnahes Offboarding.

Identity-Automatisierung liefert:

• unveränderliche Protokolle: wer wann welchen Zugriff erhalten hat und wer genehmigt hat,
• systemgenerierte Nachweise für Reviews und Entzüge,
• die Sicherheit, dass wirklich jede App - nicht nur IdP-verbundene - abgedeckt ist.

Euer Audit schrumpft von einem Albtraum zu einem Datenexport.

Wie lange dauert Identity-Automatisierung?

Für 100-500 Mitarbeitende gilt:

• Tage statt Quartale - mit der richtigen Plattform.
• Erste Apps werden oft in 24-48 Stunden automatisiert; spürbare Ticket-Reduktion innerhalb eines Monats - dank vorgefertigter Konnektoren für übliche SaaS-/HR-/IdP-Kombinationen.

Das Schwierigste ist die Einigung auf Rollen und Richtlinien - nicht die Technologie.

Identity Governance sollte nicht im Gleichschritt mit der Kopfzahl wachsen. Mit der richtigen Automatisierung und einer universellen Abdeckung eures Stacks - inklusive der 80 % der Apps ohne SCIM - erreicht ihr starke Sicherheit und prüfungsreife Compliance ohne ein großes IAM-Team.

Um zu sehen, wie das in der Praxis aussieht - universelle Konnektoren, feingranulare Steuerung, AI-native, wartungsfreie Workflows - lohnt sich ein Blick auf eine vollständige Identity-Plattform wie Iden. Erlebt "complete" in der Praxis.