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.
Why the migration choice is really a trust-state decision
The practical question is not just whether devices can be redeployed faster, it is whether the current enrollment can be trusted to leave behind nothing that still works. In-place migration preserves continuity, but it assumes you can cleanly remove prior management authority, certificates, and policy residue before the next enrollment becomes authoritative.
That makes the decision highly dependent on the device estate itself. If there is any doubt about residual trust anchors, orphaned certs, stale management profiles, or incomplete unenrollment, a full wipe is the safer reset because it re-establishes a known baseline rather than trying to unwind state in place.
When in-place migration is a defensible option
In-place migration is best treated as a controlled exception for mature environments with tight orchestration, clear sequencing, and reliable device telemetry. It is most defensible when the existing enrollment can be fully revoked, user data must be preserved, and the organisation can prove that the old management plane no longer retains effective control.
Operationally, that means migration tooling, identity removal, certificate revocation, and re-enrollment must be coordinated as one change window. If any step can lag behind, the device may sit in a partially managed state where both old and new policy stacks compete, which is where hard-to-diagnose access and compliance problems usually begin.
- NIST SP 800-53 Rev 5 Security and Privacy Controls supports treating device lifecycle, configuration, and authentication state as controlled security functions rather than ad hoc admin tasks.
- NIST Cybersecurity Framework 2.0 aligns with the need to govern, identify, protect, and recover device trust state across migration steps.
- CIS Benchmarks are useful when you want the rebuilt device state to land on a hardened, known-good configuration after the wipe or re-enrollment.
Why a full wipe is the safer default when trust cannot be proven
A full wipe is the better choice whenever the organisation cannot confidently verify that old trust material has been removed. It is also the cleaner answer when the device may contain cached credentials, orphaned certificates, local policy drift, or unmanaged software state that could survive re-enrollment and undermine the new posture.
That is why wipe is often the right decision for higher-assurance fleets, sensitive roles, or environments where posture drift has already occurred. The wipe does not just remove data, it collapses ambiguity about what management authority still exists on the endpoint.
Risk and Threat Considerations
The main risk in in-place migration is false confidence: the device can look re-enrolled while still retaining enough prior state to authenticate, sync, or inherit policy in unintended ways. That creates exposure from stale certificates, residual management channels, and orphaned access paths that are difficult to detect after the fact.
Failure mechanism: An incomplete unenrollment leaves trust anchors, tokens, or device registrations active long enough for the old and new management states to overlap, or for an attacker to abuse leftover access before the new enrollment is fully authoritative.
Impact: The organisation can end up with inconsistent policy enforcement, unauthorized access, failed revocation assumptions, and a device estate that is harder to audit, support, and recover with confidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Device migration depends on re-establishing a known baseline. |
| IA-5 — Authenticator Management | Orphaned certificates and residual trust material are the core migration hazard. | |
| Recommendation — Rebuild migrated devices from an approved baseline and validate configuration state before returning them to service. Revoke and replace device authenticators and certificates before trusting the new enrollment. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The wipe-versus-migrate decision turns on whether the endpoint can be returned to a hardened state. |
| Recommendation — Reset devices to a hardened standard before reintroducing them into management. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets are managed consistent with the organization’s access control policies and business requirements. | Managed devices must not retain unmanaged access state after migration. |
| Recommendation — Ensure device access state matches policy after re-enrollment and before production use. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Migration is fundamentally a configuration-state control problem. |
| Recommendation — Control device configuration changes so residual state is removed or intentionally preserved. | ||
Practitioner Guidance
What to verify: Before choosing in-place migration, confirm that unenrollment actually removes certificate trust, management profiles, and any device-level access paths that could survive re-enrollment. If you cannot verify those outcomes, treat the device as wipe-required.
Decision rule: If the device supports business-critical user state that must be preserved and you can enforce a tightly sequenced unenroll, revoke, and reenroll process, in-place migration is reasonable. If the device is sensitive, inconsistent, or difficult to attest, use a full wipe.
Practitioner takeaway: The right choice is the one that leaves you with a provable trust reset, not merely a successful redeployment.
Related resources from NHI Mgmt Group
- How do organisations decide whether to use a managed AI service alone or place an AI gateway in front of it?
- Why do managed devices still need PKI when organisations already use endpoint management platforms?
- What should organisations put in place before allowing employees to use personal devices for work?
- How can organisations reduce the risk of stale API keys and machine tokens?