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.
Why This Matters for Security Teams
An MDM migration only looks simple when the device has a clean enrollment history. In practice, the risk is not the new platform, but the management profile that was never fully removed, leaving the endpoint with two competing sources of authority. That creates a control gap for policy, certificates, app assignment, and compliance state.
NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, a reminder that identity and control-plane drift is usually discovered late, not during planning. The same pattern applies to managed endpoints: if the old authority still has a path to enforce policy, the migration is incomplete. The lifecycle discipline described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs maps directly to this problem because offboarding is a control, not a cleanup task. Current guidance in the NIST Cybersecurity Framework 2.0 also emphasizes governance, asset visibility, and controlled change.
In practice, many security teams encounter orphaned management profiles only after the old MDM has already pushed one last policy or certificate renewal.
How It Works in Practice
The safest migration sequence is to treat the old MDM as authoritative until the endpoint proves otherwise. That means retiring the prior management authority first, verifying unenrollment succeeded, and only then allowing the device to join the new platform. For supervised or heavily restricted devices, confirm that the unenrollment command was received, executed, and recorded. If the device is offline, do not assume removal happened just because the migration workflow advanced.
This is also where identity and device trust intersect. A lingering management profile may still carry certificates, compliance tokens, VPN settings, or app deployment rights. The endpoint can appear healthy in the new console while remaining partially governed by the old one. The NHI Lifecycle Management Guide is relevant here because it frames authority handoff as a lifecycle event with explicit revocation and verification steps.
- Remove or disable the old enrollment authority before re-enrollment begins.
- Verify device logs, MDM receipts, and policy status from the retired platform.
- Check for residual certificates, profiles, and app payloads after unenrollment.
- Block re-enrollment until the endpoint is confirmed clean and under one authority.
For governance teams, the NIST Cybersecurity Framework 2.0 is useful for structuring this as a change-control and asset-management problem, not just an endpoint support task. These controls tend to break down when devices are offline, supervised, or restricted by an always-on profile because the unenrollment command cannot complete and no one notices the residual authority.
Common Variations and Edge Cases
Tighter removal sequencing often increases operational friction, requiring teams to balance migration speed against the risk of leaving a stale control plane behind. That tradeoff matters most in fleets with kiosks, shared tablets, BYOD exceptions, or devices that rarely come online. Best practice is evolving, but there is no universal standard for how long a retired MDM should remain trusted while waiting for unenrollment confirmation.
One common edge case is a device that cannot receive the unenrollment command before it is reassigned. Another is partial migration, where a profile is removed but certificates or app configuration remain active. In both cases, the device may appear migrated while still honoring legacy policy. Teams should keep a rollback plan, preserve audit logs, and require positive proof of removal before issuing new management credentials or profiles. The Top 10 NHI Issues is a useful reference for the broader pattern: unmanaged identity leftovers create invisible access paths.
In practice, orphaned management profiles usually surface when a device misses the last unenrollment window and the old authority remains valid longer than the migration ticket assumed.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers lifecycle cleanup and revocation of lingering identity authority. |
| NIST CSF 2.0 | PR.AC-4 | Addresses controlled access changes and removal of stale access during migration. |
| NIST CSF 2.0 | ID.AM-1 | Device inventory and ownership tracking are essential to prevent orphaned profiles. |
Track each managed device and confirm its current authority before changing MDM platforms.
Related resources from NHI Mgmt Group
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- How should security teams prevent unwanted persistence in Active Directory and Entra ID?
- What is the difference between MDM and user lifecycle management?
- What is the difference between runtime protection and NHI lifecycle management?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
