Warum zentrale IAM-Teams an Grenzen stossen

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.

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 drei 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.

Im nächsten Kapitel klären wir daher präzise, was Delegated Administration im IAM genau bedeutet.

Was Delegated Administration im IAM genau bedeutet

Delegated Administration im Identity and Access Management (IAM) bezeichnet die gezielte Übertragung klar begrenzter Verwaltungsrechte von einer zentralen IAM-Funktion an ausgewählte, vertrauenswürdige Personen oder Teams ausserhalb dieser Zentrale. Entscheidend ist dabei nicht die blosse Vergabe zusätzlicher Berechtigungen, sondern ein kontrolliertes Betriebsmodell: Wer darf was tun, für wen, in welchem System, in welchem Zeitraum und unter welchen Prüf- und Freigaberegeln? Genau diese Begrenzung unterscheidet Delegation von einer vollständigen Übergabe administrativer Hoheit.

In einem zentralisierten IAM-Modell verwaltet typischerweise ein zentrales Team Benutzerkonten, Rollen, Gruppen, Zugriffe und Richtlinien für die gesamte Organisation. Das ist konsistent, aber oft langsam. Fachbereiche, regionale IT-Teams oder lokale Support-Einheiten kennen hingegen den operativen Bedarf meist besser und können Änderungen schneller beurteilen. Delegated Administration verbindet beide Seiten: Die zentrale Stelle definiert die Regeln, das Zielbild und die Sicherheitsgrenzen; delegierte Administratoren führen innerhalb dieser Grenzen konkrete Verwaltungsaufgaben aus.

Der Kernbegriff ist also nicht „Administration durch viele“, sondern „Administration durch viele innerhalb eines zentral gesteuerten Rahmens“. Dieser Rahmen besteht in der Regel aus Rollen, Scopes, Richtlinien und Kontrollmechanismen. Ein regionales HR-Team darf etwa Konten für Mitarbeitende seiner Landesgesellschaft anlegen und Stammdaten pflegen, aber keine globalen Rollen definieren. Ein Applikationsverantwortlicher darf Benutzer einer bestimmten Anwendung Gruppen zuweisen, jedoch keine unternehmensweiten Zugriffsmodelle ändern. Ein Helpdesk darf Passwörter zurücksetzen, aber keine privilegierten Konten verwalten.

Die wichtigsten Bausteine von Delegated Administration sind:

• Zentrale Administratoren: Verantwortlich für das IAM-Zielmodell, globale Policies, Rollenarchitektur, Governance und Eskalation.
• Delegierte Administratoren: Übernehmen operative Aufgaben in einem klar begrenzten Verantwortungsbereich.
• Rollen: Definieren, welche administrativen Aktionen erlaubt sind, etwa Benutzer anlegen, Attribute ändern oder Mitgliedschaften verwalten.
• Ressourcen und Scope: Begrenzen, auf welche Personen, Gruppen, Anwendungen, Organisationseinheiten oder Regionen sich die Rechte beziehen.
• Zuständigkeiten: Legen fest, wer für welche Datenqualität, Freigaben, Nachweise und Korrekturen verantwortlich ist.
• Guardrails: Technische und organisatorische Leitplanken wie Genehmigungsworkflows, Vier-Augen-Prinzip, Protokollierung und Rezertifizierung.

Wichtig ist auch die Abgrenzung zu benachbarten Konzepten. Delegated Administration ist nicht gleichbedeutend mit einfachem Rollenmanagement. Rollenmanagement beschreibt primär die Struktur von Zugriffs- oder Administrationsrollen. Delegated Administration beschreibt dagegen das operative Steuerungsmodell, in dem solche Rollen kontrolliert an dezentrale Akteure vergeben und überwacht werden. Ebenso ist Delegation keine vollständige Dezentralisierung. Wenn ein Fachbereich eigenständig Rollen entwerfen, Policies ändern und Audit-Anforderungen definieren könnte, wäre das keine Delegation mehr, sondern weitgehend autonome Administration.

