Für Microsoft Identity Manager 2016 endete der erweiterte Support nicht im Januar 2026. Microsoft hat das Datum im Lebenszyklus verschoben. Der erweiterte Support endet jetzt am 9. Januar 2029. Damit erhalten Organisationen, die MIM betreiben, mehr Zeit im unterstützten Betrieb. Aus MIM wird dadurch aber keine moderne strategische Plattform für Identity Governance. Die Verlängerung beseitigt auch nicht die alternden Abhängigkeiten von MIM und liefert kein Nachfolge-Release für ein direktes Upgrade.

Richtig gelesen heißt das: Die Verlängerung schafft ein Planungsfenster. Diese Zeit sollten Sie nutzen, um den aktuellen Betrieb zu stabilisieren, nicht unterstützte Komponenten zu entfernen, die Identitätsprozesse zu dokumentieren, die MIM tatsächlich ausführt, und jede Zuständigkeit gezielt in ein Zielsystem zu überführen. Wer 2029 als Erlaubnis versteht, die Entscheidung aufzuschieben, presst Bestandsaufnahme, Beschaffung, Migration, Parallelbetrieb und Stilllegung nur in einen kürzeren und riskanteren Zeitraum.

Dieser Leitfaden erläutert den aktuellen Supportstand, die zusätzliche Bedingung für Kunden mit Microsoft Entra ID P1 und P2, die technischen Arbeiten, die innerhalb von MIM weiterhin nötig sind, und einen praktischen Weg von einer übernommenen MIM-Landschaft zu einer gesteuerten künftigen Architektur.

Entscheidungsvorlage: Sorgen Sie dafür, dass MIM unterstützt und stabil bleibt, während Sie einen belegbaren Plan für die Ablösung oder Reduzierung aufbauen. Versprechen Sie kein „MIM-Upgrade“, solange Sie nicht benennen können, welche Zieldienste übernehmen, für welche Kontrollen sie zuständig sein werden und mit welcher Methode Sie nachweisen, dass sich die Zugriffsrechte korrekt geändert haben.

Was genau hat sich geändert?

Die Lebenszyklusseite von Microsoft für Microsoft Identity Manager 2016 zeigt jetzt einen festen Lebenszyklus (Fixed Lifecycle). Der Mainstream-Support endete bereits am 12. Januar 2021, der erweiterte Support endet am 9. Januar 2029. Microsoft gibt außerdem in der MIM-Produktdokumentation an, dass das bisherige Enddatum, der 13. Januar 2026, auf den 9. Januar 2029 verlängert wurde.

Ein zweiter Punkt wird oft zu stark vereinfacht. Microsoft veröffentlicht ein Support-Update für Kunden mit Microsoft Entra ID P1 oder P2. Für diese Kunden ist Standardsupport über das Azure-Portal für bestimmte Komponenten von MIM 2016 verfügbar. Voraussetzung ist eine Bereitstellung mit MIM 2016 Service Pack 3 oder einem späteren Hotfix oder Update. Zum aufgeführten Umfang gehören der Synchronization Service, der Password Change Notification Service, Konnektoren, MIM Service and Portal, Add-ins und Erweiterungen sowie zugehörige Supportskripte und Sprachpakete.

Das bedeutet nicht, dass jede MIM-Installation ohne P1 oder P2 sofort ohne Support ist. Die Seite von Microsoft beschreibt auch andere Wege im Rahmen des festen Lebenszyklus und des Professional Support. Lizenzierung, Version der Bereitstellung, Komponentenumfang und Supportweg müssen deshalb für den tatsächlichen Vertrag und Build der Organisation geprüft werden. Eine belastbare Programmdokumentation sollte den Lebenszyklusnachweis von Microsoft, die Lizenzsituation des Tenants, den bereitgestellten MIM-Build und die Bestätigung des Wegs enthalten, über den Vorfälle gemeldet werden.

