← Field Notes
Platform SSO · Deep dive

Platform SSO at FileVault unlock can't use VPN, Network Relay, or 802.1X

R Rob Flanagan · · 5 min read

The Platform SSO payload can be correct and the flow still fails, because this constraint lands on the network path rather than the profile. Three features are in scope, with three different version floors.

Apple names three Platform SSO features that have to reach your identity provider before FileVault unlock. For those three, the identity provider has to be reachable without a VPN, without a network relay, and without 802.1X. Apple gives the reason in the same sentence: macOS needs to establish connectivity before the data volume is available.

This is not a statement about Platform SSO generally. Most deployments never touch it. It applies to a named list, and if your rollout includes anything on that list, the network path underneath it has to be designed differently from the rest of your fleet.

I have run Jamf Connect at the login window, including FileVault escrow and Require Network Authentication. That work is why I read this as a network design problem rather than a payload one, and why I test each authentication surface on its own rather than trusting one passing login to cover the rest.

Apple names three features, and gives three different version floors

The Platform SSO deployment guide lists the features that need the identity provider before FileVault unlock, and each one became available in a different release:

  • Web-based authentication: macOS 27
  • Authenticated Guest Mode: macOS 26
  • Login policies: macOS 15

Those floors matter more than they look. Login policies have been shipping since macOS 15, so this requirement is not a future problem waiting on a beta. Be precise about which key is in scope, though: that family splits across three surfaces, and FileVaultPolicy is the one bound to FileVault unlock on Apple silicon. UnlockPolicy governs the Lock Screen and LoginPolicy the login window.

A fourth row in the same version table, FileVault support with Authenticated Guest Mode, is also listed for macOS 27. It is a separate entry and is not one of the three features carrying the reachability requirement. Apple's page also carries a banner stating that some features discussed on it are pre-release versions that may be incomplete, changed, or removed before final release, so treat the macOS 27 rows as subject to change.

The reason is the data volume, and Apple states it plainly

Because macOS needs to establish connectivity before the data volume is available, you need to reach the IdP without a VPN, network relay, or 802.1X authentication.Apple, Platform SSO for macOS

Read that as a constraint on the whole path, not just the final hop. Anything the authentication request depends on has to work at that moment. An identity-provider endpoint that only answers from inside the tunnel does not qualify. Neither does a hostname that only resolves against an internal resolver you reach through the tunnel, or a wired port that hands out network access only after certificate-based authentication.

Apple documents the boundary. Apple does not publish an inventory of which components load with the data volume, so the honest operator position is to treat the requirement as the specification and verify against it, rather than reason from where you assume each piece is stored.

Network Relay is a different surface doing a different job

Network Relay is worth separating out, because it is the transport most likely to be sitting in a modern deployment and the one most likely to be assumed adequate here.

Its managed payload is com.apple.relay.managed, available from macOS 14 and iOS 17. Apple describes a relay as a special type of proxy that uses the built-in network stack to proxy TCP and UDP traffic over HTTP/3 and HTTP/2. It is configured through its own payload, entirely separate from the Extensible Single Sign-on configuration that carries Platform SSO.

Scoping works two ways. Define match domains and only that traffic goes to the relay. Define none, and traffic to all domains routes to the relay except anything matching an excluded domain. The payload requires at least one relay server, and each server entry can optionally reference an identity certificate through the schema's PayloadCertificateUUID key.

Apple calls Relay a modern alternative to VPN when accessing internal resources, and its WWDC23 session encouraged enterprises to start replacing VPN use with relays. That guidance covers a great deal of VPN usage. It does not cover this. Device-wide scoping does not help either, because the constraint is not about how much traffic the relay carries.

I picked up this thread from Adam Derrick's MacAdmins Conference 2026 session on macOS identity, where he makes the same general point about scope: "the relay doesn't replace your whole network stack." The FileVault requirement itself is Apple's, from the deployment guide.

Losing the identity provider does not mean nobody unlocks the disk

It is tempting to describe this as a lockout, and that overstates it.

Apple documents a local account password path when web-based authentication is unavailable, and the device-management schema assigns separate online, offline, and grace-period behavior to Password-method policies. What actually happens when the live flow fails depends on the authentication method in use, the policy you set on that surface, and the fallback you configured.

The uncertainty is an argument for testing, not against it. You cannot predict the outcome from the documentation alone, and the network requirement holds either way.

Test the path before you enable it

This part is my recommendation rather than Apple's wording. Apple documents the prohibited dependencies; the testing approach is the operator conclusion I draw from them.

Prove the complete authentication path, at FileVault unlock, on the same hardware and macOS version you plan to ship. FileVault behavior is bound to both, so a result from a different Mac or a different release is not evidence about the one you are deploying.

  • Confirm the identity-provider endpoint answers with the VPN client, the relay payload, and 802.1X all out of the picture.
  • Confirm name resolution for that endpoint works the same way.
  • Do it at the FileVault unlock screen, not after login, where the tunnel is available and will mask the problem.
  • Have the recovery path documented and tested before enforcement, not after.

An endpoint that only answers over VPN, Network Relay, or 802.1X cannot meet the requirement, no matter how the Platform SSO payload is written.

For the authentication methods and policy surfaces underneath this, start with Platform SSO can be passwordless, and can also satisfy MFA. The macOS 27 declarative management changes cover the release that adds one of the three features named here.

Which identity-provider endpoints does your unlock flow depend on, and can the pre-boot network actually reach them?

Sources

Apple sources, plus the conference session that prompted this post. Retrieved 2026-07-28 and re-verified live on 2026-08-03:

← Back to Field Notes