MDM migration from Cisco Meraki exposes endpoint identity drift

At a glance

What this is: This is a technical guide to migrating endpoints off Cisco Meraki Systems Manager, with the key finding that successful transitions depend on clean deprovisioning, token reassignment, and profile removal.

Why it matters: It matters because endpoint management migrations are identity transitions, and IAM, NHI, and device governance teams all need to prevent orphaned control, stale access, and configuration drift.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read JumpCloud's guide to migrating from Cisco Meraki Systems Manager

Context

An MDM migration is not just a software swap. It is a change in who owns endpoint policy, which cryptographic trust chain signs configuration, and which enrollment portal asserts device identity. In identity terms, the critical risk is not the new platform itself, but the gap between deprovisioning the old management authority and establishing the new one.

For teams running device fleets, this is a governance problem as much as an operations problem. If the old management profile, cloud token, or push certificate remains active after migration, the device can sit in a split state with stale controls, orphaned payloads, or broken enrollment trust.

That is why endpoint transition work belongs in the same conversation as lifecycle governance, privileged access, and non-human identity control. The device is a managed identity, and the migration succeeds only when ownership, revocation, and re-enrollment happen in the right order.

Key questions

Q: How should teams prevent orphaned management profiles during an MDM migration?

A: Teams should remove the old management authority first, then confirm that the endpoint no longer receives policy from the retired platform before enrolling it elsewhere. The main control is sequencing. If the device is offline, still supervised, or blocked from receiving the unenrollment command, treat it as still governed by the old MDM until logs prove otherwise.

Q: Why do MDM migrations create endpoint identity risk?

A: Because the device is not just hardware. It carries trust bindings, certificates, and policy claims that behave like identity state. When those bindings are not fully transferred or revoked, the endpoint can drift into a split-brain condition where neither platform has clean authority and both operational teams assume the other side completed the handoff.

Q: What signals show an MDM transition is not complete?

A: Look for stale profiles, orphaned certificates, missing organisation identifiers, failed push delivery, and devices that still appear in the retired platform's inventory. A complete transition should show the old authority removed, the new authority enrolled, and no residual corporate payloads left behind.

Q: When should organisations choose a factory reset instead of in-place migration?

A: Choose a factory reset when the endpoint must be fully re-owned, when residual policy state would create compliance risk, or when a supervised device must be rebuilt from a known-clean baseline. In-place migration is only suitable when the team can verify that the old profile has been removed without leaving hidden management residue.

Technical breakdown

Cloud enrollment token reassignment

Cloud enrollment portals such as Apple Business Manager, Apple School Manager, and Android Zero-Touch act as identity binding points for hardware. When administrators move serial numbers from one MDM token to another, they are changing the authoritative link between the physical device and the management server. If that mapping is not updated cleanly, the endpoint may continue presenting itself to the old authority or fail to trust the new one. The operational risk is not just failed enrollment, but a device that remains logically claimed by a retired control plane.

Practical implication: Validate token ownership changes before profile removal so the device never loses its authoritative enrollment binding.

Unenrollment commands and profile eviction

Meraki unenrollment depends on a remote command sent through the dashboard API and delivered over push channels such as APNs or FCM. Once the endpoint receives the command, the operating system validates the signature and removes managed apps, certificates, and configuration payloads. On supervised devices, this process is more deterministic because the profile cannot be casually removed by the user. If the device is offline or the push chain is misconfigured, the unenrollment event never lands and the old profile persists locally.

Practical implication: Confirm command delivery and signature validation before cutting over to the replacement MDM.

In-place migration versus factory reset

Factory reset and in-place migration solve different trust problems. A wipe removes structural remnants, cached policies, and orphaned certificates, then rebuilds trust from a clean state. In-place migration preserves user data and applications, but it also preserves the possibility of stale profiles, timing failures, and configuration drift if the old profile is not fully removed. In identity terms, the first method resets ownership, while the second attempts to transfer it without losing continuity. The trade-off is between operational simplicity and residual state.