FrageBelegte AntwortErforderliche Maßnahme
Wird MIM 2016 nach Januar 2026 unterstützt?Das veröffentlichte Enddatum des erweiterten Supports ist der 9. Januar 2029.Das Datum im Register für Technologierisiken und im Programmplan erfassen.
Spielt Entra ID P1 oder P2 eine Rolle?Ja. Microsoft dokumentiert für P1/P2-Kunden einen Standardsupportweg über das Azure-Portal für bestimmte Komponenten von MIM 2016 ab SP3.Lizenzen, Build-Stand und abgedeckte Komponenten prüfen; die Nachweise aufbewahren.
Ist SP3 für eine langfristig betriebene Bereitstellung optional?SP3 ist die aktuelle Basis, die Microsoft für den P1/P2-Supportweg nennt, und aktuelle Updates erscheinen auf der SP3-Linie.Den Wechsel auf einen aktuellen unterstützten Build planen und testen, wenn die Landschaft älter ist.
Bringt 2029 eine Nachfolgeversion?Die Lebenszyklusverlängerung nennt weder ein Nachfolge-Release noch einen Weg zur Modernisierung per direktem Upgrade.Zielarchitektur, Migration und Stilllegung als eigene Arbeitspakete finanzieren.
Kann die Organisation bis 2028 warten?Technisch läuft MIM möglicherweise weiter, aber die verbleibende Zeit muss auch Bestandsaufnahme, Bereinigung, Migration und Nachweise abdecken.Interne Fristen für Entscheidungen und Wellen deutlich vor dem Supportdatum festlegen.

Die Zielarchitektur innerhalb des Supportzeitraums planen

MIM kann weiterhin wertvolle Arbeit leisten. Der Synchronization Service kann Identitätsdaten aus heterogenen Personalsystemen, Verzeichnissen, Datenbanken und Anwendungen zusammenführen. Er kann Attribute berechnen und Änderungen provisionieren. MIM Service and Portal kann Anfrage- und Workflow-Muster unterstützen. Der Password Change Notification Service und unterstützte Konnektoren sind möglicherweise weiterhin in betriebliche Prozesse eingebettet, auf die der Geschäftsbetrieb jeden Tag angewiesen ist.

Support für diese Funktionen ist nicht dasselbe wie eine strategische Produkt-Roadmap. Die Architektur bleibt in On-Premises-Diensten, SQL Server, SharePoint-basierten Portalkomponenten und individueller Integrationslogik verwurzelt. Microsoft liefert auf der SP3-Linie Fehlerbehebungen und Plattformunterstützung, aber die Lebenszyklusverlängerung beseitigt nicht Jahre an lokalen Regeln, Skripten, Betriebswissen und Abhängigkeiten. Ebenso wenig überführt sie einen MIM-Workflow automatisch in Microsoft Entra ID Governance.

Es laufen zwei Uhren:

  1. Die Support-Uhr läuft nach dem aktuell veröffentlichten Lebenszyklus am 9. Januar 2029 ab.
  2. Die Transformationsuhr läuft früher ab, weil die Organisation nach der Migration eine stabile Phase für Abgleich, Audit-Abnahme und kontrollierte Stilllegung braucht.

Wenn ein komplexes Programm zwölf Monate für Bestandsaufnahme und Design benötigt, weitere zwölf bis achtzehn Monate für die Umsetzungswellen und mehrere Monate für die Stabilisierung, liegt die praktische Entscheidungsfrist deutlich näher, als 2029 vermuten lässt. Die genaue Dauer hängt von der Zahl der Identitätsgruppen, angebundenen Systeme, individuellen Erweiterungen, Genehmigungswege und regulatorischen Kontrollen ab. Messen Sie diese Fakten, statt einen Zeitplan nach dem Vorbild eines anderen Unternehmens zu wählen.

Den MIM-Betrieb vor der Neugestaltung stabilisieren

Ein Migrationsprogramm sollte die Quellplattform nicht verfallen lassen, während das Ziel entworfen wird. Eine instabile MIM-Landschaft liefert unzuverlässige Bestandsdaten und macht aus jedem Migrationsfehler einen Streit darüber, ob das alte oder das neue System verantwortlich ist.

