[Startseite](https://easyiga.com/de/) / [Blog](https://easyiga.com/de/blog) / Was ist IGA Grundlagenleitfaden / Identity Governance # Was ist IGA? Zugriffsrechte, die Sinn ergeben. Identity Governance and Administration, ausführlich erklärt. Sie erfahren, welche Entscheidungen, welche Technologie und welches Betriebsmodell hinter Zugriffsrechten stehen, die Ihre Organisation begründen kann. [Vom easyIGA-Team](https://easyiga.com/de/blog/was-ist-iga#iga-author-name)Veröffentlicht am 24. August 2026Aktualisiert am 12. Oktober 202618 Minuten Lesezeit Die Antwort in einer Minute IGA hilft einer Organisation festzustellen, wer Zugriff hat, zu entscheiden, ob das so sein sollte, Änderungen umzusetzen und das Ergebnis nachzuweisen. IGA verbindet Identitätsdaten, fachliche Verantwortung und technische Kontrollen über den gesamten Lebenszyklus von Zugriffsrechten. Dieser Leitfaden hilft Ihnen, die Kategorie zu verstehen, Lücken zu erkennen und eine praxisnahe erste Implementierung zu planen. [Kolleginnen und Kollegen besprechen sich an einem Computer im Büro] Symbolfoto von [Vitaly Gariev / Unsplash](https://unsplash.com/photos/team-collaborating-around-a-computer-in-an-office-UikYLDQj9_I). [Unsplash License](https://unsplash.com/license). Die abgebildeten Personen dienen der Veranschaulichung. Es handelt sich weder um unsere Mitarbeitenden noch um eine Kundeneinführung. In diesem Leitfaden - [01 · Was IGA bedeutet](https://easyiga.com/de/blog/was-ist-iga#definition) - [02 · Der Governance-Zyklus](https://easyiga.com/de/blog/was-ist-iga#governance-cycle) - [03 · IGA, IAM und PAM](https://easyiga.com/de/blog/was-ist-iga#iga-iam-pam) - [04 · Kernfunktionen](https://easyiga.com/de/blog/was-ist-iga#building-blocks) - [05 · Eintritte, Wechsel und Austritte](https://easyiga.com/de/blog/was-ist-iga#lifecycle) - [06 · Integration und Architektur](https://easyiga.com/de/blog/was-ist-iga#architecture) - [07 · Rollen und Richtlinien](https://easyiga.com/de/blog/was-ist-iga#roles) - [08 · Zugriffsüberprüfungen](https://easyiga.com/de/blog/was-ist-iga#reviews) - [09 · Verantwortlichkeiten](https://easyiga.com/de/blog/was-ist-iga#ownership) - [10 · Nicht-menschliche Identitäten](https://easyiga.com/de/blog/was-ist-iga#nonhuman) - [11 · Compliance und Nachweise](https://easyiga.com/de/blog/was-ist-iga#compliance) - [12 · Implementierungsplan](https://easyiga.com/de/blog/was-ist-iga#implementation) - [13 · Auswahl einer Lösung](https://easyiga.com/de/blog/was-ist-iga#selection) - [14 · Checkliste für den Start](https://easyiga.com/de/blog/was-ist-iga#readiness) - [15 · Häufige Fragen](https://easyiga.com/de/blog/was-ist-iga#questions) - [16 · Wo easyIGA ansetzt](https://easyiga.com/de/blog/was-ist-iga#easyiga) - [Quellen und Autorschaft](https://easyiga.com/de/blog/was-ist-iga#sources) 01 / Die Grundlage ## Was ist Identity Governance and Administration? Identity Governance and Administration (IGA) ist das Zusammenspiel von Richtlinien, Entscheidungen mit klarer Verantwortlichkeit und operativen Prozessen, mit denen eine Organisation steuert, wer warum Zugriff auf ihre Systeme und Daten hat und wann dieser Zugriff geändert oder beendet werden muss. Governance legt Regeln und Verantwortlichkeiten fest. Administration setzt die Änderungen an Konten und Berechtigungen um. Zusammen verbinden sie geschäftliche Entscheidungen mit den Zugriffsrechten, die tatsächlich bestehen. Eine Identität kann für Mitarbeitende, externe Mitarbeitende, Partner oder einen nicht-menschlichen Akteur wie eine Anwendung oder ein Servicekonto stehen. Zugriff kann bedeuten, einen Kundendatensatz zu öffnen, eine Zahlung freizugeben, einen Server zu administrieren oder einen freigegebenen Ordner einzusehen. IGA überführt diese Identitäten und Berechtigungen in einen Prozess, der sich verstehen, betreiben und überprüfen lässt. Die zentralen Fragen sind praktischer Natur: Wer ist für dieses Konto verantwortlich, was kann es, welcher geschäftliche Bedarf rechtfertigt es, wer hat es autorisiert, und gilt diese Begründung noch? Eine brauchbare Antwort enthält Nachweise aus dem Zielsystem. Eine als „genehmigt“ markierte Anfrage belegt nicht, dass der Zugriff korrekt eingerichtet oder später entfernt wurde. [Die Identity-Governance-Übersicht von Microsoft](https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview) beschreibt Identitätslebenszyklus, Zugriffslebenszyklus und privilegierten Zugriff als zusammenhängende Bereiche. Wo ein Produkt endet, ist von Anbieter zu Anbieter verschieden. Das Betriebsmodell in diesem Leitfaden ist ein anbieterneutraler Weg, den gesamten Prozess zu bewerten, einschließlich der Arbeit, für die Menschen verantwortlich sein müssen. Ein sinnvoller Ausgangspunkt Wählen Sie eine wichtige Anwendung und eine Person, die kürzlich die Stelle gewechselt hat. Können Sie jede Berechtigung erklären, die sie noch hat, die verantwortliche Person benennen und zeigen, ob veraltete Zugriffsrechte entfernt wurden? Die Lücken in dieser Antwort ergeben einen konkreten ersten Projektumfang für IGA. 02 / So funktioniert es ## Vom Geschäftsbedarf zum geprüften Zugriff Identity Governance ist ein fortlaufender Zyklus. Eine Änderung im Beschäftigungsverhältnis, eine Projektzuordnung oder eine Anfrage gibt Anlass, Zugriffsrechte zu bewerten. Die Organisation trifft eine Entscheidung, setzt sie um, prüft das Ergebnis und überdenkt die Entscheidung, wenn sich die Umstände ändern. - 01 ### Bedarf feststellen Bestimmen Sie die Person oder den Dienst, die Ressource, den Zweck und den benötigten Zeitraum. - 02 ### Entscheiden Wenden Sie Richtlinien an, lösen Sie Konflikte und holen Sie, wo erforderlich, die Genehmigung einer verantwortlichen Person ein. - 03 ### Umsetzen Legen Sie Konten und Berechtigungen in den betreffenden Systemen an, ändern oder entfernen Sie sie. - 04 ### Verifizieren Vergleichen Sie das Zielsystem mit dem beabsichtigten Ergebnis und beheben Sie fehlgeschlagene Aktionen. - 05 ### Neu bewerten Prüfen Sie den fortbestehenden Bedarf, reagieren Sie auf Änderungen und bewahren Sie die Entscheidungshistorie auf. Ein eigenes konzeptionelles Diagramm des Governance-Zyklus. Jeder Schritt braucht eine verantwortliche Person und ein beobachtbares Ergebnis; dies ist kein Produkt-Screenshot. Nicht jede Vergabe von Zugriffsrechten braucht einen eigenen Klick der Führungskraft. Eine dokumentierte Richtlinie kann risikoarme Basiszugriffsrechte automatisch zuweisen, wenn verlässliche Identitätsattribute genehmigte Bedingungen erfüllen. Sensible, außergewöhnliche oder konfliktbehaftete Zugriffsrechte können eine ausdrückliche Genehmigung erfordern. Beim Design kommt es darauf an, wirksame Kontrolle dort anzusetzen, wo das Risiko es rechtfertigt, und Routinezugriffe vorhersehbar zu machen. Legen Sie für jeden Schritt fest, was passiert, wenn der normale Ablauf scheitert. Fehlende Führungskräfte, mehrdeutige Identitätszuordnungen, nicht verfügbare Anwendungen und abgelehnte Änderungen sollten sichtbare Ausnahmen mit klarer Verantwortung erzeugen. Ein Prozess, der eine unvollständige Aktion offenlegt, nützt mehr als ein Dashboard, das eine gesendete Anfrage als abgeschlossenes Ergebnis behandelt. 03 / Die Grenzen kennen ## IGA vs. IAM, SSO, MFA und PAM Diese Funktionen greifen ineinander, und Anbieter bündeln teils mehrere davon in einer Plattform. Am klarsten wird der Vergleich über die Frage, die jede Funktion beantwortet. Wer eine dieser Funktionen hat, hat damit nicht automatisch auch die anderen abgedeckt. Welche Identitätsfunktion löst welches Problem? | Funktion | Leitfrage | Praxisbeispiel | Zu prüfende Grenze | IAM | Wie verwalten wir Identitäten und Zugriffe insgesamt? | Die Identitätsarchitektur der Organisation sowie Authentifizierungs- und Autorisierungsdienste. | IAM ist die übergeordnete Disziplin; ein bestimmtes IAM-Produkt deckt unter Umständen nur einen Teil davon ab. | IGA | Sollte diese Identität diesen Zugriff haben, und können wir nachweisen, dass die Entscheidung umgesetzt wurde? | Eine Projektrolle genehmigen, sie ablaufen lassen und die Nachweise zu Überprüfung und Entzug aufbewahren. | Erfordert verlässliche Identitätsdaten, klare Verantwortung für Ressourcen und ausreichende Integrationsabdeckung. | SSO / Identity Provider | Wie kann sich eine Identität über mehrere Anwendungen hinweg anmelden? | Mit einer zentralen Anmeldesitzung mehrere angebundene Anwendungen erreichen. | Eine Anmeldeintegration allein rechtfertigt nicht jede Berechtigung innerhalb einer Anwendung. | MFA | Welche zusätzlichen Authentifizierungsfaktoren sind erforderlich? | Bei der Authentifizierung einen weiteren Faktor verlangen. | Stärkere Authentifizierung beseitigt keine unnötige fachliche Berechtigung. | PAM | Wie steuern wir privilegierten Zugriff und privilegierte Zugangsdaten oder Sitzungen? | Administratorzugriff vermitteln, seine Dauer begrenzen und unterstützte Aktivitäten aufzeichnen. | Die Abdeckung variiert; prüfen Sie die Anbindung an Genehmigungs-, Überprüfungs- und Beendigungsprozesse. | Provisionierung | Wie gelangt eine Änderung an einem Konto oder einer Berechtigung in ein System? | Über einen Konnektor ein Konto anlegen oder eine Gruppenmitgliedschaft entfernen. | Eine erfolgreiche Ausführung ist ein Teil der Governance; auch die zugrunde liegende Entscheidung zählt. Nehmen wir als Beispiel jemanden, der früher Finanzsysteme administriert hat und heute im Einkauf arbeitet. MFA kann diese Person korrekt authentifizieren, und SSO kann sie problemlos anmelden. Keines von beidem erklärt, warum sie noch Administrationsrechte für die Gehaltsabrechnung hat. IGA sollte den Rollenwechsel mit einer Entscheidung über die alte Berechtigung verbinden; die Anwendung oder das Zugriffskontrollsystem muss die daraus folgende Änderung durchsetzen. Das Beispiel dient der Veranschaulichung und beschreibt keinen gemeldeten Kundenvorfall. IGA unterstützt außerdem eine Zero-Trust-Architektur durch bessere Identitäts-, Berechtigungs- und Richtlinieninformationen. IGA ist aber nicht die ganze Architektur. [NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final) beschreibt ein umfassenderes, ressourcenorientiertes Modell, in dem Netzwerkstandort oder Eigentumsverhältnisse allein kein Vertrauen begründen. Zugriffsentscheidungen zur Laufzeit, Gerätezustand und Durchsetzung bleiben neben der Governance wichtig. 04 / Das Wesentliche im Betrieb ## Was ein wirksames IGA-Programm braucht Beginnen Sie mit den angestrebten Ergebnissen und ordnen Sie diese dann der Software zu. Die folgenden Funktionen bilden einen praxisnahen Bewertungsrahmen. Damit ist nicht gesagt, dass jedes Produkt jede Funktion umsetzt oder jede Organisation dieselbe Umsetzungstiefe benötigt. ### Identitätsinventar und Korrelation Machen Sie Konten aus wichtigen Systemen sichtbar und verknüpfen Sie sie mit einer bekannten Person oder, bei nicht-menschlichen Konten, mit einer verantwortlichen Person. Nutzen Sie stabile Kennungen und explizite Zuordnungsregeln. Eine E-Mail-Adresse kann sich ändern, und zwei Personen können denselben Namen tragen. Mehrdeutige Zuordnungen erfordern eine Klärung statt einer automatischen Zuweisung der Verantwortung. ### Berechtigungskatalog und Anfragen Beschreiben Sie Zugriffsrechte in einer Sprache, die die antragstellende Person versteht. Nennen Sie Ressource, Berechtigungsstufe, verantwortliche Person, Voraussetzungen und voraussichtliche Dauer. „Finanzberichte, nur lesen“ hilft einer Führungskraft mehr als ein unerklärter Gruppencode aus dem Verzeichnisdienst. Hinterlegen Sie die technische Zuordnung unter der fachlichen Beschreibung, damit die Umsetzung präzise bleibt. ### Richtlinien und Genehmigung Legen Sie fest, welche Zugriffsrechte per Regel zugewiesen werden können, welche eine Genehmigung brauchen und welche Kombinationen verboten sind. Geben Sie genehmigenden Personen relevanten Kontext: Zweck, Dauer, Sensibilität und bestehende Zugriffsrechte. Definieren Sie Vertretungen, Eskalation und das Vorgehen, wenn die genehmigende Person zugleich die antragstellende ist. ### Provisionierung und Abgleich Provisionierung ändert Konten und Berechtigungen. Beim Abgleich (Reconciliation) wird der tatsächlich vorgefundene Zustand im Zielsystem mit dem Zustand verglichen, den die Organisation erwartet. Beides ist wichtig, wenn die Administration Änderungen auch direkt in Anwendungen vornehmen kann. Die von Evolveum veröffentlichte [midPoint-Dokumentation zur Synchronisation](https://docs.evolveum.com/midpoint/reference/support-4.10/synchronization/) beschreibt Mechanismen, mit denen Änderungen auf Seiten der Ressource erkannt und verarbeitet werden; Konfiguration und Reaktion müssen im Detail zu jeder Integration passen. ### Zugriffsüberprüfungen und Nachweise Fragen Sie die verantwortlichen Prüfenden, ob Zugriffsrechte weiterhin angemessen sind, geben Sie ihnen genug Kontext für die Entscheidung und setzen Sie die Änderungen um, die ihre Entscheidungen erfordern. Speichern Sie eine zusammenhängende Historie, die Identität, Anfrage, Genehmigung, Richtlinie, Umsetzung, Ausnahme und Überprüfung verknüpft. Berichte sollten sowohl erfolgreiche Aktionen als auch offene Aufgaben ausweisen. 05 / Zugriff folgt Veränderung ## Eintritte, Wechsel und Austritte Der Identitätslebenszyklus beginnt mit einer verlässlichen Quelle für organisatorische Fakten. HR liefert in der Regel Beschäftigungsstatus, Eintrittsdatum, Führungskraft und Abteilung. Daten zu externen Mitarbeitenden können aus dem Einkauf oder von einem Sponsor stammen. Legen Sie fest, welche Quelle für welche Angabe maßgeblich ist und wie widersprüchliche Aktualisierungen aufgelöst werden, bevor Sie darauf basierende Entscheidungen automatisieren. ### Eintritt Bereiten Sie zum Eintrittsdatum passende Basiszugriffsrechte vor. Bestätigen Sie Identitätszuordnung, Voraussetzungen und Zielkonten. Beantragen Sie zusätzliche Zugriffsrechte über den regulären Richtlinienweg. ### Wechsel Bewerten Sie bestehende Rechte neu, wenn sich Aufgaben ändern. Entfernen Sie veraltete Zugriffsrechte und vergeben Sie nicht nur neue. Geben Sie einer vorübergehenden Überschneidung eine verantwortliche Person und ein Ablaufdatum. ### Austritt Setzen Sie das autorisierte Austrittsereignis in allen relevanten Systemen um. Prüfen Sie, ob die Zugriffsrechte entfernt wurden, kümmern Sie sich um verbliebene Sitzungen und übertragen Sie die Verantwortung für geschäftliche Ressourcen. Für Stellenwechsel braucht es ein eigenes Konzept. Wenn jede Versetzung nur Berechtigungen hinzufügt, häufen sich Zugriffsrechte an, auch wenn jede einzelne Vergabe zu ihrer Zeit vernünftig war. Legen Sie fest, welche Rechte zur alten Stelle gehören, welche zu einem laufenden Projekt und welche eine neue Entscheidung erfordern. Eine Versetzung mit Stichtag kann dann die passenden Änderungen auslösen, ohne davon auszugehen, dass alle alten Zugriffsrechte ungültig sind. Offboarding erfordert eine Überprüfung in jedem einzelnen Zielsystem. [Die Microsoft-Anleitung zum Entzug von Zugriffsrechten](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access) erklärt, dass eine Anwendung eine von ihr ausgestellte Sitzung unabhängig vom Identity Provider steuern kann. Das Deaktivieren eines zentralen Kontos beweist daher für sich allein nicht, dass jede bestehende Sitzung beendet ist. Lokale Konten, API-Zugangsdaten, Geräte und physischer Zugang können eigene Maßnahmen erfordern. Legen Sie Zielzeiten für den Abschluss nach Risiko und Systemklasse fest und messen Sie die Zeit vom maßgeblichen Ereignis bis zum verifizierten Abschluss. Setzen Sie keine pauschale Frist für alle Austritte an. Für den detaillierten Ablauf nutzen Sie unseren [Leitfaden zum Offboarding von Mitarbeitenden](https://easyiga.com/de/blog/zugriffsentzug-beim-austritt). 06 / Unter der Oberfläche ## Wie IGA an Ihre Anwendungslandschaft angebunden wird Eine typische Architektur besteht aus vier Teilen: maßgeblichen Identitätsquellen, einem Governance-Dienst, Integrationsmechanismen und den Systemen, die Zugriffsrechte durchsetzen. Der Governance-Dienst führt Identitätsdatensätze, Richtlinien und Entscheidungen zusammen. Konnektoren oder kontrollierte manuelle Aufgaben übertragen diese Entscheidungen an Verzeichnisdienste, SaaS-Anwendungen, Datenbanken und Infrastruktur. Dokumentieren Sie die Integrationstiefe für jedes System. Konten zu lesen ist etwas anderes, als sie anzulegen; Gruppenmitgliedschaften zu ändern ist etwas anderes, als feingranulare Geschäftsrollen zu verwalten; ein Konto zu deaktivieren ist etwas anderes, als eine Sitzung zu widerrufen. Eine Liste von Konnektornamen ersetzt keinen Test, der jede Operation einzeln prüft. [SCIM, spezifiziert in RFC 7644](https://www.rfc-editor.org/info/rfc7644/), stellt ein HTTP-basiertes Protokoll für die domänenübergreifende Verwaltung von Identitätsressourcen bereit. Es kann helfen, Integrationen zu standardisieren, doch unterstützte Ressourcentypen und Operationen müssen im jeweiligen Dienst trotzdem geprüft werden. Dass ein Konnektor existiert, bedeutet nicht, dass die gesamten Anforderungen der Organisation an Genehmigung, Berechtigungen und Entzug unterstützt werden. Für ein System ohne geeignete API kann eine gesteuerte manuelle Aufgabe eine vertretbare Übergangskontrolle sein. Benennen Sie die ausführende Person, beschreiben Sie die genaue Aktion, setzen Sie eine Frist und verlangen Sie einen Nachweis aus dem Zielsystem. Weisen Sie dieses System als manuell gesteuert aus, nicht als automatisch abgedeckt. Priorisieren Sie Automatisierung dort, wo Volumen, Sensibilität oder Verzögerungen den Aufwand rechtfertigen. Fehlerfall vor dem Go-live testen Verwenden Sie eine repräsentative Testidentität. Machen Sie ein Zielsystem unerreichbar, reichen Sie eine gültige Änderung ein und bestätigen Sie, dass der Prozess einen Fehler protokolliert, eine verantwortliche Person zuweist, die Aktion sicher wiederholt und das spätere Ergebnis verifiziert. Das Abnahmekriterium ist ein korrekter Endzustand mit verständlichen Nachweisen. Schützen Sie auch die IGA-Plattform selbst. Ihre Konnektoren können administrative Berechtigungen besitzen. Begrenzen Sie die Rechte von Servicekonten, schützen Sie Secrets, beschränken Sie administrative Rollen, protokollieren Sie Änderungen und testen Sie die Wiederherstellung. Eine Governance-Plattform braucht dieselbe Disziplin bei Verantwortung und Überprüfung, die sie an anderer Stelle einführt. 07 / Bessere Zugriffsentscheidungen ## Rollen, Attribute, minimale Rechtevergabe und Funktionstrennung Eine Berechtigung ist ein konkretes Zugriffsrecht, etwa die Mitgliedschaft in einer Gruppe oder die Befugnis, Rechnungen freizugeben. Eine Rolle bündelt zusammengehörige Zugriffsrechte zu etwas, das die Organisation zuweisen und pflegen kann. Attributbasierte Regeln nutzen Fakten wie Abteilung, Standort oder Beschäftigungsstatus, um Voraussetzungen oder Zugriffsrechte zu bestimmen. Diese Ansätze lassen sich kombinieren. Halten Sie das Modell verständlich. Eine kleine Basis mit klarer Verantwortung und ausdrücklichen Ausnahmen ist als Einstieg oft die bessere Empfehlung als eine große Rollenhierarchie, die niemand erklären kann. Jede Rolle braucht einen Zweck, eine verantwortliche Person, ein Berechtigungsinventar und einen Überprüfungsprozess. Attributregeln brauchen verlässliche Quelldaten und Tests für Änderungen, fehlende Werte und Ausnahmen. Die [Dokumentation zu Rollen und Richtlinien](https://docs.evolveum.com/midpoint/reference/support-4.10/roles-policies/) von Evolveum unterscheidet Rollen, die Zugriffsrechte oder Verantwortlichkeiten gewähren, von Richtlinien, die regeln, wie Zugriff vergeben, überprüft oder genehmigt wird. Diese Unterscheidung hilft beim Entwurf der Verantwortlichkeiten. Eine Geschäftsrolle und die daran geknüpften Bedingungen sind zusammenhängende Entscheidungen, keine austauschbaren Objekte. Minimale Rechtevergabe (Least Privilege) bedeutet, Zugriffsrechte auf das zu beschränken, was die Arbeit erfordert. Wenden Sie das Prinzip auf Berechtigungsstufe, Ressourcenumfang und Dauer an. Lesezugriff kann ausreichen, wo bisher einfach der Schreibzugriff einer Kollegin oder eines Kollegen kopiert wurde. Ein befristetes Projekt kann ein Ablaufdatum statt einer dauerhaften Mitgliedschaft rechtfertigen. Funktionstrennung (Separation of Duties, SoD) betrifft Kombinationen von Verantwortlichkeiten, die nicht ohne geeignete Kontrolle ausgeübt werden sollten. Eine Organisation kann zum Beispiel verbieten, dass dieselbe Person einen Lieferanten anlegt und auch die Zahlung an diesen Lieferanten freigibt. Diese Regel dient der Veranschaulichung. Der tatsächliche Konflikt hängt von Prozess, Berechtigungen und Risikobewertung ab. Wo eine Ausnahme nötig ist, dokumentieren Sie Begründung, genehmigende Person, kompensierende Kontrolle und Enddatum. 08 / Zugriffsrechte angemessen halten ## Zugriffsüberprüfungen mit echten Entscheidungen Eine Zugriffsüberprüfung fragt, ob eine Identität eine Berechtigung behalten soll. Die prüfende Person braucht mehr als einen Benutzernamen und ein Kontrollkästchen. Stellen Sie die geschäftliche Bedeutung, die Herkunft der Vergabe, die verantwortliche Person, Sensibilität, Begründung, Datumsangaben und, soweit verfügbar, relevante Nutzungsnachweise bereit. Fehlende Nutzungsdaten müssen als fehlend erkennbar bleiben; sie dürfen nicht zu einem erfundenen Wert für „zuletzt genutzt“ werden. [Die Übersicht zu Zugriffsüberprüfungen von Microsoft](https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview) beschreibt die wiederkehrende Bewertung von Mitgliedschaften sowie von Anwendungs- oder Rollenzugriffen. Für den Betrieb folgt daraus, sowohl den Entscheidungsprozess als auch die anschließenden Schritte festzulegen. Eine Entscheidung zum Entzug ist erst abgeschlossen, wenn die entsprechende Entfernung umgesetzt und geprüft wurde. Wählen Sie Umfang und Häufigkeit von Überprüfungen nach geltenden Pflichten, Sensibilität und Änderungsdynamik. Trennen Sie hochriskante administrative Zugriffe von einer risikoarmen allgemeinen Kollaborationsgruppe, wenn diese unterschiedliche Entscheidungen erfordern. Legen Sie fest, was passiert, wenn eine prüfende Person nicht reagiert, und werten Sie Schweigen nicht kommentarlos als Genehmigung. Messen Sie offene Entscheidungen, überfällige Entfernungen und Berechtigungen, die nach einem Entzug wieder auftauchen. Diese Werte zeigen, ob der Prozess Zugriffsrechte in der Praxis verändert. Eine Kampagne, in der jede Zeile geprüft wurde, kann dennoch ein erhebliches Risiko hinterlassen, wenn fehlgeschlagene Entfernungen offen bleiben. Erfahren Sie, wie [Zugriffsprüfungen in easyIGA](https://easyiga.com/de/produkt/zugriffsueberpruefung) die Person, ihre Berechtigung und die verfügbaren Nachweise zusammenführen. 09 / Die Menschen hinter der Richtlinie ## Wer sollte Identity Governance verantworten? IGA ist gemeinsame Arbeit mit klar zugewiesener Verantwortung. Die IT betreibt die Integrationen, kann aber nicht jeden geschäftlichen Bedarf beurteilen. Führungskräfte kennen die Aufgaben einer Person; Anwendungsverantwortliche kennen die Rechte innerhalb eines Systems; die IT-Sicherheit legt die Kontrollanforderungen fest; HR oder der Vertrags-Sponsor liefert die Lebenszyklusdaten. Eine erste Verantwortlichkeitsmatrix zur Anpassung an Ihre Organisation | Verantwortlich | Entscheidung oder Verantwortung | Aufzubewahrende Nachweise | HR / Vertrags-Sponsor | Maßgeblicher Status, Führungskraft und Stichtage. | Freigegebenes Quellereignis und Korrekturen. | Fachliche Führungskraft | Aufgaben und Zugriffsbedarf bestätigen. | Begründung und Genehmigung oder Ablehnung. | Anwendungsverantwortliche | Berechtigungen erklären, sensible Zugriffe genehmigen und Integrationslücken verantworten. | Katalogdefinitionen und Ausnahmeentscheidungen. | IT-Sicherheit / Risiko | Kontrollrichtlinien, Konfliktregeln und risikobasierte Prioritäten festlegen. | Richtlinienversionen und Risikoakzeptanz. | Identitäts- und IT-Betrieb | Workflows, Konnektoren, Abgleich und Wiederherstellung betreiben. | Ausführungsergebnisse und behobene Fehler. | Audit / Compliance | Konzeption und Betrieb anhand der relevanten Anforderungen bewerten. | Stichproben, Feststellungen und Nachverfolgung der Behebung. Weisen Sie jeder operativen Warteschlange eine tatsächlich verantwortliche Person und eine Vertretung zu. „Die Fachabteilung“ ist kein Eskalationsziel. Legen Sie fest, wer eine Ausnahme genehmigen und wer sie anfechten darf. Überprüfen Sie auch die Rechte der Governance-Administration selbst in einem Prozess, der unkontrollierte Selbstgenehmigung ausschließt. 10 / Über Mitarbeitende hinaus ## Externe, Servicekonten und nicht-menschliche Identitäten Externe Mitarbeitende brauchen einen Sponsor, einen Zweck und ein voraussichtliches Enddatum. Verlässt der Sponsor die Organisation, braucht die Zugriffsbeziehung trotzdem eine verantwortliche Person. Beziehen Sie Verlängerungen, Personalwechsel beim Dienstleister und Projektabschlüsse in den Lebenszyklus ein, statt darauf zu warten, dass eine periodische Bereinigung sie aufdeckt. Erfassen Sie für Servicekonten, Anwendungen und automatisierte Agenten die fachlich und die technisch verantwortliche Person, den Zweck der Workload, die erreichten Systeme, den Berechtigungsumfang und die Bedingungen für die Stilllegung. Wenn eine Person ausscheidet, sollte das eine Neuzuweisung oder Überprüfung der nicht-menschlichen Identitäten auslösen, für die sie verantwortlich ist, statt diese Identitäten stillschweigend unbeaufsichtigt zu lassen. Zugangsdaten und Identitäten hängen zusammen, sind aber unterschiedliche Objekte. Ein Token oder Schlüssel autorisiert den Zugriff für eine Identität oder Workload; wird die Mitgliedschaft einer Person in einem Passwort-Tresor entfernt, macht das ein Secret, das sie zuvor abgerufen hat, nicht ungültig. Verbinden Sie Identitätsentscheidungen, wo nötig, mit der Rotation und dem Widerruf von Zugangsdaten. Bewerten Sie bei der Produktauswahl ausdrücklich, wie weit nicht-menschliche Identitäten abgedeckt sind. Fragen Sie, ob das System diese Identitäten erkennen, Verantwortlichkeiten abbilden, Berechtigungen überprüfen und unterstützte Änderungen anstoßen kann. Nehmen Sie nicht an, dass eine Governance-Funktion für die Belegschaft automatisch jede Cloud-Workload oder jeden KI-Agenten verwaltet. Dokumentieren Sie die Grenze und binden Sie bei Bedarf spezialisierte Werkzeuge an. 11 / Nachweise und Pflichten ## Wie IGA Compliance unterstützt, ohne sie zu versprechen IGA kann einer Organisation helfen, zugriffsbezogene Kontrollen umzusetzen und nachzuweisen. Eine Plattform ist kein Compliance-Zertifikat. Anwendbarkeit, Angemessenheit der Kontrollen und rechtliche Auslegung hängen von der Organisation und den jeweiligen Vorschriften ab. - NIS2: Art. 21 Abs. 2 Buchst. i nennt die Sicherheit des Personals, Konzepte für die Zugriffskontrolle und das Management von Anlagen unter den Risikomanagementmaßnahmen im Bereich der Cybersicherheit. Die nationale Umsetzung und der Anwendungsbereich müssen geprüft werden. Lesen Sie dazu die [Richtlinie](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) und unseren [ausführlichen NIS2-Leitfaden](https://easyiga.com/de/blog/was-nis2-verlangt). - Datenschutz-Grundverordnung (DSGVO): Art. 5 Abs. 2, Art. 24 und Art. 32 behandeln die Rechenschaftspflicht, die Pflichten des Verantwortlichen und geeignete Sicherheitsmaßnahmen. Die Governance von Zugriffsrechten kann diese Pflichten unterstützen; die DSGVO schreibt kein bestimmtes IGA-Produkt vor. Den vollständigen Kontext finden Sie in der [Verordnung](https://eur-lex.europa.eu/eli/reg/2016/679/oj). - Kontroll-Frameworks: [NIST SP 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) enthält in der Kontrollfamilie Zugriffskontrolle (Access Control) die Kontoverwaltung, die Funktionstrennung und die minimale Rechtevergabe. Welche Kontrollen eine Organisation übernimmt und wie sie diese umsetzt, erfordert einen definierten Umfang und eine Bewertung. Für Anforderungen im Finanzsektor lesen Sie weiter in unserem [Leitfaden zu DORA und Zugangskontrolle](https://easyiga.com/de/blog/dora-und-zugangskontrolle). Halten Sie rechtliche Anforderungen getrennt von empfohlenen Umsetzungsmustern und Produktfunktionen. Ein brauchbares Nachweispaket verknüpft das maßgebliche Identitätsereignis, die Zugriffsentscheidung, die geltende Richtlinie, die Aktion im Zielsystem, die Verifizierung und gegebenenfalls die Ausnahme. Bewahren Sie Einträge nach einem angemessenen Aufbewahrungsplan und mit Zugriffsbeschränkungen auf. Nachweise brauchen genug Kontext, um die Kontrolle zu erklären, ohne unnötige personenbezogene Daten zu erfassen. 12 / Ein praxisnaher Startplan ## Wie Sie IGA in überschaubaren Etappen einführen Die folgende Abfolge ist ein empfohlener Planungsansatz, kein garantierter Lieferzeitplan. Umfang, Integrationsqualität und organisatorische Verantwortung bestimmen den Aufwand. Geben Sie jeder Etappe ein Abnahmekriterium, damit Fortschritt ein nachgewiesenes Ergebnis bedeutet. - ### Ein Ziel festlegen Wählen Sie ein wesentliches Problem, etwa nicht verifiziertes Offboarding, langsame Genehmigungen von Zugriffsrechten oder eine Überprüfung, die keine Nachweise liefern kann. Benennen Sie den verantwortlichen Sponsor, die betroffene Personengruppe und die Zielsysteme. Dokumentieren Sie die aktuellen Fehlerbilder, bevor Sie Werkzeuge auswählen. - ### Verlässliche Identitätsdaten schaffen Bestimmen Sie maßgebliche Felder, stabile Kennungen und Verantwortliche für Ausnahmen. Testen Sie Namensänderungen, Versetzungen, Wiedereinstellungen, mehrere Verträge und fehlende Führungskräfte. Korrigieren Sie die Daten, die der erste Anwendungsfall braucht, statt alle Arbeit aufzuschieben, bis jeder Datensatz perfekt ist. - ### Zugriffsrechte und Verantwortung erfassen Inventarisieren Sie Konten und Berechtigungen in den ausgewählten Systemen. Benennen Sie Anwendungsverantwortliche, beschreiben Sie sensible Berechtigungen und ermitteln Sie direkte administrative Zugriffswege. Dokumentieren Sie, welche Vorgänge sich automatisieren lassen und welche kontrollierte manuelle Arbeit brauchen. - ### Den gesamten Ablauf aufbauen und testen Konfigurieren Sie eine kleine Auswahl an Richtlinien, Anfragen, Genehmigungen und Aktionen in Zielsystemen. Testen Sie erfolgreiche Änderungen, Ablehnung, Ablauf, nicht verfügbare Systeme und falsche Identitätszuordnungen. Prüfen Sie den Zustand im Zielsystem und die Nachweise, die eine prüfende Person erhält. - ### Pilot mit echten Nutzenden Lassen Sie Führungskräfte, prüfende Personen und Support-Mitarbeitende repräsentative Aufgaben erledigen. Beobachten Sie, wo Katalognamen und Genehmigungskontext verwirren. Beheben Sie diese Probleme, dokumentieren Sie die Wiederherstellung und legen Sie die Übergabe in den Regelbetrieb fest. - ### Anhand gemessener Lücken erweitern Ergänzen Sie Systeme und Personengruppen nach Risiko und nachgewiesenem Nutzen. Überprüfen Sie wiederkehrende Ausnahmen, überfällige Entfernungen und manuellen Aufwand. Planen Sie Verantwortung, Katalogqualität und Kontrolltests fest im Betriebsbudget ein. Der erste Produktivumfang sollte klein genug sein, um ihn zu verstehen, und wichtig genug, um etwas zu bewirken. Er sollte trotzdem den vollständigen Kontrollpfad durchlaufen. Ein reines Konnektor-Pilotprojekt belegt die Konnektivität; es belegt nicht, dass fachliche Genehmigungen, Fehlerbehandlung und Nachweise zusammen funktionieren. 13 / Mit Nachweisen bewerten ## Wie Sie eine IGA-Lösung auswählen Bringen Sie repräsentative Szenarien aus Ihrer Systemlandschaft in die Evaluierung ein. Bitten Sie den Anbieter, zwischen allgemein verfügbaren Funktionen, Preview-Funktionen, Konfigurationsaufwand und geplanter Entwicklung zu unterscheiden. Eine Funktionsbezeichnung sagt weniger aus als ein beobachtetes Ergebnis in einer unterstützten Konfiguration. Fragen für eine Demo oder einen Proof of Concept | Bereich | Zeigen lassen | Akzeptabler Nachweis | Integration | Die von Ihnen benötigten Vorgänge für Konten, Berechtigungen und Entfernung. | Unterstützte Versionen, getestete Vorgänge und dokumentierte Lücken. | Fachliche Nutzbarkeit | Eine Führungskraft, die eine ungewohnte Anfrage und Überprüfung abschließt. | Verständliche Beschreibungen der Zugriffsrechte und ausreichender Entscheidungskontext. | Richtlinien | Eine konfliktbehaftete Anfrage, eine befristete Ausnahme und eine abgelaufene Vergabe. | Protokolliertes Richtlinienergebnis, Entscheidung einer verantwortlichen Person und abgeschlossene Nachbearbeitung. | Fehlerbehandlung | Ein nicht verfügbares Zielsystem und eine sichere Wiederherstellung. | Sichtbarer Fehler, Eskalation mit klarer Verantwortung und abgeglichener Endzustand. | Nachweise | Rekonstruktion einer Zugriffsentscheidung von Anfang bis Ende. | Verknüpfte Einträge statt zusammenhangloser Screenshots. | Betrieb | Backup, Wiederherstellung, Upgrades und Verantwortung für die Konfiguration. | Runbooks, Zuständigkeiten und ein getesteter Wiederherstellungsansatz. | Ausstieg und Kontrolle | Export von Identitätsdaten, Entscheidungen und Konfiguration. | Dokumentierte Formate, vertragliche Rechte und Annahmen zur Migration. Bewerten Sie die Kosten über die gesamte Betriebsdauer der Lösung. Berücksichtigen Sie Lizenzen, Infrastruktur, Integration, Datenbereinigung, das Design von Geschäftsrollen, Schulung, Support, Upgrades und das Team, das Ausnahmen verantwortet. Software auf Basis von open source kann manche Lizenzbeschränkungen verringern, erfordert aber dennoch Investitionen in Implementierung und Betrieb. Erstellen Sie einen Business Case auf Basis Ihrer eigenen Messungen. Schätzen Sie das Volumen wiederkehrender Anfragen und den Bearbeitungsaufwand, und bewerten Sie Risiko- und Nachweislücken getrennt davon. Machen Sie aus einer nicht belegten Senkung der Wahrscheinlichkeit einer Sicherheitsverletzung keine präzise Einsparsumme. Ein glaubwürdiger Vorschlag legt seine Annahmen offen und gibt der kaufenden Organisation die Möglichkeit, sie zu prüfen. 14 / Ihr nächster Arbeitstermin ## Eine Checkliste für den IGA-Start Gehen Sie diese Fragen mit HR, IT, IT-Sicherheit und den Anwendungsverantwortlichen durch. Halten Sie für jeden offenen Punkt eine verantwortliche Person und den nächsten Schritt fest. Die Checkliste ist ein Gesprächseinstieg, keine Reifegradbewertung und keine Compliance-Prüfung. - Wir wissen, welche Quelle für den Status von Mitarbeitenden und externen Mitarbeitenden maßgeblich ist. - Wir können Konten in wichtigen Systemen einer Identität oder einer verantwortlichen Person zuordnen. - Anwendungsverantwortliche können sensible Berechtigungen in fachlicher Sprache erklären. - Für Eintritte, Wechsel und Austritte sind Stichtage und Zuständigkeiten festgelegt. - Wir unterscheiden genehmigte, versuchte, abgeschlossene und verifizierte Änderungen an Zugriffsrechten. - Befristete Zugriffsrechte und Ausnahmen haben Ablaufdaten und Verantwortliche für die Nachverfolgung. - Prüfende Personen erhalten genug Kontext für fundierte Entscheidungen. - Entscheidungen zum Entzug werden bis zur tatsächlichen Entfernung nachverfolgt. - Nicht-menschliche Identitäten und gemeinsam genutzte Zugangsdaten sind Teil des Umfangs. - Wir können die Nachweise für einen vollständigen Zugriffslebenszyklus reproduzieren. Wenn mehrere Antworten unklar sind, widerstehen Sie der Versuchung, mit einem sehr großen Rollenmodell zu beginnen. Wählen Sie eine wichtige Personengruppe und Anwendung, klären Sie die Verantwortung und weisen Sie den Lebenszyklus nach. So entsteht eine brauchbare Grundlage für die Entscheidung, wo Software, Prozessänderungen oder bessere Quelldaten die größte Wirkung haben. 15 / Fragen vor der Kaufentscheidung ## Häufige Fragen zu IGA Brauchen wir IGA, wenn wir bereits Microsoft Entra ID nutzen? Prüfen Sie Ihre tatsächliche Konfiguration und Abdeckung. Microsoft bietet Funktionen für Identity Governance an, doch ein Verzeichnisdienst oder SSO bedeutet nicht, dass diese Funktionen lizenziert, konfiguriert oder an alle relevanten Systeme angebunden sind. Beginnen Sie bei den fehlenden Ergebnissen und vergleichen Sie Optionen anhand dieser Lücken. Ist IGA nur etwas für große Unternehmen? Nein. Der Bedarf hängt von der Komplexität und Sensibilität der Zugriffsrechte, von personellen Veränderungen und von Nachweisanforderungen ab. Auch eine kleinere Organisation mit vielen kritischen Anwendungen kann vor erheblicher Governance-Arbeit stehen. Eine einfache Systemlandschaft lässt sich unter Umständen mit vorhandenen Werkzeugen und disziplinierten manuellen Prozessen abdecken. Wählen Sie einen verhältnismäßigen Ansatz. Können wir IGA ohne perfektes Rollenmodell einführen? Ja. Eine fokussierte Implementierung kann mit Identitätskorrelation, einer kleinen Auswahl an Zugriffsrechten mit klarer Verantwortung und Lebenszykluskontrollen beginnen. Verbessern Sie das Rollendesign auf Basis der beobachteten Nutzung und der fachlichen Verantwortung. Vermeiden Sie, historische Berechtigungen automatisch in ein Modell zu übernehmen, das ihnen neue Legitimität verleiht. Ersetzt IGA unser HR-System oder die Berechtigungen in Anwendungen? Nein. HR oder eine andere maßgebliche Quelle liefert die Lebenszyklusdaten. Anwendungen setzen ihre eigenen unterstützten Berechtigungen weiterhin selbst durch. IGA verbindet diese Daten, Richtlinien und Entscheidungen mit der Verwaltung und Überprüfung von Zugriffsrechten. Wie lange dauert die Implementierung? Es gibt keine verlässliche allgemeingültige Dauer. Fordern Sie eine Schätzung für einen definierten Umfang an, die auf Systemen, Vorgängen, Qualität der Identitätsdaten, Komplexität der Richtlinien und verfügbaren Verantwortlichen beruht. Verlangen Sie Meilensteine, die an verifizierte Ergebnisse gebunden sind, mit schriftlich festgehaltenen Annahmen und Abhängigkeiten. Kann KI Zugriffsentscheidungen für uns treffen? KI-Unterstützung kann helfen, Zugriffsrechte zu erklären, Auffälligkeiten hervorzuheben oder Prioritäten für Überprüfungen vorzuschlagen. Behandeln Sie Empfehlungen entsprechend ihrer Belege und Grenzen. Änderungen an Zugriffsrechten brauchen weiterhin eine festgelegte Befugnis, eine Richtlinie und einen Audit-Eintrag. Bewerten Sie das tatsächliche Verhalten des Produkts, statt anzunehmen, dass ein KI-Label bereits Governance bietet. 16 / Wo easyIGA ansetzt ## Eine fachliche Ebene über midPoint easyIGA ist als Governance-Ebene für die Fachbereiche positioniert und setzt auf midPoint auf. midPoint ist open source. Die [Produktübersicht](https://easyiga.com/de/produkt) gliedert die Nutzung in die Schritte Beantragen, Genehmigen, Provisionieren, Überprüfen und Nachweisen. So arbeiten die Fachbereiche mit Zugriffsrechten, während midPoint die zugrunde liegenden Identitätsvorgänge übernimmt. Die [Nachweisübersicht](https://easyiga.com/de/produkt#evidence-receipt) erklärt, wie easyIGA Anfragen und erfasste Genehmigungsstufen protokolliert, an anderer Stelle vergebene Berechtigungen erkennt und fehlende historische Informationen kennzeichnet. Prüfungen auf Richtlinienkonflikte zum Entscheidungszeitpunkt sind verfügbar; das Erstellen und Simulieren von Regeln innerhalb von easyIGA ist geplant. Ein Pilotprojekt verbindet diese Funktionen mit Ihren eigenen Anwendungen, einschließlich des Umgangs mit fehlgeschlagenen Änderungen und unvollständigen Einträgen. Unser Team hat mindestens 14 midPoint-Einführungen umgesetzt. Diese Erfahrung prägt, wie wir easyIGA auf alltägliche Zugriffsaufgaben ausrichten. Beginnen Sie mit einem schwierigen Zugriffsszenario aus Ihrer Organisation und verfolgen Sie in einer Live-Demo Entscheidung, Ergebnis und Nachweise. ### Mit den Zugriffen beginnen, die Sie heute nicht erklären können Zeigen Sie uns die Anwendung, das Lebenszyklusereignis oder die Überprüfung, die den meisten manuellen Aufwand verursacht. Dann besprechen wir mit Ihnen Umfang, Integrationsbereitschaft und ein praxisnahes erstes Ergebnis. [IGA-Anforderungen besprechen](https://easyiga.com/de/kontakt)[Produkt entdecken](https://easyiga.com/de/produkt) Quellenverzeichnis ## Quellen und redaktionelle Angaben Produktumfang und redaktionelle Formulierungen wurden am 12. Oktober 2026 aktualisiert. Die ursprünglichen Prüfdaten der Quellen sind unten weiterhin angegeben. Primärquellen geprüft am 8. Oktober 2026. Checklisten zur Implementierung und Bewertungskriterien sind redaktionelle Empfehlungen. Abbildungen sind erläuternde Beispiele, keine Kundenergebnisse. - [Identity governance overview](https://learn.microsoft.com/en-us/entra/id-governance/identity-governance-overview), Microsoft Learn; aktualisiert am 8. Mai 2026. Geprüft am 12. September 2026. - [SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final), NIST; August 2020. Geprüft am 12. September 2026. - [SP 800-53 Rev. 5: Security and Privacy Controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), NIST; September 2020; aktueller Veröffentlichungseintrag eingesehen. Geprüft am 12. September 2026. - [midPoint roles and policies](https://docs.evolveum.com/midpoint/reference/support-4.10/roles-policies/), Evolveum; aktualisiert am 1. August 2025. Geprüft am 12. September 2026. - [midPoint synchronisation](https://docs.evolveum.com/midpoint/reference/support-4.10/synchronization/), Evolveum; fortlaufend gepflegte Dokumentation, Version 4.10. Geprüft am 12. September 2026. - [RFC 7644: SCIM Protocol](https://www.rfc-editor.org/info/rfc7644/), RFC Editor; September 2015. Geprüft am 12. September 2026. - [Access reviews overview](https://learn.microsoft.com/en-us/entra/id-governance/access-reviews-overview), Microsoft Learn; fortlaufend gepflegte Dokumentation. Geprüft am 12. September 2026. - [Revoke user access in an emergency](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access), Microsoft Learn; fortlaufend gepflegte Dokumentation. Geprüft am 12. September 2026. - [Richtlinie (EU) 2022/2555, Artikel 21](https://eur-lex.europa.eu/eli/dir/2022/2555/oj), Europäische Union; 14. Dezember 2022. Geprüft am 12. September 2026. - [Verordnung (EU) 2016/679, Artikel 5, 24 und 32](https://eur-lex.europa.eu/eli/reg/2016/679/oj), Europäische Union; 27. April 2016. Geprüft am 12. September 2026. - [Produktumfang und Integrationsstatus](https://easyiga.com/de/produkt), easyIGA; aktuelle Live-Seite. Geprüft am 12. September 2026. - [Unternehmenshintergrund und Erfahrung](https://easyiga.com/de/ueber-uns), easyIGA; aktuelle Live-Seite. Geprüft am 12. September 2026. Foto: [Vitaly Gariev / Unsplash](https://unsplash.com/photos/team-collaborating-around-a-computer-in-an-office-UikYLDQj9_I), veröffentlicht am 26. September 2025; [Unsplash License](https://unsplash.com/license) (geprüft am 12. September 2026). Die abgebildeten Personen dienen der Veranschaulichung und sind weder als unsere Mitarbeitenden noch als unsere Kundschaft ausgewiesen. eI Über das Autorenteam ## easyIGA-Team Die Erfahrung unseres Teams aus midPoint-Projekten fließt in easyIGA und in die praktischen Empfehlungen auf dieser Website ein. Die Menschen hinter dem Produkt lernen Sie auf der Seite „Über uns“ kennen. [Über das easyIGA-Team →](https://easyiga.com/de/ueber-uns) Übersetzung aktualisiert: 21. Oktober 2026