Hier ein Szenario, das häufiger vorkommt, als viele CISOs zugeben: Dein Unternehmen nutzt 40-60 SaaS-Tools, dein SSO ist eingerichtet, MFA ist aktiv - und dann fragt jemand, wer Zugriff auf eure GitHub-Repos, euren Notion-Workspace oder eure Figma-Dateien hat. Die Antwort dauert drei Tage und braucht vier Excel-Listen.
Das ist kein Prozessproblem. Das ist ein Problem der Identity Security.
Missbrauch von Zugangsdaten war 2025 der häufigste initiale Angriffsvektor und machte laut Verizons Data Breach Investigations Report 2025 22 % aller Datenpannen aus. Und 91 % der Unternehmen berichten von mindestens einem identitätsbezogenen Sicherheitsvorfall im letzten Jahr - fast doppelt so viele wie im Jahr davor. Der Perimeter ist Geschichte. Identität ist die neue Control Plane.
Die gute Nachricht: Du brauchst kein großes Enterprise-IAM-Team, um Identity First Security aufzubauen. Ein IT- oder Security-Team mit 3-5 Personen kann das leisten - wenn es in der richtigen Reihenfolge vorgeht und Tools wählt, die zu den eigenen Einschränkungen passen.
Das hier ist genau dieses Playbook.
Was "Identity-First" wirklich bedeutet (und was nicht)
Identity First Security bedeutet: Jede Zugriffsentscheidung startet mit einer verifizierten Identität - nicht mit einem Netzwerkstandort, keiner VPN-Session, keiner IP-Adresse. Cloud-Adoption, Remote Work und API-getriebene Architekturen haben klassische Netzwerkgrenzen aufgelöst. Identität ist heute der einzige konsistente Kontrollpunkt über alle Umgebungen und Zugriffspfade hinweg.
In der Praxis heißt das:
- Jede Zugriffsanfrage wird kontinuierlich bewertet, nicht nur beim Login.
- Berechtigungen hängen an Rollen und Policies, nicht an statischen Gruppenmitgliedschaften, die nie überprüft werden.
- Offboarding entzieht den Zugriff überall - nicht nur im Verzeichnis oder SSO, sondern in jeder App, mit der der User interagiert hat.
- Nicht-menschliche Identitäten - Service-Accounts, API-Keys, Bots, KI-Agenten - werden mit derselben Disziplin gesteuert wie menschliche User.
Was es nicht bedeutet: MFA ausrollen und das Thema für erledigt erklären. MFA ist eine Voraussetzung, keine Architektur.
Die eigentliche Herausforderung für schlanke Teams ist nicht das Konzept, sondern die Lücke zwischen Authentifizierung (was dein SSO abdeckt) und Identity Governance (was die meisten Teams noch manuell machen). Genau in dieser Lücke - typischerweise 60-80 % deines App-Stacks - steckt dein reales Risiko.
Die Abdeckungslücke in einfachen Zahlen: Die meisten SSO- und SCIM-nur Setups automatisieren die Governance für 20-40% Ihres Anwendungs-Stacks. Der restliche Anteil von 60-80% - Legacy-Tools, Nischen-SaaS-Apps, Apps ohne APIs - wird nach wie vor per Tickets und Tabellen verwaltet. Darin liegt das größte Risiko.
Bevor du startest: Zwei Dinge, die du über deinen Stack wissen musst
1. Erstelle ein vollständiges Inventar aller Apps - inklusive der "inoffiziellen" Tools.
Eine solide Identity-First Security Architektur beginnt mit einer ehrlichen Bestandsaufnahme. Ziehe Listen aus deinem SSO, deinem Browser-Management, deinem ITSM bzw. Ticket-System und deinen Spesenabrechnungen. Du wirst Apps finden, die IT nie bereitgestellt hat und heute nicht deprovisionieren kann. Das ist deine Shadow-IT-Fläche.
2. Kategorisiere jede App nach Integrationsfähigkeit.
Sobald du die Liste hast, sortiere deine Apps in drei Buckets:
| Bucket | Was das bedeutet | Risikostufe |
|---|---|---|
| SSO-angebunden + SCIM-fähig | Voll automatisierbar | Gemanagt |
| SSO-angebunden, kein SCIM | Login kontrolliert, Zugriff nicht governed | Mittel |
| Nicht im SSO | Vollständig ungemanagt - Direkt-Logins, lokale Accounts | Hoch |
Die meisten SaaS-lastigen Teams stellen fest: Bucket 3 enthält 40-60 % der Apps. Genau dort startet dieses Playbook.
Das 7-Schritte-Playbook
Inventiere jede App, auf die dein Team zugreift. Teile sie in drei Bereiche auf: (1) SSO-verbundene, (2) SCIM-automatisierte, (3) manuell/ticketiert. Bereich 3 ist deine unmittelbare Risikoberfläche.
Aktiviere MFA universell, konfiguriere Richtlinien für bedingten Zugriff und deaktiviere lokale Anmeldungen, wo immer möglich. Dokumentiere dann jede App, auf die dein SSO nicht zugreifen kann – diese Liste ist deine Governance-Lücke.
Füge eine IGA-Plattform (Identity Governance and Administration) hinzu, die sich mit allen Apps verbindet – einschließlich solcher ohne SCIM oder APIs. Dies ist die Schicht, die festlegt, wer Zugriff auf was hat, Lebenszyklus-Ereignisse automatisiert und Zugriffsüberprüfungen durchführt.
Verbinde dein HRIS mit deiner IGA-Plattform. Definiere rollenbasierte Bereitstellungsprofile für jede Jobfunktion. Jeder Neueintritt, jeder Rollenwechsel und jeder Austritt sollte automatische Zugriffsänderungen in allen verbundenen Apps auslösen – nicht nur in den SCIM-freundlichen.
Ersetze periodische Spreadsheet-Überprüfungen durch ständig aktive, automatisierte Zugriffs-Zertifizierungen. Kennzeichne verwaiste Konten, überprovisionierte Benutzer und veraltete Berechtigungen in Echtzeit – bevor ein Angreifer oder Auditor sie zuerst findet.
Inventariere Service-Konten, API-Schlüssel, Bots und KI-Agenten. Weise ihnen Eigentümer zu, lege Ablaufrichtlinien fest und bringe sie in dieselbe Governance-Schicht wie deine menschlichen Benutzer. Nicht-menschliche Identitäten sind jetzt die am schnellsten wachsende Angriffsfläche.
Führe vierteljährlich eine Abdeckungskontrolle durch: Welcher Anteil der Apps ist vollständig governance-gesteuert? Verfolge die mittlere Zeit bis zur Deprovisionierung, die Anzahl verwaister Konten und die Abschlussquoten von Zugriffsüberprüfungen. Das sind deine Leistungskennzahlen zur Identitätssicherheit.
Schritt 1 im Detail: Deine tatsächliche Angriffsfläche finden
Das Konzept der "Protect Surface" ist für schlanke Teams nützlicher als der alte "Perimeter", weil es konkret umsetzbar ist. Du versuchst nicht, alles gleichzeitig zu schützen - du identifizierst, wo ein Breach tatsächlich weh tun würde.
Für die meisten Teams umfasst diese kritische Fläche:
- Source-Code-Repositories (GitHub, GitLab) - insbesondere Repos mit Produktionszugriff oder Secrets
- Kommunikationstools (Slack, Teams) - wo sensible Informationen oft informell landen
- Projekt- und Produkt-Workspaces (Linear, Jira, Notion) - mit Roadmaps und Finanzdaten
- Cloud-Umgebungen (AWS, GCP, Azure) - wo der Blast Radius einer kompromittierten Identität am größten ist
- Finanz- und HR-Systeme - wo die am stärksten regulierten Daten liegen
Liste deine Top 10-15 Systeme auf. Frage dich dann: Wenn ein Account hier kompromittiert wird, worauf könnte die Person zugreifen - und wie hoch wäre der Schaden? Genau dieses Ranking bestimmt die Priorisierung deiner Identity Governance.
Schritt 2 im Detail: SSO ist das Fundament - nicht die Ziellinie
SSO (Single Sign-On) ist der richtige Startpunkt für Identity First Security. Es zentralisiert die Authentifizierung, ermöglicht Conditional-Access-Policies und gibt dir einen zentralen Hebel, um einen User schnell zu deaktivieren. Wenn du noch nicht auf eine SSO-Plattform konsolidiert hast, ist eine saubere SSO Implementierung der erste Schritt.
Aber SSO hat harte Grenzen, die schlanke Teams oft zu spät kennenlernen:
- SSO steuert nur Apps, an die es angebunden ist. Viele SaaS-Tools - vor allem in Standard-Tarifen - unterstützen kein SCIM und teilweise nicht einmal sauberes SSO. Du kannst jemanden aus Okta entfernen und trotzdem hat die Person noch aktive Sessions in drei anderen Apps.
- SSO steuert nicht, was User innerhalb der App tun dürfen. SSO kontrolliert die Vordertür. Feingranulare Berechtigungen - welche Slack-Channels, welche GitHub-Repos, welche Notion-Seiten - bleiben für die meisten SSO-Setups unsichtbar.
- Teilweises Offboarding ist eine reale und häufige Sicherheitslücke. Angreifer "hacken" sich heute seltener rein - sie loggen sich ein. Gestohlene Credentials, Privilege Escalation und Account Takeover sind der Weg mit dem geringsten Widerstand. Ein User, der im Verzeichnis entfernt, aber in einer SaaS-App nicht deaktiviert wurde, ist eine offene Tür.
Die Lösung ist nicht, SSO zu ersetzen, sondern eine Governance-Schicht darüber zu legen. Genau dafür gibt es Identity Governance & Administration (IGA).
Schritt 3 im Detail: Die Governance-Schicht - was IGA tatsächlich leistet
IGA ist die Schicht, die die Fragen beantwortet, an denen SSO scheitert:
- Wer hat worauf Zugriff - über alle Apps hinweg?
- Wann haben sie diesen Zugriff erhalten, und warum?
- Sollten sie diesen Zugriff heute noch haben?
- Wird beim Offboarding der Zugriff wirklich überall entzogen?
Das Problem: Viele "moderne IGA"-Lösungen haben dieselbe Blindstelle wie SSO - sie automatisieren nur Apps mit SCIM-Support. Das bedeutet: Du verwaltest immer noch 60-80 % deines Stacks manuell - mit Tickets, E-Mails und Deprovisioning-Checklisten.
Was du tatsächlich brauchst, ist eine Plattform mit universeller Connector-Technologie - also Konnektoren, die Apps via SCIM, via API oder ganz ohne offizielle Schnittstelle anbinden. Das ist der Unterschied zwischen teilweiser Identity Governance und vollständiger Identity Governance.
Für ein schlankes Team sollten die praktischen Auswahlkriterien für eine IGA-Plattform so aussehen:
- Go-Live in Stunden, nicht in Monaten. Ein Implementierungsprojekt über 6-18 Monate ist für ein 3-Personen-IT-Team keine Option.
- Keine erzwungenen Enterprise-Upgrades, nur um Kern-Apps zu automatisieren (die "SCIM-Steuer" - das Drei- bis Vierfache zahlen, um eine API freizuschalten, die Standard sein sollte).
- Feingranulare Kontrolle bis auf Channel-, Repo- und Projektebene - nicht nur "User ist Mitglied der Gruppe X".
- Automatisiertes Lifecycle-Management, damit Onboarding, Rollenwechsel und Offboarding automatisch die passenden Zugriffsänderungen auslösen - ohne Zugriffstickets.
- Minimaler laufender Aufwand. Zielgröße: Zero Upkeep.
Iden ist genau für diese Realität gebaut - universelle Konnektoren für 175+ Apps (Tendenz steigend), keine SCIM-Steuer und in etwa 24 Stunden live. Iden ergänzt dein SSO - es ersetzt es nicht.
Schritt 4 im Detail: Zero-Touch-Onboarding und sauberes Offboarding
Sobald deine IGA-Schicht steht, zahlt sich der JML-Prozess - Joiner, Mover, Leaver - sofort aus. Kernstück ist dabei Automatisiertes Benutzer-Provisioning, verankert in klaren Identity Governance Richtlinien.
Joiners (Neueinstellungen): Verbinde dein HRIS (Workday, BambooHR, Personio, ADP) als Source of Truth mit deiner IGA-Plattform. Wenn ein neuer Mitarbeiter im HR-System angelegt wird, startet die Provisionierung automatisch - die richtigen Apps, die richtigen Berechtigungsstufen, die richtigen Team-Channels - ohne ein einziges Ticket. Für ein Team mit 5-20 New Hires pro Monat, die jeweils 10-30 Apps brauchen, eliminiert das hunderte manueller Aufgaben pro Monat.
Movers (Rollen- und Teamwechsel): Rollenwechsel, Teamtransfers und Beförderungen sollten automatisch angepasste Zugriffe auslösen. Alte Berechtigungen werden entzogen, neue rollenbasierte Berechtigungen vergeben. Ohne Automatisierung passieren diese Anpassungen entweder gar nicht oder viel zu spät - und erzeugen überprivilegierte Konten, die bei jedem Audit auffallen.
Leavers (Offboarding): Das ist der risikoreichste Moment. Wenn jemand geht - geplant oder ungeplant - ist jede Minute aktiver Zugriffe eine potenzielle Sicherheitslücke. Automatisiertes Offboarding, das Zugriffe aus allen angebundenen Apps entzieht (nicht nur aus den SCIM-fähigen), reduziert die Deprovisionierungszeit von Tagen auf unter eine Stunde. Für externe Mitarbeitende und Saisonkräfte, die nicht immer im zentralen Verzeichnis geführt werden, ist das noch kritischer - Details dazu findest du in unserem Guide zur Identity Governance für externe Mitarbeitende.
Schritt 5 im Detail: Kontinuierliche Zugriffsüberprüfungen - statt Audit-Theater einmal im Quartal
Der typische Access-Review-Prozess in einem 200-Personen-Unternehmen: Jemand exportiert eine Excel-Liste mit Usern und Rollen, schickt sie an Manager, die mangels Zeit alles pauschal "freigeben", und legt das Ergebnis im Compliance-Ordner ab. Gummistempel, keine Governance.
Kontinuierliche Zugriffsüberprüfungen funktionieren anders:
- Sie laufen permanent, nicht quartalsweise. Entitlements werden in Echtzeit bewertet, sobald sich Rollen ändern, Apps hinzukommen oder User inaktiv werden.
- Automatisches Flagging von verwaisten Konten (User nicht mehr im HR, aber mit aktivem App-Zugriff), überprivilegierten Konten und Policy-Verletzungen.
- Gezielte Review-Anfragen, nur wenn es einen echten Anlass gibt - nicht als Massen-Zertifizierung, die niemand ernst nimmt.
- Strukturierte Audit-Belege, die automatisch erzeugt werden, statt sie aus Screenshots und Log-Exports zusammenzuklicken.
Datenpannen mit gestohlenen oder kompromittierten Credentials brauchen im Schnitt 292 Tage, um entdeckt und bereinigt zu werden - länger als jeder andere Angriffsvektor. Kontinuierliche Zugriffsüberprüfungen sind der Hebel, mit dem du genau die Zugriffslücken erkennst und schließt, auf deren lange "Dwell Time" Angreifer bauen.
Schritt 6 im Detail: Die nicht-menschlichen Identitäten, die du bisher ignoriert hast
Hier kommt der Teil, den die meisten schlanken Teams überspringen - und der Teil, auf den Angreifer sich zunehmend fokussieren: nicht-menschliche Identitäten (NHIs).
Menschliche User, Service-Accounts, API-Keys, Machine Identities und KI-Agenten brauchen alle Governance. In vielen Organisationen übertreffen nicht-menschliche Identitäten die Zahl der Menschen deutlich und werden gleichzeitig am wenigsten gesteuert.
In einem typischen SaaS-Unternehmen mit 500 Mitarbeitenden findest du vielleicht 500 menschliche Identitäten - aber 2.000+ nicht-menschliche: CI/CD-Bots, Slack-Workflow-Automationen, API-Keys für Integrationen, Service-Accounts in Cloud-Umgebungen und zunehmend KI-Agenten mit autonomem Zugriff auf Tools und Daten.
Die gleichen Governance-Prinzipien gelten auch hier:
- Inventar zuerst. Du kannst nichts steuern, was du nicht gefunden hast. Erfasse jeden Service-Account, jeden API-Key, jeden Bot.
- Verantworliche zuweisen. Jede nicht-menschliche Identität braucht einen menschlichen Owner. "Verwaiste" Service-Accounts ohne Verantwortliche sind ein etablierter Angriffsvektor.
- Ablaufrichtlinien definieren. API-Keys und Tokens sollten rotieren. Service-Accounts brauchen ein Ablaufdatum. Dauerhafter Standing Access ist ein Risiko.
- Least Privilege anwenden. Ein CI/CD-Bot braucht Zugriff auf deine Deployment-Pipeline - nicht auf dein HR-System.
- NHIs in deine Identity Governance integrieren. Die gleichen Access-Reviews, Audit-Trails und Lifecycle-Policies, die menschliche User steuern, sollten auch für Machine Identities und andere NHIs gelten.
Für eine detaillierte Schritt-für-Schritt-Anleitung speziell zu KI-Agenten und NHI-Governance, sieh dir unseren Guide zur Absicherung von KI-Agent-Zugriffen und nicht-menschlichen Identitäten an.
Schritt 7 im Detail: Das messen, was wirklich zählt
Du kannst nichts steuern, was du nicht misst. Für ein schlankes Team liefern vier Kennzahlen fast alles, was du über deine Identity-First Security und deine Identity Governance wissen musst:
| Metrik | Was sie misst | Ziel |
|---|---|---|
| App-Coverage-Rate | % der Apps mit vollständiger Governance (automatisiertes Provisioning, Deprovisioning, Zugriffsüberprüfungen) | 100 % |
| Mean Time to Deprovision | Zeit vom Offboarding-Ereignis bis zum vollständigen Entzug aller Zugriffe | Unter 1 Stunde |
| Anzahl verwaister Konten | Aktive Accounts, die zu ausgeschiedenen Usern gehören | Null |
| Abschlussrate von Access-Reviews | % der ausgelösten Reviews, die innerhalb der SLA abgeschlossen werden | 100 % |
Verfolge diese Werte monatlich. Wenn die Abdeckung unter 80 % fällt oder verwaiste Konten wieder auftauchen, weißt du sofort, wo du ansetzen musst.
Prüfe deine aktuelle Abdeckung
Vor oder nach der Umsetzung dieses Playbooks lohnt sich ein ehrlicher Status-Check. Dieses interaktive Tool geht acht zentrale Indikatoren für deine Identity-First Security Readiness durch:
Die Tools, die du brauchst (und die eine Lücke, die die meisten übersehen)
Eine vollständige Identity-First Security Architektur für ein schlankes Team sieht typischerweise so aus:
- HRIS (Workday, BambooHR, Personio, ADP) - Source of Truth für Identity Lifecycle Events
- SSO (Okta, Microsoft Entra ID) - Authentifizierung, MFA, Conditional Access
- IGA-Plattform (Iden) - Governance-Layer mit kompletter Identity Governance über alle Apps, Lifecycle-Automatisierung, Zugriffsüberprüfungen, Audit-Trails
- SIEM oder Log-Aggregation (früh optional) - Verhaltensanalyse und Anomalieerkennung
Auffällig, was nicht auf der Liste steht: ein dedizierter IAM Engineer, ein 6-monatiges Implementierungsprojekt oder ein Enterprise-Vertrag mit einem Legacy-Giganten. Ziel ist vollständige Abdeckung mit schlankem, zielgerichtetem Tooling.
Die eine Lücke, die die meisten Teams erst spät entdecken: Ihre IGA-Plattform deckt nur SCIM-Apps ab. Sie glauben, vollständige Governance zu haben - und stellen dann im Audit oder im Incident fest, dass 60 % des Stacks nie automatisiert wurden. Universelle Connector-Abdeckung ist das wichtigste Kriterium bei der Auswahl eines IGA-Tools.
Für einen direkten Vergleich von IGA-Plattformen für schlanke Teams, sieh dir unseren IGA-Vendor-Vergleich 2026 an.
Wie "fertig" für ein schlankes Team aussieht
Ein schlankes Team, das dieses Playbook umgesetzt hat, sollte in der Lage sein:
- Einen neuen Mitarbeiter zu onboarden - mit Zugriff auf den kompletten relevanten App-Stack, mit rollenbasierten Berechtigungen - automatisch, innerhalb weniger Stunden nach Anlage im HRIS. Ohne Tickets.
- Eine ausscheidende Person zu offboarden und den Zugriff auf alle angebundenen Apps in unter einer Stunde zu entziehen. Ohne manuelle Checkliste.
- Die Frage "Wer hat worauf Zugriff - und seit wann?" in unter 30 Minuten zu beantworten - ohne Excel, für jede App im gesamten Stack.
- Audit-Belege für SOC 2, ISO 27001, HIPAA oder DORA jederzeit bereitzustellen - mit unveränderlichen Audit-Logs, Access-Review-Historie und Lifecycle-Daten, ohne manuellen Evidenz-Marathon.
- Verwaiste Konten, überprivilegierte User und Policy-Verletzungen kontinuierlich zu erkennen und zu beheben - nicht nur einmal im Quartal, wenn der Audit ansteht.
Nichts davon erfordert ein dediziertes IAM-Team. Es erfordert die richtige Architektur, eine saubere SSO Implementierung - und die richtige Plattform für Identity Governance.
FAQ
Braucht unser Team einen dedizierten IAM-Ingenieur, um dies umzusetzen?
Nein. Der Leitfaden ist speziell für schlanke IT-Teams mit 3-5 Personen (oder weniger) ohne eine dedizierte IAM-Funktion konzipiert. Der Schlüssel liegt darin, eine IGA-Plattform zu wählen, die für diese Realität gebaut ist – eine, die innerhalb von Stunden statt Monaten bereitgestellt wird, keine Systemintegratoren benötigt und mit minimalem laufenden Wartungsaufwand betrieben wird. Iden ist exakt für dieses Modell konzipiert.
Wir haben bereits Okta. Warum reicht das nicht aus?
Okta (und jedes SSO) kümmert sich um die Authentifizierung – es ist die Haustür. Aber es regelt den Zugriff nur für Apps, die über SCIM verbunden sind, was typischerweise 20-40% eines realen SaaS-Stacks ausmacht. Alles andere – Notion, Figma, Linear, deine eigenen Tools, Legacy-Systeme – fällt durch die Lücke. Identity-first security erfordert eine Governance-Schicht, die alle dieser Apps abdeckt, nicht nur die SCIM-freundlichen.
Was ist der Unterschied zwischen IGA und IAM?
IAM (Identity and Access Management) ist die breite Kategorie, die Authentifizierung, Verzeichnisdienste und Zugriffskontrolle umfasst. IGA (Identity Governance and Administration) ist eine spezifische Disziplin innerhalb von IAM, die sich darauf konzentriert, wer Zugriff auf was hat zu regeln, Lebenszyklusrichtlinien (joiner-mover-leaver) durchzusetzen, Zugriffsprüfungen durchzuführen und Audit-Belege zu erzeugen. SSO ist IAM. Was darauf aufsitzt – Automatisierung des Lebenszyklus, Zugriffsprüfungen, feingranulare Berechtigungsverwaltung – ist IGA.
Wie gehen wir in diesem Modell mit Auftragnehmern und temporären Mitarbeitenden um?
Auftragnehmer sind eine der größten JML-Blindstellen. Die meisten HR-Systeme verfolgen sie nicht zuverlässig, sodass sie außerhalb der standardmäßigen Lebenszyklus-Automatisierung fallen und verwaiste Konten hinterlassen. Die Lösung: Integrieren Sie Auftragnehmer in Ihre IGA-Plattform als eigenen Identitätstyp mit definierten Zugriffprofilen, expliziten Ablaufdaten und automatisierter Deprovisionierung zum Vertragsende. Siehe unseren Leitfaden zur Auftragnehmer-Identitätsgovernance für eine detaillierte Schritt-für-Schritt-Anleitung.
Wie lange dauert es, eine vollständige Abdeckung eines SaaS-Stacks mit 30 Apps zu erreichen?
Mit einer Plattform wie Iden, die universelle Konnektoren verwendet (SCIM, API oder gar keinen), können Sie in ca. 24 Stunden in Ihrem Core-Stack live gehen. Die vollständige Abdeckung – einschließlich Long-Tail-Apps und Nicht-SCIM-Apps – dauert typischerweise 1–2 Wochen, abhängig von der Komplexität Ihres Stack. Das ist deutlich schneller als herkömmliche IGA-Tools, die typischerweise 6–18 Monate Implementierungsprojekte erfordern.
Was sind die wichtigsten Metriken zur Verfolgung der Identitätssicherheit?
Für ein schlankes Team konzentrieren Sie sich auf vier: (1) App-Abdeckungsrate - welcher Prozentsatz der Apps vollständig verwaltet wird (Ziel: 100%). (2) Durchschnittliche Zeit bis zur Deprovisionierung - wie lange nach einem Offboarding-Ereignis, bis allen Zugriff entzogen ist (Ziel: unter 1 Stunde). (3) Anzahl verwaister Konten - aktive Konten, die abgegangenen Benutzern gehören (Ziel: Null). (4) Abschlussquote der Zugriffsprüfungen - welcher Prozentsatz der Zugriffsprüfungen rechtzeitig abgeschlossen wird (Ziel: 100%). Diese vier Kennzahlen zeigen dir, ob deine identitätsorientierte Haltung Bestand hat.
Bereit, die Lücke zu schließen?
Identity First Security mit einem schlanken Team aufzubauen ist absolut machbar - aber nur, wenn du die Lücke zwischen dem, was dein SSO abdeckt, und dem, was dein gesamter Stack tatsächlich braucht, schließt. Die meisten Teams sind nur einen Schritt entfernt: Authentifizierung ist gelöst, es fehlt die durchgängige Identity Governance.
Iden liefert vollständige Identity Governance über deinen gesamten Stack - jede App, jeder Identitätstyp, jedes Lifecycle-Event - live in rund 24 Stunden, ohne SCIM-Steuer, ohne Enterprise-Plan-Upgrade und ohne zusätzliches IAM-Headcount.
