What DORA access control and identity management requirements cost you in effort
A financial entity whose contract or supervisor now asks for DORA evidence on identities and access should understand first that DORA sets no certification scheme. The entity owns its controls, and an independent assessor or the competent authority tests them. The requirements sit in Articles 20 and 21 of Delegated Regulation (EU) 2024/1774, and they have applied since 17 January 2025. The effort is not a fixed price. The main cost driver is the number of identities, systems and third parties in scope. Each staff member, each third-party staff member, each application holding critical or important functions, and each remote or privileged access path adds work to create unique accounts, record lifecycle events, and run access reviews.
Costs fall into a few groups. Internal staff spend time on the identity inventory, role design, and the review cycle, which recurs. Identity tooling and any integration work with existing directories are usually one-time setup followed by ongoing maintenance. Assessment preparation, such as assembling lifecycle records and review evidence, adds effort before an audit or supervisory visit. Efforts rise when identity sources are fragmented, when shared or generic accounts exist, or when many applications still handle their own logins. Efforts fall when a single identity provider and a clear joiner, mover and leaver process already exist.
DeployOpen plans, implements and documents identity systems inside the client's own infrastructure, and it can prepare access records and review evidence for an assessment. DeployOpen does not issue audit reports or attestations, and the entity remains accountable for the controls. When requesting a quote, ask for the list of identity sources and applications in scope, the number of third-party accounts, the review cadence for systems supporting critical or important functions, and which items are one-time versus recurring. The written scope should state who performs each review and what evidence will be handed over. Confirm with your assessor which evidence format they will accept before work starts.
How often access reviews must run and what counts as evidence
DORA's access rules set minimum review frequencies and a withdrawal standard that depend on how critical the system is. Each card below covers one rule and names the records an assessor would ask to see to confirm it works in practice.
Withdrawing access without undue delay
Article 21 requires access to be withdrawn without undue delay once it is no longer needed, such as when a role changes or a contract ends. The phrase has no fixed number of hours, so your own risk assessment should set a target. An assessor will typically sample leavers and movers and compare the date each right was removed against the date the need ended. Ask your identity team for a report of accounts still active after their HR or contract end date.
Annual review for ICT systems
Access rights to ICT systems must be reviewed at least once a year. The review should be a documented campaign covering every system in scope, not a spot check of one application. Evidence includes the list of systems in scope, the reviewer assigned to each, the decisions taken (keep, change or revoke), and proof that revocations were carried out. Confirm that the scope list matches your current asset inventory.
Six-monthly review for critical functions
Systems supporting critical or important functions must be reviewed at least every six months. This is the stricter cadence, so the same campaign tooling needs a shorter schedule for those systems. Assessors look for the separate scope definition, two dated review records per year, and the rationale for which systems are classed as supporting critical or important functions. Keep that classification consistent with your register of information and ICT risk assessment.
Privileged access on a need-to-use basis
Privileged rights must be granted only when needed, either for a defined task or on an ad hoc basis, and then withdrawn. Standing administrator rights are the main gap an assessor probes. Evidence includes the approval record for each elevation, the start and end time of the session or grant, and the logs showing what the privileged user did. Ask whether elevation requests can be traced to a ticket and a named approver.
Campaign outcomes and reviewer records
A review only counts if the reviewer decisions are recorded and acted on. Assessors ask for the reviewer identity, the decision for each access item, the timestamp, and the ticket or change that carried out each revocation. Open-source campaign tools such as midPoint can record reviewer decisions within a set timeframe, but you must confirm that exported reports include these fields before relying on them for an audit.
Where strong authentication and physical access logging apply
Remote access is the first scope where Article 21 of Delegated Regulation (EU) 2024/1774 requires strong authentication. Any connection that reaches internal ICT systems from outside the network, including staff working from home, contractors and vendor support sessions, falls within it. Because the network perimeter no longer marks where trust begins, a password alone does not give the assurance the regulation expects.
- VPN and gateway logins: Every remote session should require a second factor or an equivalent strong method, not only a username and password.
- Vendor and contractor sessions: Third-party support access is remote access too, so it needs the same controls and a documented approval step.
- Remote desktop and bastion hosts: Jump servers and remote desktop gateways should enforce strong authentication before any session opens.
- Session scope: Document which remote paths exist, so no connection path sits outside the inventory.
Check that the entity's remote access inventory is complete and that each path is tied to a named authentication method in the access control records.
Privileged accounts can change configurations, read sensitive data and disable controls, so Article 21 requires strong authentication for them. The regulation also requires privileged access to be granted on a need-to-use or ad hoc basis, which means the strong authentication step sits inside a broader approval model rather than standing on permanent accounts.
- Administrator accounts: Domain, directory, hypervisor and cloud administrator roles need strong authentication on every use.
- Ad hoc elevation: Temporary elevation for a specific task should trigger a fresh strong authentication and expire when the task ends.
- Break-glass accounts: Emergency accounts also need strong authentication, with their storage and use recorded.
- Service and shared administrative accounts: Where a shared account cannot be avoided, the entity should document how individual use is still identifiable.
Confirm that every privileged role in the access matrix maps to a strong authentication method and that elevation events are recorded.
The third scope covers access to systems that support critical or important functions, a term the entity defines through its own risk assessment and business impact analysis. Strong authentication applies to these systems whether the user is inside or outside the network, and whether the account is standard or privileged. The scope depends on the entity's classification, so the classification record is the starting point.
- Classification link: Tag each system in the asset inventory with whether it supports a critical or important function.
- Payment and trading platforms: Core transaction, settlement and customer account systems usually fall within this scope.
- Reporting and data platforms: Systems that feed regulatory reporting or risk calculations should be assessed against the same test.
- Periodic re-check: Update the scope when a function is redesigned, outsourced or moved to a new platform.
Ask for a current list of systems tagged to critical or important functions, and check that each one has a documented authentication method.
Publicly accessible ICT assets, such as customer portals, public APIs and internet-facing administration pages, are the third access category where Article 21 requires strong authentication. These assets are exposed to anyone who can reach them, so the consequences of weak authentication are higher than for internal tools. The requirement applies whether the asset is hosted on premises or in a cloud environment the entity controls.
- Customer-facing logins: Portals and apps that handle financial data should enforce strong authentication for accounts that can move money or change details.
- Public APIs: Machine and partner access should use strong client credentials, with rotation and revocation documented.
- Admin interfaces exposed to the internet: These should be removed from public reach where possible, and otherwise protected by strong authentication.
- Identity provider exposure: The single sign-on service itself becomes a public asset when it is reachable from the internet, so it needs the same treatment.
Check the external attack surface inventory and confirm that each public entry point has a stated authentication method.
Article 21 also requires physical access to be logged, monitored and promptly revoked when it is no longer needed. This is a separate control from strong authentication, but it sits in the same access control framework. Article 9(4) of the RTS puts both on a documented basis: the information security policy must limit physical and logical access to what legitimate, approved activities require.
- Access logs: Record who entered each secured area, when and under which credential, and keep the records for the period set in the entity's policy.
- Monitoring: Review entry events for secured areas such as server rooms, network closets and cash handling areas, and investigate anomalies.
- Prompt revocation: Remove badge and key rights when a role changes or a person leaves, and record the date of removal.
- Policy basis: Tie each secured area to a documented approval rule so that access follows the limit set in Article 9(4).
Ask for a sample of physical access logs and the revocation records for recent leavers, and check that the two match.
How Keycloak and midPoint produce access evidence
Keycloak and midPoint can produce much of the identity and access evidence that Articles 20 and 21 of Delegated Regulation (EU) 2024/1774 call for, but they do so only as components of a control design the financial entity owns. Keycloak handles single sign-on, so users authenticate once with the platform rather than separately into each application. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can broker logins to existing OpenID Connect or SAML 2.0 identity providers. For a DORA file, this means the authentication log, the realm configuration, the required-action settings and the enforced strong authentication flows (for example, multi-factor steps for remote and privileged access) can be exported and dated. The entity still has to confirm which applications are registered as clients, which of them sit behind the platform, and which remain on local accounts that would fall outside the evidence trail.
midPoint adds the review side. Its access certification campaigns assign designated reviewers who decide, within a set timeframe, whether to keep, change or revoke each access item, such as a role assignment. This is the mechanism that supports the requirement for access rights to be reviewed at least once a year for ICT systems and at least every six months for systems supporting critical or important functions, and it helps surface access accumulation and dangerous combinations of rights that bear on segregation of duties. Before relying on it, the entity should decide who the reviewers are for each system, what timeframe applies, what happens to items that receive no decision, and how revocations flow back to the target systems. The campaign records, decisions and revocation timestamps are the evidence an assessor will ask to see.
Neither tool makes the entity compliant on its own. The financial entity must document how each platform meets its own control design, including the roles, approval steps, review cadence and exception handling, and must show that the configuration in production matches that design. Confirm with the vendor and your own environment which features your deployed versions provide, and test them against the requirements before an assessor does. Ask an implementation partner to prepare the configuration, evidence exports and test records, but remember that the entity owns the controls and that only the competent authority or an independent assessor can judge whether they are effective.
Who owns the controls, who prepares evidence and who tests them
The financial entity is accountable for DORA compliance, including the access control and identity requirements in Articles 20 and 21 of Delegated Regulation (EU) 2024/1774. Its management body and control functions decide what the access model is, which roles carry privileged rights, and how much residual risk the business accepts. Staff in the entity approve each access request, nominate reviewers and sign off the outcome of each review. Those decisions cannot be delegated to a vendor or consultant, even when the work to record them is outsourced.
- Access policy and risk decisions: Set the documented information security policy, the access principles (need-to-know, need-to-use, least privilege) and which systems support critical or important functions.
- Approvals and reviews: Approve access requests, nominate reviewers and record the decision to keep, change or revoke each item in the periodic review.
- Privileged access: Decide when privileged rights are granted on a need-to-use or ad hoc basis and who authorizes them.
- Identity lifecycle records: Own the register of identity assignments, including records kept after reorganizations or contract end.
- Physical access: Decide who may enter sensitive areas and review access logs.
Check that your access policy names an accountable owner for each decision above and that the owner can show a dated approval for each sample you select.
An implementation partner such as DeployOpen works inside the client's own infrastructure to configure the identity platform, build the lifecycle and review workflows and prepare the evidence that the entity's controls operate. Typical open-source components include Keycloak for single sign-on and midPoint for access certification campaigns. The partner does not decide who gets access, does not approve requests and does not certify the outcome. Its role is to make the entity's decisions executable and traceable, so that the records exist when an assessor asks for them.
- Platform configuration: Set up single sign-on, strong authentication flows and brokered logins to existing identity providers, according to the scope agreed in writing.
- Lifecycle workflows: Build joiner, mover and leaver processes and automated provisioning where the entity has decided to use them.
- Review tooling: Configure access certification campaigns so designated reviewers receive items within the timeframe the entity sets.
- Evidence preparation: Export account inventories, campaign results, revocation logs and change records in a form an assessor can sample.
- Documentation and handover: Document configuration and runbooks so the entity can operate the platform after the engagement ends.
Confirm with the partner which configuration items it changes, who holds administrative credentials after handover and which evidence exports it provides.
Competent authorities supervise DORA compliance under the powers in Article 50, and no certification scheme exists for DORA. The only authority-issued attestation the Regulation provides for concerns threat-led penetration testing under Article 26(7). An independent assessor, auditor or certification body may test access controls for the entity's own assurance or for a contract, but it issues its own report, and that report is not a DORA certificate. Testing is independent of whoever built the controls, which is why the implementation partner cannot issue audit results.
- Supervisory testing: The competent authority samples accounts, approvals, review records and privileged sessions during inspections and may request documents.
- Independent assessment: An external assessor tests design and operating effectiveness against the entity's own policy and the requirements of Article 21, then reports findings.
- Sampling evidence: Testers select leavers, movers and privileged users and ask for the approval and revocation trail for each.
- Findings and remediation: The entity owns the response to each finding, sets its own remediation dates and retests where the assessor requires it.
- Scope of opinion: Ask the assessor to state the systems and period covered, because an opinion on one platform says nothing about another.
Before engaging anyone, confirm in writing who signs each report and who receives it.
Preparing identity and access evidence before an assessment
This sequence turns scattered account data into a set of records that show who holds access, why, who approved it, and whether it was reviewed. An assessor can then test each access rule against records the organization already keeps rather than against reconstructed memory.
Inventory every identity and privileged role
The IT security lead and system owners list every human account, third-party staff account, service account and privileged role across the ICT systems in scope, including systems supporting critical or important functions. Each entry records the owning system, the account type and the named person or team accountable for it. The step is complete when every account in the directories and application stores can be matched to one inventory row, and any account without an owner is flagged for a decision. Confirm with your own environment whether shadow accounts exist in standalone applications.
Document joiner, mover and leaver records
HR and the access administrators map how an identity is created, changed and removed, from hiring or contract start through role changes to exit or contract end. Each event needs a ticket or workflow record showing the request, the approver and the completion date. Where automated lifecycle tooling is used, the team confirms which events it triggers and which still depend on manual steps. The output is a sample of completed records for each event type, including records kept after a reorganisation or contract end, so an assessor can trace an identity from creation to removal.
Design roles and build the segregation-of-duties conflict list
Security architects and business owners group permissions into roles aligned to job functions, then list combinations that create dangerous conflicts, such as requesting and approving the same payment, or changing production code and deploying it without independent review. Each conflict is assigned an owner and either blocked in the role model or covered by a documented compensating control. The output is a written conflict list with a status for each entry and the role catalogue it refers to. Where privileged access is granted on a need-to-use or ad hoc basis, the list also states the approval path for those grants.
Run the first access review and record decisions
Access reviewers, designated by system owner rather than by the person being reviewed, confirm, change or revoke each access item in scope. Campaign tooling such as midPoint can record each decision with a reviewer name, a deadline and a reason. Revocations are actioned and checked in the target systems, not only in the review tool. The step closes when every item has a recorded decision, every revocation is confirmed as applied, and open items are escalated. The first run also establishes the review cycle the organization will evidence, which the RTS sets at least once a year for ICT systems and at least every 6 months for systems supporting critical or important functions.
Assemble the access evidence pack
The compliance lead, with the IT security team, gathers the outputs of the previous steps into one indexed pack: the identity inventory, lifecycle samples, role catalogue, conflict list, review campaign reports, revocation confirmations, the strong authentication configuration for remote, privileged and public access, and physical access logs with their review records. Each item is cross-referenced to the relevant article of Delegated Regulation (EU) 2024/1774. The pack is complete when a reviewer outside the project can follow any single control from its policy statement to a dated record without help from the team. Independent assessors, not DeployOpen or the organization, decide whether that evidence is sufficient.
Common gaps that fail an access control review
Assessors rarely fail an access program for lacking a policy. They fail it when the records show accounts, rights and logs that nobody is accountable for. The five gaps below are the ones most often found when a competent authority or internal audit tests identities against Articles 20 and 21 of Delegated Regulation (EU) 2024/1774.
Shared and generic accounts left in place
Service logins, team mailboxes and shared administrator IDs make it impossible to tell who did what. Article 21 limits generic and shared accounts so that users stay identifiable. The fix is to replace each shared account with named accounts, or to document a narrow, owned exception with a named accountable person, a password vault checkout record and session attribution. Ask for a list of every account with no single human owner and treat each one as a finding until it is closed.
Orphaned accounts after contract end
Accounts that survive a leaver, a reorganization or the end of a third-party contract still hold access that no one reviews. Article 20 requires a unique identity for every staff member and third-party staff member, with lifecycle management and records kept after reorganizations or contract end. The fix is to link identity records to HR and contract systems so that termination triggers disablement, then to reconcile directory accounts against active staff and contractor lists on a fixed schedule.
Access accumulation without review
Users who change roles keep the rights of every previous role, and the total grows silently. Article 21 requires access to be withdrawn without undue delay when no longer needed, and reviewed at least once a year for ICT systems and at least every six months for systems supporting critical or important functions. The fix is a certification campaign with a named reviewer for each access item, a deadline, and recorded decisions to keep, change or revoke. Ask for the last campaign's completion rate and the revocations it produced.
Privileged access standing by default
Administrators who hold permanent domain, cloud or database rights are exposed every hour of the day, not only when they work. Article 21 requires privileged access to be granted on a need-to-use or ad hoc basis, and strong authentication for privileged access. The fix is to remove standing rights, route elevation through a time-limited approval step, and log each elevation to a named person. Check whether break-glass accounts exist, who holds their credentials, and when they were last tested.
Physical access logs kept but never reviewed
Badge and door logs are often retained for months yet never read, so unnecessary physical access is not revoked promptly and intrusions go unnoticed. Article 21 requires physical access to be logged, monitored and promptly revoked when no longer needed. The fix is a named reviewer, a periodic review of badge holders against current staff lists, a rule for alerting on out-of-hours entry to data center or network rooms, and evidence of each review. Ask the physical security owner to show the most recent review record.
Frequently asked questions about DORA access control
Does DORA certify access control systems or issue a DORA certificate?
No. DORA sets no certification scheme, so nobody issues a DORA certificate for access control. Competent authorities supervise compliance using their powers under Article 50, and the only authority-issued attestation the Regulation provides for concerns threat-led penetration testing under Article 26(7). The financial entity owns its access control obligations. An implementation partner such as DeployOpen can prepare systems, configuration and evidence, but only the supervisor reviews compliance, and an independent auditor only reports where the entity has commissioned one for another framework. Ask any vendor who claims a DORA certification to show the issuing body.
How much effort does DORA access control work take, and what drives it?
Effort depends mainly on how many systems the entity runs, how many of them support critical or important functions, and how far identity is already centralized. The main cost components are internal staff time for role design and review, licenses or hosting for identity tooling, integration work for each application, and any external help with configuration and evidence. Costs are mostly one-time for initial design and integration, then recurring for reviews, joiner and leaver handling and tool upkeep. Ask any quote to separate these items, to list the systems in scope and to state whether access reviews are included for the first year.
Can an internal team meet the DORA access control requirements without outside help?
Often yes, if the team has identity engineering skills, a complete inventory of accounts and a clear owner for each system. The requirements cover unique accounts, lifecycle records, least privilege, segregation of duties, access reviews, strong authentication and physical access logging. Teams usually need outside help in three places: integrating legacy applications with single sign-on, designing segregation rules for dangerous combinations of rights, and building evidence that an assessor can follow. DeployOpen plans and implements these pieces inside the client's own infrastructure under a written, fixed scope, and the entity keeps ownership of its controls.
How does the six-monthly access review differ from the annual review under DORA?
The difference is frequency tied to criticality. Article 21 of Delegated Regulation (EU) 2024/1774 requires access rights to be reviewed at least once a year for ICT systems generally, and at least every six months for systems supporting critical or important functions. In practice, the entity should first classify its systems, then set two review cycles. Systems in the six-monthly group also need the stronger controls the Article describes, such as privileged access granted on a need-to-use or ad hoc basis. Confirm the classification with the entity's own risk assessment, since the regulation does not list the systems for you.
What do third-party staff accounts require under DORA?
Every third-party staff member who uses an entity's ICT systems needs a unique identity and user account, the same as an employee. Article 20 of Delegated Regulation (EU) 2024/1774 also requires the full account lifecycle to be managed and records of identity assignments to be kept after a contract ends. Practical controls include time-limited accounts tied to the contract, sponsor approval, periodic access review and removal when the engagement ends. Shared vendor accounts are limited because users must stay identifiable. Check the contract terms with the provider, since the entity must be able to show who did what.
What does an assessor ask for first on DORA access control?
An assessor usually starts with the policy and the population. They ask for the documented information security policy, the list of accounts and their owners, and the rules for granting, changing and withdrawing access. They then sample joiners, movers and leavers, check that access was withdrawn without undue delay, and read the most recent access review records with the decisions taken. For privileged access they expect approval records and logs. For strong authentication they check configuration exports for remote, privileged and public-facing systems. Prepare these in advance, because the supervisor's own powers are exercised against the entity's records, not against a vendor's claims.
When to bring in an outside partner for identity controls
Bring in an outside implementation partner when the identity work is too large or too interdependent to run alongside daily operations: for example, a fixed-scope rollout of a single sign-on layer such as Keycloak across applications that still hold their own local accounts, or an evidence pack that gathers unique-account records, lifecycle tickets, access review outputs and physical access logs into a form an assessor can test. In both cases the organization still owns its access decisions and its control design. The partner prepares the systems, configurations and records, and the internal owner signs off on every role model and every exception. Before work starts, ask for a written scope that names the systems in the first wave, the directory or HR source that drives joiner, mover and leaver events, the review cadence applied to systems supporting critical or important functions, and who approves privileged role assignments.
A written scope should also state the deliverables in terms an assessor can check: the configured identity provider and its federation settings, the lifecycle procedure, the access certification campaign design with named reviewers and decision deadlines, the list of generic or shared accounts with their justification and owner, and the handover documentation. Ask the partner which items it will hand over as configuration exports, which as screenshots or reports, and which remain the organization's responsibility to run after go-live. Confirm who pays for re-review if a system is added during the engagement, and how changes to scope are priced and approved in writing.
Independence matters at the assessment stage. The organization's competent authority, its internal audit function or an external assessor decides whether the controls meet DORA, and only an independent auditor or assessor issues reports or attestations. DeployOpen prepares systems, controls and evidence; it does not issue audit reports, attestations or certifications, and it does not guarantee a supervisory outcome. Keep the assessor and the implementation partner separate in your planning, and confirm with your assessor in advance which evidence formats they will accept. Where the regulator or your internal audit team has a particular expectation about the retention period for access review records, confirm that expectation before the evidence pack is built.
How DeployOpen scopes and prepares identity evidence
DeployOpen plans and implements self-hosted open-source identity and access tooling inside your own infrastructure, then documents the controls and evidence that Articles 20 and 21 of the RTS call for. Your organization owns its access policies and control decisions, and an independent auditor or competent authority assesses the result.
How we scope
- Written scope lists the ICT systems, applications and privileged paths in which identities and access rights are managed.
- Scope identifies which systems support critical or important functions, since they drive the six-month review cycle.
- Scope states which remote, emergency and physical access paths are in or out, with the responsible internal owner named.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- Single sign-on design, such as Keycloak, so users authenticate centrally instead of separately in each application.
- Lifecycle workflows for joiners, movers and leavers, with records of identity assignment kept after reorganizations or contract end.
- Role and access certification campaigns, such as midPoint, with designated reviewers and set decision timeframes.
- Strong authentication configuration for remote, privileged and publicly accessible assets, with generic and shared accounts limited.
How we hand over
- Documentation of the identity architecture, role model, segregation-of-duties rules and access review procedure.
- Evidence packs mapping each Article 20 and 21 requirement to the configuration, logs and review records that show it.
- Runbooks so your staff can run reviews, revoke access and answer assessor questions after the engagement closes.
- Confirmation with your own compliance and legal teams of how the output maps to your DORA obligations.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover recurring access review cycles, configuration drift checks and platform upgrades.
- Ask us to confirm in writing which parts of support, testing and evidence collection are included in your quote.
- DeployOpen prepares systems and evidence only. Audit reports and attestations come from independent assessors.
