Unified PKI for Mixed MDM Environments: Why Your Single-MDM Certificate Strategy Is Breaking

If you run more than one mobile device management (MDM) system, your certificate strategy is probably already broken. You likely added Jamf for Macs after standardizing on Intune for Windows, picked up Workspace ONE through an acquisition, or layered Kandji on top for iOS. Each MDM came with its own way of asking your public key infrastructure (PKI) for a cert, and every device class now has a different trust path.

This article covers why a unified PKI for mixed MDM environments is the only architecture that holds up past two device platforms, what the NDES-per-MDM trap costs, and what a single-cert-authority-across-MDMs design looks like.

What Is a Unified PKI for Mixed MDM Environments?

A unified PKI is a single certificate authority (CA) that issues, renews, and revokes X.509 certificates for every MDM and OS in your fleet. Every Windows, macOS, iOS, Android, and Linux device pulls its cert from the same root and intermediate, through the same lifecycle automation, instead of through a separate connector and certificate revocation list (CRL) per device manager.

The “mixed MDM” qualifier matters because the alternative is a parallel PKI, or a parallel Simple Certificate Enrollment Protocol (SCEP) gateway, for each MDM. That is what most enterprises end up with by accident. A unified PKI collapses those parallel pipelines into one trust hierarchy, one revocation list, and one policy surface, while letting each MDM use its native enrollment protocol (SCEP, ACME, EST, or a vendor API).

In practice, a unified PKI for mixed MDM means a cloud PKI that integrates natively with Intune, Jamf, Kandji, and Workspace ONE through APIs, instead of a stack of on-premises connectors.

Why Single-MDM Certificate Strategies Break at Scale

The original cert strategy at most enterprises was built for one MDM. Active Directory Certificate Services (AD CS) and Network Device Enrollment Service (NDES) issued certs to Intune devices. When a second MDM showed up, the strategy did not get redesigned; it got copied.

Three things go wrong as soon as you have more than one MDM:

• Trust anchors drift. If two MDMs each get their own issuing CA, you push two different roots to your network access policy. Every RADIUS server, firewall, and VPN gateway has to trust both. One gets forgotten on the next refresh.
• Validity periods desync. Intune defaults differ from Jamf defaults, which differ from Workspace ONE defaults. After a year, you have devices on different validity periods depending on which MDM enrolled them, and renewal windows stop lining up.
• Revocations become per-MDM. Each MDM has its own way of telling its connector to revoke. A user who leaves the company has certs revoked by Intune in minutes and by Jamf in hours, or never if the connector is wedged.

Single-MDM strategies also assume the MDM owns the cert. The moment a device migrates between MDMs (laptop refresh, MDM consolidation, BYOD becomes managed), the cert orphan problem appears. The new MDM cannot revoke the old MDM’s cert, and the old MDM cannot issue a renewal. Most teams handle this manually, which means slowly.

The NDES-Per-MDM Trap

The most common pattern at mixed MDM enterprises is the NDES-per-MDM trap. Each MDM gets its own SCEP gateway, its own service account, its own challenge password rotation cadence, and its own connector to the CA.

A typical setup runs three of these stacks in parallel:

1. AD CS plus NDES for Intune: This is the default path. NDES handles the SCEP challenge, AD CS issues the cert.
2. A separate NDES (or third-party SCEP server) for Jamf: Jamf cannot share NDES with Intune cleanly because the SCEP challenge model assumes one client. Most teams stand up a parallel NDES.
3. A vendor connector for Workspace ONE or Kandji: Each MDM ships its own integration, with its own credentials and update cycle.

NDES has no native high availability, so when the primary node goes down, devices fail enrollment because the secondary does not hold the one-time passphrase. Challenge passwords get rotated by hand. Every added MDM doubles the misconfiguration surface area without doubling operational budget.

The trap is that each connector looks fine in isolation. The cost shows up in cross-MDM incidents that nobody attributes to the architecture.

Operational Cost: Renewal Windows, Revocation Gaps, and Conflicting CRLs

Per-MDM cert strategies fail loudest at three points: renewal, revocation, and validation. These are also where fragmented PKI architecture creates the most security risk.

Renewal Windows

When each MDM controls its own renewal cadence, you cannot run a clean renewal window:

• Intune renews against its own threshold setting.
• Jamf renewals depend on how the configuration profile is scoped and may not trigger until the user opens the company portal.
• Workspace ONE renewal behavior differs again.

Even with the same nominal validity period, your fleet’s actual renewal pattern looks like a smear, not a curve.

Revocation Gaps

This is the one that breaks audits. When you off-board a user, every cert tied to that user must be revoked immediately, everywhere. In a per-MDM world, that means:

• Confirming the revoke fired in Intune, Jamf, and Workspace ONE
• Updating the CRL on each issuing CA
• Pushing those CRLs to every RADIUS server, firewall, and VPN appliance that consumes them

Any of these can lag. There are documented field cases where a revoked cert continued to renew through SCEP because of a CRL publication race condition between the issuing CA and the SCEP gateway. Multiply that race condition by three MDMs.

Conflicting CRLs

If you ended up with one CA per MDM (a common accident), you now have multiple CRLs to publish, distribute, and validate. RADIUS servers must check the right CRL for the right cert. If the network policy trusts both roots but only checks one CRL, a revoked cert from the wrong CA still authenticates. That is a silent authorization failure, not a noisy one.

What a Unified PKI Architecture Looks Like

A unified PKI for mixed MDM has four properties that fix the failure modes above:

1. One root and one issuing CA hierarchyfor every device: Every device, regardless of which MDM enrolled it, chains back to the same PKI hierarchy, so trust only needs to be configured once across RADIUS, VPN, and firewall infrastructure.
2. Native integration with each MDM’s enrollment protocol: The PKI accepts SCEP from Intune, SCEP or ACME from Jamf and Kandji, the Workspace ONE API, and EST or ACME for Linux and IoT. The MDM does not change, and the PKI absorbs the protocol differences.
3. One CRL and one OCSP responder: The PKI publishes revocation events centrally, regardless of which MDM triggered them, and every relying party checks the same source of truth.
4. API-driven lifecycle: Each MDM triggers renewals, revocations, and policy changes via API calls. When a device leaves Intune, the cert revokes automatically. When a device joins Jamf, the cert issues automatically. The PKI treats each MDM as an enrollment client, not the system of record.

This is the architecture cloud PKI vendors are converging on because it is the only one that scales past two MDMs. It also unlocks features that are impossible with NDES, including automatic revocation on device removal, identity-driven cert issuance, and continuous device trust checks.

How SecureW2 Delivers a Unified PKI Across Mixed MDM

JoinNow Dynamic PKI was built for mixed MDM from the start. One trust hierarchy issues certificates to every Windows, macOS, iOS, Android, ChromeOS, and Linux device, regardless of which MDM enrolled it. Native auto-enrollment gateways cover Intune, Jamf, Kandji, and Workspace ONE through advanced APIs. Linux and IoT devices use ACME or EST against the same CA.

Revocation is centralized. When a user is disabled in your identity provider, or a device is removed from any MDM, Dynamic PKI revokes the cert automatically. JoinNow Cloud RADIUS checks the same CRL on every authentication, so a revoked device cannot authenticate to Wi-Fi, VPN, or 802.1X-protected networks even before the next CRL publication cycle. Downstream network policies get simpler when there is only one root to trust, which fits cleanly with a standard 802.1X authentication configuration.

Ready to retire your NDES connectors and consolidate certificates across every MDM you run? Schedule a demo, and we will walk through your Intune, Jamf, Kandji, and Workspace ONE setup.