Practical implication: Choose wipe-based transition for high-control fleets and reserve in-place migration for devices where residual state can be verified and cleared.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Endpoint migrations expose a governance assumption that device identity can be transferred without a control gap. That assumption works only when the old authority is fully revoked before the new one takes over. In this workflow, the device can remain bound to stale profiles, expired tokens, or orphaned payloads if the sequencing fails. Practitioners should treat migration as a lifecycle event, not a tooling change.

Cloud enrollment mapping is a hardware identity control, not an administrative convenience. ABM, ASM, and Zero-Touch are the trust anchors that decide which MDM can assert authority over a device. If the serial number mapping is not updated correctly, the endpoint may preserve the old management relationship even after the software stack changes. The practical implication is that enrollment authority must be treated like any other binding credential.

Profile persistence is the failure mode that makes MDM migration risk visible. Stale management profiles, orphaned certificates, and local policy remnants are all symptoms of incomplete deprovisioning. That failure pattern shows why endpoint governance and NHI lifecycle controls are converging. A device that still carries the old management state is still partially owned by the old control plane.

Clean migration requires the same discipline as offboarding any managed identity. The real question is not whether the target platform can enroll devices, but whether the previous control can be fully retired first. When migration is handled as ownership transfer, review, revocation, and re-enrollment become one sequence. Practitioners should align endpoint migration with identity lifecycle governance rather than treating it as a systems-engineering task alone.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why unmanaged identity transitions so often become hidden control failures.
• For a lifecycle lens on this problem, see the NHI Lifecycle Management Guide, which shows how provisioning, rotation, and offboarding fit together.

What this signals

Endpoint control is becoming an identity lifecycle problem. As fleets move between MDM platforms, the decisive risk is whether old management authority is fully revoked before the new one begins. Teams that already manage service accounts, certificates, and tokens as lifecycle assets should extend the same discipline to device management portals and push credentials.

Migration runbooks should now include identity-state validation, not just device-state validation. That means checking cloud enrollment mappings, confirming profile eviction, and verifying that the retired platform no longer has residual claim over the endpoint. In practice, this is where configuration drift becomes governance drift.

The broader signal is that non-human identity work is expanding beyond APIs and workloads into managed endpoints. Organisations that treat device ownership, certificate trust, and enrollment authority as part of one control plane will have less residual risk when platforms change.

For practitioners

• Map the old and new trust anchors Document every device binding that points to the retired MDM, including ABM, ASM, Zero-Touch, APNs, and Android Enterprise service accounts. Do not begin cutover until each binding has a named owner and a verified replacement path.
• Sequence unenrollment before reenrollment Run targeted unenrollment through the original dashboard API before you push the new enrollment flow. This prevents dual control states where both management planes believe they own the same device.
• Audit for stale profiles after cutover Check endpoint logs and local management state to confirm the old organisation identifier has been removed, then verify that certificates, profiles, and corporate payloads no longer reference the previous platform.
• Use wipe-based migration for high-risk fleets Prefer a full factory reset for corporate-owned hardware when the business requirement is non-removable supervision or when residual policy state would create unacceptable drift.

Key takeaways

• MDM migration is an identity transition, because the device keeps policy, trust, and ownership state that must be revoked and re-established in sequence.
• The main failure pattern is residual control, including stale profiles, orphaned certificates, and broken enrollment bindings that survive the handoff.
• Teams that cannot prove old authority removal should default to a clean rebuild, especially for supervised or compliance-sensitive fleets.

Key terms

• MDM authority transition: The process of moving endpoint management control from one MDM platform to another without leaving the device in a partially governed state. It requires revoking the old authority, re-binding enrollment, and validating that new policy delivery works before the handoff is considered complete.
• Cloud identity assertion: A portal-based binding that maps a physical device to a specific management authority, usually through a serial number and server token. These assertions determine which MDM can enroll, supervise, and enforce policy on the endpoint, so they function like ownership records in device governance.
• Stale profile: A management profile that remains on an endpoint after the originating MDM should no longer control it. Stale profiles are a sign of incomplete unenrollment and can preserve certificates, applications, or policy settings that keep the old authority alive after migration.

Deepen your knowledge

MDM migration, endpoint ownership, and identity-state validation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping device lifecycle governance to a similar transition problem, it is worth exploring.

This post draws on content published by JumpCloud: migrating from Cisco Meraki Systems Manager to a replacement MDM. Read the original.