In der Praxis zeigt sich der Unterschied besonders deutlich bei privilegierten Aufgaben. Ein delegierter Administrator kann etwa Benutzerkonten für die Vertriebsorganisation seiner Region pflegen, jedoch keine globalen Authentifizierungsrichtlinien anpassen oder Admin-Rechte an andere Delegierte weitergeben. Solche Verbote sind kein Detail, sondern der eigentliche Sicherheitskern des Modells. Ohne sie würde aus kontrollierter Delegation schrittweise unüberschaubare Berechtigungsvergabe.

Typische Einsatzszenarien sind Unternehmen mit vielen Standorten, mehreren Geschäftsbereichen oder stark variierenden regulatorischen Anforderungen. Ein Konzern kann beispielsweise lokale IT-Teams in [year] dazu ermächtigen, Joiner-Mover-Leaver-Prozesse für ihre Gesellschaft selbst auszuführen, während die Zentrale die Rollenlogik, Segregation-of-Duties-Regeln und revisionssichere Nachvollziehbarkeit vorgibt. In einer Hochschule kann die zentrale IT Fakultäten das Management ihrer Gastkonten delegieren, ohne ihnen Zugriff auf die Identitäten aller Studierenden und Mitarbeitenden zu geben. In beiden Fällen steigt die Reaktionsgeschwindigkeit, ohne dass die zentrale Steuerung aufgegeben wird.

Gut umgesetzt ist Delegated Administration daher ein Modell der begrenzten Entscheidungs- und Handlungskompetenz: lokal dort, wo Fachnähe zählt, zentral dort, wo Konsistenz, Risiko und Compliance es verlangen.

Wie Delegation in der Praxis funktioniert

In der Praxis bewährt sich Delegated Administration vor allem dort, wo Identitäten nah am operativen Geschäft entstehen und sich häufig ändern. Typische Beispiele sind Händler- und Partnernetzwerke, Filialorganisationen, Landesgesellschaften, Franchise-Modelle, Krankenhäuser mit dezentralen Standorten, Hochschulen mit Fakultäten oder Unternehmensgruppen mit rechtlich getrennten Einheiten. In all diesen Fällen kennt die lokale Organisation ihre Nutzer, deren Aufgaben und den Zeitpunkt von Eintritt, Wechsel oder Austritt deutlich besser als eine zentrale IAM-Stelle.

Ein naheliegender Anwendungsfall ist das Onboarding externer Partner. Ein Hersteller kann etwa jedem Distributionspartner einen lokalen Administrator zuweisen, der neue Benutzer für das Partnerportal selbst anlegt, Kontaktinformationen pflegt und den Zugriff auf vertriebsbezogene Anwendungen vergibt. Ähnlich funktioniert es bei Filialen: Die Filialleitung oder ein benannter Standortadministrator verwaltet Aushilfen, befristete Kräfte oder Dienstleister direkt vor Ort. In Landesgesellschaften kommt hinzu, dass lokale Teams sprachliche, rechtliche und organisatorische Besonderheiten kennen, etwa Namenskonventionen, Zuständigkeiten oder nationale Berichtswege.

Delegation bedeutet dabei nicht, dass jede Einheit „ihr eigenes IAM“ betreibt. Wirksam ist das Modell nur, wenn Aufgaben sauber getrennt werden. In vielen Organisationen lassen sich folgende Tätigkeiten sinnvoll delegieren:

• Benutzeranlage innerhalb eines klar abgegrenzten Geltungsbereichs, etwa nur für eine Filiale, ein Partnerkonto oder eine Landesgesellschaft
• Pflege nichtkritischer Attribute wie Telefonnummer, Kostenstelle, organisatorische Zuordnung oder lokale Ansprechpartner
• Zuweisung vordefinierter Rollen oder Berechtigungspakete innerhalb eines begrenzten Katalogs
• Lebenszyklusaktionen wie Sperren, Reaktivieren oder Austritt melden, sofern dafür feste Regeln gelten
• Pflege von Gruppenmitgliedschaften für lokale Arbeitsgruppen, Projekte oder regionale Verteiler

