Skip to main content

How to find MDM gaps with XFA

Use this guide when you already have an MDM and want XFA to expose the devices it does not reliably cover. XFA starts from identity-provider activity, finds the devices that actually reach work, verifies posture at sign-in, and guides users to fix issues.

Before you start

You need:

  • An XFA admin role.
  • Admin access to your identity provider.
  • Access to your current MDM device inventory.
  • A rollout group, such as one team, department, contractor group, or application owner.
  • A device policy in XFA, or a draft list of checks you want to require.
  • One application or identity-provider route where XFA should enforce device trust.

1. Connect Discovery

In XFA, go to Discovery and connect the identity provider that holds sign-in activity for the rollout group:

Discovery depends on a connected identity provider. It shows devices seen through sign-in activity, including work devices that never entered the MDM inventory.

2. Find the access gaps MDM inventory misses

Open Devices and compare XFA's device list with the MDM inventory.

Look for:

  1. Devices in XFA that are missing from the MDM inventory.
  2. Users with more work devices than the MDM shows.
  3. Contractor, BYOD, shared, or mobile devices that still reach work applications.
  4. Applications where access is happening outside the MDM's coverage.

This is the value of using XFA during a migration: XFA starts from actual access. It shows which devices touch your work environment, then lets you verify those devices before they reach protected applications.

MDM inventory and real application access answer different questions. For cybersecurity at sign-in, use XFA as the decision point because it verifies the device that is trying to reach work.

3. Choose the first gap to close

Pick one group or application where the gap is visible and meaningful.

Good first targets are:

  • BYOD or contractor devices.
  • Users with discovered devices that are not in the MDM inventory.
  • Applications used from browsers or devices outside the MDM inventory.
  • High-value applications where device posture should be checked at sign-in.

Keep the first rollout small enough that you can test the experience yourself and support users quickly.

4. Define the XFA policy

Go to Policies and create or edit the policy for this rollout.

Start with checks that apply across device ownership models:

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

For a gentle rollout, set the first checks to warn. For high-risk applications, set the checks that must pass before access to block. XFA lets you apply the same posture standard at sign-in, including to devices that were invisible to your old coverage.

5. Onboard users with Awareness or Enforcement

You can onboard users in two ways.

Use Awareness when you want to invite users before they hit a sign-in check:

  1. In Settings for invitations and security alerts, scope the rollout with Desktop devices, Mobile devices, Only unmanaged devices, or Filter by groups.
  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 reminder cadence.
  4. Send yourself a test invitation before saving the wider rollout.

Use Enforcement when you want sign-in to drive onboarding. This is faster, because users meet XFA when they access the protected application. It can also create more friction, so start with a scoped group or warn behavior unless the application needs blocking immediately.

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.

6. Add Enforcement to close the gap

Go to Enforcement and protect the application or identity-provider route you chose.

  1. Select New.
  2. Choose the integration type.
  3. Assign the policy you prepared.
  4. Test with your own user first.
  5. Start with warning behavior if you want visibility before blocking.

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

Verify it worked

Check:

  • Devices shows devices that were missing from the MDM inventory.
  • People shows users moving from discovered or invited states toward onboarded.
  • Your own test invitation arrives and links to the expected XFA flow.
  • Your own sign-in to the protected application shows the expected warning or block behavior.
  • Enforcement shows the protected integration using the expected policy.

Notes and troubleshooting

  • If XFA finds more devices than the MDM, use the identity-provider sign-in trail to understand where those devices are accessing work applications.
  • If a discovered device is not verified yet, use Awareness invitations or an Enforcement flow to guide the user through verification.
  • If users ask about privacy, explain that XFA checks security settings and guides fixes. It does not read personal files, browsing history, messages, or location.
  • When you are ready to remove MDM from the access path, use How to migrate from MDM to XFA.