DORA Identity Controls 2026: Die sechs Zugriffslücken im Prüferfokus
DORA-Enforcement ist keine Theorie mehr. 2026 greifen Aufsichtsbehörden bei Identity- und Access-Mängeln aktiv durch. Hier sind die sechs Lücken, die sie am häufigsten finden - und die Belege, die Sie brauchen, um sie zu schließen.
9 Min. Lesezeit · Zuletzt aktualisiert Juni 2026
Die Schonfrist ist vorbei. DORA gilt seit dem 17. Januar 2025, und 2026 sind europäische Aufsichtsbehörden dazu übergegangen, nicht mehr nur Dokumentation zu prüfen, sondern Echtzeit-Belege zur Resilienz einzufordern. [1] Diese Verschiebung ist keine Rhetorik. [1], die Inkonsistenzen in ICT-Registern sofort aufdecken. Die Einreichung des Register of Information im ersten Quartal 2026 war der erste harte Aufsichtstest, und [2] - mit Identifizierung von Anbietern, die in Registern fehlen, Inkonsistenzen mit der Incident-Reporting-Historie und Subauslagerungsketten, die nicht schlüssig sind.
Für Compliance-Verantwortliche und CISOs in EU/DACH-Finanzinstituten lautet die praktische Frage nicht mehr ob Sie compliant sind. Sondern welche Belege eine Aufsichtsbehörde bei einer Prüfung einfordert - und ob Sie diese in Stunden, nicht in Wochen, vorlegen können.
Identity- und Access-Controls stehen an der Schnittstelle nahezu jeder DORA-Säule. Sie bestimmen, wer kritische Systeme erreichen kann, wer auf ihnen handeln darf - und ob Sie das nachweisen können. Dennoch sind sie der Bereich, in dem die gravierendsten Lücken fortbestehen. Dieser Beitrag beschreibt die sechs Identity-Control-Mängel, die Aufsichtsbehörden am häufigsten feststellen, die jeweils erforderliche Maßnahme und den Beleg, der den Befund schließt.
Warum Identity das schärfste Instrument von DORA ist
Artikel 9 DORA macht Credential-Sicherheit und Zugriffskontrolle zu einer verbindlichen finanziellen Risikokontrolle - mit aufsichtsrechtlichen Konsequenzen für Institute, die dahinter zurückbleiben. [3] Artikel 9(4)(c) und 9(4)(d) sind eindeutig: Least-Privilege-Zugriff, starke Authentifizierung und der Schutz kryptografischer Schlüssel sind gesetzliche Pflichten - keine Best-Practice-Empfehlungen.
[4]: Sie müssen externe Identitäten, die auf kritische Systeme zugreifen, nachverfolgen. Die RTS zu ICT-Risikomanagement konkretisiert die Anforderungen an Access-Management-Rechte, Anomalieerkennung und Funktionstrennung. Und [4], insbesondere nach Offboarding, Rollenwechseln oder Vertragsbeendigungen.
Der Incident-Reporting-Takt macht Identity-Mängel besonders gefährlich. Unter DORA löst ein schwerwiegender Vorfall eine dreistufige Meldepflicht aus: eine erste Meldung innerhalb von 4 Stunden nach Klassifizierung (spätestens jedoch 24 Stunden nach Entdeckung), einen Zwischenbericht innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats. [5] Zum Vergleich: NIS2 sieht ein 24-Stunden-Fenster für die Erstmeldung vor - DORAʼs 4-Stunden-Takt ist operativ anspruchsvoll und lässt im Krisenmoment keinen Raum für manuelle Zugriffsuntersuchungen.
Die sechs Identity-Lücken, die Aufsichtsbehörden am häufigsten finden
Lücke 1: Unvollständige Access-Governance für ICT-Drittanbieter
Dies ist die Lücke, die die meisten Institute unvorbereitet trifft. [2], und die Access-Governance für ICT-Drittanbieter-Personal ist ein zentrales Element davon. [4] - doch die meisten Institute verwalten den Anbieterzugriff über eine Mischung aus gemeinsam genutzten Konten, manuell ausgestellten Zugangsdaten und informellem Offboarding.
Das Problem verschärft sich, wenn Anbieter ihr Personal wechseln. Ein Berater verlässt ein Projekt; sein Konto bleibt aktiv. Ein Managed-Service-Provider tauscht einen Techniker aus; die alten Zugangsdaten werden nie entzogen. [6]
Die Maßnahme: Jede ICT-Drittanbieter-Identität - menschlich und nicht-menschlich - muss inventarisiert, auf den minimal notwendigen Zugriff beschränkt und demselben Review-Zyklus wie interne privilegierte Konten unterworfen werden.
Belege, die eine Aufsichtsbehörde erwartet:
- Ein vollständiges Inventar der Drittanbieter-Konten, zugeordnet zur jeweiligen ICT-Vereinbarung in Ihrem Register of Information
- Zeitlich befristete Zugriffsgewährungen mit dokumentiertem Ablaufdatum und Entzugsprotokollen
- Periodische Access-Certification-Nachweise, die belegen, dass Drittanbieter-Konten geprüft und bestätigt wurden - nicht nur angelegt
Lücke 2: Schwache Privileged-Access-Controls
[7] Die Verordnung verlangt, dass privilegierter Zugriff dokumentiert, auf die Rolle beschränkt und überwacht wird - doch viele Finanzinstitute verlassen sich weiterhin auf gemeinsam genutzte Admin-Zugangsdaten, dauerhaften Zugriff auf Produktionsumgebungen und PAM-Tools, die nur einen Bruchteil ihres Applikations-Stacks abdecken.
Das Risiko ist konkret. Gestohlene Zugangsdaten sind 2025 der mit Abstand häufigste initiale Angriffsvektor und stehen laut dem Verizon Data Breach Investigations Report für 22 % aller Datenpannen. [3] Für Finanzinstitute belaufen sich die branchenspezifischen Kosten eines Credential-bezogenen Sicherheitsvorfalls laut IBMʼs Cost of a Data Breach Report im Durchschnitt auf 5,56 Millionen US-Dollar pro Vorfall. [3]
[6] Undokumentierte Break-Glass-Konten sind ein Compliance-Risiko sowohl nach dem DORA-Text als auch nach den Aufsichtsleitlinien.
Die Maßnahme: Privilegierte Konten - einschließlich Service-Accounts, Admin-Konten und Break-Glass-Konten - müssen inventarisiert, nach dem Least-Privilege-Prinzip verwaltet und mit Session-Logging versehen werden.
Belege, die eine Aufsichtsbehörde erwartet:
- Ein Inventar privilegierter Konten mit Eigentümer, Zweck und Berechtigungsumfang für jedes Konto
- Session-Logs für privilegierten Zugriff auf kritische Systeme, aufbewahrt und manipulationssicher
- Nachweise, dass Break-Glass-Konten dokumentiert sind und nach jeder Nutzung eine Nachprüfung erfolgt
Lücke 3: Fehlende oder veraltete Access-Certifications
[4] In der Praxis führen die meisten Finanzinstitute Access-Reviews entweder jährlich durch - was zu selten ist - oder gar nicht für Anwendungen ohne SCIM-Anbindung. Das Ergebnis: Access-Certifications, die die IdP-verbundenen Apps abdecken, aber den langen Schwanz an SaaS-Tools, internen Portalen und Legacy-Systemen ungoverned lassen.
Eine Aufsichtsbehörde, die Ihre Access-Governance-Posture prüft, wird Zertifizierungsnachweise verlangen - nicht nur eine Richtlinie, die besagt, dass Reviews stattfinden. [3]
Die Maßnahme: Kontinuierliche Access-Certification über den gesamten Applikations-Stack - nicht nur IdP-verbundene Apps - mit zeitgestempelten Nachweisen darüber, wer geprüft hat, welche Entscheidung getroffen wurde und wann.
Belege, die eine Aufsichtsbehörde erwartet:
- Certification-Campaign-Nachweise mit Reviewer-Identität, Entscheidungs-Zeitstempel und Ergebnis
- Belege, dass Certifications auch Anwendungen ohne SCIM- oder API-Anbindung umfassen
- Eskalationsnachweise für Zugriffe, die markiert und entzogen wurden
Lücke 4: Keine Belege zur Funktionstrennung (Segregation of Duties)
[8] SoD ist nicht nur eine Richtlinienanforderung - sie ist eine Nachweispflicht. Aufsichtsbehörden werden fragen, ob ein einzelner User eine kritische Transaktion allein abschließen kann und ob Ihr System diese Einschränkung technisch durchsetzt oder lediglich dokumentiert.
Viele Institute haben SoD-Richtlinien auf dem Papier, aber keine technische Durchsetzung. Ein Entwickler mit sowohl Schreibzugriff auf Produktionscode als auch Deployment-Rechten. Ein Finance-User, der Zahlungen sowohl anlegen als auch genehmigen kann. Das sind die Muster, nach denen Aufsichtsbehörden suchen.
Die Maßnahme: SoD-Regeln müssen technisch durchgesetzt werden - nicht nur dokumentiert - und Verstöße müssen Alerts mit dokumentierter Behebung auslösen.
Belege, die eine Aufsichtsbehörde erwartet:
- Eine SoD-Regelmatrix, die kritischen Geschäftsfunktionen zugeordnet ist
- Systemgenerierte SoD-Verstoßberichte mit Behebungsnachweisen
- Belege, dass konflikthafte Zugriffskombinationen blockiert werden oder kompensierende Kontrollen erfordern
Lücke 5: Verwaiste Zugriffe nach Rollen- oder Anbieterwechseln
Verwaiste Konten - Zugriffe, die bestehen bleiben, nachdem ein Mitarbeiter die Rolle wechselt, das Unternehmen verlässt oder eine Anbieterbeziehung endet - gehören zu den häufigsten Befunden in jedem Identity-Audit. Unter DORA sind sie zugleich einer der deutlichsten Indikatoren für unzureichendes ICT-Risikomanagement.
[4] Doch in Organisationen, die auf manuelle Provisionierung, Ticket-Queues und SSO-only-Automatisierung setzen, ist Offboarding strukturell unvollständig. Das IdP-Konto wird deaktiviert; der nachgelagerte App-Zugriff - Notion, GitHub, Jira, Figma, das interne Risikoportal - bleibt aktiv.
Die Maßnahme: Automatisiertes, vollständiges Offboarding über den gesamten Applikations-Stack, mit Deprovisionierungs-Logs, die belegen, dass der Zugriff aus jedem System entfernt wurde - nicht nur aus dem IdP.
Belege, die eine Aufsichtsbehörde erwartet:
- Deprovisionierungs-Logs mit Zeitstempel innerhalb weniger Stunden nach dem auslösenden Ereignis (Rollenwechsel, Kündigung, Vertragsende)
- Belege, dass die Deprovisionierung auch Anwendungen ohne SCIM-Anbindung umfasst
- Regelmäßige Scans nach verwaisten Konten mit Behebungsnachweisen
Lücke 6: Die SSO-Coverage-Illusion
Dies ist die Lücke, die schnell wachsende Finanzinstitute am häufigsten unvorbereitet trifft. SSO ist nicht IGA. Eine SSO-Plattform authentifiziert User bei den Apps, die sie kennt - typischerweise die 10 bis 20 Apps, die SAML oder OIDC unterstützen und formal integriert sind. Die anderen 40 bis 60 Apps in einem typischen SaaS-Stack sind für sie unsichtbar.
[4] - nicht nur die, die Ihr IdP sehen kann. Ein reiner SSO-Ansatz hinterlässt eine strukturelle Lücke: keine Provisionierungsnachweise, keine Deprovisionierungsbelege, keine Access-Certification-Fähigkeit für den langen Schwanz an Tools, in denen sensible Daten tatsächlich liegen.
Die Maßnahme: IGA-Abdeckung, die über SCIM-fähige Apps hinausgeht und jede Anwendung im Stack erfasst - einschließlich Tools ohne APIs oder Enterprise-Plan-Integrationen.
Belege, die eine Aufsichtsbehörde erwartet:
- Ein Applikationsinventar, das jedes Tool seiner Access-Governance-Methode zuordnet
- Provisionierungs- und Deprovisionierungsnachweise für Anwendungen ohne SCIM-Anbindung
- Access-Certification-Nachweise, die den gesamten Stack abdecken - nicht nur IdP-verbundene Apps
Wie kontinuierliche Governance in der Praxis aussieht
Das Muster hinter allen sechs Lücken ist dasselbe: Stichtagskontrollen erzeugen Stichtagsbelege. Aufsichtsbehörden sind 2026 nicht mit einer jährlichen Access-Review-Tabelle oder einem Richtliniendokument zufrieden, das beschreibt, was eigentlich passieren sollte. [9]
Kontinuierliche Governance bedeutet:
- Automatisierte Provisionierung und Deprovisionierung, die durch HR-Ereignisse ausgelöst wird - nicht durch IT-Tickets - und jede App abdeckt, nicht nur die SCIM-verbundenen
- Kontinuierliche Access-Certification, die fortlaufend läuft, nicht jährlich, mit zeitgestempelten Nachweisen, die einer Prüfung standhalten
- Ein vollständiger Audit-Trail über den gesamten Applikations-Stack - einschließlich der Tools, die Ihr IdP nicht verwaltet - sodass die Antwort auf die Frage "Wer hatte an diesem Datum Zugriff auf dieses System?" in Minuten abrufbar ist
- Technisch durchgesetzte SoD - Verstöße werden in Echtzeit blockiert oder markiert, mit angehängten Behebungsnachweisen
Genau diese Lücke hinterlassen SSO-only- und Legacy-IGA-Ansätze. SSO regelt die Authentifizierung. Legacy-IGA regelt die 20 % der Apps, die SCIM unterstützen. Keiner von beiden erzeugt den vollständigen, kontinuierlichen, revisionssicheren Audit-Trail, den DORA-Aufsichtsbehörden heute über den gesamten Stack erwarten.
Die DACH-Dimension
Für Institute, die von der BaFin, der FMA (Österreich) oder FINMA-nahen Behörden beaufsichtigt werden, haben die Identity-Control-Anforderungen zusätzliches Gewicht. Im Januar 2026 veröffentlichte die BaFin eine unverbindliche Orientierungshilfe, die klarstellt, wie KI-basierte Systeme in DORA-konforme ICT-Risikomanagement-Rahmenwerke zu integrieren sind - einschließlich der Dokumentation von Zugriffskontrollen für KI-Anwendungen. [10] Die bestehenden BAIT-Aufsichtsanforderungen der BaFin für IT setzen bereits eine hohe Messlatte für Access-Governance - DORA hebt diese weiter an und macht sie direkt anwendbar, ohne nationale Umsetzung.
[11], wobei die zuständigen Behörden die Register bis zum 31. März 2026 an die ESAs übermitteln mussten. Die Identity-Governance-Belege, die Ihr Register of Information stützen - Drittanbieter-Kontoinventare, Dokumentation des Zugriffsumfangs, Deprovisionierungsnachweise - sind dieselben Belege, die Ihr ICT-Risikomanagement-Framework-Assessment untermauern.
DORA Identity Controls - Readiness-Checkliste
Nutzen Sie diese Checkliste, um Ihre aktuelle Posture gegenüber den sechs oben genannten Lücken zu bewerten. Jeder Punkt ist einem konkreten DORA-Artikel oder einer RTS-Anforderung zugeordnet.
Der Beweisstandard hat sich verändert
Die praktische Realität von DORA im Jahr 2026 ist einfach: [12] Für Identity- und Access-Controls bedeutet das einen kontinuierlichen, automatisierten, revisionssicheren Audit-Trail über den gesamten Applikations-Stack - einschließlich der Apps, die SSO nicht verwaltet und Legacy-IGA nie erreicht hat.
Die Institute, die die Aufsichtszyklen 2026 souverän durchlaufen werden, sind jene, die manuelle Ticket-Queues und tabellengetriebene Reviews durch kontinuierliche Governance ersetzt haben: automatisiertes Lifecycle-Management, das durch HR-Ereignisse ausgelöst wird, Access-Certifications, die fortlaufend laufen, und Deprovisionierung, die jede App abdeckt - nicht nur die, die SCIM unterstützen.
Genau das ist es, wofür Iden gebaut wurde. Universelle App-Abdeckung - SCIM, API oder keines von beidem - sorgt dafür, dass der Audit-Trail vollständig ist. Policy-gesteuerte Workflows bedeuten, dass Belege automatisch generiert werden - nicht unter Druck zusammengestellt, wenn eine Aufsichtsbehörde fragt. Und da Iden in Tagen statt Monaten deployed wird, können Sie die Lücken schließen, bevor der nächste Prüfungszyklus Sie erreicht.
Einen tieferen Einblick in die Entwicklung der Enforcement-Posture 2026 finden Sie in unserem Beitrag zu DORA Enforcement wird 2026 ernst und unserem Leitfaden zu IGA-Lösungen für Finanzdienstleister.