Pre-install XFA through MDM Enterprise plan

XFA does not require an MDM

XFA is made to be self-installed by the team you want to secure. They install it themselves after an invitation through Awareness, or at a login protected by Enforcement. For most organizations that is the whole rollout.

An organization that already manages its devices can pre-install and enroll XFA through an MDM instead, so it is in place the moment someone signs in. This works with Intune, Configuration Manager, Jamf, or any other system that can install a package and run a command as the signed-in user.

When to pre-install

Pre-install when one of these is true:

You already manage these devices centrally, and adding XFA to an existing deployment is less work than asking people to install it.
You want XFA's checks in place from day one, without waiting for each person to accept an invitation, which helps when the checks gate access to something.
You are moving away from MDM-based access controls and want XFA's device checks running alongside your MDM before you rely on them. Start with Migrate from MDM to XFA.

If none of those apply, an invitation is faster to set up and easier to undo.

Running XFA alongside your MDM

XFA runs alongside your MDM and does not compete with it.

XFA does not manage the operating system. It does not configure settings, push policies, or wipe devices. It checks the device's security posture and can warn the user or block access to protected applications. Your MDM keeps doing what it does.
It installs for the user, not the machine, and needs no administrator rights on the device itself. Deploying it through your MDM is a convenience, not a requirement. The same package installs if a person downloads it.
It does not need to be your only agent. A device can be managed by your MDM and checked by XFA at the same time; XFA reports on what it finds rather than taking control.
A device can belong to more than one organization. Removing one organization leaves the others alone, which is why offboarding removes an affiliation rather than the application.

The install command

Whatever system you use, this is the command it runs.

On Windows, the enrollment token is an ordinary MSI property:

msiexec /i XFA.msi /qn ENROLLMENT_TOKEN=<your-enrollment-token>

That is the whole command for a fleet. XFA reads each device's address from the directory, so nothing about the command changes per person.

EMAIL is an optional second property for installing on a single device, where you know whose it is. It sets one address, so a fleet deployment carrying it would enrol every device as that person:

msiexec /i XFA.msi /qn ENROLLMENT_TOKEN=<your-enrollment-token> EMAIL=person@example.com

On macOS, a package cannot take arguments, so the token travels in a configuration profile with the preference domain com.xfa.desktop and the key EnrollmentToken. Email is an optional second key. Deploy XFA.pkg alongside it.

Install it while the person is signed in. The package installs as root, as every macOS package does, and then hands the application to whoever is at the console, so a Mac sitting at the login window ends up with an application owned by root that its user cannot run or update. In Jamf, use the Login trigger. In Intune, assign the app to a user group rather than a device group, so it installs when that person is signed in.

If your system can do either of those, it can deploy XFA, even if it is not listed below.

Packages

Package	Platform
XFA.msi	Windows, x64 and ARM64
XFA-arm64.msi	Windows, native ARM64 only
XFA.pkg	macOS, Apple Silicon and Intel

Use XFA.msi for all Windows devices. On ARM64 it runs under emulation and XFA replaces itself with the native build automatically. Deploy XFA-arm64.msi to an ARM64 device group only if you want native from the first minute.

These links always point at the current release, so a deployment does not need updating when XFA ships a new version.

The packages are signed, and the signer is the same on every release. If your tooling verifies the publisher, pin XFA's identity rather than accepting any valid signature:

macOS: Developer ID Application: XFA (89ZG68UL25) (Team ID 89ZG68UL25).
Windows: the Authenticode certificate whose subject common name is XFA. Read the full publisher from a downloaded XFA.msi with Get-AuthenticodeSignature XFA.msi and pin that.

Choose your system

System	Platform	Guide
Microsoft Intune	Windows	Deploy with Intune
Microsoft Configuration Manager (SCCM)	Windows	Deploy with Configuration Manager
Jamf Pro	macOS	Deploy with Jamf Pro
Anything else	Windows, macOS	Deploy with any other system

Before you start

Pre-installing through an MDM is enabled per organization. If the Pre-install XFA through MDM section is not on your Integrations page, ask XFA to enable it for your organization; until then an enrollment token cannot be created and enrollments are refused.

Open Integrations > Pre-install XFA through MDM in the XFA dashboard and pick your system. The dashboard creates the enrollment token the first time an administrator opens one of these, and shows the finished command with the token already in it.

There is one enrollment token per organization, shared by every deployment. Treat it as a secret and limit access to the policy that carries it. Rotating it stops every copied command that contains the old token; devices that are already enrolled are unaffected.

How XFA picks the user

XFA is a per-user application. Deploy it to users and install it while that user is signed in.

No MDM hands the assigned user's email address to an install command, so XFA works it out on the device. It takes the first of these that gives a valid email address:

Windows

Order	Source	When it applies
1	The `EMAIL` property you passed	Single-device installs only. It sets one address, so it does not belong in a fleet deployment.
2	The `mail` attribute in Active Directory	Domain-joined devices that can reach a domain controller. This is the person's real email address.
3	The account's user principal name	Entra-joined devices, where the principal name is the email address.

macOS