Beginnen Sie mit der bereitgestellten Version und der Matrix der unterstützten Plattformen. Microsoft führt die aktuell unterstützten Kombinationen für MIM 2016 SP3 auf, einschließlich der unterstützten Versionen von Windows Server, SQL Server und SharePoint. Gleichen Sie jeden MIM-Server und jede Abhängigkeit mit dieser Matrix ab. Erfassen Sie Editionen der Betriebssysteme, Datenbankversionen, SharePoint-Edition, Servicekonten, Zertifikate, Agent-Versionen, Konnektor-Builds und Hotfix-Stände. Eine Bezeichnung wie „MIM 2016“ reicht nicht aus, um die Supportfähigkeit festzustellen.

Entfernen oder ersetzen Sie Abhängigkeiten, die Microsoft bereits abgekündigt hat:

  • Microsoft Entra MFA Server ist abgekündigt und hat die Verarbeitung von Anfragen zur Multi-Faktor-Authentifizierung nach dem 30. September 2024 eingestellt. Ein MIM-Prozess, der vom alten MFA-Server-Pfad ausgeht, braucht ein unterstütztes Authentifizierungsdesign.
  • Silverlight wird nicht mehr unterstützt und ist nicht mehr verfügbar. Laut Microsoft sollten BHOLD-Module, die Silverlight benötigen, deinstalliert werden. Ein ungenutztes BHOLD-Portal in Betrieb zu lassen, schafft eine vermeidbare Angriffsfläche und trügerische Sicherheit.
  • Hybrid Reporting über den früheren MIM-Berichtsweg ist abgekündigt. Die Empfehlungen von Microsoft verweisen Kunden für Berichts- und Überwachungsszenarien auf Server mit Azure Arc und auf Azure Monitor.
  • Funktionen auf der Liste der abgekündigten Funktionen von Microsoft sollten für neue Entwürfe nicht gewählt werden. „Es läuft noch“ ist kein tragfähiger Grund, die künftige Abhängigkeit davon zu vergrößern.

Zur betrieblichen Härtung gehören außerdem getestete Sicherung und Wiederherstellung, Überwachung ablaufender Zertifikate, Alarmierung für Jobs und Konnektoren, dokumentierte Notfallzugriffsverfahren (Break Glass) und ein klarer Patch-Prozess. Führen Sie vor einer größeren Migrationswelle eine Wiederherstellungsprobe durch. Eine Sicherung, die nie wiederhergestellt wurde, ist nur eine Annahme.

Identitätsprozesse und ihre Abhängigkeiten inventarisieren

MIM-Landschaften enthalten oft mehr Geschäftsregeln, als ihre Dokumentation zeigt. Join-Regeln, Metaverse-Erweiterungen, Synchronisierungsregeln, Management-Agent-Flows, Workflows, Sets, Richtlinien, geplante Skripte und manuelle Betriebsverfahren können zusammen entscheiden, wer Zugriff erhält. Eine einfache Liste der MIM-Server und Konnektoren übersieht diese Entscheidungen.

Verfolgen Sie für jeden Identitätsablauf den vollständigen Weg:

Quellereignis → Korrelation → Richtlinienentscheidung → Genehmigung → Provisionierungsauftrag → Ergebnis im Zielsystem → Abgleich → aufbewahrter Nachweis

Nutzen Sie Konfigurationsexporte aus der Produktion, Ausführungsverläufe, Konnektorstatistiken, Serviceunterlagen und Nachweise aus den Zielsystemen. Befragen Sie HR, die für Anwendungen verantwortlichen Personen, IT-Sicherheit, Audit und Betrieb, aber gleichen Sie die Antworten aus Workshops mit der bereitgestellten Konfiguration ab. Wo sich die Nachweise widersprechen, dokumentieren Sie die Abweichung und benennen Sie eine verantwortliche Person, die über die künftige Regel entscheidet.

