PSSO for macOS: Version compatibility and features

This page covers the specific capabilities and features added to Platform Single Sign-on (Platform SSO) through the different versions of macOS.

Version Features

macOS 26 Tahoe

  • The most polished and streamlined version of the identity-first PSSO 2.0 deployment model.

  • The zero-touch deployment flow through Apple Setup Assistant is the primary and expected user experience for new device enrollments as part of the Automated Device Enrollment process.

  • Your devices must have Okta Verify for macOS version 9.52 or later installed.

macOS 15 Sequoia

  • MDM policy settings include payload keys to support authentication and grace period policies. These control PSSO behavior for different authentication contexts, such as screen unlock, initial user sign in, and FileVault. See Authentication policies and Grace period policies.

  • For Platform SSO user registration on macOS 15.4 and later, the user must be an MDM-managed user.

  • To enforce or attempt a password sync in the FileVault window, connect the computer to a known network. See FileVault network requirements.

macOS 14 Sonoma

  • Architectural shift to a modern, identity-first PSSO 2.0 implementation.

  • Supports PSSO registration directly within the Apple Setup Assistant.

  • Supports Just-In-Time Local Account Creation from the macOS login window.

  • Allows a user to use their new Okta password directly at the macOS login window.

  • Introduces the technology for a passwordless device unlock experience using the Apple Secure Enclave.

macOS 13 Ventura

  • Users can initiate enrollment only after they have already signed in to a pre-existing local account.

  • Local accounts must be created manually before you can enable PSSO.

  • You can't integrate the PSSO flow into the initial device setup process.

Policy settings for Unlock, Login, and FileVault windows

With Apple's authentication policies, you can specify authentication requirements in macOS 15 Sequoia and later.

You can set each policy to either RequireAuthentication, AttemptAuthentication, or leave it blank. On macOS 14 Sonoma, the default is blank.

The policies outlined here work only for Desktop Password Sync on PSSO.

Authentication policies

Policy name Description

RequireAuthentication

This policy requires a successful Okta authentication before granting access to the user. The user is denied access if the Okta authentication isn't successful for any reason.

If the Okta server is unreachable due to internet connectivity issues, the user is locked out. Set the AllowOfflineGracePeriod flag to avoid this issue.

This policy disables Touch ID at the Unlock screen.

If you want to allow Touch ID access for a locked computer, you must enable AllowTouchIDOrWatchForUnlock.

This policy applies to unregistered local macOS accounts. Unless these accounts are included in the NonPlatformSSOAccounts group, or the AuthenticationGracePeriod policy is active, users are denied access. The policy takes effect when registration begins.

If registration fails and users sign out or lock their device, they're locked out unless you configure a grace period.

AttemptAuthentication

This policy attempts to authenticate with Okta before granting access to the user. If the Okta authentication fails due to an incorrect password, access is denied.

If the Okta authentication fails for a different reason, the password is verified locally.

Examples of authentication failures include:

  • The server can't be reached.

  • The password is expired.

  • The user or device status is invalid.

  • The user hasn't been assigned to the app.

None

If you haven't set either RequireAuthentication or AttemptAuthentication policy, the framework falls back to the default behavior and the password is checked locally.

If it matches, the user is granted access.

If the local password doesn't match, it's checked against Okta.

If the user's local password is synced at the FileVault or sign-in screen, the operating system prompts the user to enter their old macOS password to unlock the keychain. Their password can still be synced if the user doesn't remember it. However, all protected data, the previous keychain, and any prior Okta FastPass enrollments become inaccessible.

You can't reverse this action, so advise your users to read the warnings carefully and contact an admin for support.

Grace period policies

Apple's Device Management Profile FileVaultPolicy, LoginPolicy, and UnlockPolicy properties allow you to specify a grace period for offline and unregistered scenarios. For configuration details, see Apple's Device Management properties for Platform SSO.

NonPlatformSSOAccounts provides a list of local accounts that aren't subject to the FileVaultPolicy, LoginPolicy, or UnlockPolicy properties. These accounts aren't prompted to register for Platform SSO.

Policy name Description

AllowOfflineGracePeriod

Allows offline authentication after validating the password locally and requires that you set OfflineGracePeriod.

If the device is online, then the AllowOfflineGracePeriod is bypassed and the authentication policies configured in the previous section determine the behavior. See Authentication policies.

This policy is similar to the LoginPeriodWithOfflineFactorDesktop MFA policy.

OfflineGracePeriod

The amount of time that the user can use the local account password offline after a successful Okta authentication.

The value is in seconds.

AllowAuthenticationGracePeriod

Allows users to unlock their unregistered local macOS accounts by validating the password locally. This policy requires that you set AuthenticationGracePeriod.

This policy is similar to the LoginPeriodWithoutEnrolledFactorDesktop MFA policy.

AuthenticationGracePeriod

The amount of time that unregistered local accounts can unlock or sign in to the computer after the FileVaultPolicy, LoginPolicy, or UnlockPolicy is triggered.

The timer countdown starts when the user begins the registration process, regardless of whether the registration was successful.

The value is in seconds.

FileVault network requirements

Connect the computer to a known network to enforce or attempt a password sync in the FileVault window.

For FileVault, the network the computer connects to must already be present. A new network connection isn't allowed.

WiFi connections

  • The only network types that work for FileVault are Open or WPA2 Personal.

  • The computer must have previously connected to the network successfully.

  • You can't use the following network types. The secrets for these networks are stored on the system or device keychain and are inaccessible until the drive is decrypted:

    • Captive portal networks of any form (any network that presents a web page to interact with before providing connectivity)

    • WEP or WPA3 Personal

    • Any form of WPA Enterprise network (RADIUS 802.1x)

Ethernet connections

  • Open network access is required. RADIUS 802.1x authentication isn't supported.
  • If the computer uses a USB Ethernet adapter, the user must have the adapter and computer configured to work on a specific USB port. See Use the ports on your Mac.
  • If an MDM profile that allows unrestricted USB access is pushed to the computer before attempting to connect at the FileVault window, then any USB-based Ethernet adapter can connect to an accepted network.

Registration update query

You can track which users have completed the registration update by running the following query in the System Log.

Copy 
eventType eq "device.password_sync.enrollment.create" and target.detailEntry.PlatformSsoProtocol eq "2.0"