DORA Enforcement Gets Real in 2026: Can Your Access Reviews Survive a Live Audit?

Executive summary. DORA became legally binding on 17 January 2025 for EU financial entities and many ICT service providers, but 2026 marks the shift from guidance to real enforcement. Regulators like BaFin will begin targeted DORA and NIS2 reviews in 2026, with BaFin launching DORA ICT-risk audits as early as Q1 2026^{1eba.europa.eu}. The question is no longer "Do we have an access policy?" but "Can we prove, right now, that every privileged access path is under control?"

This article breaks down what DORA actually changes for access governance, what a 2026 "live audit" looks like in practice, and why spreadsheets and SSO-only coverage won't meet regulatory demands.

From paperwork to proof: How DORA changes the audit game

For years, access reviews have amounted to compliance theater: exporting from a few core systems, assigning spreadsheets, and approving everything just before year-end.

DORA ends that approach.

A regulation for continuous risk, not annual checklists

DORA (Regulation (EU) 2022/2554) targets digital operational resilience-the ability to withstand ICT incidents without interrupting critical services. This has four big implications for your identity and access stack:

• Unified ICT risk management. DORA standardizes ICT risk obligations across banks, insurers, investment firms, payment institutions, replacing fragmented previous guidelines.^{1eba.europa.eu}
• Massive scope. Over 22,000 financial entities and ICT providers fall under DORA in the EU^2pwc.de-this is far-reaching regulation.
• Direct obligations for providers. Critical ICT third-party providers (CTPPs) now face EU-level supervision. Your providers' access controls are in scope for your audits, too.^{1eba.europa.eu}
• Evidence over narratives. Supervisors will use RTS/ITS templates and registers expecting on-demand, queryable access data-not PDF report packs.^{3eba.europa.eu}

Static, point-in-time attestations are out. Continuous, data-driven supervision is in.

2026: Shift to inspections

2024-2025 focused on technical standards, guidance, and gap assessments. In 2026:

• Firms and supervisors designate 2026 as the first real year for DORA examinations, with planned thematic reviews of ICT risk and vendor oversight.^4advisori.de
• BaFin and the Bundesbank already issued DORA guidance and implementation notes, clarifying coming audits.^{5gleisslutz.com}
• In 2026, reports will tie ICT governance directly to capital and risk assessments, making digital resilience a board-level issue.^{6eba.europa.eu}

Expect inspectors to dig into who can access what, how access is granted, how it's reviewed, and if you can prove it instantly.

Why access governance sits in DORA's critical path

DORA isn't an "access control regulation" by name. But if you read the text-Articles, RTS, guidance-identity and access governance are everywhere.

What DORA actually demands for access

Key points directly affecting access reviews:

• Protection & prevention (Article 9). Article 9 mandates continuous monitoring and control of ICT to prevent corruption, loss, or unauthorized data access^{7elvingerhoss.lu}-meaning you need an up-to-date view of access.
• Logging and audit trails. DORA's RTS require logging of logical and physical access in the ICT risk management framework^{8digital-operational-resilience.net}-privileged access included.
• Access rights principles. Access rights must follow need-to-know, least privilege, and segregation-of-duties per Article 9(4)(c) and RTS. Ad-hoc privilege creep equals non-compliance^{9riskpublishing.com}
• ICT third-party register. Maintain an exhaustive register of all ICT third-party service provider contracts, including access and security info^{10bundesbank.de}

If your reviews only cover some in-house systems and ignore SaaS, data platforms, and third-party consoles, you're missing both the spirit and now the letter of DORA.

Real-time audits require real-time data

Regulators are clear: they expect ongoing supervision - not static, annual reporting.

• ICT incidents must be classified and reported in standardized, structured formats.^{11regulation-dora.eu}
• Risk frameworks need near-real-time monitoring and anomaly detection, not annual registers.^12iomete.com

In identity: If you cannot answer, on demand, "Which privileged identities have access, via which paths, and when were they last reviewed?", you have a regulatory exposure.

Inside a 2026 DORA exam: What a "live access audit" looks like

Picture October 2026. Your institution is facing its DORA inspection.

Supervisors won't just ask for policies-they'll sit down with your CISO, IT, and Compliance leads and demand to see access governance in action.

The questions you'll get

Most institutions will face:

• Coverage:
  • "Show your complete inventory of systems within DORA scope-including SaaS, cloud, and key ICT providers."
  • "Which systems are centrally governed? Which need manual admin?"
