Kriterienkatalog · Identity and Access Management
IAM-Auswahl: die Kriterien, die unter NIS2 und DORA zählen
Die meisten IAM-Bewertungen prüfen den SSO-Katalog und den Preis pro Nutzer. Unter NIS2 und DORA zählen andere Fragen: Was passiert, wenn der IdP ausfällt, wer belegt, welches Konto wann gesperrt wurde, und wo der Identity Store liegt.
Unabhängige Kriterienreferenz · 23 Kriterien · Stand August 2026 · Von keinem Anbieter gesponsert
Eine Identity-Plattform ist das eine System, dem alle anderen Systeme vertrauen. Damit ist eine IAM-Entscheidung zugleich eine Sicherheits-, eine Kontinuitäts- und eine Jurisdiktionsentscheidung. NIS2 Artikel 21 nennt Multi-Faktor-Authentifizierung und Zugriffskontrolle unter den geforderten Maßnahmen, und DORA erwartet den Nachweis, dass der Zugriff auf kritische Systeme kontrolliert, protokolliert und entziehbar ist. Die Kriterien unten sind die, die DecisionOS für einen IAM-Fall auf den Bewertungsbogen setzt, in derselben Reihenfolge und Gruppierung, damit du hier prüfst, was du dort bewertest.
Kern-Identitätsfunktionen
Kriterium 01
SSO- / SAML- / OIDC-Integration
Warum es zählt
SAML und OIDC decken moderne Anwendungen ab, und dort sieht der Katalog jedes Vendors beeindruckend aus. Die Anwendungen, die im Audit wehtun, sind die anderen: das ERP im eigenen Rechenzentrum mit eigener Nutzertabelle, das Sammelkonto in der Fertigung, das Tool, das nur einen Header- oder Kerberos-Login spricht. Wenn die Plattform sie nicht erreicht, bleiben diese Systeme außerhalb deiner Zugriffskontrolle und außerhalb deines Nachweises.
Was du fragst
Gib dem Vendor deine echte Anwendungsliste mit den zehn sperrigsten Systemen markiert, und frag für jedes einzeln, wie SSO funktionieren würde: nativ, über ein Gateway oder einen Agenten, oder gar nicht. Frag, welche Protokollfunktionen (signierte Assertions, verschlüsselte Assertions, Step-up-Authentifizierung) pro Anwendung unterstützt werden.
Die Falle
Der Integrationskatalog mit tausenden Einträgen misst Logos, nicht Tiefe. Viele Einträge sind reines SSO ohne Provisioning, und über die Altsysteme, die nicht drinstehen, sagt der Katalog nichts. Deine Liste ist der Maßstab, nicht seine.
Kriterium 02
Multi-Faktor-Authentifizierung (MFA)
Warum es zählt
Push-Benachrichtigungen und Einmalcodes sind besser als Passwörter, aber Angreifer umgehen beides routiniert, über Echtzeit-Phishing-Proxys und Push-Ermüdung. FIDO2 und Passkeys binden die Anmeldung an die echte Website, eine gefälschte Login-Seite kann sie nicht abgreifen. NIS2 Artikel 21 verlangt Multi-Faktor-Authentifizierung, sagt aber nicht welche. Die Qualität des Faktors ist deine Entscheidung, und dein Auditor wird fragen, warum du sie so getroffen hast.
Was du fragst
Frag, ob FIDO2 oder Passkeys für eine Gruppe als einzig zulässiger Faktor erzwungen werden können, mit gesperrten statt nur nachrangigen schwächeren Faktoren, und was der Rückfallweg ist, wenn ein Nutzer seinen Schlüssel verloren hat.
Die Falle
"Unterstützt FIDO2" heißt meist: verfügbar als eine Option unter vielen. Wenn der Nutzer weiterhin auf SMS oder Push ausweichen kann, wählt der Angreifer einfach diesen Weg. Unterstützung ist nicht Erzwingung.
Kriterium 03
Rollenbasierte Zugriffssteuerung (RBAC)
Warum es zählt
Rollen sind das Mittel, mit dem "Need to know" zu etwas wird, das ein System erzwingen und ein Auditor lesen kann. Ohne Rollenmodell werden Berechtigungen einzeln vergeben, vom Kollegen kopiert und nie entfernt, und die Antwort auf "wer darf Zahlungen freigeben" ist eine Datenbankabfrage, die niemand ausführen kann. NIS2 und DORA erwarten beide, dass Zugriff dokumentiert und rollenbasiert vergeben wird.
Was du fragst
Frag, wie Rollen modelliert werden (Hierarchien, Vererbung, anwendungsspezifische Rollen), ob eine Rolle mit Zeitlimit und Verantwortlichem zugewiesen werden kann, wie Berechtigungen außerhalb einer Rolle erkannt werden, und wie der Bericht aussieht, der jeden Nutzer einer Rolle mit Datum und Genehmiger auflistet.
Die Falle
"Unterstützt RBAC" stimmt schon für eine flache Gruppenliste. Die Frage ist, ob das Modell deine Organisation überlebt: Matrix-Berichtslinien, Externe in zwei Abteilungen, ein ERP mit sechshundert Transaktionscodes. Lass im Pilot deine drei komplexesten Rollen modellieren.
Kriterium 04
SCIM-Provisionierung / Lifecycle-Management
Warum es zählt
Verwaiste Konten sind der stille Fehler der meisten IAM-Einführungen: Der Externe, der im März gegangen ist, hat im September noch einen funktionierenden Login. Unter NIS2 und DORA musst du zeigen können, dass Zugriff nach Bedarf vergeben und entzogen wird, sobald der Bedarf endet. Diesen Nachweis gibt es nur, wenn die Plattform aus einer führenden Quelle wie dem HR-System liest und nachgelagert per SCIM oder Konnektor ohne Ticket provisioniert und deprovisioniert.
Was du fragst
Bitte um eine Live-Vorführung eines Leaver-Ereignisses: eine Statusänderung im HR-System, und dann stoppe die Zeit, bis das Konto gesperrt, die Sessions beendet und der Zugriff in den angebundenen Anwendungen entfernt ist. Frag, welche deiner Anwendungen SCIM unterstützen und welche einen eigenen Konnektor brauchen.
Die Falle
"Vollständiges Lifecycle-Management" deckt oft das Anlegen von Konten ab und hört dort auf. Mover behalten ihre alten Berechtigungen zusätzlich zu den neuen, und Leaver werden im monatlichen Review erledigt. Frag gezielt nach dem Deprovisioning-Pfad.
Kriterium 05
Verzeichnisintegration (AD, LDAP)
Warum es zählt
Fast jede Organisation hat noch ein Active Directory oder ein LDAP-Verzeichnis, gegen das Dateiserver, Drucker, VPNs und die Hälfte der internen Anwendungen authentifizieren. Die neue Plattform wird entweder zur führenden Quelle für dieses Verzeichnis, synchronisiert sich damit oder läuft daneben, und jede Option entscheidet, wo ein gesperrtes Konto tatsächlich gesperrt ist.
Was du fragst
Frag, welches Verzeichnis die Plattform für welche Attribute als führend behandelt, wie eine Änderung in beide Richtungen fließt und wie schnell, was passiert, wenn beide sich widersprechen, und ob domänengebundene Rechner und Kerberos-abhängige Anwendungen weiterlaufen, wenn die neue Plattform vor dem Verzeichnis steht.
Die Falle
"Nahtlose AD-Integration" heißt meist: ein Sync-Agent in eine Richtung. Die Falle ist eine Sperre in der Cloud-Plattform, die das On-Premises-Verzeichnis nie erreicht, das das VPN prüft, sodass der Ausgeschiedene aus der E-Mail ausgesperrt ist und trotzdem im Netz.
Privilegierter Zugriff & Governance
Kriterium 06
Privileged Access Management (PAM)
Warum es zählt
Die Konten, die die Identity-Plattform verwalten, können jede andere Identität erzeugen, und Domänen-Admins, Datenbank-Owner und Cloud-Root-Konten können jede Kontrolle unter sich aushebeln. Dauerhafte Privilegien auf diesen Konten sind das Ziel jedes ernsten Einbruchs. Ob die Plattform diese Konten nativ verwahren, rotieren, just in time erhöhen und aufzeichnen kann oder das an ein separates PAM-Produkt abgibt, entscheidet, aus wie vielen Tools deine Geschichte zum privilegierten Zugriff besteht.
Was du fragst
Frag, welche privilegierten Kontotypen die Plattform nativ verwalten kann (Verwahrung, Rotation, zeitlich begrenzte Erhöhung, Session-Aufzeichnung), welche ein separates PAM-Produkt brauchen und wie beide integrieren, und wie die eigenen Admin-Konten der Plattform geschützt sind, inklusive Break-Glass-Zugang, wenn SSO selbst ausfällt.
Die Falle
"Privilegierter Zugriff integriert" heißt oft: Admin-Rollen lassen sich in der Konsole zuweisen. Ein Service-Konto verwahren, ein Datenbankpasswort rotieren und eine RDP-Session aufzeichnen sind verschiedene Fähigkeiten, und das eigene Break-Glass-Konto der Plattform, das beim Start eingerichtet und nie getestet wurde, ist das, das versagt, wenn du es brauchst.
Kriterium 07
Identity-Governance & Zugriffszertifizierung
Warum es zählt
Provisioning gibt Menschen Zugriff; Governance belegt, dass der Zugriff noch begründet ist. Unter NIS2 müssen Zugriffskontrollrichtlinien und unter DORA die Zugriffsrechte auf kritische Systeme überprüft werden, und der Auditor fragt nach der letzten Rezertifizierungskampagne mit ihren Entscheidungen. Kann die Plattform keine Rezertifizierung ausführen, bei der eine Führungskraft jede Berechtigung bestätigt oder entzieht und der Entzug ausgeführt und protokolliert wird, kaufst du ein zweites Produkt oder führst die Prüfung in einer Tabelle, was dasselbe ist wie gar nicht.
Was du fragst
Lass dir in der Demo eine Rezertifizierungskampagne zeigen: Abgrenzung nach Anwendung oder Rolle, die Ansicht des Prüfers, was mit einer abgelehnten Berechtigung passiert, und den Bericht, der dabei entsteht. Frag, ob der Bericht exportierbar ist und wie lange er aufbewahrt wird.
Die Falle
"Access Reviews" in der Funktionsliste kann ein Bericht sein, der auflistet, wer was hat. Eine Rezertifizierung ist ein Workflow mit Frist, einer Entscheidung pro Berechtigung und automatischem Entzug, und dieser Unterschied ist der ganze Auditnachweis.
Kriterium 08
Unterstützung für Zero-Trust-Architektur
Warum es zählt
Zero Trust heißt, dass jede Zugriffsentscheidung berücksichtigt, wer fragt, von welchem Gerät, in welchem Zustand, für welche Ressource, jedes Mal, statt dem Netzwerkstandort zu vertrauen. Für die Identity-Plattform übersetzt sich das in konkrete Funktionen: Gerätezustand in der Richtlinie, laufende Session-Bewertung, Risikosignale aus dem EDR, Richtlinien pro Anwendung statt pro Netz. Ohne sie bleibt das VPN die Kontrolle und die Identity-Plattform eine Login-Seite.
Was du fragst
Frag, welche Signale in eine Zugriffsrichtlinie einfließen können (Gerätekonformität, Standort, Risikowert aus EDR oder SIEM, Authentifizierungsstärke), ob eine Session mittendrin widerrufen werden kann, wenn sich ein Signal ändert, und wie eine Richtlinie für eine Anwendung formuliert wird, die on premises hinter keinem Proxy liegt.
Die Falle
"Zero-Trust-ready" ist ein Marketing-Etikett ohne Test dahinter. Die konkrete Frage ist, ob eine kompromittierte Session auf einem gesund wirkenden Gerät gekappt wird, wenn das EDR das Gerät markiert, und wie viele Minuten das dauert. Lautet die Antwort "beim nächsten Login", vertraut weiterhin das Netz.
Kriterium 09
Vollständigkeit von Audit-Trail & Zugriffsprotokollen
Warum es zählt
Unter NIS2 und DORA ist das Identity-Log der Nachweis: wer sich von wo authentifiziert hat, welche Berechtigung von wem vergeben wurde, wann ein Konto gesperrt wurde. Lebt das Log nur in der Konsole des Vendors mit einem Fenster von 90 Tagen, oder fehlen darin Admin-Änderungen und fehlgeschlagene Versuche, kannst du die Frage des Auditors nach dem letzten Jahr nicht beantworten und das SIEM nicht füttern, das den Vorfall korrelieren muss.
Was du fragst
Frag, welche Ereignisse protokolliert werden (erfolgreiche und fehlgeschlagene Anmeldungen, Berechtigungsänderungen, Admin-Aktionen, Richtlinienänderungen), wie lange sie in der Grundstufe aufbewahrt werden, ob das Log selbst manipulationssicher ist, und ob ein vollständiger, lückenloser Export in deinen eigenen Speicher oder dein SIEM enthalten ist oder ein Zusatzmodul. Lass dir das Exportformat zeigen.
Die Falle
"Umfassendes Audit-Logging" mit einer Aufbewahrung in Tagen und einem Export, der als Premium-Modul verkauft wird. Die Lücke entdeckst du, wenn ein Auditor oder ein Vorfall zum ersten Mal nach Ereignissen außerhalb des Fensters fragt, oder nach der Admin-Aktion, die die fragliche Berechtigung vergeben hat.
Kriterium 10
Durchsetzung der Funktionstrennung
Warum es zählt
Wer einen Lieferanten anlegt, sollte nicht dessen Rechnung freigeben; wer eine Berechtigung vergibt, sollte sie nicht selbst zertifizieren. Funktionstrennung ist das Mittel, mit dem Betrug und Fehler strukturell schwer gemacht werden, und DORA wie jeder Wirtschaftsprüfer erwarten, dass das System sie erzwingt, nicht ein Richtliniendokument. Die Identity-Plattform ist der Ort, an dem die konfliktären Kombinationen anwendungsübergreifend sichtbar sind.
Was du fragst
Frag, ob konfliktäre Berechtigungskombinationen anwendungsübergreifend definiert werden können, ob eine Anfrage, die einen Konflikt erzeugen würde, blockiert oder in eine Ausnahmegenehmigung geleitet wird, wie bestehende Konflikte berichtet werden, und ob die Konfliktregeln die Transaktionsebene des ERP abdecken oder nur Rollen auf Anwendungsebene.
Die Falle
"SoD unterstützt" heißt meist: Konflikte lassen sich im Nachhinein berichten. Die Zuweisung zu verhindern, und zwar für die Kombination einer ERP-Rolle mit einer Rolle im Bankportal, ist eine andere Fähigkeit. Bitte um eine Demo mit zwei deiner echten konfliktären Rollen.
Compliance & Sicherheit
Kriterium 11
DSGVO- / Data-Residency-Compliance
Warum es zählt
Der Identity Store enthält von jedem Mitarbeitenden Name, Rolle, Gerät, Standort und Anmeldehistorie. Das sind personenbezogene Daten unter der DSGVO, und für eine regulierte Organisation ist es zugleich die Karte, wer was erreichen kann. Wo er gespeichert und von wo er administriert wird, entscheidet über dein Schrems-II-Risiko und über deine Antwort auf die Residenzfrage im DORA-Informationsregister.
Was du fragst
Frag, wo Verzeichnis, Logs und Backups gespeichert werden, ob die EU-Region Standard oder eine kostenpflichtige Option ist, aus welchen Ländern Support- und Betriebspersonal des Vendors auf Mandantendaten zugreifen kann, und nach dem Auftragsverarbeitungsvertrag und der Liste der Unterauftragsverarbeiter mit Standorten.
Die Falle
"EU-Rechenzentrum" für das Verzeichnis, während Logs, Analytik und Support-Zugriff über Infrastruktur anderswo laufen. Residenz einer Komponente ist nicht Residenz der Plattform, und Residenz der Speicherung ist nicht Residenz des Zugriffs.
Kriterium 12
SOC-2- / ISO-27001-Zertifizierung
Warum es zählt
Die eigene Sicherheit des Vendors ist deine Sicherheit: Ein Einbruch beim Identity Provider ist ein Einbruch in jede Anwendung dahinter. SOC 2 Typ II und ISO 27001 sind die Nachweise, mit denen du den Vendor unter der Lieferkettenmaßnahme von NIS2 und den Drittparteiregeln von DORA in die Lieferantenakte legen kannst, sofern der Scope den Service und die Region abdeckt, die du kaufst.
Was du fragst
Bitte um den aktuellen SOC-2-Typ-II-Bericht und das ISO-27001-Zertifikat mit Erklärung zur Anwendbarkeit, prüfe den Scope auf die Services und Regionen, die du nutzen wirst, und frag, wie der Vendor seinen letzten erheblichen Sicherheitsvorfall behandelt hat und wie Kunden informiert wurden.
Die Falle
"SOC 2 und ISO 27001 zertifiziert" auf der Website mit einem Bericht, der eine andere Produktlinie oder eine Region abdeckt, in der du nicht bist. Und ein sauberer Bericht sagt nichts über den Vorfall nach dem Prüfzeitraum; frag direkt nach der Vorfallshistorie.
Kriterium 13
NIS2- / DORA-Reife
Warum es zählt
NIS2 Artikel 21 nennt MFA und Zugriffskontrolle unter den geforderten Maßnahmen; DORA erwartet, dass Identitäts- und Zugriffsmanagement für kritische Systeme nachweisbar ist und der Anbieter mit den Vertragsklauseln aus Artikel 30 im Informationsregister steht. Reife ist kein Zertifikat, das der Vendor hält, sondern ob die Plattform die Nachweise erzeugt und der Vertrag die Klauseln trägt.
Was du fragst
Frag, welche Berichte die Plattform erzeugt, die auf NIS2 Artikel 21 und die Zugriffskontroll-Erwartungen von DORA abbilden, ob der Vendor ein DORA-Vertragsaddendum mit Prüf- und Exit-Klauseln anbietet, und nach zwei Referenzkunden unter NIS2- oder DORA-Aufsicht, die mit der Plattform ein Audit durchlaufen haben.
Die Falle
"NIS2- und DORA-konform" ist eine Aussage über die eigene Lage des Vendors, nicht über deine Fähigkeit, deine nachzuweisen. Die Verordnung verpflichtet dich, nicht ihn; frag, was dir die Plattform für den Auditor gibt, und lies das Vertragsaddendum vor der Unterschrift, nicht danach.
Kriterium 14
Breach-Erkennung & Alarmierung bei auffälligen Logins
Warum es zählt
Die meisten Einbrüche beginnen heute mit einem gültigen Zugangsdatum. Die Identity-Plattform sieht jede Anmeldung und ist der erste Ort, an dem ein unmöglicher Ortswechsel, ein neues Gerät, ein Password Spray oder ein wiederverwendetes Session-Token sichtbar wird. Wenn sie diese Signale nicht auslöst, oder nur in einem Dashboard, das niemand beobachtet, entdeckt das EDR den Angriff Wochen später.
Was du fragst
Frag, welche auffälligen Anmeldemuster von Haus aus erkannt werden, wie eine Erkennung in Echtzeit dein SIEM oder SOC erreicht, ob eine riskante Session automatisch herausgefordert oder beendet werden kann, und nach der False-Positive-Erfahrung eines Referenzkunden im ersten Monat.
Die Falle
"KI-gestützte Erkennung von Identitätsbedrohungen" heißt oft: ein Risikowert in der Admin-Konsole. Bekommt niemand den Alarm und handelt keine Richtlinie auf den Wert, existiert das Feature und die Kontrolle nicht. Frag nach dem Weg von der Erkennung zur Handlung, und wer ihn nachts verantwortet.
Kriterium 15
API-Security & OAuth-2.0-Unterstützung
Warum es zählt
Anwendungen sprechen miteinander über Tokens, nicht über Passwörter, und die Identity-Plattform stellt diese Tokens aus. Wie sie OAuth-2.0-Scopes, Token-Lebensdauern, Client Credentials für Maschinenidentitäten und den Widerruf eines geleakten Tokens handhabt, entscheidet, ob dein API-Bestand gesteuert ist oder ob jeder Dienst ein langlebiges Secret hält, das niemand rotiert.
Was du fragst
Frag, welche OAuth-2.0- und OIDC-Flows unterstützt werden, wie Maschinen- und Service-Identitäten ausgestellt, rotiert und widerrufen werden, ob Token-Lebensdauern und Scopes pro Client erzwungen werden können, und wie die eigenen APIs der Plattform gegen den Missbrauch eines Admin-Tokens geschützt sind.
Die Falle
"OAuth 2.0 unterstützt" stimmt für jeden modernen IdP. Die Lücke liegt bei den Maschinenidentitäten: Client Secrets, die nie ablaufen, Tokens mit einem Jahr Gültigkeit, und kein Inventar, welcher Dienst welches Credential hält. Bitte um den Bericht, der jede nicht-menschliche Identität mit letzter Nutzung und Ablauf auflistet.
Wirtschaftlichkeit & strategische Passung
Kriterium 16
Lizenzkosten pro Nutzer (3-Jahres-TCO)
Warum es zählt
Mitarbeiteridentitäten sind nur ein Teil der Population. Externe Partner, Kunden, Servicekonten und Maschinenidentitäten übersteigen die Zahl der Beschäftigten meist deutlich, und Vendoren bepreisen sie nach unterschiedlichen Modellen. Eine Plattform, die für 500 Beschäftigte bezahlbar aussieht, wird teuer, sobald 3.000 Lieferanten-Logins und jeder API-Client als abrechenbare Identität zählen.
Was du fragst
Bitte um eine vollständige Preiskalkulation mit deinen echten Zahlen: Beschäftigte, externe Nutzer, Service- und Maschinenidentitäten, dazu die MFA- und Governance-Module, die du wirklich brauchst, über drei Jahre und inklusive Preisdeckel bei Verlängerung.
Die Falle
Der Preis pro Nutzer in der Vergleichstabelle nimmt an, dass jede Identität ein Mitarbeitender in der Grundstufe ist. Die Identitäten, die das Budget sprengen, sind die, die niemand gezählt hat.
Kriterium 17
Implementierungs- & Migrationsaufwand
Warum es zählt
Jede Anwendung zeigt auf die Identity-Plattform, also heißt Einführung, jede einzelne neu anzubinden, Nutzer, Gruppen, Anmeldedaten und MFA-Registrierungen zu migrieren und Alt und Neu monatelang parallel zu betreiben. Der Aufwand misst sich an Anwendungszahl und Legacy-Anteil, nicht an der Lizenzgröße, und hier verlieren die meisten IAM-Projekte ihr erstes Jahr.
Was du fragst
Bitte um den Migrationsplan für deine Anwendungsliste mit Aufwand pro Integrationstyp, frag, wie Nutzer und MFA-Registrierungen ohne Massen-Neuregistrierung migriert werden, wie lange alte und neue Plattform parallel laufen können, und was das Projekt eines vergleichbaren Kunden tatsächlich in Monaten und Personentagen gekostet hat.
Die Falle
"Migrations-Tooling inklusive" bewegt das Verzeichnis. Die Monate stecken in den zweihundert Anwendungsanbindungen, den Fertigungssystemen mit fest verdrahtetem LDAP und der Neuregistrierung jedes Hardware-Schlüssels. Bitte um den Projektplan der letzten vergleichbaren Migration, mit den Terminen, die gerutscht sind.
Kriterium 18
Anbieterabhängigkeit & Exit-Portabilität
Warum es zählt
Eine Identity-Plattform ist das System, das man am schwersten verlässt, weil jede Anwendung auf sie zeigt. Die Migration heraus kostet dasselbe wie die hinein, plus das Risiko, Anmeldedaten, Gruppenstrukturen und Audit-Historie zu verlieren. DORA erwartet für kritische IKT-Dienste eine dokumentierte Exit-Strategie, und das hier ist einer.
Was du fragst
Frag, wie Nutzer, Gruppen, Anmeldedaten und Anwendungskonfigurationen in einem Standardformat exportiert werden können, was ein Wechsel zu einem anderen Anbieter bedeuten würde, und ob der Vendor je einem Kunden beim Verlassen geholfen hat.
Die Falle
"Offene Standards" für die Authentifizierung, proprietär alles in der Konfiguration. SAML und OIDC machen den Login portabel; die Richtlinien, die App-Anbindungen und die MFA-Registrierungen sind die Teile, die dich binden.
Kriterium 19
Roadmap & Enterprise-Skalierbarkeit
Warum es zählt
Du unterschreibst für drei Jahre, und die Plattform muss die Übernahmen, das Kundenidentitätsprogramm und die Explosion der Maschinenidentitäten tragen, die in dieser Zeit kommen. Ob der Vendor in die Richtungen investiert, die du brauchen wirst, und ob die Architektur ohne Neuaufbau auf das Zehnfache an Identitäten skaliert, entscheidet, ob diese Entscheidung im zweiten Jahr erneut ansteht.
Was du fragst
Bitte um die Zwölfmonats-Roadmap unter NDA und prüfe sie gegen deine eigenen Pläne, frag, welche Roadmap-Punkte des letzten Jahres ausgeliefert wurden, und frag nach dem größten Tenant auf der Plattform in Identitäten und Anwendungen und wie lange ein vollständiger Verzeichnis-Sync in dieser Größe dauert.
Die Falle
Roadmap-Folien sind Absichten mit Datum. Und "skaliert auf Millionen" meint das Consumer-Identity-Produkt, nicht den Workforce-Tenant mit komplexer Gruppenverschachtelung, der bei fünfzigtausend zu kriechen beginnt. Frag nach der Referenz in deiner Zielgröße, nicht nach dem Maximum auf der Folie.
Kriterium 20
Nutzerakzeptanz & Admin-Experience
Warum es zählt
Eine Plattform, die Nutzer langsam oder verwirrend finden, wird umgangen: Passwörter werden geteilt, MFA-Abfragen blind bestätigt, Schattenkonten entstehen. Eine Plattform, die Administratoren umständlich finden, wird falsch konfiguriert, weil die Ausnahme, deren saubere Konfiguration eine Stunde gedauert hätte, stattdessen schnell konfiguriert wird. Akzeptanz ist der Ort, an dem die bezahlte Sicherheit entweder ankommt oder verloren geht.
Was du fragst
Lass im Pilot zwei deiner eigenen Administratoren und zehn deiner Nutzer die Aufgaben eines normalen Tages durch das Produkt erledigen, zähl die zusätzlichen Schritte und die Helpdesk-Tickets, und frag den Vendor nach der Abschlussquote der MFA-Registrierung und dem Helpdesk-Ticketvolumen eines vergleichbaren Rollouts.
Die Falle
Akzeptanzzahlen der Vendoren zählen lizenzierte Nutzer, nicht Nutzer, die einen starken Faktor registriert haben und keine Passwörter mehr teilen. Und ein schönes Endnutzer-Portal kann auf einer Admin-Konsole sitzen, in der jede Richtlinie ein JSON-Dokument ist. Teste beide Seiten.
Preis
Kriterium 21
Passung des Preismodells
Warum es zählt
IAM wird pro Nutzer, pro Identitätstyp, pro Funktionsmodul oder in Bündeln lizenziert, und dieselbe Organisation kostet unter jedem Modell sehr unterschiedlich. Externe Nutzer, Servicekonten, Kunden und die MFA-Hardware fallen in verschiedene Preiszeilen, und das Modell, das zu einem Unternehmen mit 500 Personen passt, passt selten zu einem Konzern mit 30.000 Identitäten und 200 Anwendungen.
Was du fragst
Beschreib deine Identitätspopulation ehrlich nach Typ und lass den Vendor sie unter jedem angebotenen Modell bepreisen, mit den Modulen, die du in den Kriterien oben identifiziert hast, und frag dann, was mit dem Preis passiert, wenn sich die externen Identitäten nach einer Übernahme verdoppeln.
Die Falle
Das Modell, das die Vergleichstabelle gewinnt, ist das, dessen Zähleinheit in deiner heutigen Population am kleinsten ist. Frag, wie gezählt und nachgezählt wird, und ob ein gesperrtes, aber für Audit-Zwecke aufbewahrtes Konto weiterhin als lizenziert zählt.
Kriterium 22
Preisplanbarkeit & versteckte Kosten
Warum es zählt
Das Angebot deckt Jahr eins beim heutigen Nutzerbestand und den heutigen Modulen. Die Kosten, die überraschen, kommen später: das Governance-Modul, das für das Audit doch nötig war, die Log-Aufbewahrung über das Grundfenster hinaus, die Premium-Support-Stufe, die die Migration brauchte, die Preiserhöhung bei der Verlängerung und die Professional Services, die niemand einzeln ausgewiesen hat.
Was du fragst
Bitte um eine schriftliche Liste von allem, was über die Lizenz hinaus Kosten erzeugen kann: Module, Aufbewahrungsstufen, API-Nutzung, Support-Stufen, MFA-Hardware, Onboarding-Services und die maximale Preiserhöhung bei Verlängerung. Frag einen Referenzkunden, wie seine Rechnung im zweiten Jahr gegen das erste Angebot aussah.
Die Falle
"Alles inklusive" bis die Rechnung für das Governance-Modul kommt, und das ist genau das Modul, nach dem der Auditor gefragt hat. Kann der Vendor die möglichen Zusatzkosten nicht auflisten, nimm an, dass es mehr sind, als dir gesagt wurde.
Kriterium 23
Angebotener Lizenzpreis
Warum es zählt
Am Ende braucht die Entscheidung eine Zahl pro Vendor, die sich vergleichen lässt: den angebotenen Lizenzpreis für die Konfiguration, die du wirklich betreiben wirst, über die Laufzeit, die du wirklich unterschreibst. Jedes andere Kriterium in diesem Katalog fließt ein, wie viel diese Zahl wert ist; dieses sorgt dafür, dass sie existiert und vergleichbar ist.
Was du fragst
Bitte jeden Vendor um ein verbindliches schriftliches Angebot für denselben Umfang: Identitätszahlen nach Typ, die in den Kriterien oben identifizierten Module, Aufbewahrung, Support-Stufe, Onboarding- und Migrationsleistungen und Laufzeit, mit Jahrespreis und Dreijahressumme getrennt ausgewiesen.
Die Falle
Angebote mit unterschiedlichem Umfang lassen sich nicht vergleichen, und Vendoren wissen das. Ein Angebot enthält Governance, das nächste schließt externe Nutzer aus, das dritte bündelt MFA-Hardware. Gleiche den Umfang ab, bevor du die Zahl vergleichst, sonst ist das günstigste Angebot das, das am meisten weggelassen hat.
Welche Pflicht welches Kriterium abdeckt
Die Regulatorik-Karte dieses Katalogs: die Pflicht, ihre Quelle und die Kriterien, die sie abdecken. Damit zeigst du dem Auditor, dass die Anforderungsliste aus den Regeln kommt, nicht aus einer Anbieterpräsentation.
| Pflicht | Quelle | Abgedeckt durch |
|---|---|---|
| Multi-Faktor-Authentifizierung und Zugriffskontrolle als geforderte Risikomanagementmaßnahmen | NIS2 Art. 21(2)(i), (j) | |
| Sicherheit der Lieferkette, einschließlich der Sicherheit von IKT-Dienstleistern | NIS2 Art. 21(2)(d) | |
| Bewältigung und Meldung von Vorfällen binnen 24 Stunden, 72 Stunden und einem Monat, was verwertbare Identitätsnachweise voraussetzt | NIS2 Art. 21(2)(b), Art. 23 | |
| IKT-Drittparteirisiko: Informationsregister und Exit-Strategien für kritische Dienste | DORA Art. 28 | |
| Vertragliche Bestimmungen mit IKT-Drittdienstleistern, einschließlich Datenstandort und Kündigungsrechten | DORA Art. 30 | |
| Identifizierung, Authentifizierung und Zugriffsverwaltung für kritische IKT-Systeme | DORA Art. 9 | |
| Auftragsverarbeitungsvertrag und Sicherheit der Verarbeitung für Identitätsdaten der Beschäftigten | GDPR Art. 28 and Art. 32 | |
| Leitungsorgane überwachen die Maßnahmen, und die Identity-Plattform wird genutzt statt umgangen | NIS2 Art. 20 |
Der Fragebogen
Alle Anbieterfragen dieses Katalogs in einer Liste, in der Reihenfolge der Kriterien. Stell jedem Anbieter dieselben Fragen im selben Wortlaut und schreib die Antworten nebeneinander.
- SSO- / SAML- / OIDC-Integration
Gib dem Vendor deine echte Anwendungsliste mit den zehn sperrigsten Systemen markiert, und frag für jedes einzeln, wie SSO funktionieren würde: nativ, über ein Gateway oder einen Agenten, oder gar nicht. Frag, welche Protokollfunktionen (signierte Assertions, verschlüsselte Assertions, Step-up-Authentifizierung) pro Anwendung unterstützt werden.
- Multi-Faktor-Authentifizierung (MFA)
Frag, ob FIDO2 oder Passkeys für eine Gruppe als einzig zulässiger Faktor erzwungen werden können, mit gesperrten statt nur nachrangigen schwächeren Faktoren, und was der Rückfallweg ist, wenn ein Nutzer seinen Schlüssel verloren hat.
- Rollenbasierte Zugriffssteuerung (RBAC)
Frag, wie Rollen modelliert werden (Hierarchien, Vererbung, anwendungsspezifische Rollen), ob eine Rolle mit Zeitlimit und Verantwortlichem zugewiesen werden kann, wie Berechtigungen außerhalb einer Rolle erkannt werden, und wie der Bericht aussieht, der jeden Nutzer einer Rolle mit Datum und Genehmiger auflistet.
- SCIM-Provisionierung / Lifecycle-Management
Bitte um eine Live-Vorführung eines Leaver-Ereignisses: eine Statusänderung im HR-System, und dann stoppe die Zeit, bis das Konto gesperrt, die Sessions beendet und der Zugriff in den angebundenen Anwendungen entfernt ist. Frag, welche deiner Anwendungen SCIM unterstützen und welche einen eigenen Konnektor brauchen.
- Verzeichnisintegration (AD, LDAP)
Frag, welches Verzeichnis die Plattform für welche Attribute als führend behandelt, wie eine Änderung in beide Richtungen fließt und wie schnell, was passiert, wenn beide sich widersprechen, und ob domänengebundene Rechner und Kerberos-abhängige Anwendungen weiterlaufen, wenn die neue Plattform vor dem Verzeichnis steht.
- Privileged Access Management (PAM)
Frag, welche privilegierten Kontotypen die Plattform nativ verwalten kann (Verwahrung, Rotation, zeitlich begrenzte Erhöhung, Session-Aufzeichnung), welche ein separates PAM-Produkt brauchen und wie beide integrieren, und wie die eigenen Admin-Konten der Plattform geschützt sind, inklusive Break-Glass-Zugang, wenn SSO selbst ausfällt.
- Identity-Governance & Zugriffszertifizierung
Lass dir in der Demo eine Rezertifizierungskampagne zeigen: Abgrenzung nach Anwendung oder Rolle, die Ansicht des Prüfers, was mit einer abgelehnten Berechtigung passiert, und den Bericht, der dabei entsteht. Frag, ob der Bericht exportierbar ist und wie lange er aufbewahrt wird.
- Unterstützung für Zero-Trust-Architektur
Frag, welche Signale in eine Zugriffsrichtlinie einfließen können (Gerätekonformität, Standort, Risikowert aus EDR oder SIEM, Authentifizierungsstärke), ob eine Session mittendrin widerrufen werden kann, wenn sich ein Signal ändert, und wie eine Richtlinie für eine Anwendung formuliert wird, die on premises hinter keinem Proxy liegt.
- Vollständigkeit von Audit-Trail & Zugriffsprotokollen
Frag, welche Ereignisse protokolliert werden (erfolgreiche und fehlgeschlagene Anmeldungen, Berechtigungsänderungen, Admin-Aktionen, Richtlinienänderungen), wie lange sie in der Grundstufe aufbewahrt werden, ob das Log selbst manipulationssicher ist, und ob ein vollständiger, lückenloser Export in deinen eigenen Speicher oder dein SIEM enthalten ist oder ein Zusatzmodul. Lass dir das Exportformat zeigen.
- Durchsetzung der Funktionstrennung
Frag, ob konfliktäre Berechtigungskombinationen anwendungsübergreifend definiert werden können, ob eine Anfrage, die einen Konflikt erzeugen würde, blockiert oder in eine Ausnahmegenehmigung geleitet wird, wie bestehende Konflikte berichtet werden, und ob die Konfliktregeln die Transaktionsebene des ERP abdecken oder nur Rollen auf Anwendungsebene.
- DSGVO- / Data-Residency-Compliance
Frag, wo Verzeichnis, Logs und Backups gespeichert werden, ob die EU-Region Standard oder eine kostenpflichtige Option ist, aus welchen Ländern Support- und Betriebspersonal des Vendors auf Mandantendaten zugreifen kann, und nach dem Auftragsverarbeitungsvertrag und der Liste der Unterauftragsverarbeiter mit Standorten.
- SOC-2- / ISO-27001-Zertifizierung
Bitte um den aktuellen SOC-2-Typ-II-Bericht und das ISO-27001-Zertifikat mit Erklärung zur Anwendbarkeit, prüfe den Scope auf die Services und Regionen, die du nutzen wirst, und frag, wie der Vendor seinen letzten erheblichen Sicherheitsvorfall behandelt hat und wie Kunden informiert wurden.
- NIS2- / DORA-Reife
Frag, welche Berichte die Plattform erzeugt, die auf NIS2 Artikel 21 und die Zugriffskontroll-Erwartungen von DORA abbilden, ob der Vendor ein DORA-Vertragsaddendum mit Prüf- und Exit-Klauseln anbietet, und nach zwei Referenzkunden unter NIS2- oder DORA-Aufsicht, die mit der Plattform ein Audit durchlaufen haben.
- Breach-Erkennung & Alarmierung bei auffälligen Logins
Frag, welche auffälligen Anmeldemuster von Haus aus erkannt werden, wie eine Erkennung in Echtzeit dein SIEM oder SOC erreicht, ob eine riskante Session automatisch herausgefordert oder beendet werden kann, und nach der False-Positive-Erfahrung eines Referenzkunden im ersten Monat.
- API-Security & OAuth-2.0-Unterstützung
Frag, welche OAuth-2.0- und OIDC-Flows unterstützt werden, wie Maschinen- und Service-Identitäten ausgestellt, rotiert und widerrufen werden, ob Token-Lebensdauern und Scopes pro Client erzwungen werden können, und wie die eigenen APIs der Plattform gegen den Missbrauch eines Admin-Tokens geschützt sind.
- Lizenzkosten pro Nutzer (3-Jahres-TCO)
Bitte um eine vollständige Preiskalkulation mit deinen echten Zahlen: Beschäftigte, externe Nutzer, Service- und Maschinenidentitäten, dazu die MFA- und Governance-Module, die du wirklich brauchst, über drei Jahre und inklusive Preisdeckel bei Verlängerung.
- Implementierungs- & Migrationsaufwand
Bitte um den Migrationsplan für deine Anwendungsliste mit Aufwand pro Integrationstyp, frag, wie Nutzer und MFA-Registrierungen ohne Massen-Neuregistrierung migriert werden, wie lange alte und neue Plattform parallel laufen können, und was das Projekt eines vergleichbaren Kunden tatsächlich in Monaten und Personentagen gekostet hat.
- Anbieterabhängigkeit & Exit-Portabilität
Frag, wie Nutzer, Gruppen, Anmeldedaten und Anwendungskonfigurationen in einem Standardformat exportiert werden können, was ein Wechsel zu einem anderen Anbieter bedeuten würde, und ob der Vendor je einem Kunden beim Verlassen geholfen hat.
- Roadmap & Enterprise-Skalierbarkeit
Bitte um die Zwölfmonats-Roadmap unter NDA und prüfe sie gegen deine eigenen Pläne, frag, welche Roadmap-Punkte des letzten Jahres ausgeliefert wurden, und frag nach dem größten Tenant auf der Plattform in Identitäten und Anwendungen und wie lange ein vollständiger Verzeichnis-Sync in dieser Größe dauert.
- Nutzerakzeptanz & Admin-Experience
Lass im Pilot zwei deiner eigenen Administratoren und zehn deiner Nutzer die Aufgaben eines normalen Tages durch das Produkt erledigen, zähl die zusätzlichen Schritte und die Helpdesk-Tickets, und frag den Vendor nach der Abschlussquote der MFA-Registrierung und dem Helpdesk-Ticketvolumen eines vergleichbaren Rollouts.
- Passung des Preismodells
Beschreib deine Identitätspopulation ehrlich nach Typ und lass den Vendor sie unter jedem angebotenen Modell bepreisen, mit den Modulen, die du in den Kriterien oben identifiziert hast, und frag dann, was mit dem Preis passiert, wenn sich die externen Identitäten nach einer Übernahme verdoppeln.
- Preisplanbarkeit & versteckte Kosten
Bitte um eine schriftliche Liste von allem, was über die Lizenz hinaus Kosten erzeugen kann: Module, Aufbewahrungsstufen, API-Nutzung, Support-Stufen, MFA-Hardware, Onboarding-Services und die maximale Preiserhöhung bei Verlängerung. Frag einen Referenzkunden, wie seine Rechnung im zweiten Jahr gegen das erste Angebot aussah.
- Angebotener Lizenzpreis
Bitte jeden Vendor um ein verbindliches schriftliches Angebot für denselben Umfang: Identitätszahlen nach Typ, die in den Kriterien oben identifizierten Module, Aufbewahrung, Support-Stufe, Onboarding- und Migrationsleistungen und Laufzeit, mit Jahrespreis und Dreijahressumme getrennt ausgewiesen.
Diese Kriterien sind der Anfang. Nicht die Entscheidung.
Eine Kriterienliste sagt dir, worauf du schauen musst. Sie gewichtet die Kriterien nicht gegen deine Situation, prüft sie nicht gegen deine harten Grenzen und macht kein Memo daraus, das dein Vorstand und dein Auditor lesen können. DecisionOS nimmt diese Kriterien, gewichtet sie für deine Entscheidung und baut daraus eine belastbare Akte. In Tagen, nicht Monaten.
Weiter mit dem Entscheidungs-Guide
Verwandte Kriterienkataloge
- Privileged Access ManagementPAM-Auswahl: die Kriterien, die unter NIS2 und DORA zählen12 Kriterien
- Endpoint Detection and ResponseEDR-Auswahl: die Kriterien, die unter NIS2 und DORA zählen23 Kriterien
- Souveräne Cloud und Cloud-PlattformenSouveräne Cloud: die Auswahlkriterien, die unter NIS2, DORA und DSGVO zählen23 Kriterien
Diesen Katalog drucken oder als PDF fürs Meeting sichern
