Sovereign MDM: On-Premises Intune Replacement for Regulated Organisations

Sovereign endpoint management is the practice of enrolling, monitoring and enforcing security policy on managed devices through infrastructure that remains entirely under the legal control of the operating organisation, without routing device telemetry, identity credentials or configuration data through cloud platforms subject to foreign jurisdiction. For European regulated organisations, this distinction is not architectural preference but a legal requirement that flows directly from the GDPR, NIS-2 and DORA.

Why Microsoft Intune Creates CLOUD Act and GDPR Exposure

Microsoft Intune, as a US-incorporated cloud service, is legally compelled to produce customer data in response to US government orders regardless of where that data is physically stored. This exposure is the reason organisations in public administration, finance, healthcare and law cannot treat Azure-hosted MDM as jurisdictionally neutral.

When a device enrols in Intune, the platform continuously collects hardware identifiers, OS version, patch compliance state, installed application inventory, Wi-Fi and VPN configuration profiles, certificate enrolment records and device health attestation signals. This stream of telemetry flows to Microsoft’s cloud and, because Microsoft is a US person under 18 U.S.C. § 2713 (the CLOUD Act), it remains accessible to US authorities through a single administrative subpoena without prior judicial review in the EU and without notification to the data subject or controller.

The European Data Protection Board has stated explicitly: “Personal data processed by providers subject to US law may be accessed by US authorities under the CLOUD Act regardless of where the data is physically stored.” Hosting Intune data in a Frankfurt or Amsterdam Azure region does not resolve this conflict; it only changes the physical address of the server, not the legal entity responsible for it. GDPR Article 48 prohibits transfers triggered by foreign court orders or administrative decisions unless an international agreement such as an adequacy decision specifically authorises them, and no such agreement covers CLOUD Act production orders directed at a processor.

FISA Section 702 adds a second layer. Foreign intelligence collection authorised under 702 may target communications infrastructure, including device management channels, when the US government determines a foreign intelligence purpose. Organisations managing devices used to process classified, legally privileged or patient-identifiable data cannot accept this residual risk.

Sovereign MDM Platforms That Eliminate Foreign Cloud Dependency

Several platforms can replace Intune while keeping all management traffic, policy data and device telemetry within infrastructure controlled by the organisation or a European hosting partner.

Headwind MDM is the most unambiguously sovereign option for Android fleets. It is Apache-licensed, runs on a single Linux host or a containerised stack, and exposes a REST API that integrates with internal SIEM and SOAR platforms. For organisations managing mixed-OS fleets, pairing Headwind MDM for Android with a self-hosted Apple MDM protocol (APNs dependency is a constraint Apple does not relax) and a Windows management layer based on open standards such as OMA-DM or Windows MDM bridge provides full coverage. NIST SP 800-124r2, published in 2023, explicitly recommends that organisations evaluate whether the MDM platform itself introduces third-party data-sharing risk before selecting a solution.

Enforcing Device Compliance and Feeding Zero-Trust Attestation

Sovereign MDM is not only about data residency: it must also produce machine-readable compliance evidence that a Zero-Trust policy engine can consume in real time before granting access to sensitive resources.

A sovereign deployment enforces compliance across four dimensions. First, disk encryption: the MDM verifies that BitLocker (Windows) or FileVault (macOS) is active and that recovery keys are escrowed to an internal key management system, not to a Microsoft or Apple cloud account. Second, OS patch level: devices that fall below a defined patch baseline are quarantined from internal services until remediated. Third, certificate-based network authentication: SCEP (Simple Certificate Enrolment Protocol) and EST (Enrolment over Secure Transport) allow the MDM to enrol devices against an on-premises or privately operated PKI, issuing short-lived identity certificates that gate access to Wi-Fi SSIDs and VPN concentrators. No certificate means no network access, regardless of whether the user knows the pre-shared key. Fourth, application allow-listing: only approved software versions may run on managed devices, and deviations trigger an automated compliance event.

These four signals, disk encryption status, patch level, certificate validity and application state, are then exported as structured attestation records to the Zero-Trust policy decision point. An on-premises identity-aware proxy or a sovereign ZTNA gateway evaluates each access request against the current attestation record for the requesting device. ISO 27001:2022 control A.8.9 (configuration management) requires exactly this kind of documented, verifiable baseline: the MDM-generated attestation log is the primary evidence artefact for A.8.9 audits.

Meeting NIS-2 and DORA Audit Requirements with On-Premises MDM

Both NIS-2 and DORA impose explicit obligations that map directly onto MDM capability, and both require organisations to produce audit artefacts that demonstrate ongoing compliance rather than point-in-time self-assessment.

NIS-2 Article 21(2)(e) requires measures addressing supply chain security and the security of network and information systems including endpoints used by staff. Competent authorities expect organisations to demonstrate a complete, continuously updated asset inventory, documented patch management procedures with evidence of timely remediation, and configuration baselines that are enforced rather than merely described in policy documents. An on-premises MDM that writes device state to an internal database produces exactly the timestamped, queryable inventory that Article 21 auditors request.