Gerade die Rollenvergabe ist ein gutes Beispiel für die richtige Balance. Lokal kann entschieden werden, ob eine Person die Rolle „Filialverkauf“, „Partner Support“ oder „Landesgesellschaft Finance Read“ erhält, wenn diese Rollen zentral definiert, dokumentiert und genehmigt sind. Nicht delegiert werden sollte dagegen die Erstellung neuer privilegierter Rollen oder die Vergabe weitreichender administrativer Rechte. Sonst entstehen schleichend Berechtigungsmodelle, die weder vergleichbar noch prüfbar sind.

Ein zweiter zentraler Praxispunkt ist die Begrenzung des Verwaltungsraums. Ein lokaler Administrator darf nur die Benutzer sehen und ändern, die seiner Organisationseinheit zugeordnet sind. Das ist technisch meist über Scoping-Regeln abgebildet: nach Mandant, Region, Partner-ID, Kostenstelle oder organisatorischem Baum. Ein Administrator einer Filiale in München darf dann keine Benutzer einer Filiale in Hamburg bearbeiten; ein Partner darf ausschliesslich die Identitäten seines eigenen Unternehmens verwalten. Diese Begrenzung reduziert Fehlbedienungen und ist für Audits essenziell.

Ebenso wichtig ist die Frage, was zwingend zentral bleiben muss. Dazu zählen in der Regel die Identitätsrichtlinien, das Rollenmodell, Passwort- und Authentifizierungsstandards, Rezertifizierungsprozesse, Segregation-of-Duties-Regeln, die Definition kritischer Attribute sowie alle Kontrollen für privilegierte Zugriffe. Auch die Protokollierung bleibt zentral: Wer hat wann welchen Benutzer angelegt, welche Rolle vergeben oder welchen Account deaktiviert? Ohne lückenlose Nachvollziehbarkeit wird Delegation schnell zum Blindflug.

In reifen Modellen wird Delegation deshalb durch Workflows abgesichert. Ein lokaler Administrator kann etwa einen neuen Benutzer anlegen, doch die Freischaltung für eine sensible Anwendung erfolgt erst nach zentraler oder fachlicher Genehmigung. Oder eine Landesgesellschaft darf Rollen zuweisen, aber nur aus einem freigegebenen Set; jede Abweichung löst einen Review aus. Dieses Prinzip ist aus dem Access-Governance-Umfeld bekannt: operative Geschwindigkeit lokal, Kontrollpunkte zentral.

Ein häufiger Fehler besteht darin, Delegation als blosse Entlastung des zentralen IAM-Teams zu betrachten. Der eigentliche Nutzen liegt tiefer: Datenqualität steigt, weil Änderungen dort gepflegt werden, wo sie entstehen; Reaktionszeiten sinken, weil man nicht auf ein zentrales Ticket warten muss; und Verantwortlichkeiten werden sichtbar. In Programmen mit vielen externen Identitäten kann das einen messbaren Unterschied machen. Wenn ein Partnernetzwerk mit [customer]-Grösse mehrere hundert Benutzerwechsel pro Monat hat, reduziert lokale Pflege typischerweise die Durchlaufzeit von Tagen auf Stunden, vorausgesetzt, Rollen, Freigaben und Prüfpfade sind vorher sauber definiert.

Genau deshalb entscheidet nicht die Idee der Delegation über ihren Erfolg, sondern die Qualität des Modells — und damit sind wir bei der Frage, worauf Entscheider bei einem Delegationsmodell achten sollten.

Worauf Entscheider bei einem Delegationsmodell achten sollten