• Access state:
  • "For this key platform, pull a real-time list of all privileged accounts-including service and machine identities."
  • "Show when those rights were last reviewed, by whom, and what changed."
• Lifecycle control:
  • "For a random joiner and leaver, show the full access lifecycle, with timestamps and approver decisions."
• Third-party risk:
  • "From your ICT third-party register, show who can admin provider consoles, and how rights are reviewed."
• Evidence integrity:
  • "Where are access review and provisioning logs? Are they immutable? Exportable?"

If your answer is "Give us a few days to compile that," you're not ready. DORA expects live, queryable evidence, not reports built on the fly.

Manual + SSO vs. continuous access governance

Most 50-2,000 employee financial companies today:

DORA will expose that gap in 2026.

Why manual reviews and SSO-only coverage won't survive DORA

Let's get blunt.

"We have SSO, so we're fine"

SSO tools like Okta or Entra ID solve authentication. They don't deliver identity governance:

• They typically automate access for only SCIM-enabled or SSO-integrated apps-often just 20% of your stack. Iden data shows most mid-market firms automate that minority, and provision the rest manually.
• SSO controls groups/roles, but DORA demands entitlement-level rights. Supervisors will drill into channels, repos, projects-where SCIM and SSO get watery.

SSO answers the login question, not the governance question.

"Our managers sign off on access once a year"

Annual spreadsheet certifications fail DORA for three core reasons:

1. Incomplete. Long-tail SaaS, business tools, and admin consoles get no review.
2. Unverifiable. CSVs and emails are easily edited, lost, or never matched to real access. There's no guarantee reviews used current data.
3. Not continuous. DORA expects real-time monitoring and rapid revocation, not annual cycles.

Supervisors just need to require live, system-of-record evidence-spreadsheets become obsolete.

"We'll fix it when DORA audits start"

This is dangerous thinking.

Most Member States have adopted DORA, with maximum administrative fines commonly up to EUR 5 million-or up to 10% of annual turnover in Belgium^{13dlapiper.com}

Building continuous access governance-especially for SaaS, cloud, and third parties-can't happen at the last minute. It requires structure, not a scramble.

What "DORA-ready" access governance actually looks like

Scrap the buzzwords. Here's a practical target state for DORA and lean IT teams alike.

1. Universal coverage for all in-scope systems

A single view of identities and access spanning:

• Core banking/trading/payments platforms
• Internal line-of-business systems
• Sensitive SaaS tools (CRM, document signing, cloud storage, collaboration)
• Cloud and infrastructure (IaaS, Kubernetes, DB consoles, security tools)

DORA doesn't care if an app lacks SCIM or an API. You must close SSO "coverage gaps."

2. Lifecycle automation with policy-driven access

Manual joiner/mover/leaver flows always lag. DORA-ready access uses policy-driven automation:

• Birthright access by role, department, location, and risk
• Time-bound elevations with auto-revoke
• Event-driven deprovisioning on HR/directory triggers
• Consistent, automated treatment of contractors, service accounts, and AI agents

This proves least privilege and enforcement, not just box ticking.

3. Automated, risk-based access reviews

You don't need fewer reviews-just smarter ones:

• Risk-based scope: high-risk systems reviewed more often
• Context provided: when/who/how access was granted; last used
• Default actions (auto-revoke dormant, justify exceptions)
• Immutable certification records

Iden customers report saving around 120 hours per quarter on reviews once evidence is automated-time redirected from wrangling to risk management.

4. Immutable audit logs aligned to DORA

Your logs must serve both SOC and supervisors. Basics:

• Timestamps and initiators for all access events
• Link logs to all identities (including agents, service accounts)
• Cryptographically protected/immutable storage
• Ability to roll back access state to any point in time

DORA expects you to disprove "unauthorized access" claims with evidence-not claims.

5. Third-party risk connected to access paths

DORA's ICT third-party rules demand more than contract language. You need to:

• Start from your third-party register: map who can admin those providers
• Apply least privilege and SoD to those critical rights
• Show when those rights were last reviewed, by whom

If contract and access data are separate, DORA forces you to close that gap.

How Iden approaches DORA-grade governance

This isn't a sales pitch-just facts from the field. Iden was purpose-built for organizations beyond SSO/manual provisioning, without legacy IGA baggage. That's now the DORA sweet spot: 50-2,000 employees, heavy SaaS, lean IT/security.

Here's our approach:

