DORA Identity Controls in 2026: The Six Access Gaps Supervisors Are Checking Now

DORA enforcement is no longer theoretical. In 2026, supervisors are acting on identity and access failures. Here are the six gaps they find most often - and the evidence you need to close them.

10 min read · Last updated June 2026

The grace period is over. DORA has applied since 17 January 2025, and in 2026 European regulators have shifted from reviewing documentation to demanding real-time evidence of resilience. [1] That shift is not rhetorical. [1] that flag inconsistencies in ICT registers immediately. The Q1 2026 Register of Information submission was the first hard supervisory test, and [2] - identifying providers absent from registers, inconsistencies with incident-reporting history, and sub-outsourcing chains that don't add up.

For compliance leaders and CISOs in EU/DACH financial entities, the practical question is no longer whether you comply. It's what evidence a supervisor will ask for when they arrive - and whether you can produce it in hours, not weeks.

Identity and access controls sit at the intersection of almost every DORA pillar. They determine who can reach critical systems, who can act on them, and whether you can prove it. Yet they remain the area where the most exploitable gaps persist. This post maps the six identity control failures supervisors find most often, the concrete control each one requires, and the evidence artifact that closes the finding.


Why Identity Is DORA's Sharpest Edge

DORA's Article 9 makes credential security and access control a binding financial risk control, with supervisory consequences for institutions that fall short. [3] Articles 9(4)(c) and 9(4)(d) are explicit: least-privilege access, strong authentication, and cryptographic key protection are legal obligations - not best-practice recommendations.

[4]: you must track external identities accessing critical systems. The RTS on ICT risk management adds specificity on access management rights, anomaly detection, and segregation of duties. And [4], especially after offboarding, role changes, or contract terminations.

The incident-reporting clock makes identity failures acutely dangerous. Under DORA, a major incident triggers a three-stage reporting cadence: an initial notification within 4 hours of classification (and no later than 24 hours from detection), an intermediate report within 72 hours, and a final report within one month. [5] Compare that to NIS2's 24-hour initial window - DORA's 4-hour clock is operationally demanding and leaves no room for manual access investigations at the moment of crisis.

Isometric diagram of a financial institution's access governance layer: a central identity hub connecting to cloud apps, on-premise systems, and third-party vendor portals, with audit trail logs flowing into a compliance dashboard. Clean, professional, minimal color palette.

The Six Identity Gaps Supervisors Find Most Often

Gap 1: Incomplete Access Governance Over ICT Third Parties

This is the gap that catches the most institutions off guard. [2], and access governance for ICT third-party staff is a core element of it. [4] - but most institutions manage vendor access through a mix of shared accounts, manually issued credentials, and informal offboarding.

The problem compounds when vendors change staff. A consultant rotates off an engagement; their account stays active. A managed-service provider replaces a technician; the old credentials are never revoked. [6]

The control: Every ICT third-party identity - human and non-human - must be inventoried, scoped to minimum necessary access, and subject to the same review cycle as internal privileged accounts.

Evidence a supervisor expects:

  • A complete inventory of third-party accounts, mapped to the relevant ICT arrangement in your Register of Information
  • Time-bounded access grants with documented expiry and revocation logs
  • Periodic access certification records showing third-party accounts were reviewed and attested - not just created

Gap 2: Weak Privileged Access Controls

[7] The regulation requires that privileged access be documented, scoped to role, and monitored - but many financial entities still rely on shared admin credentials, standing access to production environments, and PAM tools that cover only a fraction of their app stack.

The risk is concrete. Stolen credentials are the single largest initial access vector in 2025, accounting for 22% of all data breaches, per Verizon's Data Breach Investigations Report. [3] For financial institutions, the sector-specific cost of a credential-related breach averages $5.56 million per incident, according to IBM's Cost of a Data Breach Report. [3]

[6] Undocumented break-glass accounts are a compliance risk under both the DORA text and supervisory guidance.

The control: Privileged accounts - including service accounts, admin accounts, and break-glass accounts - must be inventoried, governed under least-privilege, and subject to session logging.

Evidence a supervisor expects:

  • A privileged account inventory with owner, purpose, and permission scope for every account
  • Session logs for privileged access to critical systems, retained and tamper-evident
  • Evidence that break-glass accounts are documented and that post-use reviews are conducted

Gap 3: Missing or Stale Access Certifications

[4] In practice, most financial entities conduct access reviews either annually (too infrequent) or not at all for non-SCIM applications. The result: access certifications that cover the IdP-connected apps but leave the long tail of SaaS tools, internal portals, and legacy systems ungoverned.

A supervisor examining your access governance posture will ask for certification records - not just a policy that says reviews happen. [3]

The control: Continuous access certification across the full application stack - not just IdP-connected apps - with timestamped records of who reviewed, what decision was made, and when.

Evidence a supervisor expects:

  • Certification campaign records with reviewer identity, decision timestamp, and outcome
  • Evidence that certifications cover non-SCIM and non-API-connected applications
  • Escalation records for access that was flagged and revoked

Gap 4: No Segregation of Duties Evidence