DORA Article 9 requires financial entities to implement ICT asset management covering all devices that process or transmit information relevant to regulated activities. The European Supervisory Authorities have clarified in their regulatory technical standards that this includes mobile and remote devices. A sovereign MDM feeding a configuration management database (CMDB) satisfies the DORA requirement to maintain an accurate register of ICT assets and their configuration state.

According to the IBM Cost of a Data Breach Report 2024, the average total cost of a data breach reached USD 4.88 million, the highest figure ever recorded in the report series. The same report found that 16 percent of all breaches began with stolen or compromised credentials, the precise vector that certificate-based device authentication addresses. For DORA-regulated entities, a breach traced to an unmanaged or poorly managed endpoint would expose the organisation not only to incident notification obligations under DORA Article 19 but also to supervisory scrutiny of whether the ICT risk management framework was adequate.

ENISA has noted in its NIS-2 implementation guidance: “Organisations should ensure that mobile device management solutions are included in their supply-chain security assessments, as unmanaged or externally managed endpoints represent a significant attack surface.” This directly supports the argument that MDM platform selection is itself a supply-chain security decision under NIS-2 Article 21(2)(e).

Securing Remote and Travelling Staff Without Foreign Cloud Routing

The management channel between a travelling device and its MDM platform must itself be protected. When a device is outside the corporate perimeter, policy pushes, certificate renewals and compliance checks all traverse the public internet. Routing this traffic through a sovereign VPN gateway, one that does not terminate at a US-hosted relay, is the baseline requirement.

For organisations already implementing post-quantum-safe network architecture, the MDM management tunnel is a natural candidate for a hybrid key encapsulation mechanism using CRYSTALS-Kyber (now standardised as ML-KEM under FIPS 203) alongside classical ECDH. This protects not only the current session but also the certificate enrolment records and device identity material from harvest-now-decrypt-later interception. A device in a high-risk location, such as a conference or a foreign government network, presents a distinct threat model that a sovereign MDM with quantum-safe transport addresses directly.

Migration Path from Intune to a Sovereign MDM

A phased migration avoids the compliance gap that would arise from withdrawing Intune before the replacement platform is fully operational.

The migration begins with an inventory export from Intune via the Microsoft Graph API, capturing all device records, configuration profiles, compliance policies, application assignments and certificate templates. This export becomes the source of truth for the sovereign platform configuration. In the second phase, the sovereign MDM is deployed alongside Intune in parallel; new device enrolments go to the sovereign platform while existing devices remain on Intune. Certificate templates are reproduced against the internal PKI using SCEP or EST, and application catalogues are mirrored to an internal repository.

In the third phase, devices are migrated cohort by cohort, beginning with a pilot group, then administrative workstations, then field devices and mobile phones. Each cohort is unenrolled from Intune and re-enrolled in the sovereign platform within a defined maintenance window. Compliance policy continuity is verified before Intune licences for the cohort are retired. The final phase is decommissioning the Intune tenant entirely, removing the CLOUD Act exposure at the processor level. Throughout the migration, both platforms write to the CMDB so that the asset inventory, the primary NIS-2 and DORA audit artefact, has no gap period.

FAQ

Does physically hosting Intune data in an EU Azure region solve the CLOUD Act problem?

No. The CLOUD Act applies to the corporate parent, not to the physical location of data. Because Microsoft is incorporated in the United States, US authorities can compel Microsoft to produce data stored in its EU datacentres. Physical location in Europe does not remove the legal exposure.

What is Headwind MDM and how does it differ from Intune?

Headwind MDM is an open-source, self-hosted Unified Endpoint Management platform that runs on infrastructure you control. Unlike Intune, it transmits no telemetry to US-controlled cloud services. It supports Android devices natively and can integrate with third-party agents for Windows and macOS policy enforcement, with all management data remaining on your own servers.

Which NIS-2 and DORA articles specifically require endpoint management controls?

NIS-2 Article 21(2)(e) mandates supply chain security including endpoint asset management. DORA Article 9 requires continuous monitoring of ICT assets and documented configuration management. Both frameworks require organisations to produce audit artefacts demonstrating that these controls are operative and evidenced over time, not merely described in policy.

How do SCEP and EST certificate enrolment protocols support sovereign MDM?

SCEP and EST allow an on-premises MDM to issue device identity certificates from an internal or privately operated PKI. This keeps the entire certificate lifecycle, including private keys and enrolment records, within the organisation’s own infrastructure, eliminating reliance on a US-hosted certificate authority and the CLOUD Act exposure that comes with it.

Can a sovereign MDM solution support staff who travel outside the EU?

Yes. A self-hosted MDM platform reachable via a sovereign VPN gateway, preferably one using post-quantum-safe key encapsulation, allows travelling devices to receive policy updates, compliance checks and certificate renewals without routing traffic through non-European cloud infrastructure. The MDM management channel itself remains under European jurisdiction regardless of the device’s physical location.