Skip to main content

How to migrate from MDM to XFA

Use this guide when the decision is made: you want to remove MDM from the device-access flow and move fully to XFA. The migration path is simple: map what you will replace, configure XFA, onboard users, switch Enforcement on, then remove the old MDM requirement.

Before you start

You need:

  • An XFA admin role.
  • Admin access to your identity provider.
  • Admin access to the MDM settings you need to remove.
  • The user group you want to migrate first.
  • The applications or identity-provider routes currently protected by MDM-based access rules.
  • A support contact users can reach during rollout.

1. Map what XFA will replace

Before changing access rules, map the places where MDM decides whether a user can reach work applications.

Record:

  1. Which applications depend on an MDM compliance signal today.
  2. Which users or groups are in the first migration wave.
  3. Which access rules, Conditional Access policies, or application policies reference the MDM.
  4. Which group filters, app assignments, or exclusions must change during cutover.
  5. Which message users will receive before the first XFA invite or sign-in check.

This is your removal checklist. The goal is not to compare two systems. The goal is to replace each old access dependency with an XFA decision.

2. Connect Discovery

In XFA, go to Discovery and connect the identity provider used by the migration group:

Discovery shows the devices actually seen in sign-in activity. Use it to build the XFA view before you remove the old MDM-based access requirement.

3. Review the migration group in XFA

Open Devices.

Use:

  1. Devices to review each discovered or verified device.
  2. People to see which users are discovered, invited, onboarding, onboarded, or disconnected.
  3. Discovery results to confirm which devices are actually reaching work applications.

This gives XFA the view it needs before you remove the old requirement from the access path.

4. Create the XFA migration policy

Go to Policies and create the policy that will decide access after the MDM requirement is removed.

Start with a baseline users can understand and fix:

  • Operating system version.
  • Browser version.
  • Disk encryption.
  • Screen lock.
  • Antivirus.
  • Device reboot.

For the first migration wave, choose whether each check should warn or block. Use warn behavior when you want to see failures before enforcement. Use block behavior when a check must pass before the protected application can be reached.

5. Test the flow with yourself first

Before inviting the group, scope the rollout to yourself or a small admin test group.

Check:

  1. You can receive an Awareness test invitation.
  2. You can verify your device.
  3. The device appears in Devices.
  4. A sign-in to the protected application triggers the expected XFA flow.
  5. The policy result matches the checks you configured.

Do this before changing the wider group. It catches wrong policy, wrong configuration, and access issues while the blast radius is small.

6. Onboard the migration group

Go to Awareness and configure onboarding for the migration group.

  1. In Settings for invitations and security alerts, scope the users and device types.
  2. In Onboard your team, enable the invitation channel, such as Send auto-invites through email.
  3. In Onboarding reminders, set Send every to the cadence you want.
  4. In Security awareness, enable risk notifications for users whose verified devices fail policy.
  5. Select Save changes.

Tell users what will happen before invitations go out. Keep the message simple: XFA verifies the security of the device before access, guides users when something needs attention, and respects their privacy.

If users will see XFA during onboarding or sign-in, add a short support note with custom onboarding and sign-in messages. This message appears inside the XFA web-flow and can point users to your support channel or internal migration page.

7. Switch access to XFA Enforcement

Go to Enforcement and protect the application or identity-provider route that will move to XFA.

  1. Select New.
  2. Choose the integration type.
  3. Assign the XFA migration policy.
  4. Test with yourself or the admin test group.
  5. Turn on the behavior you want for the migration wave: warn first, or block when the policy must pass.

For SAML applications, use Create a SAML application in XFA.

8. Remove MDM from the access path

Once XFA Enforcement works for the migration group, remove the old MDM requirement from the sign-in path.

In practice, this usually means:

  1. Disable the rule that requires the MDM compliance signal for the migration group.
  2. Remove the MDM enrollment requirement from the application or identity-provider policy.
  3. Stop sending users through MDM setup as part of sign-in.
  4. Confirm the protected application now depends on XFA Enforcement instead.
  5. Keep the test group available while you monitor the first sign-ins.

Use vendor documentation for the exact removal steps. The important point is sequencing: test XFA Enforcement first, then remove the old requirement.

9. Expand the migration

After the first group is stable, repeat the same sequence for the next group or application.

For each wave:

  1. Confirm the users and applications in scope.
  2. Send the rollout message.
  3. Verify Discovery and Devices.
  4. Enable Awareness and reminders.
  5. Add or update Enforcement.
  6. Remove the old MDM access requirement for that group.

Do not migrate everything at once unless you have already tested the full sign-in experience and support path.

Verify it worked

Check:

  • Your own test sign-in uses XFA, not the old MDM access requirement.
  • The migration group appears in People with the expected onboarding states.
  • Verified devices appear in Devices with the expected posture.
  • The protected application uses the expected XFA policy.
  • A device that fails a blocking check cannot complete sign-in.
  • The identity-provider or application policy no longer requires the MDM signal for the migrated group.

Notes and troubleshooting

  • If users are blocked too early, switch the affected check to warn while you fix the rollout.
  • If users do not receive invitations, check the Awareness scope, group filters, and invitation channel.
  • If users are confused, point them to Install XFA and your internal support contact.