DORA MFA Requirements: Strong Authentication Without Rewriting Legacy Apps
DORA (the EU Digital Operational Resilience Act) raises the bar on operational resilience—and that includes practical controls that reduce the likelihood of major ICT incidents. One of the most effective (and most auditable) controls is MFA.
You’ll often hear the requirement described as “DORA MFA”, even though DORA typically uses the phrase “strong authentication mechanisms” (not “MFA”) in the ICT risk management framework. The practical takeaway for most financial institutions is the same: implement strong, multi-factor authentication across the access paths that could materially impact your systems, services, and critical operations.
This hub guide covers:
- What DORA expects for strong authentication
- Where to apply MFA first (and the most common gaps)
- A copy/paste audit evidence checklist
- How to cover legacy apps and portals without rewriting them
What does “DORA MFA” mean in practice?
DORA is not a vendor checklist. It’s a resilience framework that expects financial entities to manage ICT risk with policies, controls, testing, monitoring, and governance. “Strong authentication” is one of the controls that supports those outcomes.
In practice, “DORA MFA” usually means:
- Two independent factors for authentication (e.g., password + authenticator app / device-based prompt / security key)
- Stronger controls for privileged access
- MFA coverage for third-party access paths
- MFA coverage for key business applications and portals (not only VPN)
The goal is coverage + governance:
- Coverage: MFA is actually enforced where it matters
- Governance: exceptions are documented, approved, and reviewed
Where to apply DORA MFA first (scope that holds up in audits)
A good DORA MFA program is less about one perfect policy and more about avoiding the common “coverage gaps” that show up during audits or incident reviews.
1) Privileged and administrative access
Start with the “keys to the kingdom”:
- Cloud admin consoles
- Identity provider admin access
- Bastion hosts / jump boxes
- Privileged access to databases, CI/CD, secrets tools, monitoring, virtualization
Why this matters: privileged credentials are high-value targets, and compromise here can rapidly become a major operational incident.
2) Workforce access to business-critical apps
MFA shouldn’t stop at VPN. Ensure coverage for:
- Core operational apps used to deliver services
- Internal web apps and legacy systems used in critical workflows
- Email and collaboration suites (often used for account recovery and lateral movement)
Common gap: “We have MFA for remote access” while critical internal apps remain password-only behind “trusted network” assumptions.
3) Third-party and vendor access
Third-party access paths are frequently exploited because they’re:
- Long-lived
- Poorly governed
- Built on shared accounts or legacy remote access tools
Apply MFA to:
- MSP/outsourcer admin access
- Vendor support portals
- Remote support tooling (and require named accounts where possible)
Best practice: treat vendor MFA coverage as a contract + technical control + monitoring problem, not just policy.
4) External portals that expose sensitive actions or data
Many financial institutions enforce MFA for employees but under-enforce it on:
- Customer portals
- Partner/broker portals
- Supplier or service portals
If portal compromise can lead to data access, fraud, or operational disruption, scope it into strong authentication.
Practical approach: use step-up MFA for sensitive actions to reduce friction while still meeting strong-control expectations.
What counts as “strong authentication” (practical definition)
For most environments, “strong authentication” maps to:
- Something you know (password/PIN)
- Something you have (authenticator app, device prompt, security key, hardware token)
- Something you are (biometrics, used appropriately)
Recommended direction (without over-complicating it)
- Prefer phishing-resistant approaches for privileged access where feasible (security keys or device-bound methods)
- Use risk-based step-up (new device, unusual location, sensitive actions) for portals where usability matters
- Avoid “temporary” exceptions that become permanent
Common DORA MFA gaps (and how to avoid them)
These are the patterns that repeatedly undermine “strong authentication” programs:
- VPN-only MFA while critical apps remain password-only
- Vendor access that bypasses MFA (shared accounts, legacy support tooling)
- Legacy apps that can’t integrate with modern identity
- Inconsistent enforcement across business units (policy drift)
- Exceptions without governance (no approvals, no review dates, no evidence)
If you fix only one thing: make MFA coverage explicit and provable.
DORA MFA audit evidence checklist
Use this checklist to make your program easier to defend during audits, assessments, and incident reviews.
A) Scope and policy
- Written policy defining “strong authentication” and when it is required
- Inventory of systems and access paths in scope (workforce, privileged, third-party, portals)
- Rationale for prioritization (what you covered first and why)
B) Technical enforcement mapping
- System → enforcement point (IdP / gateway / application) → MFA method
- Screenshots/exports of authentication policies (e.g., conditional access rules)
- Admin access
- Third-party access
- Key apps and sensitive portal actions
C) Logs and monitoring
- Authentication logs showing MFA challenges and outcomes (success/failure)
- Alerting/monitoring for anomalous sign-ins (where available)
- Log retention settings and access controls for audit trails
D) Exception governance
- System / access path
- Users affected
- Why MFA can’t be enforced (constraint)
- Compensating controls
- Approver
- Approval date
- Review date
- Evidence links
Evidence of compensating controls (PAM, network segmentation, device trust, etc.)
Periodic review records (at least annually)
How to meet DORA MFA requirements without rewriting legacy apps
This is the real blocker for many teams: “We know we need MFA, but the app can’t support modern authentication.”
Here are proven patterns.
Pattern 1: Enforce MFA through your IdP (best when apps support SSO)
If the app supports SAML/OIDC, enforce MFA centrally via IdP policies:
- consistent enforcement
- centralized logs
- easier audit evidence
Pattern 2: Enforce MFA in front of the application (best for legacy web apps)
When apps can’t be changed quickly or safely, enforce MFA at an access layer (proxy/gateway) so you can:
- add MFA without application code changes
- standardize enforcement across many apps
- centralize logging and evidence
Pattern 3: Step-up MFA for sensitive actions (best for portal UX)
For portals and high-volume user flows:
- Always-on MFA may be too disruptive
- privileged paths (/admin)
- sensitive actions (export, payouts, profile changes)
- off-network access
- risky sign-in conditions
How Datawiza helps with DORA MFA coverage
Datawiza Access Proxy enforces strong multi-factor authentication (MFA) in front of any web app—using either Datawiza MFA or your existing IdP—without rewriting the application.
Datawiza helps financial institutions enforce strong authentication across legacy web applications and external portals without rewriting those applications. Typical outcomes include:
- MFA added with no code changes
- No forced user migration in many scenarios
- Works with your existing IdP (e.g., Entra ID, Okta) or Datawiza MFA
- Deployment options that fit on-prem, cloud, and hybrid environments
- Centralized enforcement patterns and logs to support audit evidence
Next step
Book a quick demo to see how you can add MFA to your legacy applications and support DORA strong-authentication goals—fast, with no code changes, and no disruption to your business.