Ein tragfähiges Delegationsmodell im Identity and Access Management wird nicht daran gemessen, ob Aufgaben formal verteilt werden können, sondern daran, ob diese Verteilung kontrollierbar, nachvollziehbar und über Organisationsgrenzen hinweg konsistent bleibt. Für Entscheider ist Delegated Administration deshalb kein reines Betriebsdesign, sondern ein Governance-Thema: Wer darf was, in welchem Kontext, für welchen Zeitraum und mit welcher Nachweisfähigkeit?

Der erste Prüfpunkt ist die Feingranularität der Berechtigungen. Ein Modell, das nur zwischen „globalem Admin“ und „lokalem Admin“ unterscheidet, ist in komplexen Umgebungen meist zu grob. Praktikabel sind Rollenmodelle, die Aufgaben nach Funktion, Objektart und Aktion trennen: etwa Benutzer anlegen, Gruppenmitgliedschaften verwalten, Attributwerte ändern oder Zugriffe rezertifizieren. In regulierten Umgebungen ist zudem entscheidend, dass sensible Attribute — etwa Vertragsstatus, Kostenstelle, Funktionsträgerkennzeichen oder privilegierte Rollen — gesondert behandelt werden. Ein HR-Administrator in einer Landesgesellschaft sollte beispielsweise Stammdaten pflegen dürfen, aber keine Berechtigungen für produktive Kernsysteme vergeben können.

Eng damit verbunden ist die klare Scope-Abgrenzung. Delegation funktioniert nur dann sicher, wenn Zuständigkeiten technisch erzwungen werden, nicht nur organisatorisch beschrieben sind. Scopes können sich auf Organisationseinheiten, Regionen, Tochtergesellschaften, Applikationen, Identitätstypen oder Lebenszyklusphasen beziehen. In der Praxis bedeutet das: Ein Helpdesk-Team darf Passwort-Resets nur für interne Mitarbeitende einer bestimmten Business Unit ausführen, nicht aber für externe Partnerkonten oder privilegierte Administratoren. Je komplexer das Ökosystem, desto wichtiger ist ein konsistentes Scope-Modell über Verzeichnisdienste, Zielsysteme und Workflows hinweg. Sonst entstehen Schattenwege, in denen lokale Sonderrechte das zentrale Steuerungsmodell unterlaufen.

Der dritte Kernfaktor ist Auditierbarkeit. Delegation erhöht die Zahl der Akteure, damit auch die Zahl der risikorelevanten Aktionen. Deshalb müssen Entscheidungen und Änderungen lückenlos protokolliert werden: Wer hat welche Berechtigung vergeben, auf Basis welcher Genehmigung, mit welchem Gültigkeitszeitraum und in welchem Zielsystem? Gute Modelle unterstützen nachvollziehbare Ereignisketten statt isolierter Log-Einträge. Für interne Revision, Datenschutz und externe Prüfer ist nicht nur die Aktion selbst relevant, sondern der vollständige Entscheidungsweg. Frameworks wie ISO 27001, SOX-nahe Kontrollanforderungen oder BaFin-/DORA-bezogene Nachweispflichten erhöhen diesen Bedarf zusätzlich.

Ebenso wichtig sind belastbare Genehmigungsprozesse. Delegation darf keine Abkürzung an formalen Kontrollen vorbei schaffen. Entscheider sollten prüfen, ob das Modell mehrstufige Freigaben, Vier-Augen-Prinzip, risikobasierte Eskalationen und zeitliche Befristungen unterstützt. Besonders bei privilegierten Rollen oder Zugängen zu personenbezogenen Daten ist eine einfache Selbstfreigabe durch lokale Administratoren nicht ausreichend. In vielen Organisationen bewährt sich eine Kombination aus dauerhaften Zuständigkeiten und Just-in-Time-Freigaben für Ausnahmen. Das reduziert stehende Privilegien und verbessert die Kontrolltiefe.

