How should financial institutions apply strong authentication to remote workforce access under DORA?

How DORA Treats Remote Workforce Access

Under DORA, remote access is not just a generic login problem. It is an ICT risk question: the institution must apply authentication strength in line with the sensitivity of the asset, the exposure of the access path, and the role being exercised. That is why remote network access, privileged access, and access to critical or publicly accessible ICT assets deserve the strongest controls.

For financial institutions, the practical test is whether the access path materially increases the chance that stolen credentials, phishing, or session abuse could reach important systems. If it does, the authentication requirement should tighten accordingly, and the policy should be documented inside the ICT risk management framework rather than handled as an ad hoc access rule.

Why Phishing-Resistant MFA Becomes the Default for Higher-Risk Paths

Strong authentication under DORA should be risk-based, but “risk-based” does not mean “optional.” For remote workforce access, phishing-resistant MFA is the right baseline when users can reach sensitive production systems, administrative interfaces, or assets exposed beyond the internal network boundary.

That generally means preferring methods that bind the authenticator to the session or device, rather than one-time codes that can be intercepted, relayed, or socially engineered. The point is not to maximize friction, but to make remote compromise significantly harder at the exact points where the institution would absorb the most harm.

A useful implementation rule is to distinguish between low-consequence remote work and privileged or operationally sensitive access. The former may be covered by standard strong authentication; the latter should trigger a higher assurance method and tighter conditional access decisions.

How to Operationalize the Policy in a Financial Institution

DORA implementation works best when authentication is mapped to access classes, not user titles. Remote users who only consume low-risk internal services should not inherit the same control burden as administrators, operations staff, or third parties with reach into critical environments.

A strong policy usually has three parts. First, define the assets and access paths that require the strongest authentication. Second, assign the required method by risk tier. Third, ensure the policy can be evidenced through logging, access reviews, and formal approval within the ICT risk management process.

That makes the control auditable. It also prevents a common failure mode where “strong authentication” exists on paper but is bypassed for legacy VPNs, emergency accounts, or privileged remote sessions that were never brought under the same governance.

Risk and Threat Considerations

Remote access increases exposure because the attacker only needs to defeat the weakest login path, not the whole internal environment. Phishing, credential theft, MFA fatigue, token replay, and help-desk social engineering all become more valuable when remote access reaches privileged or critical systems.

Failure mechanism: A weaker remote authentication method, or an exception path that bypasses the standard method, can let an attacker convert a stolen password or intercepted session into valid access to production or administrative systems.

Impact: That can lead to data theft, service disruption, privilege escalation, and broader ICT compromise, especially when the remote path reaches assets that support core financial operations.

Practitioner Guidance

What to prioritise: Treat remote privileged access and remote access to critical assets as the first candidates for phishing-resistant MFA. Those paths create the highest downside if they are downgraded to convenience-driven authentication.

What to verify: Confirm that the access policy distinguishes user populations and asset classes, and that exceptions for break-glass, legacy, or third-party access are time-bound and explicitly approved.

Common mistake: Rolling out “MFA” without checking whether the chosen method resists phishing and session replay. Under DORA, that is often not enough for higher-risk remote access.

Practitioner takeaway: The control objective is not universal uniformity, but proportional assurance, the more sensitive the remote access path, the harder it should be to authenticate into it.

Related resources from NHI Mgmt Group

• How should financial institutions balance DORA compliance with customer authentication experience?
• How should financial institutions align IAM and third-party access with DORA?
• How should financial institutions govern remote onboarding under the new EU AML rules?
• How should financial institutions govern privileged access for DORA compliance?