IAM solutions for banks, insurers, investment firms, payment and e-money institutions, and the ICT providers that serve them - delivered by specialists across EMEA. Intragen's IAM solutions help organisations meet DORA's identity and access control requirements, and produce the evidence to prove it.
Compliance
DORA Identity Access Management
Looking for NIS2?
If your organisation is in scope of NIS2 rather than DORA, explore how its identity and access requirements differ.
What does DORA mean for Identity and Access Management?
DORA does not introduce unfamiliar concepts. Unique identities, joiner-mover-leaver processes, least privilege, segregation of duties, access certification and privileged access controls are established IAM practice, and most financial entities already have all of them in some form.
What DORA adds is specificity. Its principle, set out in Article 9 of the Regulation, is that access should be limited to what is required for legitimate, approved activity, with strong authentication applied where risk demands it. The operational detail sits in the accompanying regulatory technical standards, which dedicate two full articles to identity management and access control. Between them they fix how often controls must operate, how far they must extend, and what has to be retained to prove they operated.
The shift for established programmes
That last point is where established programmes are falling short. A control that works is no longer sufficient on its own. Under DORA, the record proving it worked is part of the control.
Who does DORA apply to?
DORA applies to financial entities authorised in the European Union, including credit institutions, payment and electronic money institutions, investment firms, insurers and crypto-asset service providers.
It also reaches ICT third-party service providers, by a different route. DORA requires financial entities to include specific provisions in their ICT contracts, and where a service supports a critical or important function those provisions include rights of access, inspection and audit, participation in resilience testing, and defined ICT security measures.
If you supply the financial sector
Providers serving the financial sector encounter DORA through procurement rather than through direct regulation. Intragen's experience is that this is where many providers first have to demonstrate the maturity of their own identity controls, often at short notice and in response to a client questionnaire.
In scope directly
- Credit institutions
- Payment and electronic money institutions
- Investment firms
- Insurers
- Crypto-asset service providers
The simplified framework
Financial entities operating under DORA's simplified ICT risk management framework are subject to a lighter set of requirements, including periodic review and withdrawal of unnecessary access without a fixed interval being specified.
What DORA requires from your identity and access controls
Six requirements account for most of the work organisations need to do.
Unique identities, extended to your providers' staff
DORA requires a unique identity corresponding to a unique user account for each member of staff, and this extends explicitly to the staff of ICT third-party service providers accessing your systems. Records of identity assignments must be retained after a reorganisation and after the contractual relationship that created them has ended.
Lifecycle management across all accounts
Creation, change, review and update, temporary deactivation and termination, applied to all accounts rather than only to employee accounts, with automated solutions deployed where feasible and appropriate. In practice this brings service accounts and integration credentials into scope alongside your workforce.
Access reviews at a defined frequency
Access rights must be reviewed at least once a year across all ICT systems, and at least every six months for ICT systems supporting critical or important functions. Access must be withdrawn without undue delay when employment ends, or the access is no longer necessary.
Privileged access granted on a need-to-use basis
Privileged, emergency and administrator access should be assigned on a need-to-use basis across all ICT systems, with dedicated accounts used for administrative tasks where possible and automated privileged access management deployed where feasible. Standing administrator entitlements are the most common gap here, and generally the most straightforward to close.
Restricted use of shared accounts, with actions always attributable
Generic and shared accounts should be limited to the extent possible, and users must remain identifiable for the actions performed in ICT systems at all times. Where a shared account cannot be removed, attributability becomes the operative control, which makes credential brokering and session recording the practical answer rather than a provisioning change.
Strong authentication rather than a named technology
DORA does not specify multi-factor authentication. It requires strong authentication methods in line with leading practices for remote access to the network, for privileged access, for access to assets supporting critical or important functions, and for publicly accessible assets. Because the requirement is tied to leading practice rather than to a fixed control, it moves as practice moves.
The requirement organisations most often fall short on
From our work with clients, Intragen has found that access review frequency is where programmes most often fall short. Meeting it means your access review process has to know which systems support critical or important functions, which depends on an asset classification that is current and readable by your certification tooling. Most organisations have the classification somewhere and no route from it into the tooling.
DORA requirements mapped to identity and access controls
Each obligation, the article it comes from, the control that satisfies it, and the Intragen capability that delivers it.
Scroll the table sideways →
| DORA requirement | Reference | IAM control | Intragen solution |
|---|---|---|---|
| Access limited to approved functions and activities | DORA Art. 9(4)(c) | Access governance | IGA |
| Strong authentication mechanisms | DORA Art. 9(4)(d) | Authentication | Access Management |
| Unique identity per account, including ICT provider staff | RTS Art. 20(2)(a) | Identity management | IGA |
| Lifecycle for all accounts: create, change, review, deactivate, terminate | RTS Art. 20(2)(b) | Identity lifecycle management | IGA |
| Identity assignment records retained after reorganisation or contract end | RTS Art. 20(2) | Identity records and audit trail | IGA |
| Need-to-know, need-to-use and least privilege, including remote and emergency access | RTS Art. 21(1)(a) | Entitlement governance | IGA and PAM |
| Segregation of duties | RTS Art. 21(1)(b) | Role and SoD governance | IGA |
| Generic and shared accounts limited, users identifiable at all times | RTS Art. 21(1)(c) | Accountability and session recording | IGA and PAM |
| Privileged, emergency and administrator access on a need-to-use or ad-hoc basis | RTS Art. 21(1)(e)(ii) | Just-in-time privileged access | PAM |
| Access withdrawn without undue delay on termination or when no longer required | RTS Art. 21(1)(e)(iii) | Automated deprovisioning | IGA |
| Review at least annually, and at least every six months for critical or important functions | RTS Art. 21(1)(e)(iv) | Access certification | IGA |
| Strong authentication for remote, privileged, critical-function and publicly accessible access | RTS Art. 21(1)(f)(ii) | Strong authentication | Access Management |
| Dedicated accounts for administrative tasks, automated PAM where feasible | RTS Art. 21(1)(e) | Administrative account separation | PAM |
| Logging of access control and identity management events, protected from tampering | RTS Art. 12(2) | Access and session logging | IGA and PAM |
| Remote sessions limited, locked and terminated after inactivity | RTS Art. 13 | Session management | Access Mgmt and PAM |
| Rights of access, inspection and audit over ICT providers | DORA Art. 30(3) | Third-party access governance | IGA and PAM |
References are to Regulation (EU) 2022/2554 and the accompanying regulatory technical standards on ICT risk management tools, methods, processes and policies.
Common gaps Intragen sees in DORA identity controls
Across DORA-related engagements, Intragen typically sees the same issues recurring.
A single annual recertification covering everything
There is no separate six-monthly cycle for systems supporting critical or important functions, usually because those systems have not been identified in a form the access review process can consume.
Access records that do not outlive the system
Identity assignment history is held only within the application it belongs to and is lost when that application is decommissioned or a contractor's account is removed.
Standing privilege in production environments
Permanent administrator entitlements remain where the requirement is need-to-use or ad-hoc access, often because removing them would disrupt an operational process that has not yet been redesigned.
Administrative work performed from ordinary user accounts
This weakens accountability, reduces the value of access logs, and increases the impact of a single compromised credential.
Third-party administrators outside the identity estate
Provider staff are granted access locally, outside joiner-mover-leaver processes and invisible to certification campaigns, while DORA extends the unique identity requirement to them explicitly.
Emergency access that is a procedure rather than a control
Break-glass is documented on paper rather than delivered as a brokered, logged and time-bound mechanism, which means it cannot be evidenced when asked for.
Most common finding
Controls that operate but cannot be evidenced
The control works, but the dated, approved and retained record proving it worked does not exist in a form an auditor will accept. Intragen's view is that under DORA the evidence is part of the control, not a by-product of it.
How Intragen supports your DORA journey
Intragen works across the full lifecycle of a DORA identity programme, from establishing where you stand through to running the controls once they are live.
Identity Governance and Administration
Delivers control for the identity lifecycle across employees, contractors and ICT provider staff, with access requests and approval workflows, certification campaigns configured to the annual and six-monthly cycles DORA requires, role and segregation-of-duties governance, and the retained records that provide evidence of those controls.
Explore →Privileged Access Management
Delivers credential vaulting, just-in-time elevation, dedicated administrative accounts, brokered emergency access, session monitoring and recording, and privileged activity reporting.
Explore →Access Management
Allows implementation of strong authentication applied where DORA requires it, aligned to how you classify your assets, single sign-on, and session controls.
Explore →Non-Human Identities
Provide for the discovery, ownership and lifecycle management of the service accounts, integration credentials and automation identities that sit within DORA's account scope and rarely appear in a certification campaign.
Explore →Advisory and consulting
Maps your current controls against DORA's identity and access requirements, identifies where the gaps carry the most regulatory and operational risk, and produces a prioritised roadmap. Organisations use this to decide what to fix first and to give their board a defensible view of the position.
Explore →Implementation and integration
Delivers that roadmap across leading IAM platforms, onboards the applications that matter most, and automates the lifecycle and certification processes that DORA requires to run on a schedule.
Explore →Managed Services
Keeps the programme working, running the certification cycles, maintaining the evidence set, and keeping controls current as your estate and supervisory expectations evolve. Intragen has proven, successful experience that shows that a Managed Service model can accelerate time-to-value and reduce operational burden, particularly for organisations without the in-house capacity to sustain a six-monthly review cycle indefinitely.
Explore →Why choose Intragen for DORA
Identity is the only thing we do
As one of Europe's established and leading specialists, Intragen has focused exclusively on Identity and Access Management since 2006. Our people are IAM practitioners, not generalists.
That focus matters for DORA - we understand the demands of bringing the required controls into operation across real estates, with legacy applications that resist automated deprovisioning, third-party administrators without clear ownership, service accounts with no named owner, and entitlements accumulated through years of role changes. Our view is that DORA readiness is an identity engineering problem before it is a compliance problem, and we have the team, skills and process to deliver.
- Certified to the standards we design for. ISO 27001 certified and Cyber Essentials certified, so the access governance we build for clients is governance we are audited against ourselves.
- Recognised platform expertise. Okta Apex Partner and Okta EMEA Partner of the Year 2025, One Identity Platinum Premier Plus Partner and a double Partner Award winner.
- Backed by group scale. Part of the Nomios Group, one of Europe's largest cyber security and secure networking specialists.
Identity specialists at European scale
Delivering from across our five European offices, Intragen has worked exclusively on Identity and Access Management since 2006.
- Implementations delivered
- 400+ IAM implementations
- People
- 250 Identity and Access Management specialists
- Certifications
- ISO 27001 certified, alongside Cyber Essentials
- Okta
- Apex Partner and EMEA Partner of the Year 2025
Questions we hear most about DORA and identity
DORA Article 9(4)(c) requires policies that limit access to what is required for legitimate and approved functions and activities. The detail sits in the accompanying regulatory technical standards, which require unique identities for staff and for ICT provider staff, lifecycle management across all accounts, access assigned on need-to-know and least privilege principles, segregation of duties, privileged access on a need-to-use basis, restricted use of shared accounts, and strong authentication for remote, privileged, critical-function and publicly accessible access.
At least once a year for all ICT systems, and at least every six months for ICT systems supporting critical or important functions. Access must also be withdrawn without undue delay when employment ends or the access is no longer necessary. Entities using DORA's simplified framework are required to review access periodically without a specific interval being set.
Not in those terms. DORA requires strong authentication mechanisms based on relevant standards, and the technical standards require strong authentication methods in line with leading practices for remote access to the network, privileged access, access to assets supporting critical or important functions, and publicly accessible assets. No number of factors is specified. Multi-factor authentication is how most organisations meet the requirement in practice, but the obligation is tied to evolving leading practice rather than to a named control.
Privileged, emergency and administrator access must be assigned on a need-to-use or ad-hoc basis across all ICT systems. Organisations should use dedicated accounts for administrative tasks where possible and deploy automated privileged access management solutions where feasible and appropriate. Least privilege applies explicitly to remote and emergency access, and privileged access requires strong authentication.
In substance, yes. The technical standards require unique identification and authentication of natural persons and systems, and apply the account lifecycle process to all accounts, which brings service accounts, integration accounts and automation credentials within scope for lifecycle management and oversight. DORA does not use the terms service account or machine identity, so it is more accurate to say that non-human accounts fall within its account scope than to say it mandates a machine identity programme.
Not directly, but its requirements reach providers through contract. Financial entities have to build specific ICT security, audit and resilience-testing provisions into the contracts they sign, so providers serving the sector are increasingly asked to demonstrate the maturity of their own identity and access controls before a deal closes. Who DORA applies to sets out what those provisions cover.
They are restricted rather than prohibited. The technical standards require the use of generic and shared user accounts to be limited to the extent possible, while ensuring users remain identifiable for the actions performed in ICT systems at all times. Account management procedures apply to generic accounts including generic administrator accounts. Where a shared account cannot be eliminated, the operative requirement becomes attributability of individual actions.
The documented access control and identity management policies, records of identity assignments retained beyond reorganisations and contract endings, dated access review records at the correct annual or six-monthly cadence showing who reviewed and what changed, approval records for access grants and for privileged, emergency and administrator access, deprovisioning records, and access and identity management logs protected against tampering and deletion. From our own work, Intragen has found that it is this evidence set, rather than the controls themselves, where most DORA programmes are weakest.
Assess your identity controls against DORA
A Maturity Assessment gives you an independent view of your current identity and access controls, a gap analysis against DORA's requirements, and a prioritised roadmap for improvement. It is available as a four-week Light engagement or an eight-week Core engagement, and it is not a commitment to buy.
Request an assessment
Prefer to talk it through first? Speak to an IAM specialist
This page provides general information and does not constitute legal or compliance advice. Organisations should assess their obligations under DORA with reference to the Official Journal texts and their competent authority.