Ein weiterer Prüfstein ist starke Authentisierung für delegierte Administratoren. Wer Identitäten verwalten darf, ist selbst ein hochkritischer Benutzerkreis. Multi-Faktor-Authentisierung, kontextbezogene Richtlinien, abgesicherte Administrationspfade und getrennte Administrationskonten sollten Mindeststandard sein. Ohne diese Massnahmen verlagert Delegation das Risiko lediglich vom zentralen IAM-Team auf eine grössere Gruppe operativer Akteure.

Oft unterschätzt wird die Benutzerführung für Administratoren. Schlechte UX ist kein Komfortproblem, sondern ein Kontrollproblem. Wenn Zuständigkeiten, Genehmigungsstatus oder Scope-Grenzen in der Oberfläche unklar bleiben, steigen Fehlbedienungen, Umgehungen und Supportaufwände. Gute Delegationsmodelle zeigen Verantwortlichen genau die Objekte und Aktionen, für die sie zuständig sind, und blenden alles andere aus. Das senkt Fehlerquoten und verkürzt Bearbeitungszeiten. In Projekten mit mehreren hundert lokalen Admins kann allein diese Klarheit den Unterschied zwischen skalierbarem Betrieb und dauerhaftem Ausnahmezustand ausmachen.

Für Entscheider lassen sich die wesentlichen Kriterien auf sechs Fragen verdichten:

• Sind Rechte und Aufgaben fein genug getrennt, um Überprivilegierung zu vermeiden?
• Lassen sich Scopes technisch sauber und dauerhaft durchsetzen?
• Ist jede Änderung vollständig auditierbar und prüfungssicher?
• Unterstützt das Modell risikoadäquate Genehmigungen und Befristungen?
• Sind delegierte Administratoren stark authentisiert und besonders geschützt?
• Kann das Modell hybride, föderierte und organisationsübergreifende Landschaften konsistent orchestrieren?

Gerade der letzte Punkt gewinnt an Gewicht. Kaum ein Unternehmen verwaltet heute nur ein zentrales Verzeichnis. Realität sind hybride Umgebungen aus Cloud-Diensten, SaaS-Anwendungen, Legacy-Systemen, externen Identitäten und regionalen Betriebsmodellen. Delegation muss in diesem Gefüge konsistent bleiben, sonst entstehen Governance-Lücken an den Übergängen zwischen Systemen und Verantwortungsbereichen.

Hinzu kommt der regulatorische Kontext. Datenhoheit, Aufenthaltsort von Administrationsdaten, Zugriffe aus Drittländern und europäische Souveränitätsanforderungen verändern die Bewertung deutlich. Sobald Delegation Auswirkungen auf personenbezogene Daten, grenzüberschreitende Betriebsmodelle oder die Kontrolle über kritische Identitätsinfrastrukturen hat, ist sie keine reine Effizienzfrage mehr. Sie berührt Compliance, Risikomanagement und unter Umständen die strategische Technologiewahl. Genau an dieser Stelle zeigt sich, dass ein Delegationsmodell nicht nur funktionieren, sondern auch gegenüber Aufsicht, Revision und Geschäftsleitung belastbar begründet werden muss.

Doch selbst wenn diese Kriterien erfüllt scheinen, scheitern viele Vorhaben an falschen Annahmen in der Umsetzung – und genau diese betrachten wir im nächsten Kapitel: Häufige Fehlannahmen und Risiken bei der Umsetzung.

Häufige Fehlannahmen und Risiken bei der Umsetzung

Delegated Administration in IAM wird in der Praxis oft nicht an der Idee selbst scheitern, sondern an falschen Annahmen über ihre Grenzen. Die häufigste Fehlannahme lautet: Delegation bedeute zwangsläufig Kontrollverlust. Tatsächlich ist das Gegenteil der Fall, wenn Zuständigkeiten formalisiert, technisch begrenzt und revisionsfähig umgesetzt werden. Kontrolle geht nicht dadurch verloren, dass operative Aufgaben näher an die Fachbereiche verlagert werden; sie geht verloren, wenn diese Aufgaben informell per E-Mail, Ticket oder Excel erfolgen, ohne klare Regeln, Genehmigungspfade und Protokollierung.