Ordnen Sie jede aktuelle Funktion einer von fünf Kategorien zu:

  • Vorübergehend beibehalten: während eines kontrollierten Parallelbetriebs in MIM erforderlich.
  • Verlagern: das fachliche Ergebnis in einem benannten Zieldienst sicherstellen.
  • Neu gestalten: das Kontrollziel beibehalten, aber Prozess oder Zuständigkeit ändern.
  • Zusammenführen: doppelte Regeln, Rollen oder Konnektoren vor der Migration zusammenlegen.
  • Stilllegen: veraltete Zugriffsrechte, Integrationen oder Berichte mit Genehmigung der verantwortlichen Person entfernen.

Diese Einordnung verhindert, dass die Zielplattform zu einer teuren Kopie historisch gewachsener Komplexität wird. Außerdem erhalten Prüfende eine nachvollziehbare Antwort, wenn ein alter Prozess bewusst entfernt wird.

Was Microsoft Entra übernehmen kann und wo weiterhin Analyse nötig ist

Microsoft Entra bietet inzwischen mehrere Dienste, die für eine MIM-Modernisierung relevant sind, aber sie lösen unterschiedliche Teile des Problems.

Inbound Provisioning kann Identitätsdaten von Beschäftigten aus unterstützten Cloud-HR-Systemen oder über API-gesteuerte Provisionierung in Entra ID übernehmen. Microsoft dokumentiert dafür ein Muster mit dem Endpunkt /bulkUpload von Microsoft Graph für API-gesteuertes Inbound Provisioning. Der Datenvertrag mit der Quelle, die Abgleichsattribute, die Datenqualität, das Wiederholungsverhalten und die maßgebliche Zuständigkeit müssen weiterhin konzipiert werden.

Lifecycle Workflows können in Entra ID Governance Aufgaben für Eintritt, Wechsel und Austritt automatisieren. Der Dienst setzt geeignete Identitätsattribute und Lizenzen voraus. In den Bereitstellungsempfehlungen von Microsoft gehören Attribute wie Eintritts- und Austrittsdatum der Beschäftigten zur Vorbereitung. Veröffentlichte Dienstgrenzen, darunter Grenzen für Workflows und benutzerdefinierte Aufgaben, müssen am geplanten Betriebsmodell gemessen werden, statt erst während der Implementierung aufzufallen.

Application Provisioning kann Benutzer und Gruppen in unterstützte SaaS- und On-Premises-Anwendungen provisionieren. Microsoft dokumentiert SCIM für viele Anwendungen als bevorzugten Standard und stellt einen On-Premises-Provisionierungsagenten für Anwendungen hinter der Firewall der Organisation bereit. Für weitere On-Premises-Systeme kann ECMA Connector Host Konnektoren unterstützen, ohne dass der MIM Synchronization Service laufen muss. Dass ein Konnektor verfügbar ist, beweist nicht, dass jede MIM-Transformation, jede Löschregel oder jede Abgleichsanforderung gleichwertig abgebildet wird.

Entitlement Management und Zugriffsüberprüfungen können gesteuerte Zugriffspakete, Zuweisungsrichtlinien, Ablaufdaten und Überprüfungsszenarien unterstützen. Dafür braucht es ein fachliches Modell, das Katalogverantwortung, verbundene Organisationen, genehmigende und prüfende Personen, Ausnahmen und Nachweise regelt. Ein technisch gültiges Zugriffspaket ohne verantwortliche Person ist keine ausgereifte Governance.

Self-Service-Kennwortzurücksetzung ist ein Bereich mit klarer strategischer Vorgabe: Microsoft empfiehlt Kunden mit Entra ID P1/P2, die MIM für die Self-Service-Kennwortzurücksetzung nutzen, den Wechsel zur Self-Service-Kennwortzurücksetzung von Microsoft Entra. Behandeln Sie das als abgegrenzte Migration mit Tests der Abhängigkeiten und der Benutzererfahrung, nicht bloß als Wechsel des Portals.

