Identity Fabric, entmystifiziert: Was hinter dem Buzzword steckt

"Identity Fabric" steht auf jeder Roadmap, in jedem Analystenbericht, in jedem Vendor-Deck. Und genau deshalb hat der Begriff aufgehört, etwas zu bedeuten. Wenn ein Wort alles beschreibt, beschreibt es nichts.

Dieser Artikel ist kein Glossar-Eintrag. Er ist eine ehrliche Einordnung: Was ist eine Identity Fabric wirklich, was leistet sie architektonisch, wo hört sie auf - und warum ist die Governance-Schicht das Herzstück, das die meisten Implementierungen noch immer schuldig bleiben.

Alle Identitäten in einer Ansicht

Kurz gezeigt: Wie menschliche und nicht-menschliche Identitäten in einer einzigen Governance-Ansicht zusammenlaufen statt in drei getrennten Systemen.

---

Was eine Identity Fabric tatsächlich ist - und was nicht

Eine Identity Fabric ist der architektonische Ansatz, der Identity and Access Management (IAM) über alle Systeme, Umgebungen und Identitätstypen hinweg vereinheitlicht. Kein einzelnes Produkt, kein Vendor-Feature, kein Modul. Ein Architekturprinzip.

Die Fabric sitzt auf der bestehenden Identity-Infrastruktur einer Organisation und orchestriert sie als einheitliches System. Die Komponenten, die sie verbindet, umfassen typischerweise Identity Provider (IDPs), Access-Management-Lösungen, Directory Services, SIEM-Systeme, IGA-Tools und API-Gateways.

Das klingt nach einem großen Versprechen. Und es ist eines - aber mit einem entscheidenden Vorbehalt: Identity ist die neue Control Plane der Enterprise-Security, und die Architektur, die sie regiert, hat mit der Umgebung, die sie schützen soll, nicht Schritt gehalten. Fragmentierte IAM-Stacks, explodierende Non-Human-Identity-Populationen und applikationsnative Authentifizierungslogik, die zentralisierte Tools nie erreichen, haben eine Angriffsfläche geschaffen, die die meisten Organisationen noch nicht vollständig kartiert haben.

Eine Fabric löst das Fragmentierungsproblem auf Architekturebene. Sie löst nicht automatisch das Governance-Problem.

Warum fragmentierte Stacks gefährlicher sind als sie aussehen

Um zu verstehen, warum Identity Fabric an Fahrt gewinnt, betrachte den Zustand von Enterprise-IAM im Jahr 2026: Tool-Sprawl. Das durchschnittliche große Unternehmen nutzt 6-8 verschiedene IAM-Produkte über Workforce Identity, Customer Identity, Privileged Access, Governance, Machine Identity und Cloud Entitlements. Jedes hat sein eigenes Datenmodell, seine eigene Policy-Sprache und seine eigene Administrationserfahrung.

Das Ergebnis ist nicht nur operativer Overhead. Fragmentierte IAM-Stacks erzeugen etwas Gefährlicheres als Verwaltungsaufwand. Wenn Identity-Daten zwischen einer PAM-Plattform, einer IGA-Lösung und dem nativen IAM-Layer eines Cloud-Providers voneinander abweichen, erbt jede nachgelagerte Sicherheitsentscheidung diese Inkonsistenz. SIEM-Detektionen, Access-Anomalie-Scoring und Incident Response hängen alle von akkuraten, synchronisierten Identity-Daten ab. Wo diese Synchronisation abbricht, arbeiten Defender mit widersprüchlichen Versionen der Wahrheit, während Angreifer die Lücken zwischen Systemen ausnutzen.

Das ist das eigentliche Argument für eine Fabric: nicht Konsolidierung um der Konsolidierung willen, sondern konsistente Policy-Durchsetzung über alle Schichten.

Die Schicht, die alle übersehen: Governance

Hier wird es konkret - und hier trennt sich die Theorie von der Praxis.

Eine Identity Fabric erzwingt konsistente Access-Policies über IAM, PAM, IGA und das gesamte Applikationsportfolio hinweg - von einer einzigen Governance-Schicht aus, anstatt separate Policy-Engines pro Tool zu verwalten. Das ist das Ideal. Die Realität in den meisten Unternehmen: Die Governance-Schicht ist entweder gar nicht vorhanden, auf SCIM-fähige Apps beschränkt oder so komplex implementiert, dass sie niemand wirklich bedient.