Ein zweites Missverständnis ist, dass sich Delegation allein über Rollenmodelle sauber abbilden lasse. Rollen sind wichtig, aber sie genügen selten. In komplexen Organisationen reicht „HR-Administrator“ oder „Standortmanager“ als Berechtigungslogik nicht aus, weil Zuständigkeiten fast immer an zusätzliche Bedingungen geknüpft sind: Region, Kostenstelle, Gesellschaft, Beschäftigungsart, Sensitivität der Anwendung oder Zeitfenster. Ein reines Rollenmodell führt dann schnell zu pauschalen Rechten, die mehr erlauben als fachlich notwendig. Policy-basierte Begrenzungen schliessen diese Lücke, indem sie nicht nur definieren, wer etwas tun darf, sondern auch unter welchen Bedingungen, für welche Zielgruppen und mit welchen Ausnahmen.

Typische Risiken entstehen an fünf wiederkehrenden Stellen:

• zu breit geschnittene Rechtepakete statt fein abgegrenzter Aufgaben
• unklare Verantwortlichkeiten zwischen IAM-Team, Fachbereich und Revision
• fehlende Nachvollziehbarkeit von Änderungen und Genehmigungen
• Medienbrüche zwischen IAM-System, Tickets, E-Mail und Verzeichnisdiensten
• schlechte Nutzererlebnisse, die Umgehungsprozesse fördern

Zu breite Rechte sind besonders kritisch. Wenn lokale Administratoren beispielsweise Benutzer anlegen, Attribute ändern und zusätzlich Rechte für sensible Anwendungen vergeben dürfen, entsteht eine riskante Bündelung. Das verletzt das Prinzip der Funktionstrennung und erhöht die Wahrscheinlichkeit von Fehlzuweisungen oder missbräuchlichen Änderungen. In Audits fällt dies oft erst auf, wenn ein Vorfall bereits eingetreten ist. Ein belastbares Modell trennt deshalb Identitätsverwaltung, fachliche Freigabe und technische Provisionierung. Ein Standortverantwortlicher darf dann etwa Stammdaten für Mitarbeitende seiner Organisationseinheit pflegen, aber keine privilegierten Zugänge vergeben oder Genehmigungen für eigene Anträge erteilen.

Ebenso problematisch sind unklare Verantwortlichkeiten. Delegation wird häufig eingeführt mit dem impliziten Satz: „Die Fachbereiche kümmern sich künftig selbst darum.“ Genau dort beginnen die Reibungen. Wer ist verantwortlich, wenn eine Berechtigung falsch vergeben wurde? Wer pflegt Organisationsstrukturen? Wer entscheidet über Ausnahmen? Ohne ein klares RACI-Modell bleiben Eskalationen im Tagesgeschäft hängen. In der Folge steigt die Bearbeitungszeit, und Anwender suchen Abkürzungen. Aus Sicht der Governance ist nicht entscheidend, dass jede Aufgabe zentral ausgeführt wird, sondern dass für jede Aufgabe eindeutig festgelegt ist, wer ausführt, wer genehmigt, wer kontrolliert und wer informiert wird.

Ein weiterer Fallstrick ist mangelnde Nachvollziehbarkeit. Delegation ist nur dann belastbar, wenn jede Änderung mit Verantwortlichem, Zeitpunkt, Begründung und betroffenem Objekt dokumentiert wird. Ein Ticketverweis allein reicht oft nicht aus, wenn die technische Änderung nicht systemisch mit dem Genehmigungsvorgang verknüpft ist. Revisionssichere Protokolle, unveränderbare Audit-Trails und standardisierte Begründungsfelder sind hier keine Kür, sondern Voraussetzung. Gerade in regulierten Branchen lassen sich Nachweise für Zugriffsentscheidungen aus [year] nicht zuverlässig aus E-Mail-Postfächern rekonstruieren.