Entra kann deshalb einen erheblichen Teil des MIM-Umfangs ersetzen oder verringern. Entra steuert aber nicht automatisch jede Altdatenbank, jeden Infrastrukturendpunkt, jede SAP-Rolle, jede nicht-menschliche Identität oder jedes individuelle Genehmigungsmodell. Microsoft dokumentiert On-Premises-Konnektoren und Erweiterbarkeit, doch jedes Zielsystem muss gegen die Anforderungen für Anlegen, Aktualisieren, Deaktivieren, Löschen, Abgleich und Wiederherstellung nach Fehlern geprüft werden. Wo Entra nicht für das vollständige Governance-Ergebnis zuständig ist, braucht die Architektur möglicherweise eine unternehmensweite IGA-Ebene, anwendungsspezifische Kontrollen oder beides.

Ein Modernisierungsplan in vier Strängen

Arbeiten Sie in vier verbundenen Strängen statt in einem großen Arbeitspaket „MIM ersetzen“. Jeder Strang liefert Nachweise, die der nächste braucht.

Strang 1. Supportfähigkeit und Risikokontrolle

Bestätigen Sie die Lebenszyklus- und Lizenzsituation, wechseln Sie auf ein geeignetes aktuelles Update von MIM 2016 SP3, richten Sie die Abhängigkeiten an der Matrix der unterstützten Plattformen aus, entfernen Sie abgekündigte Komponenten und proben Sie die Wiederherstellung. Legen Sie ein Risikoregister an, das Wissen bei einzelnen Personen, abgelaufene Zuständigkeiten, nicht unterstützte Konnektoren, anfällige Skripte und fehlenden Abgleich erfasst.

Abschlussnachweise: genehmigter Supportnachweis, aktuelles Komponenteninventar, Ergebnis der Wiederherstellung, Entscheidungen zu Schwachstellen und Abhängigkeiten, benannte verantwortliche Personen für den Betrieb.

Strang 2. Bestandsaufnahme von Identitäten und Kontrollen

Erfassen Sie maßgebliche Quellen, Identitätsgruppen, Korrelationslogik, Rollen, Workflows, Konnektoren, privilegierte Zugriffe, nicht-menschliche Identitäten und Audit-Ausgaben. Messen Sie Mengen und Fehlerquoten. Legen Sie für jede wichtige Regel das zugrunde liegende Kontrollziel fest und ordnen Sie die Regel einer Kategorie zu.

Abschlussnachweise: unterzeichnetes Inventar, Ausgangswert der Datenqualität, Einordnung der Funktionen, Ablaufkarten des Ist-Zustands, Katalog der Kontrollen und Nachweise.

Strang 3. Zielarchitektur und Pilotprojekt

Ordnen Sie jede Zuständigkeit einem benannten Dienst zu. Legen Sie fest, wo der Identitätszustand berechnet wird, wo Zugriff beantragt und genehmigt wird, welche Plattform in welches Zielsystem schreibt und wo das abgeglichene Ergebnis gespeichert wird. Wählen Sie ein Pilotprojekt, das einen vollständigen Ablauf und realistische Fehlerpfade umfasst.

Das Pilotprojekt sollte fehlende Quelldaten, eine doppelte Identität, Wechsel der Führungskraft, eine abgelehnte Genehmigung, eine Zeitüberschreitung im Zielsystem, eine teilweise Provisionierung, einen dringenden Austritt und ein Rollback testen. Eine erfolgreiche API-Antwort reicht nicht aus. Vergleichen Sie die beabsichtigten Zugriffsrechte mit dem tatsächlichen Zustand im Zielsystem.

Abschlussnachweise: Matrix der Zuständigkeiten im Zielbild, Prüfung von Bedrohungen und Datenschutz, Abnahmeergebnisse des Pilotprojekts, abgeglichener Bericht zum Zielsystem, Support- und Betriebsmodell.

Strang 4. Migrationswellen und Stilllegung

