Nevis: Warum zentrale IAM-Teams an Grenzen stossen
Zürich – Identity and Access Management wurde lange so organisiert, als ginge es im Kern um eine überschaubare Zahl interner Mitarbeitender: Eintritt, Rollenwechsel, Austritt, dazu einige Standardanwendungen und klar definierte Freigabewege. Dieses Modell trägt in vielen Organisationen nicht mehr. Identitäten umfassen heute nicht nur Beschäftigte, sondern auch Kunden, Partner, externe Dienstleister, temporäre Projektrollen, technische Konten, APIs, Workloads und zunehmend auch AI Agents mit eigenständigen Zugriffsrechten. Damit steigt nicht nur die Anzahl der Identitäten, sondern auch die Vielfalt der Verantwortlichkeiten, Lebenszyklen und Risiken.
Genau an diesem Punkt stossen zentrale IAM-Teams an strukturelle Grenzen. Das Problem ist selten fehlende Kompetenz. Im Gegenteil: Zentrale Teams verfügen meist über die höchste Fachlichkeit in Governance, Rezertifizierung, Rollenmodellen und technischen Integrationen. Die Engstelle entsteht, weil ein kleines Spezialistenteam operativ Entscheidungen treffen oder umsetzen soll, die fachlich in verteilten Bereichen entstehen. Wer darf in einer Region auf ein Vertriebssystem zugreifen? Welche Partner dürfen auf ein gemeinsames Portal zugreifen? Wann endet der Zugang eines externen Prüfers? Ob ein AI Agent nur lesen oder auch schreiben darf, ist keine rein technische Frage, sondern eine fachliche.
In der Praxis führt die Zentralisierung dann zu drei wiederkehrenden Mustern. Erstens entstehen Wartezeiten. Wenn jede Rechtevergabe, jede Gruppenpflege und jede Ausnahme über ein zentrales Team läuft, wachsen Backlogs. Schon bei moderatem Volumen führt das zu Verzögerungen bei Onboarding, Projektstarts oder Partneranbindungen. Zweitens sinkt die Präzision von Entscheidungen. Ein zentrales Team kann Regeln umsetzen, kennt aber häufig nicht den Geschäftskontext im Detail. Das erhöht das Risiko von Überberechtigungen oder unnötigen Sperren. Drittens verwischt Verantwortung. Fachbereiche erwarten operative Unterstützung, das IAM-Team trägt die technische Last, und im Audit ist unklar, wer eine konkrete Berechtigung tatsächlich veranlasst oder fachlich verantwortet hat.
Dynamik moderner Identitätslandschaften
Diese Entwicklung wird durch die Dynamik moderner Identitätslandschaften weiter verschärft. In B2B- und B2C-Szenarien ändern sich Populationen oft täglich. Externe Nutzer werden in grosser Zahl eingeladen, Berechtigungen sind an Verträge, Regionen, Mandanten oder Produkte gebunden, und technische Identitäten entstehen automatisiert in DevOps- und Cloud-Prozessen. Studien und Marktbeobachtungen der letzten Jahre zeigen, dass maschinelle Identitäten in vielen Umgebungen bereits die Zahl menschlicher Identitäten übersteigen oder ihr Wachstum deutlich schneller verläuft [year]. Ein rein zentrales Betriebsmodell skaliert unter diesen Bedingungen nicht zuverlässig.
Hinzu kommt ein regulatorischer Druck, der das Dilemma sichtbar macht. Anforderungen aus ISO 27001, NIS2, DORA oder branchenspezifischen Auflagen verlangen nachvollziehbare Verantwortlichkeiten, zeitnahe Entzüge von Zugriffsrechten und prüfbare Genehmigungswege. Ein zentrales Team kann diese Anforderungen nicht allein erfüllen, wenn die fachliche Wahrheit über Rollen, Ausnahmen und Gültigkeiten dezentral in Regionen, Produktlinien oder Partnerorganisationen liegt. Sicherheit scheitert dann nicht an fehlenden Kontrollen, sondern an einem Betriebsmodell, das Entscheidungen von ihrem Kontext trennt.
Deshalb ist Delegated Administration im IAM kein Komfort-Feature für grosse Installationen, sondern ein Steuerungsmodell. Es beantwortet eine grundlegende Organisationsfrage: Wie werden Zugriffsentscheidungen so verteilt, dass sie dort getroffen und ausgeführt werden können, wo der Kontext vorhanden ist, ohne Governance, Nachvollziehbarkeit und Sicherheitsstandards aufzugeben? Die Alternative ist nicht „zentral sicher“ versus „dezentral flexibel“, sondern meist ein informelles Schattenmodell: Fachbereiche umgehen Engpässe mit gemeinsamen Konten, manuellen Listen, E-Mail-Freigaben oder lokalen Admin-Strukturen ausserhalb der zentralen Sicht.
Ein belastbares Modell muss daher fünf Ziele gleichzeitig erfüllen:
- operative Skalierung bei wachsender Zahl und Vielfalt von Identitäten
- klare fachliche Verantwortung für Rechtevergabe und Lebenszyklus
- zentrale Leitplanken für Compliance, Auditierbarkeit und Risikobegrenzung
- kurze Durchlaufzeiten für Standardfälle ohne Verlust an Kontrolle
- konsistente Umsetzung über Mitarbeitende, Externe, Maschinen und AI Agents hinweg
Das ist die eigentliche Ausgangslage dieses Whitepapers. Nicht die Frage, ob ein zentrales IAM-Team wichtig ist, sondern warum es allein nicht ausreicht. Seine Rolle verschiebt sich: weg vom Flaschenhals für jede Einzelentscheidung, hin zum Gestalter von Regeln, Rollen, Kontrollmechanismen und Plattformstandards. Fachnahe Einheiten übernehmen innerhalb dieser Leitplanken klar definierte administrative Aufgaben. Erst dadurch lassen sich Wachstum, Sicherheit und Verantwortlichkeit miteinander vereinbaren. (Nevis/mc/hfu)
Lesen Sie hier weiter, was Delegated Administration im IAM genau bedeutet.