• Complete coverage, no SCIM tax. Universal connectors support SCIM, APIs, and even hard-to-integrate or "closed" SaaS, covering the long tail where sensitive data lurks.
• Fine-grained control. Governance down to channel, repo, project-not just "has app/no app." That's the real site of SoD conflicts.
• Continuous governance and automated reviews. Agentic (AI-driven, autonomous) workflows run reviews, gather evidence, and flag anomalies-without ticket gridlock.
• Immutable audit trails. Bank-grade encryption and logs you can show an inspector-not just a SharePoint folder labeled "DORA 2026."
• Zero SCIM tax. Full automation without forced SaaS enterprise plan upgrades, avoiding friction between DORA and cost control.

You don't need Iden to be compliant. But any DORA-grade solution must cover the same core: coverage, control, and continuous evidence-across your full stack.

Actionable steps before your 2026 exams

If you're in DORA's crosshairs and still working in spreadsheets, here's your move sequence:

1. Map your true access surface

• Define DORA-regulated entities in your business
• Build/update your application inventory with risk tags (critical, supporting, low-risk)
• Include SaaS and ICT third-party systems

2. Classify identities and high-risk access

• Inventory identities: employees, contractors, third-party operators, AI agents, service accounts
• Mark roles with sensitive powers (money movement, trading, configuration, security)
• Decide which roles need continuous review under DORA

3. Gap-analyze current access reviews

For every key system:

• How are accounts provisioned (SSO, local admins, tickets)?
• How and how often are reviews done?
• Where's evidence stored? Can you tie it to true state?
• How are departures and role changes handled?

This reveals your DORA exposure hot spots.

4. Pilot continuous governance in a core area

Pick a critical slice (e.g., trading + SaaS or payments + fraud tools):

• Integrate all relevant apps (SCIM or not)
• Automate joiner/mover/leaver flows
• Run one automated, policy-driven access review with evidence
• Document effort, closed gaps, findings

This proves feasibility and provides a concrete supervisor narrative.

5. Industrialize, then optimize

Once the pilot works:

• Expand coverage app by app, focusing on critical systems and providers
• Standardize policies (e.g., max privilege duration, dormant thresholds)
• Connect governance evidence into your DORA program (risk register, IR, BCP)

Continuous access governance becomes your operating baseline-not a last-minute panic.

Frequently Asked Questions

Does DORA mandate explicit access reviews?

DORA never says "user access review" directly, but it mandates:

• Rights must follow least privilege and SoD.^{14worldfinancialreview.com}
• ICT risk frameworks must monitor and control unauthorized access and log related events.^{8digital-operational-resilience.net}

Regular, documented, increasingly automated reviews are the only practical way to comply.

Are smaller entities given a break under DORA?

DORA does allow simplified frameworks for smaller or less complex firms, but does not drop requirements for access control, logging, or vendor risk.^{1eba.europa.eu}

If you're covered, you must still control, monitor, and review privileged access-even if that looks lighter-weight.

How does DORA interact with NIS2 and MaRisk?

DORA is for the financial sector; NIS2 is for essential/important players economy-wide. In reality:

• Most financials are covered by both regimes
• National regulators (e.g., BaFin) note that DORA complements, not replaces, MaRisk

Design for continuous evidence and universal coverage once-map that to DORA, NIS2, SOC 2, ISO 27001, etc. Avoid parallel programs.

What about SaaS apps with no SCIM or APIs?

DORA doesn't care about integration difficulty. If a system handles payments, trading, customer info, or security, it's in scope. So you must govern access for:

• Collaboration platforms with sensitive sharing
• Critical but obscure SaaS (fraud tools, regtech, treasury)
• Third-party consoles you use to admin providers

Iden's experience: most identity blindspots and manual effort live here. DORA compliance demands solving this "missing 80%."

Do you need an IGA platform to comply with DORA?

Strictly, no-DORA doesn't force IGA purchase. But you must deliver:

• Complete, up-to-date access inventories
• Enforced least privilege and SoD
• Continuous monitoring and immutable log evidence
• Reliable, quick answers for supervisors

You can build this from SSO, ITSM, spreadsheets-but most lean teams find that breaks under DORA's weight by 2026. A lightweight, complete governance layer (Iden or similar) is the real answer.

Takeaway. DORA doesn't introduce a new concept. It simply ends any illusion that partial, manual access governance suffices. If you can't handle a live, DORA-driven audit in 2026-with real-time coverage across all systems and providers-now is the time to close those gaps. Not Q4 2026.