On-Premises vs Cloud MFA: Deployment & Sovereignty

Choosing between on-premises and cloud-based multi-factor authentication affects where your data lives, how much control you have, and what happens when your internet connection goes down. Mideye Server is an on-premises MFA platform with optional cloud delivery — giving you local control over authentication decisions while still supporting push notifications and SMS delivery through Mideye’s cloud services.

Three deployment models

MFA solutions generally fall into three categories:

Fully cloud-based

The MFA server runs in the vendor’s cloud. Your VPN or application sends authentication requests to the vendor’s infrastructure, which validates credentials and delivers second-factor challenges.

Examples: Duo Security, Okta Verify, Microsoft Entra ID MFA (cloud-only).

Advantages:

No infrastructure to maintain
Automatic updates and scaling
Fast initial deployment

Trade-offs:

Authentication decisions happen outside your network
User data (usernames, phone numbers, authentication logs) stored in the vendor’s cloud
Internet outage = no MFA = no access (unless offline modes are configured)
Vendor controls the data — subject to the vendor’s jurisdiction and data processing agreements
Ongoing subscription costs that scale with user count

Fully on-premises

The MFA server runs entirely on your infrastructure. No data leaves your network — authentication decisions, user data, and logs stay local. Second-factor delivery is limited to methods that don’t require internet connectivity, such as hardware tokens and TOTP authenticator apps.

Advantages:

Complete data sovereignty — nothing leaves your network
Works without internet connectivity (air-gapped)
No dependency on external services for authentication decisions
Full control over updates, maintenance, and lifecycle

Trade-offs:

No push notifications or SMS delivery
Limited to TOTP/HOTP tokens and hardware tokens
You manage the infrastructure (but this may be a requirement, not a trade-off)

Hybrid: on-premises server with cloud delivery

The authentication engine runs on your infrastructure. Credentials and authentication decisions stay local. Cloud services are used only for message delivery — routing SMS codes, push notifications, and Magic Link messages to users’ phones.

This is how Mideye Server works.

Advantages:

Authentication decisions happen on your server, under your control
User credentials, passwords, and token seeds never leave your network
Full range of MFA methods: push, SMS, TOTP, hardware tokens, Magic Link
Cloud services handle delivery only — no credentials in transit
Can operate in air-gapped mode (TOTP only) if internet access is unavailable or prohibited

Trade-offs:

SMS and push notifications require outbound connectivity to Mideye Switch
You manage the server infrastructure (installation, updates, database)

Why on-premises MFA matters

Data sovereignty

When your MFA server runs in the cloud, your authentication data — usernames, phone numbers, authentication logs, and policy configurations — lives on someone else’s infrastructure. You depend on the vendor’s data processing agreements, jurisdiction, and security practices.

With on-premises MFA, you control where data is stored, who has access, and which laws apply. This is particularly important for organizations subject to GDPR, NIS2, or sector-specific regulations that restrict where authentication data can be processed.

Mideye Server stores all persistent data on your infrastructure. Mideye’s cloud services handle message delivery — phone numbers and message content pass through Mideye Switch for SMS routing but are not stored after delivery. Operational logs (metadata only, no message content) are retained for 30 days in centralized log analytics in Sweden. See Data Residency for a detailed breakdown.

Authentication decisions stay local

In a cloud MFA model, the accept/reject decision happens on the vendor’s server. If the vendor’s service is degraded, compromised, or unavailable, your authentication system is affected.

With Mideye Server, the RADIUS Access-Accept or Access-Reject is always issued by your server, running on your infrastructure. Even if Mideye’s cloud services are temporarily unavailable, authentication types that don’t require cloud delivery (on-premise TOTP, hardware tokens) continue to work.

No vendor lock-in for access control

Cloud MFA vendors typically require you to integrate tightly with their platform — their agents, their SDKs, their APIs. Switching vendors means re-integrating every application and device.

Mideye Server uses RADIUS, the universal standard for network access authentication. Your VPNs and firewalls already speak RADIUS. Switching to Mideye means pointing your RADIUS clients at a new server — not re-architecting your access infrastructure.

Internet independence

Cloud MFA fails when your internet connection fails. For organizations with mission-critical access requirements — emergency services, utilities, healthcare — this is unacceptable.

Mideye Server’s air-gapped mode provides MFA with zero internet dependency. Users authenticate with TOTP codes from authenticator apps or hardware tokens, validated entirely on your local server. See Air-Gapped Authentication for details.

When cloud MFA makes sense

Cloud-based MFA is a reasonable choice when:

Your organization is cloud-first with no on-premises infrastructure to protect
You don’t have regulatory requirements around data residency
Fast deployment matters more than control and customization
You need MFA for cloud-native SaaS applications that don’t support RADIUS
Your IT team prefers managed services over self-hosted infrastructure

Many organizations start with cloud MFA for its simplicity and later add on-premises MFA when regulatory requirements, data sovereignty concerns, or reliability needs grow.

How Mideye Server gives you both

Mideye Server is designed as a hybrid: the authentication engine is on-premises; cloud services are optional and limited to delivery.

Capability	Where it runs	Internet required?
Password validation	Your server	No
OTP generation and validation	Your server	No
Authentication decision (accept/reject)	Your server	No
User lookup (LDAP/AD)	Your network	No
Authentication and audit logs	Your server	No
SMS OTP delivery	Mideye Switch (Sweden)	Yes
Push notifications (Touch)	Mideye Cloud (AKS, Sweden)	Yes
Magic Link	MAS (AKS, Sweden)	Yes
IP reputation (Mideye Shield)	Mideye Cloud (AKS, Sweden)	Yes
On-premise TOTP validation	Your server	No

If your internet connection fails, on-premise TOTP tokens continue to work. If you need to operate without any external connectivity, air-gapped mode disables all cloud features and runs entirely locally.

Graceful degradation

Mideye Server is designed to degrade gracefully:

Normal operation — All MFA methods available: push, SMS, TOTP, hardware tokens, Magic Link.
Mideye Switch unreachable — SMS and push delivery fail, but on-premise TOTP and hardware tokens continue working. Touch-Plus and Touch-Mobile fall back automatically to on-premise TOTP if configured.
All external services unreachable — On-premise TOTP and hardware tokens work. Air-gapped mode covers this permanently.

The authentication decision is always local. External services are used for delivery, never for authorization.

Choosing the right deployment model

Consideration	Cloud MFA	On-premises (Mideye)
Data residency control	Vendor-dependent	Full control
Authentication decision location	Vendor’s cloud	Your server
Internet dependency	Required	Optional (air-gapped available)
MFA methods available	Vendor-dependent	11 types including push, SMS, TOTP, hardware tokens
RADIUS support	Often limited or proxy-based	Native RADIUS + RADSEC server
Compliance simplicity	Depends on vendor’s certifications	Your infrastructure, your jurisdiction
Setup time	Fast	Moderate (wizard-guided setup)
Ongoing maintenance	Vendor-managed	You manage (with package updates from Mideye)
Cost model	Per-user subscription	Per-user license

Next steps

What is Mideye Server? — Product overview and capabilities
Air-Gapped Authentication — MFA without any internet connection
Data Residency — Exactly where your data lives
System Architecture — Components and connections
Compliance & Regulatory Frameworks — How on-premises MFA supports compliance