Die Policy-Engine übersetzt Governance-Anforderungen - einschließlich Framework-Controls aus NIST CSF, PCI DSS, HIPAA und ISO 27001 sowie organisationaler Access-Policies - in ausführbare Regeln. Diese Regeln regeln Authentifizierungsanforderungen, Privilege-Grenzen, Session-Constraints und MFA-Enforcement für jeden Identitätstyp im Scope. Die Orchestrierungsschicht schiebt diese Regeln an verbundene IAM-, IGA- und PAM-Systeme, ohne dass jede nachgelagerte Plattform ihre eigene separate Policy-Konfiguration pflegen muss.

Das ist der Anspruch. Aber wer hat in der Praxis eine solche Orchestrierungsschicht vollständig implementiert? Und wer hat sie für alle Apps - nicht nur für die SCIM-freundlichen?

Das Non-Human-Identity-Problem: Die Fabric muss größer denken

Security-Architekten, die heute eine Identity Fabric planen, stehen vor einem Problem, das vor drei Jahren noch kaum existierte: der Explosion von Non-Human Identities (NHIs).

Laut Palo Alto Networks' Identity Security Landscape Report 2026 übersteigen Machine Identities - einschließlich AI-Agenten - menschliche Identitäten im Verhältnis 109 zu 1, gegenüber 82 zu 1 im Vorjahr. Das ist ein Anstieg von fast einem Drittel innerhalb eines einzigen Jahres.

In cloud-nativen Umgebungen kann das Verhältnis laut Entro Labs auf 144 zu 1 steigen. In modernen Unternehmen übersteigen Non-Human Identities - Service Accounts, API Keys, OAuth Tokens, Machine Certificates und die Credentials von AI-Agenten - menschliche Nutzer im Durchschnitt um das 45-fache. Die Governance-Frameworks, die auf diese Identitäten angewendet werden, entsprechen selten der Strenge, die für ihre menschlichen Pendants gilt.

Das ist kein Randproblem. Während Organisationen menschliche Nutzer akribisch verfolgen, proliferieren NHIs in SaaS-Umgebungen mit minimaler Security-Aufsicht und schaffen einen Identity Blind Spot, an dem 68 % der IT-Security-Incidents beteiligt sind.

Eine Identity Fabric, die nur menschliche Identitäten abdeckt, ist 2026 keine Fabric - sie ist ein Sieb.

Secrets Vaults sind kein Ersatz für Governance

Ein häufiger Denkfehler in Security-Teams: "Wir haben einen Vault - unsere Machine Identities sind abgesichert."

Die Marktreaktion auf NHI-Risiken hat historisch auf Credential Vaulting zurückgegriffen. PAM-Plattformen vaulten Secrets, schränken Zugriff ein und zeichnen Sessions auf. Das ist ein notwendiger Ausgangspunkt, adressiert aber nur das Problem "Credential at rest sichern". Es beantwortet nicht die Governance-Fragen: Welche NHIs existieren in meiner Hybrid-Umgebung, einschließlich plattformverwalteter, die der Provider kontrolliert?

Jahrelang haben wir Secrets Management (den Vault) und Identity Governance and Administration (IGA) als separate Silos behandelt. Der Vault war für die Engineers; IGA war für HR und Compliance. Diese Trennung ist heute ein klaffendes Sicherheitsloch. Einen Secret zu vaulten ist nutzlos, wenn man nicht weiß, wer - oder was - berechtigt ist, auf diesen Vault zuzugreifen, oder wenn dieser Secret Berechtigungen hat, die seinen Zweck übersteigen.

Laut einer Analyse des NHIMG haben nur 20 % der Organisationen formale Prozesse für das Offboarding und die Revokation von API Keys. 96 % der Organisationen speichern Secrets außerhalb von Secrets Managern an unsicheren Orten - in Code, Config-Dateien und CI/CD-Tools.

Der Vault ist eine notwendige Komponente. Er ist nicht die Governance-Schicht. "We use a vault" ist keine Antwort mehr, die standhält.

Was eine echte Governance-Schicht leisten muss

Wenn die Fabric das Netzwerk ist, ist IGA das Nervensystem. Ohne es gibt es keine Entscheidungen, nur Verbindungen.

Eine vollständige Governance-Schicht über einer Identity Fabric muss:

• Universelle App-Coverage liefern - nicht nur für SCIM-fähige Tools, sondern für den gesamten Stack, einschließlich der Apps, die kein SCIM unterstützen oder es hinter Enterprise-Tiers verstecken.
• Feingranulare Kontrolle ermöglichen - tiefer als Gruppen und Rollen, bis auf Channel-, Repository- und Projektebene.
• Human und Non-Human Identities in einem einzigen, auditierbaren Policy-Framework vereinen.
• Lifecycle-Automatisierung vollständig abdecken - Onboarding, Änderungen, Offboarding - ohne manuelle Ticket-Queues.
• Policy-driven sein, nicht regelbasiert-statisch: Workflows, die sich an Kontext anpassen, nicht an Ausnahmen scheitern.

