Mideye GDPR & Data Residency Compliance
Mideye Server Data Residency
Section titled “Mideye Server Data Residency”Understanding where your data lives is critical for compliance. This page explains exactly what data Mideye processes, where it’s stored, and which jurisdictions apply.
For how the components work, see System Architecture. For step-by-step authentication sequences, see Authentication Flows.
Quick summary
Section titled “Quick summary”| Data | Where it lives | Controlled by |
|---|---|---|
| User accounts, passwords, token seeds | Your Mideye Server database | You |
| Authentication logs and audit logs | Your Mideye Server | You |
| Configuration and encryption keys | Your Mideye Server | You |
| SMS content (during delivery) | Mideye Switch (Sweden) — not stored after delivery | Mideye |
| Switch operational logs | Log analytics (Sweden) — 30 days | Mideye |
| Push notification payloads | Mideye Cloud (Sweden) — not stored after delivery | Mideye |
| Cloud operational logs | Log analytics (Sweden) — 30 days | Mideye |
| Magic Link sessions | Mideye Cloud (Sweden) — session duration only | Mideye |
| IP reputation data | Mideye Cloud (Sweden) | Mideye |
Key principle: Your credentials and authentication decisions never leave your infrastructure. Mideye’s cloud services only handle message delivery and session coordination.
Data at rest (your infrastructure)
Section titled “Data at rest (your infrastructure)”All persistent data lives on your Mideye Server:
| Data type | Storage location | Notes |
|---|---|---|
| User accounts and attributes | Your database (MySQL, MariaDB, or MsSQL) | You choose the database |
| Passwords and hashes | Your database | Never sent to Mideye |
| TOTP token seeds | Your database | Encrypted |
| Authentication policies | Your database | Per-client and per-user |
| Authentication logs | Your database | Every attempt logged |
Encryption keys (keystore.p12) | Your server file system | You manage the keys |
Configuration (application-prod.yml) | Your server file system | All settings local |
Data in transit (through Mideye services)
Section titled “Data in transit (through Mideye services)”When a user authenticates, some data passes through Mideye’s services for delivery purposes:
Through Mideye Switch (Sweden)
Section titled “Through Mideye Switch (Sweden)”| Data | Purpose | Retention |
|---|---|---|
| Phone numbers | Route SMS to the correct carrier | Not stored after delivery |
| OTP codes | Deliver via SMS | Not stored after delivery |
| Push/Touch requests | Route to Plus services in the cloud | Not stored |
| Token validation requests | Forward to Yubicloud or HID | Not stored |
| Operational logs (metadata only) | Service monitoring and troubleshooting | 30 days (log analytics, Sweden) |
The Switch does not store message content after delivery. Operational logs (timestamps, delivery status, error codes) are retained for 30 days in centralized log analytics in Sweden for monitoring and troubleshooting. These logs do not contain usernames, passwords, OTP codes, or authentication policies.
Through Mideye Cloud
Section titled “Through Mideye Cloud”| Data | Purpose | Retention |
|---|---|---|
| Magic Link sessions | Host the approval page | Session duration only |
| Push notification payloads | Deliver approve/reject challenge to app | Not stored after delivery |
| IP addresses | Shield threat assessment | Configurable |
| RADIUS session events | Session management in Mideye+ app | Session duration only |
| Operational logs (metadata only) | Application monitoring and troubleshooting | 30 days (log analytics, Sweden) |
Mideye Cloud runs in Europe-based cloud infrastructure in Sweden. Operational logs (timestamps, API requests, error codes, performance metrics) are retained for 30 days in centralized log analytics for monitoring and troubleshooting. These logs do not contain user credentials, OTP codes, or message content.
Through third-party services
Section titled “Through third-party services”Push notifications and SMS pass through external providers:
| Service | Data processed | Provider location |
|---|---|---|
| Apple Push (APNs) | Device token, notification payload | USA (Apple) |
| Google Push (FCM) | Device token, notification payload | USA (Google) |
| SMS providers | Phone number, message content | Varies by carrier |
| Data transfers to US-based push notification services are governed by the respective provider terms. Both Apple and Google participate in the EU-US Data Privacy Framework. | ||
| Push notification payloads contain only a challenge identifier — no user credentials, no authentication tokens. |
What stays in your network
Section titled “What stays in your network”These data types never leave your infrastructure:
- Usernames, passwords, and credentials
- LDAP/AD queries and responses
- RADIUS shared secrets
- Authentication decisions (accept/reject)
- All audit and authentication logs
- Token seeds and encryption keys
Mideye infrastructure locations
Section titled “Mideye infrastructure locations”All Mideye-operated services run in Sweden:
| Service | Data center | Location |
|---|---|---|
| Mideye Switch (Primary) | Swedish DC 1 | Sweden |
| Mideye Switch (Secondary) | Swedish DC 2 | Sweden |
| Mideye Cloud | Europe-based cloud (Sweden) | Sweden |
Both Switch data centers are within EU jurisdiction and subject to Swedish data protection law.
GDPR compliance
Section titled “GDPR compliance”Mideye is a Swedish company subject to GDPR.
| Role | Who |
|---|---|
| Data Controller | Your organization (you decide what data to process) |
| Data Processor | Mideye (for message routing through Switch and cloud services) |
In an on-premises deployment where you only use Mideye Switch for SMS delivery, Mideye’s role as processor is limited to message routing and operational logging (30-day retention in Sweden).
Security capabilities
Section titled “Security capabilities”Mideye provides the following security capabilities that organizations may evaluate for their regulatory requirements:
| Capability | Implementation |
|---|---|
| Multi-factor authentication | Core product capability |
| Access control | User and group policies |
| Audit logging | Comprehensive authentication logs |
| Incident detection | Failed login monitoring, Mideye Shield |
| Supply chain security | Swedish/EU hosting (operational logs in Sweden) |
Data sovereignty
Section titled “Data sovereignty”EU data
Section titled “EU data”All Mideye-operated services process data exclusively within the EU:
- Mideye Switch: Sweden
- Mideye Cloud: Sweden
- Support systems: Sweden/EU
Non-EU data transfers
Section titled “Non-EU data transfers”The following services may transfer data outside the EU:
| Service | Transfer destination | Mechanism |
|---|---|---|
| Apple Push (APNs) | USA | Provider terms; EU-US Data Privacy Framework |
| Google Push (FCM) | USA | Provider terms; EU-US Data Privacy Framework |
| SMS delivery | Carrier-dependent | Varies |
If your compliance requirements prohibit non-EU data transfers, use authentication methods that don’t require push or SMS:
- On-premise TOTP (authenticator apps or hardware tokens)
- Air-gapped mode (no Mideye cloud connectivity needed)
US jurisdiction considerations
Section titled “US jurisdiction considerations”Your Mideye Server data (user accounts, credentials, token seeds, authentication logs, configuration) is stored on your infrastructure and is not subject to US jurisdiction.
Mideye operational logs are stored in centralized log analytics (Sweden region, 30 days retention). Logs are stored and processed within European infrastructure. These logs contain only operational metadata (timestamps, delivery status, error codes) — not user credentials, OTP codes, or message content.
Message delivery services (Apple Push, Google FCM) are US companies. Push notification payloads contain only challenge identifiers, not credentials.
For maximum data sovereignty, use air-gapped mode with on-premise TOTP authentication, which eliminates all external dependencies.
Next steps
Section titled “Next steps”- System Architecture — How the components work together
- Authentication Flows — See exactly what data moves during each flow