Medienbrüche verstärken diese Probleme. Ein häufiger Aufbau sieht so aus: Antrag im Portal, Klärung per Mail, Freigabe im Ticket, technische Umsetzung manuell im Zielsystem. Jeder Übergang erzeugt Interpretationsspielraum und Verzögerung. Zudem sinkt die Datenqualität, wenn identische Informationen mehrfach gepflegt werden. Delegation sollte deshalb als durchgängiger Prozess gedacht werden, nicht als zusätzliche Oberfläche vor manuellen Schritten. Wo dies kurzfristig nicht möglich ist, sollten zumindest die risikoreichsten Übergänge standardisiert und protokolliert werden.

Schliesslich wird die Bedeutung des Nutzererlebnisses oft unterschätzt. Wenn delegierte Administratoren komplexe Formulare, uneinheitliche Begriffe oder unverständliche Fehlermeldungen vorfinden, entstehen Fehlbedienungen. Schlechte Usability ist kein kosmetisches Problem, sondern ein Sicherheits- und Effizienzrisiko. Ein [customer]-Beispiel aus dem Handel zeigt typischerweise, dass Filialleitungen einfache Personalwechsel zuverlässig bearbeiten, solange Formulare auf wenige kontextspezifische Felder reduziert sind; sobald jedoch technische Systembegriffe und dutzende Auswahloptionen erscheinen, steigt die Fehlerquote deutlich.

Policy-basierte Begrenzung macht diese Risiken beherrschbar, weil sie Delegation auf den kleinsten sinnvollen Handlungsspielraum reduziert. Statt globaler Rechte werden Aktionen, Zielobjekte, Bedingungen und Ausnahmen explizit festgelegt. Kombiniert mit Genehmigungsregeln, SoD-Kontrollen, zeitlicher Begrenzung und vollständiger Protokollierung entsteht kein Kontrollverlust, sondern ein präziseres Steuerungsmodell als in vielen zentral organisierten, aber informell gelebten Prozessen.

Wie sich daraus ein umsetzbarer, schrittweiser Ansatz ableiten lässt, zeigt das nächste Kapitel: Der pragmatische Weg nach vorn.

Der pragmatische Weg nach vorn

Delegated Administration in IAM ist kein Ziel an sich, sondern ein Steuerungsmodell. Ihr Wert zeigt sich erst dann, wenn Zuständigkeiten, Risiken und Kontrollen sauber zueinander passen. Genau deshalb ist der nächste Schritt nicht die Auswahl einer Funktion im Tool, sondern die systematische Klärung der eigenen Ausgangslage. Wer zu früh über Rollenmodelle, Portale oder Freigabeworkflows spricht, ohne Identitätsdomänen und Delegationsgrenzen verstanden zu haben, baut Komplexität in das System ein, statt sie zu ordnen.

Ein belastbarer Startpunkt ist die Kartierung von vier Ebenen. Erstens: Identitätsdomänen. Welche Personengruppen, Kontenarten und Verzeichnisse gibt es tatsächlich — etwa Mitarbeitende, Externe, Partner, technische Konten, privilegierte Konten oder regionale Verzeichnisse? Zweitens: Delegationsgrenzen. Welche Entscheidungen können fachnah getroffen werden, und welche müssen zentral bleiben, etwa aus Compliance-, Sicherheits- oder Betriebsgründen? Drittens: Kontrollmechanismen. Wo sind Vier-Augen-Prinzip, Genehmigungspflichten, Rezertifizierungen, Logging und Notfallzugriffe zwingend? Viertens: besonders risikorelevante Prozesse. Dazu zählen in vielen Organisationen Joiner-Mover-Leaver-Prozesse, privilegierte Zugriffe, Berechtigungen für Finanz- oder Personaldaten, Änderungen an Rollenmodellen sowie die Anbindung externer Identitäten.

