MFA Compliance: NIS2, GDPR & DORA Standards Guide
Multi-factor authentication is a requirement — or strong recommendation — in every major security and compliance framework. Mideye Server’s on-premises architecture, comprehensive audit logging, and EU-based data processing make compliance simpler. This page maps Mideye Server’s capabilities to the specific requirements of each framework.
NIS2 — Network and Information Security Directive
Section titled “NIS2 — Network and Information Security Directive”The NIS2 directive (EU 2022/2555) mandates cybersecurity measures for essential and important entities across the EU. Member states have transposed the directive into national law, and enforcement is active.
What NIS2 requires
Section titled “What NIS2 requires”NIS2 Article 21 requires “appropriate and proportionate technical, operational and organisational measures” including:
- Policies on access control and asset management
- Multi-factor authentication or continuous authentication solutions
- Incident handling and reporting
- Supply chain security
- Cryptography and encryption policies
How Mideye Server helps
Section titled “How Mideye Server helps”| NIS2 requirement | Mideye Server capability |
|---|---|
| Multi-factor authentication | Core product — 11 authentication types including push, SMS, TOTP, hardware tokens |
| Access control policies | Per-user and per-group authentication type assignment via LDAP/AD groups |
| Incident detection | Mideye Shield threat intelligence, authentication logging, blocked attempts log |
| Audit logging | Every authentication attempt and administrative action logged with full detail |
| Cryptography | TLS 1.3 for Switch communication, RADSEC for RADIUS encryption, AES for stored data |
| Supply chain security | Swedish company, services hosted in Sweden/EU (operational logs in Sweden) |
| Business continuity | Air-gapped mode for offline operation, dual-redundant Switch, graceful degradation |
Swedish origin as a trust signal
Section titled “Swedish origin as a trust signal”Mideye is a Swedish company. All Mideye-operated infrastructure — Switch, Cloud, support systems — is located in Sweden. For organizations subject to NIS2 in the Nordic and EU region, this eliminates concerns about non-EU data processing and aligns with the directive’s emphasis on supply chain trustworthiness.
GDPR — General Data Protection Regulation
Section titled “GDPR — General Data Protection Regulation”GDPR (EU 2016/679) requires appropriate technical measures to protect personal data. While GDPR doesn’t mandate specific technologies, MFA is widely recognized as a baseline measure for protecting access to systems containing personal data.
How Mideye Server supports GDPR
Section titled “How Mideye Server supports GDPR”| GDPR principle | Mideye Server implementation |
|---|---|
| Data minimization | Mideye only processes the data needed for authentication: username, phone number, authentication type |
| Purpose limitation | Authentication data is used only for access control and audit logging |
| Storage limitation | Configurable log retention periods; audit logs are cleaned up automatically |
| Data protection by design | On-premises architecture keeps credentials and decisions on your infrastructure |
| Security of processing | MFA itself is a “technical measure” for data protection |
| Data residency | All persistent data on your server; message delivery through Sweden-based services (operational logs: 30 days in Sweden) |
Roles and responsibilities
Section titled “Roles and responsibilities”| Role | Who |
|---|---|
| Data Controller | Your organization — you decide what data to process and why |
| Data Processor | Mideye — for message routing through Switch and Cloud (logs retained 30 days in Sweden) |
Mideye processes data only as instructed by you (sending MFA messages to your users). A Data Processing Agreement (DPA) is available for organizations that require formal GDPR documentation.
Data residency
Section titled “Data residency”All persistent data — user accounts, credentials, token seeds, authentication logs, configuration — stays on your infrastructure. Mideye’s services handle message delivery and retain operational logs for 30 days in centralized log analytics (Sweden). Message content (SMS text, OTP codes) is not stored after delivery. See Data Residency for a complete breakdown.
DORA — Digital Operational Resilience Act
Section titled “DORA — Digital Operational Resilience Act”DORA (EU 2022/2554) applies to financial entities and their ICT service providers. It requires strong authentication, operational resilience, and third-party risk management.
How Mideye Server supports DORA
Section titled “How Mideye Server supports DORA”| DORA requirement | Mideye Server capability |
|---|---|
| Strong authentication | Multi-factor authentication for access to ICT systems |
| ICT risk management | Threat intelligence via Mideye Shield; comprehensive audit logging |
| Operational resilience | Dual-redundant Switch, air-gapped fallback, graceful degradation |
| Third-party risk management | On-premises deployment minimizes third-party dependencies; Mideye operates within EU |
| Incident reporting | Authentication logs and Shield alerts provide data for incident analysis |
DORA emphasizes that financial entities must not depend on single points of failure. Mideye Server’s architecture supports this: the authentication engine runs on your infrastructure, the Switch has dual redundancy, and air-gapped mode works without any external service.
ISO 27001 — Information Security Management
Section titled “ISO 27001 — Information Security Management”ISO 27001 is the international standard for information security management systems (ISMS). Annex A defines controls that organizations should implement.
Relevant ISO 27001 controls
Section titled “Relevant ISO 27001 controls”| Control | Description | Mideye Server support |
|---|---|---|
| A.9 — Access control | Restrict access to information and systems based on business needs | MFA for network and application access; role-based admin access |
| A.9.4.2 — Secure log-on | Authentication procedures for access to systems | 11 authentication types; challenge-response; push notifications |
| A.10 — Cryptography | Protect confidentiality and integrity of information using cryptographic controls | TLS 1.3, RADSEC, AES encryption for stored data, BCrypt password hashing |
| A.12 — Operations security | Ensure correct and secure operations | Audit logging, log monitoring, Mideye Shield threat detection |
| A.12.4 — Logging and monitoring | Record events and generate evidence | Authentication logs, blocked attempts, administrative audit logs |
| A.14 — System acquisition | Security in development and support processes | Security updates provided; see Release Notes for changelog |
| A.18 — Compliance | Comply with legal, regulatory, and contractual requirements | Data residency controls, GDPR compliance, DPA available |
Mideye Server’s capabilities align with several ISO 27001 Annex A controls related to access control and cryptography. Mideye does not currently hold ISO 27001 certification.
NIST SP 800-63 — Digital Identity Guidelines
Section titled “NIST SP 800-63 — Digital Identity Guidelines”NIST Special Publication 800-63 defines Authentication Assurance Levels (AALs) for digital identity. While it’s a US standard, it’s widely adopted internationally as a reference framework.
Authentication Assurance Levels
Section titled “Authentication Assurance Levels”| Level | Requirement | Mideye Server capability |
|---|---|---|
| AAL1 | Single-factor authentication | Password-only (auth type 1) |
| AAL2 | Two-factor authentication; approved authenticator types | Push (Touch), SMS OTP, TOTP, hardware tokens — all qualify as AAL2 authenticators |
| AAL3 | Two-factor with hardware-based authenticator and verifier impersonation resistance | Hardware tokens (YubiKey, HID Mini Token) with RADIUS challenge-response |
Phishing resistance
Section titled “Phishing resistance”NIST SP 800-63B emphasizes phishing-resistant authenticators. Push-based authentication (Touch) is resistant to most phishing attacks because the user doesn’t enter a code — they approve a specific login request on their device. Hardware tokens provide the strongest phishing resistance.
Verifier requirements
Section titled “Verifier requirements”NIST requires that the authentication verifier (the MFA server) protects stored credentials. Mideye Server stores passwords with BCrypt hashing, encrypts token seeds with AES, and keeps all credential data on your infrastructure — aligning with the verifier security recommendations.
PCI DSS — Payment Card Industry Data Security Standard
Section titled “PCI DSS — Payment Card Industry Data Security Standard”PCI DSS requires MFA for remote access to systems in the cardholder data environment (CDE).
Relevant PCI DSS requirements
Section titled “Relevant PCI DSS requirements”| Requirement | Description | Mideye Server support |
|---|---|---|
| 8.3 | Secure all individual non-console administrative access with MFA | MFA enforced for VPN and remote access via RADIUS |
| 8.4 | MFA for all remote network access | All remote users authenticate through Mideye’s RADIUS server |
| 10.1 | Implement audit trails | Every authentication attempt logged with timestamp, user, source, result |
| 10.2 | Automated audit trails for all system components | Authentication logs, admin action audit logs |
| 10.5 | Secure audit trails | Logs stored on your infrastructure, access controlled |
PCI DSS explicitly requires that MFA factors come from different categories (something you know + something you have). Mideye Server’s authentication types support this requirement: password (knowledge) + push/SMS/TOTP/hardware token (possession).
Compliance advantages of on-premises MFA
Section titled “Compliance advantages of on-premises MFA”Several compliance benefits are inherent to Mideye Server’s on-premises architecture:
| Advantage | Why it matters |
|---|---|
| Data stays in your jurisdiction | No cross-border data transfer concerns for authentication data |
| You choose the database | Store authentication logs in your own compliant database |
| No third-party credential access | Mideye (the company) never has access to your users’ credentials |
| Audit readiness | All logs are on your server, accessible to your auditors without third-party coordination |
| DPA simplicity | Mideye is a data processor only for transient message delivery; the scope is narrow |
| Air-gapped option | For the highest compliance requirements, remove all external dependencies |
EU data sovereignty
Section titled “EU data sovereignty”Mideye is a Swedish company with all infrastructure in Sweden/EU. For organizations evaluating MFA vendors:
- Swedish company. Mideye is incorporated and operates within Sweden/EU jurisdiction.
- EU jurisdiction. Mideye services operate under Swedish and EU law.
- Operational logs. Operational logs (30 days) are stored in centralized log analytics (Sweden region). Logs are stored and processed within European infrastructure. Logs contain only metadata — no credentials or message content.
- Minimal non-EU exposure. Push notifications pass through Apple APNs and Google FCM (US-based), but payloads contain only challenge identifiers — no user credentials. Air-gapped mode avoids these services entirely.
- Air-gapped mode eliminates cloud dependencies entirely for maximum sovereignty.
For a detailed data flow analysis, see Data Residency.
Next steps
Section titled “Next steps”- Data Residency — Detailed breakdown of where your data lives
- On-Premises vs Cloud MFA — Why deployment model matters for compliance
- Mideye Shield — Threat intelligence for incident detection
- Air-Gapped Authentication — Maximum data isolation