Changelog

This week is about making setup clearer: you can see exactly when an Enforcement policy warns or blocks, and adding a Discovery connection is simpler.

See exactly when a device is warned or blocked

Setting up an Enforcement policy no longer means guessing what will happen. The policy settings now show a threshold timeline and a live timing summary as you edit, plus suggestion chips for common warn and block windows. You can see precisely when a device would be warned, and when it would be blocked, before you save. Enforcement stays configurable: a policy can warn or block, with or without an Awareness notification. Set up a policy

A simpler way to connect Discovery

Discovery has a redesigned two-column overview and a clearer way to add a connection. Selecting Add connection now opens a provider picker for Microsoft, Google or Okta and takes you straight to a step-by-step setup page for the one you chose. Discovery reads the devices in your organization from a connected identity provider, so adding one is the first step to seeing every device in use. Connect Discovery

Administrators now get a clearer signal when a device with the XFA agent stops reporting a verified status. The Devices overview highlights these devices as Lost connection, making it easier to spot endpoints that need to reconnect and complete verification again.

You can filter by the new status in both the Devices and People views, then request verification from the Dashboard to help the user reconnect the XFA app and resume sharing device security status.

Learn more about device verification statuses

XFA now supports screen lock timeout enforcement in addition to the existing screen lock enable/disable check.

Previously, XFA only verified whether screen lock was enabled on a device. Now, admins can also configure a maximum allowed timeout duration — and XFA will verify that the device's screen lock timeout is within that limit.

What's new:

• Admins can set a maximum screen lock timeout (in minutes) in their organization's policy
• XFA checks both that screen lock is enabled and that the configured timeout does not exceed the maximum
• Supports macOS, Windows, and Linux with platform-specific timeout detection
• The timeout check works alongside the existing enable/disable check — both must pass for the device to be compliant

This gives organizations tighter control over idle device security, ensuring employees cannot set excessively long timeouts that leave devices exposed.

Configure your policies

The dashboard now includes a clearer compliance status bar for policy-based device security.

The new view helps administrators quickly understand how devices are progressing against their security policy:

• See which devices are already compliant and which still need attention.
• Distinguish devices that are warned, blocked, or not yet covered by an action.
• Identify devices with missing information that may need verification before their status is complete.

This gives teams a faster way to review policy health and decide where to focus next.

Open the dashboard

Policy detail pages now include a compliance summary next to the policy settings.

The summary helps administrators understand the current state of a policy while editing it:

• See how many devices are compliant, non-compliant, or missing information for the selected policy.
• Keep the compliance overview visible while reviewing or updating policy settings.
• Quickly understand whether a policy is already broadly satisfied or still needs attention.

Review your policies

XFA's unsafe AI mode check now recognises Claude Code's newer persisted permission modes alongside the legacy dangerouslySkipPermissions flag, so administrators get accurate reporting whenever an agent is configured to auto-approve every tool call.

The following values of permissions.defaultMode in ~/.claude/settings.json (or ~/.claude/settings.local.json) are now flagged as unsafe because they auto-approve every tool call, including shell commands and network requests:

• bypassPermissions — persisted equivalent of running with --dangerously-skip-permissions. Treat this as 'agent has full local user privileges'.
• auto — the new Claude Code 'Auto' mode. Same risk class: skips permission prompts via a classifier and is intended for sandboxed CI, not for personal devices.

Both modes are unsafe to run on machines with credentials or production access. Safe values (default, plan, acceptEdits) remain unflagged. Devices configured with either flagged mode are now reported in the Unsafe AI Mode check, and end users see remediation steps in the in-app guide.

Review your AI policies

Administrators can now snooze individual devices from the dashboard when a device needs a temporary exception.

Snooze is available from the device action menu in the Devices overview and from the device detail page. Choose a preset or custom date and time for each device, optionally add a reason, and remove or update the snooze later from the same menu.

Snoozed devices are hidden from overviews and analytics by default, but remain available through the Show snoozed devices filter. During the snooze period, device checks and awareness notifications are paused for that device.

MFA remains active by default. Admins can explicitly include MFA in the snooze when they need to pause MFA for Enforcement sign-ins as well.

Manage your devices

Add your own message to the bottom of XFA's onboarding and sign-in cards. Configure two separate messages — one shown during device onboarding, one during sign-in — from the Applications page in your Dashboard to reinforce your policies, link to an internal runbook, or add a bit of your own voice where end users will actually see it.

XFA's Linux disk-encryption check now recognises TCG OPAL self-encrypting drives* alongside LUKS.

When drive locking is enabled on an OPAL-capable drive, the device counts as encrypted, giving administrators accurate compliance reporting for Linux devices that rely on hardware encryption.

Review your disk-encryption policy

XFA's Windows disk-encryption check now recognises VeraCrypt system-drive encryption* alongside BitLocker.

Devices whose Windows boot/system drive is encrypted with VeraCrypt are now reported as compliant automatically, no configuration required.

Review your disk-encryption policy

Installing XFA on Linux is now easier than ever. Simply run a single command in your terminal to get started:

curl -fsSL https://distribution.xfa.tech/xfa-native-desktop-application/install.sh | sh

No more picking the right package from a dropdown, just copy, paste, done.

XFA's Linux integrity protection check now recognises AppArmor as a valid mandatory-access-control system, alongside SELinux.

Linux users who rely on AppArmor as their kernel-level integrity protection now pass the check automatically.

Two new MDM and compliance checks are now available for the desktop app:

• Microsoft Intune — Verify whether a device is enrolled in Microsoft Intune. Supports both macOS and Windows.
• Vanta — Detect whether the Vanta compliance monitoring agent is installed and running. Supports macOS, Windows, and Linux.

Both checks can be configured in your organization's policy with warning and blocking actions, just like all other security checks.

These checks are currently available on desktop only.

Configure your policies