[8] SoD is not just a policy requirement - it's an evidential one. Supervisors will ask whether any single user can complete a critical transaction alone, and whether your system enforces that constraint or merely documents it.

Many institutions have SoD policies on paper but no technical enforcement. A developer with both write access to production code and deployment rights. A finance user who can both create and approve payments. These are the patterns supervisors look for.

The control: SoD rules must be technically enforced - not just documented - and violations must generate alerts with documented remediation.

Evidence a supervisor expects:

  • A SoD rule matrix mapped to critical business functions
  • System-generated SoD violation reports with remediation records
  • Evidence that conflicting access combinations are blocked or require compensating controls

Gap 5: Orphaned Access After Role or Vendor Changes

Orphaned accounts - access that persists after an employee changes role, leaves the organization, or a vendor relationship ends - are one of the most common findings in any identity audit. Under DORA, they are also one of the clearest indicators of inadequate ICT risk management.

[4] But in organizations that rely on manual provisioning, ticket queues, and SSO-only automation, offboarding is partial by design. The IdP account is disabled; the downstream app access - Notion, GitHub, Jira, Figma, the internal risk portal - stays active.

The control: Automated, complete offboarding across the full app stack, with deprovisioning logs that prove access was removed from every system - not just the IdP.

Evidence a supervisor expects:

  • Deprovisioning logs timestamped to within hours of the triggering event (role change, termination, contract end)
  • Evidence that deprovisioning covers non-SCIM applications
  • Periodic orphaned-account scans with remediation records

Gap 6: The SSO Coverage Illusion

This is the gap that catches fast-growing financial entities most off guard. SSO is not IGA. An SSO platform authenticates users to the apps it knows about - typically the 10-20 apps that support SAML or OIDC and are formally integrated. The other 40-60 apps in a typical SaaS stack are invisible to it.

[4] - not just the ones your IdP can see. An SSO-only approach leaves a structural gap: no provisioning records, no deprovisioning evidence, no access certification capability for the long tail of tools where sensitive data actually lives.

The control: IGA coverage that extends beyond SCIM-capable apps to every application in the stack - including tools without APIs or enterprise-plan integrations.

Evidence a supervisor expects:

  • An application inventory that maps every tool to its access governance method
  • Provisioning and deprovisioning records for non-SCIM applications
  • Access certification records that cover the full stack, not just IdP-connected apps

What Continuous Governance Looks Like in Practice

The pattern across all six gaps is the same: point-in-time controls produce point-in-time evidence. Supervisors in 2026 are not satisfied with an annual access review spreadsheet or a policy document that describes what should happen. [9]

Continuous governance means:

  • Automated provisioning and deprovisioning that fires on HR events - not on IT tickets - and covers every app, not just the SCIM-connected ones
  • Continuous access certification that runs on a rolling basis, not annually, with timestamped records that survive an audit
  • A complete audit trail across the full app stack - including the tools your IdP doesn't govern - so that when a supervisor asks "who had access to this system on this date," the answer is retrievable in minutes
  • SoD enforcement that is technical, not documentary - violations blocked or flagged in real time, with remediation records attached

This is exactly the gap that SSO-only and legacy IGA approaches leave open. SSO governs authentication. Legacy IGA governs the 20% of apps that support SCIM. Neither produces the complete, continuous, audit-proof trail that DORA supervisors now expect across the full stack.


The DACH Dimension

For institutions supervised by BaFin, FMA (Austria), or FINMA-adjacent entities, the identity control requirements carry additional weight. In January 2026, Germany's BaFin issued non-binding guidance clarifying how AI-based systems must be integrated into DORA-compliant ICT risk management frameworks, including documentation of access controls for AI applications. [10] BaFin's existing BAIT supervisory requirements for IT already set a high bar for access governance - DORA raises it further and makes it directly applicable without national transposition.

[11], with competent authorities required to submit registers to the ESAs by 31 March 2026. The identity governance evidence that supports your Register of Information - third-party account inventories, access scope documentation, deprovisioning records - is the same evidence that underpins your ICT risk management framework assessment.


DORA Identity Controls Readiness Checklist

Use this checklist to assess your current posture against the six gaps above. Each item maps to a specific DORA article or RTS requirement.


The Evidence Standard Has Changed

The practical reality of DORA in 2026 is simple: [12] For identity and access controls, that means a continuous, automated, audit-proof trail across the full application stack - including the apps that SSO doesn't govern and legacy IGA never reached.

The institutions that will navigate 2026 supervisory cycles with confidence are the ones that have replaced manual ticket queues and spreadsheet-driven reviews with continuous governance: automated lifecycle management that fires on HR events, access certifications that run on a rolling basis, and deprovisioning that covers every app - not just the ones that support SCIM.

That is what Iden is built to deliver. Universal app coverage - SCIM, API, or neither - means the audit trail is complete. Policy-driven workflows mean the evidence is generated automatically, not assembled under pressure when a supervisor asks. And because Iden deploys in days rather than months, you can close the gaps before the next examination cycle reaches you.

For a deeper look at how the 2026 enforcement posture is changing, see our post on DORA Enforcement Gets Real in 2026 and our guide to IGA Solutions for Financial Services.

Related reading