On-Premise MFA: Complete Guide to Self-Hosted Multi-Factor Authentication (2026)
Cloud-based authentication is the path of least resistance for most organizations. Faster to deploy, no infrastructure to maintain, someone else’s problem when it breaks at 2 AM. For a significant portion of enterprises, that trade-off is perfectly acceptable.
For the rest — those operating under GDPR, DORA, NIS2, PCI DSS, or HIPAA, those running air-gapped networks in defense or critical infrastructure, those whose compliance auditors ask uncomfortable questions about where authentication data actually lives — the calculus looks different. When users authenticate to systems containing cardholder data or electronic protected health information, authentication data often falls under strict compliance and data residency requirements. In a cloud MFA deployment, that data leaves your network. In an on-premise deployment, it doesn’t.
This guide explains how on-premise MFA architecture works, why it is still required in 2026 for organizations under strict compliance or network isolation constraints, and how it compares with cloud and private-cloud alternatives. For Protectimus product specifics — pricing, deployment specs, supported tokens, and demo — see the Protectimus On-Premise MFA Platform page.
Table of Contents
Quick Answer
On-premise MFA is a self-hosted authentication architecture where the OTP validation engine, user database, token secrets, and audit logs all run inside your own infrastructure — physical servers, virtualized environments, or private cloud. No authentication request leaves your network.
This guide explains why regulated industries still choose this model in 2026, how the architecture works, what it protects, and how it compares with cloud-based alternatives.
For Protectimus product specifics — pricing, supported tokens, deployment specs, and demo — see the
Protectimus On-Premise MFA Platform →
Key facts
99.9% of attacks blocked by MFA
Microsoft reports that MFA blocks over 99.9% of account compromise attacks — the single highest-impact control against credential-based intrusions. (Microsoft Digital Defense Report)
$4.4M average breach cost in 2025
The global average cost of a data breach reached $4.44 million in 2025, while US organizations hit an all-time high of $10.22 million (IBM Cost of a Data Breach Report 2025)
22% of breaches via credential abuse
Credential abuse was the initial access vector in 22% of breaches; 88% of Basic Web Application attacks involved stolen credentials. (Verizon 2026 Data Breach Investigations Report)
Key Takeaways
Authentication Stays On-Prem
All OTP validation, token secrets, and audit logs run inside your own network. No external dependency for authentication processing.
High-Availability Clustering
Production deployments use clustered multi-node architecture (typically 3+ nodes) with load balancing and database replication.
Multidomain Active Directory
Native support for multi-domain Active Directory environments, with centralized authentication management from a single platform instance.
Broad Service Coverage
Protects AD, VPN gateways, ADFS-federated apps, Windows logon and RDP, OWA, and custom web applications.
Compliance Coverage
Helps meet PCI DSS v4.0, HIPAA, NIST SP 800-63B, SOC 2, ISO 27001, GDPR, DORA, NIS2.
Air-Gapped Capable
Operates without internet connectivity after deployment — the only viable architecture for classified and ICS environments.
Why On-Premise MFA Matters in 2026
The honest answer is that most organizations don’t choose it — they’re pushed toward it by constraints that make cloud MFA non-viable.
GDPR treats authentication event data — usernames, timestamps, IP addresses, validation results — as personal data. Routing it through a cloud authentication provider creates a data processing relationship that requires a DPA, a security assessment, and potentially a transfer impact assessment. DORA classifies authentication services as ICT services, making cloud MFA providers subject to its third-party risk management requirements. NIS2 Article 21 puts authentication infrastructure dependencies in scope for supply chain risk assessment.
For financial institutions, healthcare providers, and critical infrastructure operators, keeping authentication in-house often simplifies compliance reviews and reduces third-party risk exposure.
Air-gapped networks are the harder constraint. Classified government systems, defense contractor environments under ITAR or CMMC, industrial control system networks, and certain financial trading infrastructure are typically unable to route authentication requests to external APIs. On-premise is the only architecture that works.
On-Premise MFA vs Cloud MFA vs Private Cloud
Factor | On-Premise | Cloud MFA | Private Cloud |
Authentication data location | Your servers | Vendor infrastructure | Your cloud tenant |
Air-gapped support | Yes | No | Depends |
External connectivity required | No | Yes | Yes (cloud provider) |
Latency | LAN — predictable | Internet-dependent | Internet-dependent |
HA / clustering | Self-managed (3-node recommended) | Provider-managed | Self-managed |
Third-party audit scope | None | Full vendor assessment | Cloud provider in scope |
Time to deploy | Days | Hours | Hours to days |
Private cloud combines many of the benefits of on-premise MFA with the operational flexibility of cloud infrastructure. Authentication data remains within the organization’s dedicated cloud environment rather than a shared SaaS platform, while the underlying cloud provider remains part of the compliance and risk assessment scope. For organizations already running regulated workloads in AWS or Azure with appropriate contractual coverage, it offers a balance between control and operational flexibility.
How Protectimus On-Premise MFA Works
The platform has three functional layers:
Authentication engine. The OTP validation engine implements OATH TOTP, HOTP, and OCRA standards. Authentication requests arrive via RADIUS, DSPA, or API. The engine validates the OTP against the token seed stored locally and returns pass or fail. No seed material ever leaves your infrastructure — at provisioning or validation time.
Integration layer. Protocols, plugins, and integration components that connect protected systems to the authentication engine:
- RADIUS — VPN gateways, network access controllers, Wi-Fi, and other RADIUS-based systems
- DSPA — OTP-based authentication for Active Directory, LDAP directories, and connected services
- ADFS plugin — federated access to Microsoft 365, SharePoint, Salesforce, and other applications connected through ADFS
- Windows Credential Provider — Windows logon and RDP protection, including offline authentication support
- Web application plugins and API integrations — Outlook Web App, Roundcube, custom web applications, and services integrated through REST API or SDK
Management and audit layer. Integration with Active Directory, LDAP directories, and other user data sources keeps user accounts synchronized automatically. Authentication event logs — every attempt, timestamp, result — stay local. The Self-Service Portal handles token enrollment, synchronization, and device replacement without administrator involvement.
Enterprise Features: Clustering, High Availability, Multidomain AD
Production on-premise MFA deployments typically use a clustered multi-node architecture with load balancing and database replication — so that authentication continues if a node fails. The minimum viable high-availability setup is three nodes (for quorum) with a load balancer in front and master-slave database replication behind.
Multidomain Active Directory support enables integration with complex enterprise environments containing multiple domains or directory structures. LDAP synchronization can be configured across separate directories while maintaining centralized authentication management from a single platform instance.
The Protectimus On-Premise MFA Platform supports clustered deployments with multiple platform nodes, HAProxy load balancing, and replicated PostgreSQL databases. See the full deployment architecture, system requirements, and rollout timeline on the Protectimus On-Premise MFA Platform →
Supported MFA Methods
Method | Phishing Resistance | Offline | Self-Service Recovery |
High | Yes | Yes (cloud backup) | |
High | Yes | No (admin replaces) | |
Medium | No | N/A | |
Low-Medium | No | N/A | |
Low-Medium | No | N/A | |
Medium | No | Yes (cloud backup) |
For environments where mobile devices are prohibited — manufacturing floors, secure facilities, classified networks — hardware OATH TOTP tokens are typically the preferred second factor. Standardized on OATH means tokens are vendor-portable: an OATH TOTP token from one provider works with another OATH-compliant validation engine.
Protectimus offers four hardware token models for these scenarios, including programmable NFC cards and SHA-256 fixed-seed tokens. See all hardware token options →
TOTP-based methods (authenticator app and hardware tokens) are operationally the strongest choice for most enterprise on-premise deployments. Both generate codes locally without internet connectivity. Both produce 30-second codes that are worthless to an attacker who intercepts them after they expire.
What Services Can Be Protected
Active Directory, LDAP, and databases. With Protectimus DSPA, on-premise MFA protects directory accounts at the directory level, extending protection to Windows logon, RDP, VPN access, OWA, and any AD-bound application. Group-based scoping lets you start with privileged accounts before extending coverage. Protectimus implements directory-level MFA via DSPA (Dynamic Strong Password Authentication) →
VPN gateways via RADIUS. Covers Cisco ASA, Cisco Firepower, Fortinet, Palo Alto, Check Point, Juniper, and most RFC 2865-compliant VPN gateways. UDP 1812 inbound from the gateway is the primary network requirement. For a worked example, see MFA for Cisco AnyConnect →
ADFS and federated applications. A plugin integrates as an additional authentication provider in the ADFS pipeline, enabling MFA protection for all federated services routed through ADFS — Microsoft 365, SharePoint, Salesforce, and others. See ADFS integration →
Windows logon and RDP. A Windows Credential Provider protects desktop and server logons, with offline validation support via one-time backup codes for workstations that cannot reach the authentication server. See Windows logon & RDP MFA →
Outlook Web App and web applications. OWA integration for Exchange 2013–2019. Roundcube via plugin. Custom web applications via REST API or SDK. See OWA integration → and Roundcube integration →
Deployment Requirements
On-premise MFA platforms have modest hardware requirements — a few CPU cores and several GB of RAM per node are typically enough for the authentication engine itself. Storage scales primarily with audit-log retention.
A standard single-domain rollout — one AD forest, one VPN gateway, standard workstations — is achievable in one to two days, including pilot testing. Full rollout time then depends on the number of integrations and the enrollment approach (self-service portal or bulk CSV provisioning).
Existing RADIUS infrastructure — including Cisco ISE and FreeRADIUS — can typically be preserved by integrating the new authentication platform as a RADIUS proxy layer with minimal configuration changes.
For exact Protectimus deployment specs (CPU, RAM, storage, supported OS and database, step-by-step rollout timeline), see the Protectimus On-Premise MFA Platform →
Industry Use Cases & Compliance
Sector | Compliance Driver | Notes |
Financial services | PCI DSS v4.0, SOX, DORA | Hardware tokens for regulated and high-security environments; DSPA for AD |
Healthcare | HIPAA, HITECH | Hardware tokens for EVV workflows and MFA for shared clinical workstations |
Government / Defense | NIST 800-63B, FISMA, CMMC | Air-gapped deployments and hardware token support |
Energy / Critical infrastructure | NERC CIP, NIS2 | On-premise MFA and hardware tokens for isolated ICS and OT environments |
Telecom | NIS2 | MFA for distributed telecom and multi-site network infrastructure |
PCI DSS v4.0 Requirement 8.4.2 mandates MFA for all remote access into the cardholder data environment — no exceptions. DORA makes cloud authentication providers ICT third-party vendors requiring formal due diligence. HIPAA Technical Safeguards (45 CFR §164.312) require access controls for ePHI systems; HHS explicitly recommends MFA for remote access. OATH TOTP is widely used to support NIST SP 800-63B AAL2 authentication requirements.
FAQ
What is on-premise MFA and how does it differ from cloud MFA?
On-premise MFA runs the full authentication stack — OTP engine, user database, token secrets, audit logs — on your own servers. Cloud MFA sends authentication requests to a vendor’s infrastructure for processing. The end-user experience is identical: a second-factor prompt. The difference is where processing happens and whether external connectivity is required. On-premise validates OTPs locally with no outbound calls. Cloud MFA stops working if the vendor’s API is unreachable.
Why do regulated industries prefer on-premise MFA in 2026?
Three reasons. First, data residency: GDPR, DORA, and PCI DSS impose requirements on where authentication data is processed; on-premise MFA keeps it entirely under organizational control. Second, air-gapped networks: classified and critical infrastructure environments cannot route requests to external APIs — on-premise is the only architecture that functions. Third, audit simplicity: no third-party authentication processor means no vendor security assessment in scope for compliance audits.
Can Protectimus On-Premise MFA work in air-gapped networks?
Yes. All OTP validation runs against token seeds stored locally. No outbound call is made during authentication. The platform operates without internet connectivity after initial deployment. Pre-provisioned hardware tokens support fully isolated air-gapped deployments.
What are the hardware requirements for on-premise MFA deployment?
Recommended minimum per node: 2-core CPU, 8 GB RAM, 20 GB storage, Linux or Windows. Production HA deployments typically use a 3-node cluster with a load balancer. The same deployment requirements apply to physical, virtual, and private cloud environments, including AWS and Azure.
Does on-premise MFA support clustering and high availability?
Yes. Recommended minimum is a 3-node cluster with HAProxy load balancing and primary-replica database replication. Automatic failover routes requests to healthy nodes if one becomes unavailable. Node count beyond three increases both throughput and fault tolerance.
What services can on-premise MFA protect?
Active Directory via DSPA, VPN gateways and other services via RADIUS, federated applications via ADFS plugin, Windows workstation logon and RDP via Windows Credential Provider, Outlook Web App, Roundcube, and custom web applications via REST API.
Is on-premise MFA compliant with GDPR, DORA, PCI DSS, HIPAA?
On-premise is the strongest compliance posture for frameworks with data residency requirements. PCI DSS v4.0 Requirement 8.4.2 can be met by OATH TOTP via RADIUS and other integration components. GDPR compliance is strengthened by eliminating external authentication processor dependencies. DORA third-party ICT risk requirements do not apply to internally hosted infrastructure. HIPAA Technical Safeguards are satisfied with authentication logs retained locally.
How long does it take to deploy Protectimus On-Premise MFA Platform?
Standard single-domain environment — one AD forest, one VPN gateway, standard workstations — achievable in one to two days, including pilot testing. Full rollout depends on integration count and enrollment approach. Self-Service Portal and CSV bulk provisioning reduce administrator load significantly during rollout. Contact Protectimus to scope your specific environment.
Conclusion
On-premise MFA is not the right choice for every organization. Without regulatory data residency constraints or network isolation requirements, cloud MFA is faster and operationally simpler.
For organizations where those constraints are real — where authentication data leaving the network creates compliance exposure, where air-gapped architecture makes external API calls impossible — on-premise is the only architecture that works. Protectimus On-Premise MFA Platform covers the full deployment in this scenario: DSPA for Active Directory, RADIUS for VPN, ADFS for federated apps, Windows Credential Provider for workstations.
See the Protectimus On-Premise MFA Platform — pricing, deployment specs, free trial →