Fassen Sie Anwendungen und Abläufe in kontrollierte Wellen zusammen. Legen Sie während des Parallelbetriebs genau fest, welcher Dienst für jedes Zielsystem und jede Berechtigungsklasse Schreibhoheit hat. Verhindern Sie, dass MIM und ein neuer Provisionierungsdienst im Wettlauf unterschiedliche Sollzustände durchsetzen. Nutzen Sie Vergleichsberichte, bis Abweichungen verstanden und akzeptiert sind.

Legen Sie MIM bewusst still, nachdem die letzte Abhängigkeit entfernt ist. Stoppen Sie Zeitpläne und eingehende Datenflüsse in der richtigen Reihenfolge, archivieren Sie Konfiguration und Nachweise gemäß den Aufbewahrungsanforderungen, widerrufen Sie Servicekonten und Zertifikate, entfernen Sie den Netzwerkzugang, schließen Sie die Supportverfahren ab und übertragen Sie die Zuständigkeit für aufbewahrte Einträge.

Abschlussnachweise: Abnahmen der Wellen, abgeglichene Ergebnisse, akzeptierte Ausnahmen, archivierte Nachweise, widerrufene Anmeldedaten, Protokoll der Abschaltung der Infrastruktur.

Drei Entscheidungen, die die Leitung jetzt treffen sollte

Entscheiden Sie erstens, ob die Organisation die Verlängerung als Stabilitätsfenster nutzt oder zulässt, dass der Umfang von MIM wächst. Neue MIM-Anpassungen sollten nur als Ausnahme möglich sein, mit verantwortlicher Person, Stilllegungsplan und einer klaren Begründung, warum die Zielarchitektur die Funktion nicht bereitstellen kann.

Wählen Sie zweitens ein internes Abschlussdatum vor dem 9. Januar 2029. Planen Sie von diesem Datum aus rückwärts über Stabilisierung, Migrationswellen, Pilotprojekt, Design, Beschaffung und Bestandsaufnahme. Planen Sie Reserven anhand der gemessenen Integrationskomplexität ein, nicht anhand eines pauschalen Prozentsatzes.

Finanzieren Sie drittens Governance und Nachweise zusammen mit der Provisionierung. Das sichtbarste technische Ergebnis ist meist ein angelegtes oder deaktiviertes Konto. Das geschäftliche Ergebnis ist umfassender: Die richtige Person hat auf Grundlage einer verantworteten Entscheidung die richtigen Zugriffsrechte erhalten oder verloren, und die Organisation kann den Endzustand nachweisen.

Ein Bereitschaftstest für Ihren nächsten Lenkungskreis

Ihr MIM-Programm ist bereit, von der Diskussion in die Umsetzung zu wechseln, wenn das Team alle diese Fragen mit konkreten Nachweisen beantworten kann:

  • Welcher MIM-Build und welche Versionen der abhängigen Plattformen laufen, und werden sie unterstützt?
  • Welche Entra-ID-Lizenzen und welcher Microsoft-Supportweg gelten für die Landschaft?
  • Welche abgekündigten MIM-Komponenten oder Integrationen sind noch vorhanden, und was ersetzt sie?
  • Was sind die maßgeblichen Quellen für Mitarbeitende, externe Mitarbeitende, Partner und nicht-menschliche Identitäten?
  • Welche Regeln oder Erweiterungen entscheiden über Identitätskorrelation, Lebenszyklusstatus und Zugriff?
  • Welcher Zieldienst ist für Lebenszyklus, Governance, Provisionierung, Authentifizierung, Abgleich und Berichtswesen zuständig?
  • Welcher Dienst darf während des Parallelbetriebs in welche Anwendung schreiben?
  • Wie weist das Pilotprojekt den tatsächlichen Zustand im Zielsystem nach, einschließlich Fehlerfall und Rollback?
  • Welche historischen Nachweise müssen nach der Abschaltung von MIM verfügbar bleiben?
  • Welches interne Abschlussdatum lässt genug Zeit vor dem 9. Januar 2029?

