Live-Sessions. Echte Konfigurationen. Praxiswissen für IAM & GRC. Jetzt anmelden für NEXIS Hacks | Live & On Demand | Online

IAM

Governance für das Identity-Patchwork: Was IVIP leisten muss

3 Nov. 2026
Dr. Heiko Klarl
Dr. Heiko Klarl CEO, Nexis

Gartners Hype Cycle for Digital Identity 2025 hat erstmals eine Kategorie benannt. Identity Visibility and Intelligence Platforms, kurz IVIP, werden seither in der Identity-Community diskutiert – und die Debatte ging schnell über das Akronym hinaus zur Frage, ob es sich um eine echte Produktklasse handelt oder nur um ein Label für Arbeit, die Anbieter seit Jahren unter anderen Namen leisten.

Dasselbe Dokument definiert die Kategorie als Produkte, die eine schnelle Integration und Sichtbarkeit für IAM-relevante Daten liefern, meist kombiniert mit fortgeschrittener, häufig AI-gestützter Analytik. Ziel eines solchen Produkts ist eine einheitliche Sicht auf IAM-Daten, Ereignisse, Beziehungen, Konfiguration und Sicherheitslage – und aus dieser Sicht lassen sich die übrigen IAM-Kontrollen verbessern, ohne für jede einzelne eine separate Datensammlung durchführen zu müssen.

Fragmentierte Stacks verschleiern, wo Identitätsrisiken tatsächlich liegen

Identity- und Access-Management-Stacks sind so gewachsen, dass man sie kaum noch vollständig überblicken kann. Ein CISO in einem großen Unternehmen betreibt im Schnitt rund 83 separate Cybersecurity-Tools – eine Zahl aus Capturing the cybersecurity dividend, einer Studie des IBM Institute for Business Value mit Palo Alto Networks. Nur wenige dieser Tools sind in einem sinnvollen Sinne integriert. Die Folge ist eine fragmentierte Sicht auf Identitätsdaten – und schlimmer noch: keine verlässliche Intelligence darüber, welche Systeme tatsächlich abgedeckt sind und wo das verbleibende Risiko liegt.

Betrachten Sie Identity Governance and Administration neben Privileged Access Management. Beides sind reife Disziplinen mit zwei Jahrzehnten Tooling. Dennoch können sehr viele Unternehmen die Frage, die ein Auditor zuerst stellt, noch immer nicht beantworten: Wer darf was tun? Rollennamen und technische Berechtigungen sagen einem Fachanwender selten etwas Nützliches – dadurch werden Zugriffszuweisungen und Rezertifizierungskampagnen zu Abnickübungen. Privilegierte Konten verschärfen das Problem. Regulierte Unternehmen müssen segregation of duties nachweisen, und in der Praxis laufen IGA und PAM oft nebeneinander her, ohne echte Integration: Das eine deckt die Belegschaft ab, das andere die Administratoren. Konflikte, die beide Welten betreffen, bleiben unsichtbar.

Ein Beispiel aus dem HR-Bereich zeigt, wie sich das auswirkt. Ein System verwaltet Business-Rollen, ein anderes administrative Konten. Auf dem Papier hält die Trennung. Ohne eine durchgängige Sicht bleiben Überschneidungen verborgen – und ein Nutzer kann in einem System eine HR-Administratorrolle haben, während er im anderen widersprüchliche HR-Business-Berechtigungen trägt. Technisch bleiben die Systeme getrennt, während dieselbe Person am Ende sowohl Regeln für sensible Daten definieren als auch diese manipulieren kann. Erst eine Ende-zu-Ende-Integration bringt eine solche Verletzung ans Licht.

Jede Identity-Fabric im Betrieb ist aus überlappenden Produkten zusammengesetzt

Das Identity-Fabric-Modell beantwortet eine andere Frage als ein Produktkatalog. Statt Tools zu benennen, beschreibt es, welche Fähigkeiten eine moderne IAM-Umgebung bereitstellen muss – und ist damit als Zielbild für eine bereits laufende Umgebung nutzbar. Kaum ein Unternehmen startet bei null; der praktische Wert des Modells liegt daher darin, das bereits Laufende gegen die definierten Fähigkeiten zu mappen. Jede Fähigkeit in diesem Modell muss dann durch einen konkreten Service oder ein Produkt geliefert werden – und hier trifft das Modell auf die Realität der Beschaffung. Produkte überlappen sich oder lassen Lücken, und sie schneiden selten entlang derselben Linien, die das Modell zieht. So entsteht in Unternehmen ein Patchwork, das zusammengenäht wird, um das Zielbild näherungsweise zu erreichen.

IVIP adressiert genau diese Lücke. Das Konzept beschreibt eine Schicht, die sich über jede Art von Identität und jeden Typ von IAM spannt und eine Governance-Sicht auf das Ganze erzeugt. Reine Erkenntnis wäre zu wenig. Optimierung und Remediation verändern Ergebnisse – ob das bedeutet, Berechtigungsstrukturen zu bereinigen oder einem Fachanwender eine Empfehlung zu geben, die er umsetzen kann. Die weiteste Ausprägung ist Identity Security Posture Management, bei dem das System Abweichungen von einer erlernten Baseline selbstständig korrigiert.

