Something shifted in enterprise security conversations across Europe over the past eighteen months. Organizations that had migrated authentication infrastructure to cloud services — or were planning to — started asking questions they hadn’t asked before. Not about features or pricing, but about where authentication data actually lives, who processes it, and what happens during a vendor incident.
The questions aren’t coming from security teams. They’re coming from compliance officers, legal counsel, and external auditors working through the practical implications of three regulatory frameworks that either took effect or gained serious enforcement teeth in 2024–2025: DORA, NIS2, and an increasingly aggressive GDPR enforcement posture from national data protection authorities.
The short version: cloud MFA works well for most organizations. For a specific subset — financial entities under DORA, operators of essential services under NIS2, and any organization processing EU personal data at scale — “cloud MFA” and “compliance” are not automatically synonymous. The gap between them is where on-premise authentication infrastructure has re-emerged as a serious architectural consideration.
The New EU Regulatory Landscape in 2026 — DORA, NIS2, and GDPR Enforcement
Three frameworks are reshaping how European organizations think about authentication infrastructure.
DORA (Regulation EU 2022/2554) — the Digital Operational Resilience Act — applies to financial entities, including banks, insurance companies, investment firms, payment institutions, and their critical ICT third-party providers. It became enforceable in January 2025. DORA’s most operationally significant requirement for authentication infrastructure is its treatment of information and communication technology (ICT) third-party risk. Under Articles 28–30, financial entities must identify, classify, and manage all ICT third-party dependencies. Cloud authentication providers are ICT third-party services. This means using one requires formal due diligence, contractual provisions that meet DORA’s specifications, and ongoing monitoring. For organizations with dozens of ICT third-party relationships already in scope, adding a cloud MFA provider to that register is not trivial.
NIS2 (Directive EU 2022/2555) expanded the scope of cybersecurity obligations to a significantly broader set of essential and important entities — energy, transport, healthcare, digital infrastructure, water, public administration, and others. NIS2 Article 21 requires appropriate technical and organizational measures, including multi-factor authentication, with supply chain security explicitly in scope. Authentication infrastructure is a node in the supply chain. NIS2’s reporting timelines — 24-hour early warning, 72-hour incident notification — also have implications for authentication failures. If authentication infrastructure goes down and the provider is a third party, the investigation and reporting obligation falls on the entity, not the provider.
GDPR is not new, but enforcement scrutiny continues to increase. The European Data Protection Board’s 2024–2025 enforcement actions have increasingly focused on data processor relationships and international data transfers. Authentication event data — usernames, IP addresses, timestamps, device identifiers — is personal data. Processing it through a cloud service typically creates a controller-processor relationship that requires a Data Processing Agreement, an assessment of the processor’s technical and organizational security measures, and, for providers operating infrastructure outside the EU, a Transfer Impact Assessment. National DPAs in Germany, France, and the Netherlands have fined organizations specifically for inadequate processor due diligence.
Why Cloud MFA Alone Often Fails Compliance Audits
Cloud MFA fails compliance audits not because it’s insecure, but because the compliance questions being asked are about data residency, sub-processor disclosure, third-party risk, and audit log access — and cloud services don’t always produce satisfying answers to those questions.
Data residency. GDPR requires organizations to know where personal data is processed. Most cloud MFA providers operate a globally distributed infrastructure. When an auditor asks “where are authentication events for EU users processed and stored?”, the answer from a global SaaS provider is often a list of regions that may include non-EU infrastructure. Some providers offer EU data residency as a configuration option; many don’t, or charge a premium for it. Organizations that assumed their cloud MFA was EU-resident and discovered otherwise during an audit have had to scramble.
Sub-processor disclosure. Cloud services use sub-processors — infrastructure providers, CDN services, monitoring tools. GDPR Article 28 requires data processors to disclose sub-processors and obtain controller authorization before engaging new ones. Some cloud MFA providers’ sub-processor lists run to dozens of entities across multiple jurisdictions. Each one is a potential point of auditor scrutiny.
Third-party risk under DORA. A financial entity using cloud MFA must assess that provider under DORA’s ICT third-party risk framework. This includes evaluating the provider’s business continuity arrangements, security practices, and concentration risk. If the provider experiences an outage, the financial entity’s own operational resilience obligations are implicated. DORA’s concentration risk provisions specifically address scenarios where many regulated entities depend on the same critical ICT provider — a description that fits several major cloud MFA vendors.
Audit log access. Compliance audits for PCI DSS, HIPAA, and ISO 27001 require access to authentication logs. Cloud MFA providers offer log access through their platforms, but the log data lives in the provider’s infrastructure. For organizations that need to demonstrate continuous log retention, tamper evidence, or perform forensic analysis, depending on a third party’s log export functionality introduces operational risk.
Real audit findings in regulated sectors have followed this pattern: auditors identify that authentication event logs are held by a third-party cloud provider, flag this as a data processing arrangement that wasn’t fully documented, and require remediation. The remediation is either a complete processor assessment and DPA update, or moving authentication processing in-house.
On-Premise MFA — What It Actually Solves for Compliance
On-premise MFA addresses the compliance gaps above through architectural simplicity: if authentication processing happens on your own infrastructure, most of the third-party data processing questions don’t arise.
Full audit control. Authentication event logs — every attempt, result, timestamp, user, and service — are written to your own storage. No export dependency, no third-party retention policy, no need to coordinate with a vendor for forensic access. Auditors can inspect logs directly. This is straightforward to document and straightforward to demonstrate.
No external dependencies. OTP validation happens locally, against token seeds stored in your infrastructure. There is no outbound API call during authentication. This eliminates the vendor-side availability risk that DORA’s operational resilience requirements are designed to manage. It also eliminates the network dependency that makes cloud MFA impractical for air-gapped or highly isolated environments — common in energy sector OT networks, defense contractors, and certain government systems that NIS2 now brings into scope.
Supply chain isolation. NIS2 Article 21’s supply chain security requirements apply to dependencies in your security controls. An on-premise authentication platform that, once deployed, requires no external connectivity for its core function reduces reliance on external service providers. Vendor lock-in risk is also lower: OATH TOTP is an open standard, allowing organizations to migrate tokens and integrations more easily than with proprietary MFA ecosystems.
A note on architecture. On-premise doesn’t mean a single server in a closet. Enterprise-grade deployments use clustered configurations — typically a minimum three-node setup with load balancing and master-slave replication — that can provide availability comparable to cloud services, under organizational control. Protectimus On-Premise Platform, for example, supports clustering architecture with automatic failover and multidomain Active Directory support. The operational overhead is real, but for organizations with strict compliance requirements, it’s a known cost.
Practical Architecture for Compliant On-Premise MFA
The typical on-premise MFA deployment for a regulated European organization integrates at three points: Active Directory, VPN/remote access, and federated applications.
Active Directory integration happens through an agent installed on domain controllers — in Protectimus’s implementation, this is the DSPA component — that continuously updates Active Directory passwords with dynamically generated one-time passwords. MFA enforcement applies to all services authenticating through AD without per-service reconfiguration. For financial entities with complex AD forests built through M&A activity, multi-domain support is a practical requirement, not a nice-to-have.
VPN and remote access integration uses RADIUS — the standard protocol for network access authentication. The on-premise RADIUS server sits between the VPN gateway and the authentication platform. This covers Cisco ASA, Fortinet, Palo Alto, Check Point, and virtually any RADIUS-compatible access infrastructure. Remote access is specifically called out in PCI DSS v4.0 Requirement 8.4.2 as requiring MFA — an on-premise RADIUS integration satisfies this without creating a cloud data processing dependency.
Federated applications — Microsoft 365, SharePoint, Salesforce, and custom SAML relying parties — integrate through ADFS. The MFA platform becomes an additional authentication provider in the ADFS pipeline. Selective enforcement by application is supported, which matters for organizations doing phased rollouts or applying different authentication policies to different risk tiers.
Clustering for HA. Production deployments for regulated entities require high availability — authentication downtime has both operational and compliance implications. A minimum three-node cluster with HAProxy load balancing and database replication across nodes is designed to minimize single points of failure. NIS2’s focus on operational resilience and DORA’s continuity requirements both support this as a design requirement rather than an optional enhancement.
Conclusion
The regulatory argument for on-premise MFA in European financial services and critical infrastructure is not about distrust of cloud services. It’s about a specific set of compliance obligations — data residency documentation, processor due diligence, supply chain risk assessment, audit log control — that cloud MFA deployments handle inconsistently and that on-premise deployments handle by removing the third-party from the picture entirely.
DORA, NIS2, and GDPR enforcement have moved from theoretical risk to operational reality for compliance officers. The organizations working through the implications — mapping ICT third-party dependencies, responding to auditor questions about authentication data processing, assessing concentration risk in their security stack — are arriving at on-premise MFA not as an ideological preference, but as the architecture that produces the cleaner compliance outcome.
The checklist for compliance officers evaluating authentication infrastructure: data residency check, audit trail control, vendor independence, supply chain isolation, operational resilience under NIS2 and DORA continuity requirements. On-premise MFA addresses each point directly. Whether that trade-off is worth the operational overhead depends on the organization — but for regulated entities operating under the EU frameworks described here, the question is increasingly not whether on-premise MFA makes sense, but how quickly it can be implemented.