Order	Source	When it applies
1	The `Email` key in the configuration profile	Whenever the profile carries one. The profile the XFA dashboard generates uses your MDM's own variable (`$EMAIL` for Jamf, `{{mail}}` for Intune), so the email address comes from the system that already knows it.
2	The `EMailAddress` record in the local directory	Macs bound to a directory service. Most are not.

If none of them produces a valid email address, XFA stops rather than guessing. On Windows your deployment reports a failure, and %TEMP%\xfa\xfa-enrollment.log on the device says which step ran out of options. On macOS the same detail is in /tmp/xfa/xfa-enrollment.log.

A principal name is not always an email

Active Directory is checked before the principal name because the two often differ. A suffix like someone@corp.local is a valid address as far as XFA can tell, so trusting it first would enrol devices under identities nobody uses, and nothing would say so. Entra accounts use the address as the principal name, so both agree there.

Neither Jamf nor Intune checks that its profile variable was substituted. If it was not, the literal text arrives instead of an address. XFA discards anything that is not an address and falls back rather than enrolling a device as {{mail}}.

Remove XFA from a managed device

To remove only this organization and keep XFA installed, run as the signed-in user:

xfa unenroll --organization-id <organization-id>

It removes that organization only, keeps any other affiliation, and succeeds when the affiliation is already gone.

To remove the application too, follow the uninstall step in your platform's guide above. On Windows those guides ship an uninstall-xfa.ps1 that removes XFA by its stable UpgradeCode, because XFA's product code changes as it updates itself and a plain msiexec /x XFA.msi no longer matches the installed version. On macOS, remove XFA.app. A plain uninstall removes the shared application without unenrolling, so if the device still belongs to another organization, unenroll first and leave the application in place: xfa enrollment-status returns exit code 0 while any affiliation remains, and 10 once it is safe to remove. On macOS, remove the configuration profile first, or the device enrolls again from it the next time XFA starts.

What happens on the device

The package installs for the signed-in user.
XFA enrolls that user in your organization, using the token you supplied.
XFA starts immediately (no sign-out, no restart) and registers itself to start with the device from then on.
The device appears on your Devices page, and XFA keeps itself up to date from then on without further deployment.

Nothing appears on the user's screen. XFA's normal first-run window is deliberately suppressed for a managed installation, so a rollout across a fleet is invisible to the people it reaches.

Result codes

These are XFA's own enrollment result codes. You see them directly when you run the enroll command yourself. Through an MDM you usually see only whether the install succeeded or failed, and the matching reason is written to %TEMP%\xfa\xfa-enrollment.log on the device.

Code	Meaning	What to do
0	Enrolled, or already enrolled	Nothing
1	The command was wrong, or no usable email address	Fix the command; retrying will not help
2	The enrollment token was rejected	Reissue it in the XFA dashboard
3	XFA could not be reached	Retry later
4	Something local went wrong: the credentials could not be stored, XFA could not be started after enrolling, or the device was left claiming an organization it no longer has	Retry; contact support if it persists
5	This device's own credentials were refused	Contact support; the token is not the problem
6	It ran as the machine rather than as a person	Deploy to users, not devices. On a Mac, run it as the signed-in user: a Jamf policy script runs as root, and root has no XFA of its own

Through the MSI, enrollment runs as the last step of the install with Return="check", so a nonzero result fails the install: the MDM reports a failure (a generic installer error such as 1603, not the specific code above) rather than passing silently as a device that installed without joining your organization. Read the actual reason from %TEMP%\xfa\xfa-enrollment.log. Because enrollment runs once the installation is already committed, XFA stays installed either way, so the user still has a working application they can enroll themselves.

Troubleshooting

What you see	What it means
The deployment succeeded, but no device appears	It installed for the wrong account. On Windows this is the install context: it must install for the signed-in user, not the machine.
Exit code 2	The token was rejected. Reissue it in the dashboard and update the deployment. Rotating invalidates every command carrying the old token.
Exit code 1, mentioning an email address	XFA found no address for that account. On a domain-joined fleet, populate `mail` in Active Directory for those users. Do not add `EMAIL` to a fleet deployment: it sets one address for everyone it reaches.
Devices enrolled under addresses nobody recognises	Active Directory has no `mail` for those accounts, so XFA fell back to the user principal name, which in your directory is a suffix like `corp.local` rather than an email address. Populate `mail`; XFA prefers it.
The Mac has XFA but never enrolls	The profile is not scoped to it, or carries a different preference domain. It must be `com.xfa.desktop` with the key `EnrollmentToken`.
A device enrolled in the wrong organization	Run `xfa unenroll --organization-id <id>` as that user, then redeploy with the right token.

To ask a device what it thinks it is enrolled in, run xfa enrollment-status as the signed-in user: exit code 0 means enrolled, 10 means not. It reads local credentials, so it needs no network and no administrator rights.

On Windows, start it and wait for it: XFA is a windowed application, so a shell returns immediately and never receives its exit code. Running the commands by hand shows how, and names the log file that says why an enrollment failed: %TEMP%\xfa\xfa-enrollment.log.