Einige Analysten argumentieren, dass eine Visibility-Schicht kein Ersatz dafür ist, eine Identity-Fabric sauber zu entwerfen und umzusetzen. Damit haben sie recht. Sie bleibt jedoch ein pragmatischer Weg, die Distanz zwischen einer realen Implementierung und dem Ideal zu schließen. Andere fragen, ob die Kategorie das heutige Fragmentierungsproblem eher zementiert als löst. Fragmentierung war allerdings schon immer ein Merkmal von Enterprise-IT. Die Komplexität ist seit zwanzig Jahren stetig gewachsen, und Technologie kommt schneller, als Enterprise-Produkte sie aufnehmen können – agentic AI ist das jüngste Beispiel. Das Patchwork ist die Ausgangslage für jedes realistische Governance-Design, und nichts deutet darauf hin, dass in absehbarer Zeit eine perfekt integrierte Fabric aus einzelnen Standardprodukten zusammengesetzt wird. Diskussionswürdig ist, wie man sie so steuert, dass sich Security- und Business-Ergebnisse verbessern.

Das Plattform-Label hängt vom jeweiligen Produkt ab

Ist IVIP also eine Plattform? Das hängt vom Produkt ab, das Sie vor sich haben. Im Kern ist die Kategorie eine Summe von Fähigkeiten, die sich mit unterschiedlichen Tools auf verschiedene Weise realisieren lassen. Deckt ein Produkt genügend Bereiche ab, ist das Plattform-Label durchaus gerechtfertigt; und wenn mehrere es gemeinsam abdecken, kann das Ergebnis dasselbe sein. Das Label ist der am wenigsten interessante Teil der Diskussion.

Was eine Governance-Schicht leisten muss

Wenn die Kategorie über Fähigkeiten statt über Packaging definiert ist, lohnt es sich, diese Fähigkeiten zu benennen. Berechtigungen gehören auf jeder Ebene in den Scope – von Policies und Rollen bis hin zu einzelnen Entitlements – und über Systemgrenzen hinweg. Das umfasst IGA-Umgebungen ebenso wie die Systeme für privilegierten Zugriff und nicht-menschliche Identitäten, die danebenstehen. Posture Management, das in Access-Management-Produkte hineinreicht, macht Least Privilege praktisch, weil ungenutzte Berechtigungen identifiziert und entzogen werden können, statt sich über Jahre unbemerkt anzusammeln.

Analytische Fähigkeiten sind die zweite Hälfte. Machine Learning, trainiert auf Feedback der Personen, die Zugriffe tatsächlich genehmigen, kann bessere Policy- und Rollenmodelle simulieren und entwerfen – und eine visuelle Darstellung komplexer Berechtigungsstrukturen sagt einem Reviewer mehr als ein weiterer Export aus Excel-Tabellen. Nachvollziehbares Reasoning ist genauso wichtig wie die Empfehlung selbst. Ein Fachanwender, der versteht, warum Zugriff gewährt oder verweigert werden sollte, entscheidet beim nächsten Mal besser – und ein Auditor wird die Begründung ohnehin einfordern. Regulierung macht den Punkt konkret. Artikel 9(4)(c) des Digital Operational Resilience Act, Verordnung (EU) 2022/2554, verpflichtet Finanzunternehmen, „implement policies that limit the physical or logical access to information assets and ICT assets to what is required for legitimate and approved functions and activities only“ umzusetzen. Nachzuweisen, dass eine solche Richtlinie eingehalten wird, bedeutet, für jedes System unter IAM-Verwaltung – einschließlich Service Accounts – ein Berechtigungskonzept vorzulegen, was eine entsprechend weitreichende Transparenz voraussetzt. Dokumentation, die aus einer Live-Sicht auf Berechtigungen zusammengestellt wird, kann an dem Tag erstellt werden, an dem eine Aufsicht danach fragt, statt einmal jährlich für die Akte rekonstruiert zu werden.

Die Lücke, die hier geschlossen wird, ist eine sehr konkrete. Ein Unternehmen, das die Berechtigungskonflikte über seine IGA- und PAM-Systeme hinweg auflisten und diese Liste kurzfristig belegen kann, gewinnt etwas, das sein bisheriger Stack nicht liefern konnte. Ob dieser Gewinn sich in Governance-Entscheidungen niederschlägt, hängt davon ab, ob außerhalb des IAM-Teams jemand auf das reagiert, was die Schicht sichtbar macht – und das ist keine Beschaffungsfrage.

So sieht einheitliche Identity Visibility in der Praxis aus

Erfahren Sie, wie die NEXIS Plattform Identitätsdaten über IGA, PAM und andere IAM-Systeme hinweg verbindet, um verborgene Zugriffsrisiken aufzudecken, Governance zu stärken und fragmentierte Informationen in umsetzbare Intelligence zu verwandeln.

Demo anfordern