Diese Kartierung muss nicht monatelang dauern. In vielen Fällen reicht ein strukturierter Analysezyklus von vier bis sechs Wochen, wenn die relevanten Bereiche eingebunden sind: IAM-Verantwortung, Informationssicherheit, Betriebsorganisation, HR, Einkauf oder Partnermanagement sowie ausgewählte Fachbereiche. Ziel ist kein perfektes Architekturdiagramm, sondern ein belastbares Bild darüber, wo Delegation heute bereits informell stattfindet, wo sie kontrolliert werden sollte und wo sie ausdrücklich nicht stattfinden darf. Gerade diese informellen Muster werden oft unterschätzt: lokale Administratoren, manuelle Listenpflege, E-Mail-Freigaben oder Ausnahmeprozesse ausserhalb des IAM sind in der Praxis häufig die eigentlichen Schwachstellen.

Für die Bestandsaufnahme der heutigen Admin-Modelle hat sich ein einfacher Fragenrahmen bewährt:

• Wer darf heute was für wen ändern?
• Auf welcher Grundlage wird diese Berechtigung vergeben und entzogen?
• Welche Aufgaben sind dokumentiert, welche nur gelebte Praxis?
• Welche Kontrollen greifen vor, während und nach einer Änderung?
• Wo entstehen Medienbrüche, Verzögerungen oder Intransparenz?
• Welche Prozesse hätten bei Fehlbedienung oder Missbrauch den höchsten Schaden?

Aus den Antworten lassen sich Anforderungen für ein tragfähiges Zielbild ableiten. Ein skalierbares Modell trennt in der Regel klar zwischen Richtlinienhoheit und operativer Durchführung: zentral definierte Leitplanken, dezentral ausgeführte Standardaufgaben. Ein souveränes Modell macht Verantwortlichkeiten eindeutig, begrenzt Berechtigungen auf den notwendigen Umfang und erzwingt Nachvollziehbarkeit. Ein benutzerfreundliches Modell reduziert Reibung für Fachbereiche und Endnutzer, etwa durch klare Self-Service-Grenzen, verständliche Rollennamen und standardisierte Genehmigungspfade. Diese drei Qualitäten stehen nicht im Widerspruch zueinander, wenn das Design vom Risiko her gedacht wird. Niedrigrisiko-Aufgaben können näher an den Fachbereich verlagert werden; Hochrisiko-Entscheidungen bleiben zentral oder werden mit stärkeren Kontrollen versehen.

Hilfreich ist dabei die Einteilung in Delegationsstufen. Beispielhaft kann eine Organisation Aufgaben wie Gruppenmitgliedschaften für unkritische Anwendungen lokal delegieren, während die Vergabe privilegierter Rollen, Änderungen an SoD-kritischen Berechtigungen oder die Freischaltung technischer Konten zentral verantwortet werden. Ebenso kann nach Objektarten, Regionen oder Mandanten unterschieden werden. Entscheidend ist nicht die Eleganz des Modells auf dem Papier, sondern ob es mit realen Betriebsprozessen, Verantwortlichkeiten und Prüfanforderungen zusammenpasst.

Der pragmatische Weg nach vorn ist daher kein Grossprojekt mit ungewissem Ausgang, sondern ein nüchterner Ordnungsprozess: Risiken sichtbar machen, Zuständigkeiten sauber zuschneiden, Kontrollen dort verdichten, wo sie nötig sind, und nur das delegieren, was fachlich sinnvoll und auditierbar bleibt. So wird Delegated Administration von einer technischen Option zu einem belastbaren Führungsinstrument für komplexe Identitäten.

Der konkrete nächste Schritt für Sie: Starten Sie in den kommenden 30 Tagen eine strukturierte Bestandsaufnahme Ihrer heutigen Administrationsmodelle entlang von Identitätsdomänen, Delegationsgrenzen, Kontrollmechanismen und risikorelevanten Prozessen.