TL;DR: Migrating from Cisco Meraki Systems Manager requires cleanly removing old management control, reassigning device tokens, and preserving APNs or Android Enterprise trust so endpoints do not drift, lose control, or keep stale profiles, according to JumpCloud. The governance lesson is that endpoint identity transitions fail when lifecycle and cryptographic ownership are not treated as one process.
At a glance
What this is: This is an analysis of MDM migration from Cisco Meraki Systems Manager and the main finding is that endpoint identity drift appears when deprovisioning, token reassignment, and certificate handoff are not coordinated.
Why it matters: It matters because IAM, IGA, and endpoint security teams have to govern device identity transitions as lifecycle events, not as isolated admin tasks, or old management trust can persist after cutover.
Context
MDM migration is the process of moving endpoint management authority from one platform to another without losing control of the device. In this article, the core problem is not the migration tool itself but the governance gap that appears when deprovisioning, certificate control, and enrollment ownership are handled separately.
For identity teams, the article is really about endpoint identity lifecycle management. If a device is still anchored to the old management plane after cutover, the organisation can end up with orphaned profiles, broken policy enforcement, or a device that no longer matches the intended trust state.
Key questions
Q: What breaks when an MDM migration does not fully remove the old management profile?
A: The device can keep stale configuration, certificates, or policy bindings that belong to the previous MDM, which creates drift between the intended control plane and the actual endpoint state. That usually shows up as orphaned profiles, inconsistent enforcement, or a failed re-enrollment path that leaves IT unable to prove which system is authoritative.
Q: Why does endpoint migration create identity risk instead of just operational downtime?
A: Because management authority is part of the device’s trust state. If deprovisioning, token reassignment, and push authentication do not complete together, the old relationship can linger and continue to shape policy enforcement. That creates a governance failure, not just a support issue, because access and control are no longer aligned.
Q: How can security teams tell whether an MDM cutover is actually complete?
A: They should verify three things: the old profile has been removed locally, the endpoint no longer reports the previous organisation identifier, and the new MDM can successfully issue policy or wipe commands. If any of those checks fail, the device still carries residual trust state and the migration is not finished.
Q: Should organisations use in-place migration or a full wipe for managed devices?
A: Use a full wipe when the environment cannot tolerate residual trust state or orphaned certificates. In-place migration is faster and preserves user data, but it only works if the organisation can tightly coordinate unenrollment and re-enrollment. The choice depends on how much leftover policy state you are willing to accept.
Technical breakdown
How MDM authority transitions work
An MDM authority transition shifts cryptographic control and configuration enforcement from one management server to another. The endpoint is not just receiving new settings; it is being re-attested to a new management relationship through enrollment tokens, signed profiles, and push channels such as APNs or FCM. That means the old authority must be removed cleanly before the new one can safely take over. If the transition is incomplete, the device may still trust the previous management plane even though the new platform is active.
Practical implication: Treat endpoint migration as a controlled authority handoff, not a profile swap.
Why stale profiles and orphaned tokens appear
Stale profiles appear when unenrollment never reaches the endpoint or when the device cannot complete the removal sequence. In this article, that can happen through network isolation, expired enrollment tokens, or a broken APNs handshake. The result is a local profile that remains installed even after the cloud record has moved on. This is a lifecycle failure in the management layer, because the endpoint and the control plane no longer agree on who owns the device.
Practical implication: Verify that unenrollment, token reassignment, and push authentication all complete before declaring migration done.
How supervised state and enrollment mode change the risk
Supervised devices, automated enrollment, and BYOD workflows do not behave the same way during migration. Corporate-owned devices can be wiped and re-enrolled with stronger control, while BYOD devices require selective removal that preserves personal data. In-place transitions are faster, but they increase the chance of residual policy conflict if the old profile is not fully evicted. The more the organisation tries to preserve state, the more carefully it must govern what remains trusted on the endpoint.
Practical implication: Choose the migration path based on how much residual trust state you can safely tolerate.
Threat narrative
Attacker objective: The operational objective is not classic compromise but unmanaged persistence of the old management state long enough to disrupt secure device control and policy enforcement.
- Entry occurs when the endpoint remains connected to the old MDM relationship because the unenrollment command is not delivered or not processed.
- Credential and control access persist through stale profiles, orphaned certificates, or expired enrollment tokens that keep the old trust chain alive.
- Escalation happens when the replacement MDM cannot establish a clean handshake, allowing configuration drift and policy conflict to accumulate across the endpoint estate.
- Impact is loss of control over endpoint identity state, with orphaned management profiles, downtime, and possible exposure of corporate access paths.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Endpoint identity drift is a lifecycle failure, not a deployment glitch. The article shows that MDM migration breaks when deprovisioning, certificate transfer, and re-enrollment are treated as separate tasks. That separation creates a trust gap where the device can remain partially bound to the old authority while the new one is trying to take control. Practitioners should read this as an identity governance problem spanning endpoint, certificate, and enrollment ownership.
Authority transition is the real control plane in MDM migration. The endpoint is only secure if one management authority is fully retired before the next one becomes trusted. When APNs, Android Enterprise, or cloud enrollment portals are out of sync, the device may accept commands inconsistently or keep stale policy state. The implication is that migration governance must focus on who is authoritative at each stage, not just whether a profile was copied over.
Residual management state creates a hidden blast radius across the endpoint estate. A device that still carries old management artefacts can undermine policy consistency, access enforcement, and support operations even if users believe the migration is complete. In practical terms, the risk is not limited to one failed enrolment. It is the spread of inconsistent trust state across fleets, which makes troubleshooting, compliance, and revocation harder.
Cross-platform device governance needs explicit offboarding discipline. The article makes clear that moving from one MDM to another is structurally similar to offboarding an identity from one control domain and onboarding it into another. Without a clean retirement of the old relationship, the device can remain governed by two partially overlapping sources of truth. Teams should therefore treat endpoint migration as a joiner-mover-leaver event for devices, with ownership, revocation, and verification all tied together.
Endpoint migration failure is a warning about how organisations model trust transitions. The named concept here is endpoint identity drift: the state where the intended management authority no longer matches the active management artefacts on the device. That drift is what creates stale profiles, orphaned policy, and re-enrollment failures. The practical conclusion is that endpoint governance must be measured by trust-state alignment, not by whether a cutover checklist was completed.
What this signals
Endpoint migration should now be treated as a lifecycle governance problem, not a tooling swap. If the old management authority can survive cutover in any form, the organisation has not completed offboarding, only replatforming.
The named concept here is endpoint identity drift: the device’s intended trust state and its actual management artefacts no longer match. That mismatch is what turns migration work into an access-control and compliance problem, because policy enforcement becomes ambiguous the moment two authorities overlap.
For security and IAM teams, the practical shift is to verify trust-state removal before trusting the new management plane. In other words, migration success should be measured by the disappearance of the old authority, not by the presence of the new one.
For practitioners
- Map endpoint offboarding before enrollment cutover Define the exact sequence for retiring the old MDM trust relationship, including unenrollment command delivery, cloud token reassignment, and local profile removal before any new enrollment is trusted.
- Validate push-certificate and token handoff together Check APNs certificates, Android Enterprise service accounts, and cloud enrollment tokens as one migration dependency chain so the target MDM can complete its handshake.
- Use supervised wipe paths where residual trust is unacceptable For corporate-owned devices, prefer full reset or Automated Device Enrollment workflows when the business cannot tolerate leftover profiles, orphaned certificates, or policy conflicts.
- Instrument post-migration verification on the endpoint Confirm that the old management identifier has disappeared from local logs and that the device only reports the new management relationship before declaring the cutover complete.
Key takeaways
- Meraki-to-new-MDM migration fails when endpoint deprovisioning, certificate handoff, and re-enrollment are not executed as one governed lifecycle.
- The main risk is residual trust state, which leaves stale profiles, orphaned certificates, and policy drift on devices that appear migrated.
- Migration controls should prove that the old authority is gone before the new one is accepted as the device’s source of truth.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centres on retiring old MDM authority cleanly during endpoint migration. |
| NHI-09 — NHI Reuse | Reusing endpoint trust state across platforms creates residual identity drift and stale control. | |
| Recommendation — Treat MDM cutover as NHI offboarding and confirm the old authority is fully revoked before re-enrollment. Avoid carrying device trust artefacts across MDM platforms without explicit re-issuance and validation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Device enrollment and policy authority determine what each endpoint is authorised to receive. |
| Recommendation — Verify endpoint authorizations are updated when the MDM authority changes so stale access cannot persist. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | APNs certificates and enrollment tokens are authenticators that must be managed through migration. |
| Recommendation — Rotate, revoke, and validate device authenticators as part of every migration cutover. | ||
| CIS Controls v8 | CIS-5 — Account Management | Migration depends on cleaning up device and service-account access paths across platforms. |
| Recommendation — Remove obsolete device and service accounts when moving endpoints between MDM platforms. | ||
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.
- Endpoint Identity Drift: A mismatch between the management state the organisation intends and the trust artefacts still present on the device. In practice, it shows up when a migrated endpoint still carries old profiles, tokens, or certificates that no longer match the new source of authority.
- Supervised Device State: An operating mode that gives the enterprise stronger control over whether users can remove management profiles. In migration scenarios, it changes how cleanly a device can be offboarded and re-enrolled, especially when residual trust state is unacceptable.
- Stale Management Profile: A leftover device management profile that remains installed after the platform should have removed it. These remnants can preserve old policy, certificates, or enrollment relationships and make the endpoint behave as if it is still attached to the previous MDM.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org