Wenn das Team mehrere dieser Fragen nicht beantworten kann, ist der nächste sinnvolle Schritt eine strukturierte Bestandsaufnahme und Architekturbewertung. Wer weitere Lizenzen kauft, bevor die aktuellen Ergebnisse und Kontrollen bekannt sind, verlagert die Unsicherheit, statt sie aufzulösen.

Wo easyIGA ins Bild passt

Organisationen, die eine selbst gehostete Governance-Ebene für Microsoft- und Nicht-Microsoft-Systeme benötigen, können easyIGA als Teil des Zielentwurfs bewerten. easyIGA bietet eine fachlich ausgerichtete Ebene über der Identity-Governance-Plattform midPoint. midPoint ist open source. Der Schwerpunkt liegt auf Zugriffsanfragen, Genehmigungen, Überprüfungen und verständlichen Governance-Nachweisen. Standardmäßig selbst gehostet, auf Ihrer eigenen Infrastruktur, in Ihrem eigenen Rechtsraum. Für Organisationen ohne geeignete Infrastruktur ist auf Anfrage eine in der EU gehostete Bereitstellung verfügbar, die unser Team betreibt.

Bewerten Sie die Zielkombination anhand der geforderten Identitätsergebnisse und der realen Anwendungslandschaft. Prüfen Sie, wer für jede Richtlinie verantwortlich ist und wie die Implementierung das Ergebnis nachweist. Bestandsaufnahme, Datenbereinigung und Kontrolldesign bleiben notwendig, unabhängig davon, welche Produkte ausgewählt werden.

Kontaktieren Sie unser Team, wenn Sie eine technische Bewertung einer MIM-Landschaft oder Unterstützung bei der Definition der ersten Modernisierungswelle wünschen. Eine sinnvolle Prüfung beginnt mit der bereitgestellten Version, dem Konnektorinventar, den Erweiterungen, den Lebenszyklusabläufen, den Betriebsvorfällen und den Audit-Nachweisen. Ergebnis sollten ein Plan zur Supportfähigkeit, eine Matrix der Zuständigkeiten im Zielbild und eine priorisierte Abfolge sein, die sich testen lässt.

Den Produktumfang vor der Plattformwahl bestätigen

Testen Sie für einen MIM-Umstieg easyIGA und midPoint mit Ihren Konnektorversionen und Lebenszyklusregeln. Die Nachweisübersicht erläutert erfasste Genehmigungen, extern erteilte Zugriffsrechte und fehlende historische Einträge. Beziehen Sie Genehmigungen und fehlgeschlagene Änderungen in Zielsystemen in das Pilotprojekt ein. Die Erfahrung unseres Teams aus mindestens 14 midPoint-Einführungen hilft dabei, diesen Umfang in einen praktikablen Migrationsplan zu überführen.

Weiter mit der Umsetzung

Nutzen Sie den IGA-Leitfaden, um die Governance-Funktionen möglicher Zielplattformen zu vergleichen, und das Offboarding-Playbook, um einen Abnahmetest für Austritte zu entwerfen.

Quellen und Hinweise zur Prüfung

Angaben zum Produktumfang und redaktionelle Formulierungen wurden am 24. September 2026 aktualisiert. Die unten genannten Daten beziehen sich weiterhin auf die ursprüngliche Prüfung der Quellen.

Die Sachaussagen und aktuellen Produkthinweise in diesem Artikel haben wir anhand dieser Primärquellen geprüft. Die Prüfung erfolgte am 12. September 2026.

Support, Lizenzierung und Funktionen der Dienste können sich ändern. Prüfen Sie die geltenden Bedingungen von Microsoft, Lizenzen, Versionen der Bereitstellung und den vertraglichen Supportweg, bevor Sie eine verbindliche Programmentscheidung treffen.

Über das Autorenteam

easyIGA-Team

Die Erfahrung unseres Teams aus midPoint-Projekten fließt in easyIGA und in die praktischen Hinweise auf dieser Website ein. Die Menschen hinter dem Produkt stellen wir auf der Seite „Über uns“ vor.

Wenden Sie sich an unser Team, um einen sachlichen Fehler zu melden oder um eine Klarstellung zu bitten.