Innerhalb einer Identity Security Fabric wird Governance zu einer aktiven Defense-Schicht, die Least-Privilege-Enforcement und risikobasierte Access-Zertifizierungen ermöglicht, die Exposition reduzieren und Resilienz verbessern.

Das ist der Anspruch. Ihn zu erfüllen, erfordert eine IGA-Plattform, die nicht an SCIM-Grenzen endet.

Der SCIM-Tax-Effekt: Warum Coverage-Lücken teuer werden

Viele "moderne" IGA-Tools werben mit Identity-Fabric-Kompatibilität - und liefern dann nur für SCIM-fähige Apps. Der Rest des Stacks bleibt manuell verwaltet.

Das ist kein Randproblem. In einem typischen SaaS-Stack sind die kritischsten Tools oft genau die, die kein SCIM unterstützen - oder es nur in teuren Enterprise-Tiers anbieten. Notion, Figma, Linear, GitHub auf Repo-Ebene, Slack auf Channel-Ebene: All das fällt durch das Raster klassischer SCIM-basierter Governance.

Organisationen stoßen auf SCIMs Grenzen typischerweise erst nach einem Deprovisioning-Fehler, einem Tenant-Mix-up oder einem Privilege-Review, der Accounts aufdeckt, die nie wirklich entfernt wurden. Dann ist der Schaden bereits entstanden.

Die SCIM-Tax ist real: Entweder zahlt man für Enterprise-Upgrades, um Automatisierung zu bekommen, die man eigentlich schon bezahlt hat - oder man akzeptiert Coverage-Lücken und nennt sie "Ausnahmen". Beides ist keine Governance-Strategie.

Wie Iden die Governance-Schicht schließt

Iden ist keine Fabric im Sinne eines Orchestrierungs-Overlays. Iden ist die IGA-Schicht, die eine Identity Fabric erst vollständig macht.

Der Unterschied ist praktisch:

• Universelle Konnektivität: Iden verbindet sich mit jeder App im Stack - ob SCIM, API oder keines von beidem. Kein Enterprise-Upgrade erforderlich, um Automatisierung für kritische Tools zu bekommen.
• Feingranulare Kontrolle: Tiefer als Gruppen und Rollen. Bis auf Channel-, Repository- und Projektebene - die Ebene, auf der reale Zugriffsrisiken entstehen.
• Human + Non-Human in einer Policy-Engine: Service Accounts, OAuth Tokens, AI-Agenten und menschliche Nutzer werden in denselben Policy-Workflows verwaltet. Kein separates Silo für Machine Identities.
• Policy-driven Lifecycle-Automatisierung: Onboarding, Änderungen, Offboarding - vollständig automatisiert, ohne Ticket-Queues und ohne manuelle Ausnahmen.
• Fast Time-to-Value: Live in ~24 Stunden, nicht in Monaten. Für lean IT-Teams, die nicht auf "Phase 2" warten können.

Eine einheitliche Identity Security Fabric liefert die grundlegenden Nachweise, die für traditionelle und neue regulatorische Frameworks erforderlich sind. Zentralisiertes Policy-Management und konsistentes Logging vereinfachen Audits für Frameworks wie NIST, ISO 27001, SOC 2 und GDPR. Das funktioniert aber nur, wenn die Governance-Schicht tatsächlich alle Apps abdeckt - nicht nur die SCIM-freundlichen.

Das Takeaway

Identity Fabric ist ein legitimes Architekturkonzept. Es beschreibt das Ziel: eine einheitliche, orchestrierte Identity-Infrastruktur, die konsistente Policy-Durchsetzung über alle Systeme, Umgebungen und Identitätstypen ermöglicht.

Aber eine Fabric ohne vollständige Governance-Schicht ist Infrastruktur ohne Kontrolle. Und eine Governance-Schicht, die bei SCIM endet, ist 2026 keine vollständige Governance-Schicht mehr - nicht in einem Stack, in dem Non-Human Identities menschliche Nutzer um das 45- bis 109-fache übersteigen.

Die Frage für Security-Architekten ist nicht: "Haben wir eine Identity Fabric?" Die Frage ist: "Deckt unsere Governance-Schicht wirklich alles ab - oder haben wir nur die sichtbaren Teile gut verdrahtet?"