🇪🇺 DORA Password & Access Control Requirements for Financial Firms (2026)
Most European financial firms spent 2024 racing to meet a single deadline: 17 January 2025, the day the Digital Operational Resilience Act — DORA — started to apply. More than a year on, the scramble has shifted from "are we in scope?" to "can we evidence it?" And when supervisors and auditors open the ICT risk file, one of the first folders they reach for is access control: who can log in, how they authenticate, and how tightly privileged accounts are held. If your password and identity controls are still running on legacy habits, DORA is where that shows up.
This guide translates DORA's access-control and authentication expectations into concrete password, MFA, and privileged-access controls your financial firm needs in 2026 — what the regulation actually requires, why each rule exists, and a practical checklist auditors want to see evidenced.
Why DORA Matters for Passwords and Access
DORA matters because, for the first time, it puts ICT security controls that were once "best practice" into directly enforceable EU law with named accountability at board level. Access management sits at the heart of it. Article 9 of the regulation — "Protection and prevention" — requires financial entities to design and document policies that restrict access to systems and data, and to deploy authentication mechanisms strong enough to match the risk.
The scale is what makes it unavoidable. DORA applies to an estimated 22,000+ financial entities across the EU — banks, insurers, investment and payment firms, crypto-asset service providers, and fund managers — plus the critical ICT third parties that serve them. Weak or reused credentials remain one of the most common entry points in confirmed breaches, which is exactly why identity and access management is treated as a core pillar of operational resilience rather than an IT footnote.
What DORA Actually Requires for Access & Authentication
DORA is deliberately outcome-based, and the detail lives in its Regulatory Technical Standards (RTS) on ICT risk management — Commission Delegated Regulation (EU) 2024/1774. Those standards spell out identity management and access-control obligations. Here are the requirements that most directly shape your password and authentication policy.
| Control area | What DORA and its RTS expect |
|---|---|
| Unique identity | Every user and system gets a unique, attributable identity — no shared or generic accounts for individuals |
| Least privilege | Access limited to what a role legitimately needs, on a need-to-know basis |
| Strong authentication | Authentication methods proportionate to risk; strong methods based on leading practices for remote, administrative, and privileged access |
| Password policy | Documented rules for credential strength, storage, and change — aligned to recognised standards, not composition theatre |
| Privileged access | Privileged and administrative accounts tightly restricted, individually assigned, and closely monitored |
| Logging & monitoring | Access and authentication events logged to support detection and forensic review |
| Periodic review | Access rights reviewed and recertified regularly; revoked promptly on role change or exit |
Notice what's missing: a magic number of characters. DORA does not prescribe an 8- or 15-character minimum. It expects you to choose a password standard, justify it, and enforce it — which is why so many firms anchor their DORA password policy to NIST SP 800-63B, the most widely referenced modern benchmark.
Strong Authentication and MFA
The phrase that recurs throughout DORA's technical standards is "strong authentication … based on leading practices" for remote access, administrative access, and privileged operations. In 2026 that language points squarely at multi-factor authentication — and, for your highest-risk accounts, phishing-resistant MFA.
A password alone no longer satisfies the "strong" bar for anything sensitive. The pragmatic reading for financial firms is:
- All remote access to corporate systems should sit behind MFA, not a password alone.
- Administrators, finance staff, and privileged users should move to phishing-resistant factors — FIDO2/WebAuthn security keys or passkeys — which resist the credential-phishing and push-fatigue attacks that defeat one-time codes.
- The underlying password still matters. MFA is a second layer, not an excuse for a weak first one; each credential should be long, unique, and screened against known-breached values.
This is where DORA and standards like NIST converge on the same message we make throughout this site: strength comes from length and uniqueness, backed by a second factor — not from forcing a symbol into Summer2026!. If you want the mechanics of the second factor, see our guide to two-factor authentication.
Privileged Access Is Where Audits Focus
If DORA has a single pressure point on identity, it is privileged access. Administrator credentials are the keys to the estate, and the regulation's technical standards single them out for tighter treatment: individually assigned (never a shared admin login), authenticated with strong methods, used only for the task at hand, and logged so activity can be reconstructed after an incident.
Practically, that pushes financial firms toward a privileged access management (PAM) approach: vault the privileged credentials, rotate them, broker sessions, and record what privileged users do. Long, randomly generated passwords are the raw material for that vault — a service account protected by Winter2026! is exactly the finding an auditor will flag. The same discipline underpins our three-tier password strategy, where the most sensitive accounts get the strongest, most isolated credentials.
How to Bring Your Firm into DORA Access Alignment
Here is a practical, ordered checklist to move a legacy access model toward DORA alignment in 2026. None of it requires a multi-year programme — most of it is policy plus the right tooling.
- Adopt a documented password standard — anchor your policy to NIST SP 800-63B: long minimums, no forced rotation, no composition rules, and breach screening at creation.
- Eliminate shared accounts — give every human and service a unique, attributable identity so access is traceable.
- Enforce least privilege — map roles to the minimum access required and remove standing entitlements nobody uses.
- Put remote access behind MFA — no corporate system should be reachable with a password alone.
- Upgrade privileged accounts to phishing-resistant MFA — FIDO2 keys or passkeys for admins, finance, and other high-risk roles.
- Vault and rotate privileged credentials — use a PAM or enterprise password manager to store, rotate, and monitor privileged secrets.
- Screen every password against breach data — block known-compromised credentials at the point of creation.
- Recertify access regularly — schedule periodic access reviews and prompt revocation on role change or departure.
- Log and evidence it — retain authentication and access logs, and keep written policy. DORA is as much about provable governance as technical controls.
Much of this becomes a configuration exercise the moment you roll out a business password manager. A tool like NordPass Business generates long random passwords by default, screens them against breach databases, enforces policy centrally, supports MFA, and produces the access audit trail DORA assessors expect. You can also pair it with the TitanPasswords generator to mint strong, unique credentials for service and privileged accounts on demand.
FAQs About DORA Password & Access Requirements
What is DORA?
DORA is the EU's Digital Operational Resilience Act, Regulation (EU) 2022/2554. It creates a single set of rules for how financial entities and their critical ICT third-party providers manage technology risk, including access control and authentication. It has applied across the European Union since 17 January 2025.
Does DORA set a specific password length?
No. DORA is outcome-based and does not mandate a character count. It requires strong authentication, unique identities, least-privilege access, and a documented password policy aligned to leading practices such as NIST SP 800-63B — in effect, long, unique, breach-screened passwords plus MFA for privileged and remote access.
Who has to comply with DORA?
An estimated 22,000+ financial entities in the EU — banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers, and fund managers — plus the critical ICT third-party providers (such as cloud and software vendors) that serve them.
What does DORA require for privileged access?
Privileged and administrative accounts must be individually assigned, authenticated with strong methods based on leading practices, restricted to what the task requires, logged and monitored, and reviewed periodically. Firms typically meet this with MFA, a PAM tool, and enforced least privilege.
What are the penalties for non-compliance with DORA?
National competent authorities can impose administrative penalties and remediation measures on financial entities. For designated critical ICT third-party providers, the Lead Overseer can levy periodic penalty payments of up to 1% of average daily worldwide turnover for each day of non-compliance, for up to six months.
Automate DORA-aligned access controls with NordPass Business — breach screening, MFA, policy enforcement, and audit trails built in.