The Digital Operational Resilience Act (DORA) has been fully enforceable since January 2025. In 2026, European supervisors moved from readiness checks to active enforcement. If your financial institution still treats identity governance as an IT project rather than a regulatory obligation, the gap between your policies and your evidence is where the examiner will start.
DORA applies to more than 22,000 financial entities across the EU – banks, insurers, investment firms, payment providers, crypto-asset service providers, and their critical ICT third-party providers. Its identity and access requirements are not vague best practices. They are specific, article-level legal obligations with penalties reaching 2% of global annual turnover and up to EUR 1 million in personal fines for senior management.
Here is what DORA actually requires for identity governance, where most organizations are falling short, and how midPoint addresses each requirement.
What DORA requires for identity and access control
DORA’s ICT risk management framework (Articles 5–16) contains explicit identity governance requirements. The European Supervisory Authorities (EBA, ESMA, EIOPA) further elaborated these in Regulatory Technical Standards (RTS) that took effect alongside the regulation. Two RTS articles are specifically dedicated to identity:
RTS Article 20 – Identity Management
Financial entities must develop, document, and implement identity management policies and procedures that ensure unique identification and authentication of all natural persons and systems accessing ICT assets.
RTS Article 21 – Access Control
Access rights must be assigned based on need-to-know, need-to-use, and least privilege principles. Segregation of duties must prevent unjustified access or role combinations that could circumvent controls. All users must be individually accountable – generic and shared accounts must be limited and traceable. Privileged and emergency access must be granted on a need-to-use or ad-hoc basis. Policies must be reviewed at least annually and approved by management.
Article 9 of DORA itself – Protection and Prevention – turns these into hard legal obligations:
- Article 9(4)(c): Limit physical and logical access to what is required for legitimate and approved functions only. Establish policies, procedures, and controls that address access rights with sound administration.
- Article 9(4)(d): Implement strong authentication mechanisms based on relevant standards – including mandatory MFA for all privileged access and for access to critical or important function systems.
Article 10 adds detection requirements: mechanisms to detect anomalous authentication patterns, privileged access anomalies, and deviations from access baselines. Article 12 requires logging of all user activity, system events, and security-related events.
This is not aspirational. This is the minimum. And it is being checked.
Where financial institutions are falling short
of institutions expected full compliance by end 2025 – the rest pushed to 2026
Deloitte
of financial service organizations find it difficult to remain compliant
SailPoint Research
expect DORA to result in permanently higher run costs for technology and controls
KPMG
Early DORA examinations in the Netherlands, Germany, and Ireland consistently surface the same finding: the policy-evidence gap. Organizations have well-written policies that describe controls not operating in practice. The access management policy says “quarterly review of privileged accounts.” The examiner asks for evidence of the last four reviews and finds two were skipped and one was a rubber stamp.
Supervisory examination frameworks from EBA and ESMA focus on specific identity controls:
- Privileged account inventory – complete, with owners and last review dates
- Sample testing of access reviews – verifying that removed accounts were actually removed from target systems
- MFA exception review – every undocumented exception is a finding
- Service account governance – inventoried, owned, operating within documented purpose
- Emergency access account audit – break-glass accounts documented, with logged usage
The common thread: supervisors do not want to see your policy. They want to see evidence that the policy operates.
How midPoint addresses DORA identity requirements
Evolveum midPoint is an open-source Identity Governance and Administration (IGA) platform that maps directly to DORA’s identity and access control requirements. Here is the specific mapping.
| DORA Requirement | Article | midPoint Capability |
|---|---|---|
| Unique identification and authentication | RTS Art. 20 | Authoritative identity management with HR source sync, unique identity lifecycle |
| Least privilege access control | Art. 9(4)(c), RTS Art. 21 | Policy-driven RBAC and ABAC with automatic role assignment based on organizational attributes |
| Timely access revocation | Art. 9(4)(c), RTS Art. 21 | Automated joiner-mover-leaver (JML) deprovisioning – when someone changes role or leaves, access is revoked across all connected systems in real time |
| Periodic access reviews | RTS Art. 21 | Access certification campaigns with multi-stage review, configurable scope, and automated remediation |
| Segregation of duties | RTS Art. 21 | SoD policy engine with conflict detection and prevention across all connected systems |
| Privileged access governance | Art. 9(4)(c)(d) | Separate privileged account management, approval workflows, time-limited access, enhanced logging |
| User accountability | RTS Art. 21 | Complete audit trail of every identity change – who changed what, when, and why |
| Anomaly detection | Art. 10 | Audit logging with SIEM integration, outlier detection for access pattern anomalies |
| Event logging | Art. 12 | Comprehensive audit trail in documented database tables, exportable for supervisory review |
| Documented access policies | RTS Art. 21 | Policy objects with version history, enforcement evidence, and review timestamps |
Closing the policy-evidence gap
The specific advantage midPoint offers for DORA compliance is not feature-level. It is architectural. midPoint does not just enforce policies – it produces evidence that policies are being enforced.
When a certification campaign runs, midPoint records every reviewer decision: who reviewed, what they decided, when, and the resulting provisioning action. When an access right is revoked because an employee changed departments, midPoint logs the policy that triggered the change, the systems affected, and the timestamps of both the request and the execution. When a segregation of duties violation is blocked, the audit trail shows the conflicting roles, the policy that caught them, and the user who would have received the toxic combination.
This is the evidence chain that examiners are looking for. Policy documents describe what should happen. midPoint’s audit trail proves what actually happened.
The open-source advantage for financial supervisors
DORA emphasizes transparency and auditability throughout its framework. midPoint is fully open source – every line of governance logic is inspectable. Financial entities and their supervisors can verify that the platform does exactly what it claims.
This is not a theoretical advantage. When a supervisor asks how your IGA platform determines access decisions, you can point to the actual source code, the policy configuration, and the audit output. No black box. No vendor-controlled decision engine that you cannot inspect.
NIS2 Recital 52 explicitly endorses open-source technologies for cybersecurity. For financial entities subject to both DORA and NIS2 – which includes most banks and large financial institutions – the open-source argument is a compliance argument.
DORA and NIS2: one platform for dual compliance
Many financial entities must comply with both frameworks. Under the lex specialis principle (NIS2 Article 4), DORA takes precedence for ICT risk management matters in the financial sector. But NIS2’s broader provisions – physical security, supply chain security, non-technology risk areas – still apply where DORA does not fully address them.
The identity governance requirements overlap significantly:
- Both require access control policies based on least privilege
- Both mandate multi-factor authentication (DORA Art. 9(4)(d), NIS2 Art. 21(2)(j))
- Both require incident management including identity-related incidents
- Both require human resources security and access control
- Both require supply chain and third-party access governance
A single midPoint deployment serves as the IGA platform for both frameworks. The same certification campaigns, SoD policies, JML automation, and audit trails satisfy both sets of requirements simultaneously.
The migration opportunity: DORA compliance during platform transition
Financial institutions running legacy IAM platforms face a compound problem. SAP Identity Management reaches end of maintenance in December 2027. Microsoft Identity Manager reached mainstream end of life in April 2026. Both platforms are approaching or past their support deadlines – and neither meets DORA’s identity governance requirements out of the box.
Migrating to midPoint addresses both problems in a single initiative: replacing end-of-life infrastructure and establishing a DORA-compliant identity governance platform. The migration can be phased – connector by connector, system by system – with parallel operation during transition and zero-downtime cutover.
For organizations that need to demonstrate DORA compliance while simultaneously modernizing their IAM stack, this is the practical path.
Penalties and personal liability
DORA’s penalty framework is designed to ensure management attention:
- Up to 2% of total annual worldwide turnover for the most serious violations
- Up to 1% of average daily turnover for certain continuing breaches
- Fixed fines up to EUR 5 million depending on severity
- Personal fines up to EUR 1 million for senior management
- Some member states have set higher ceilings – Italy allows up to EUR 20 million or 10% of turnover
The management body bears ultimate, non-delegable responsibility for the ICT risk management framework (Article 5). This is not an IT problem that can be delegated. It is a board-level accountability.
Our experience
At WeKnowIdentity, we implement midPoint for organizations that need governance frameworks that survive audit. Our team holds four Evolveum midPoint certifications and has delivered 10+ enterprise deployments across telecom, finance, government, and technology sectors in Europe. We design identity governance architectures that produce the evidence trail regulators expect – not just the policy documents they already have.
Start your DORA identity governance assessment
Contact us for a DORA identity governance readiness review. We will assess your current access control posture against DORA Articles 9, 10, and 12 and the RTS identity management requirements, identify the gaps between your policies and your evidence, and provide a practical implementation roadmap with midPoint.
Related Resources
- NIS2 Directive: How midPoint Helps You Meet Identity Security Requirements
- midPoint consulting and implementation services
- Microsoft MIM to midPoint migration
- SAP IDM to midPoint migration
- midPoint vs Commercial IGA: Which Approach Fits Your Enterprise?
- Case study: European Telecom Operator
Sources
- DORA Regulation (EU) 2022/2554 – digital-operational-resilience-act.com
- EIOPA, Digital Operational Resilience Act overview – eiopa.europa.eu
- EBA/ESMA/EIOPA, Final Draft RTS on ICT Risk Management – eba.europa.eu
- Springlex, RTS Article 21 Access Control – springlex.eu
- Deloitte, DORA compliance readiness survey – thenextweb.com
- KPMG, DORA implementation at financial institutions – kpmg.com
- SailPoint Research, financial services compliance – itsupplychain.com
- regulation-dora.eu, DORA 2026 enforcement changes – regulation-dora.eu
- regulation-dora.eu, DORA penalties and fines guide – regulation-dora.eu
- Evolveum, midPoint compliance documentation – docs.evolveum.com
- Evolveum, NIS2 and identity governance – evolveum.com
Planning an IAM modernization or migration?
Our midPoint specialists help enterprises implement, migrate, and operate identity governance platforms. Whether you are replacing MIM, SAP IDM, or another legacy system — we can help you plan a structured, low-risk transition.
Discuss Your ProjectJán Minárčiný
Founder & Lead midPoint Consultant | 4x Evolveum Certified
Ján is the founder of WeKnowIdentity, a boutique IAM consulting firm specializing in Evolveum midPoint. He holds four midPoint certifications (Professional, Advanced, Deployment Specialist, Group Synchronization), plus IDPro BoK and GitOps (CGOA) certifications. With 10+ enterprise midPoint deployments across Europe, he writes about IAM strategy, midPoint best practices, and identity governance.
Add a Comment