Maybe not on the FileVault unlock screen, but is it possible on the macOS login window? If FDE auto-login is disabled, the user lands on the standard login window after authenticating with FileVault. I can use an authorization plugin on that login window, but is there a way to leverage a persistent token or any other mechanism to enable passwordless authentication at this stage ?

Thanks for the reply. I’m currently working on threat modeling for my PSSO extension and trying to understand the different attack scenarios. For example, what if an attacker creates a separate SSO extension to generate a valid attestation, and then somehow replaces or injects a malformed payload from their own device into the registration request of another device, potentially updating the keys? In such cases, what protections does the attestation mechanism provide? Also, is it sufficient to send the attestation payload directly in the request body, or should I add an extra layer of security—such as wrapping the payload in a JWT and signing it using Secure Enclave–backed keys generated during registration—to ensure the payload hasn’t been tampered with? At the same time, I want to avoid overengineering the solution. I’m trying to determine whether these additional measures are necessary or just redundant.

Thanks for the update. I did some investigation on my end using Charles to inspect the traffic and verify whether any Apple attestation APIs are being called. I can confirm that an attestation API is indeed triggered, but I’m not entirely sure what happens behind the scenes. Any progress on the research at your end ?

If Apple were to rotate or replace the attestation certificate chain (for example, in the event of a compromised root attestation CA), would this automatically trigger a repair / re-enrollment flow on all previously enrolled devices? Or is the repair flow initiated only based on server-side decisions, such as attestation validation failures or explicit policy enforcement?

Okay so looks like API request.complete(httpAuthorizationHeaders: ["x-sso-attestation": signedJWT])  is only for credential extensions and not meant for Redirect extension.

During further research,I observed that when generating an attestation for the first time, Apple makes a call to a remote service to obtain a signed attestation. This attestation is then cached and reused for subsequent requests. Any future attestation calls return the cached value. To obtain a new attestation, the device keys need to be reset.

Here is the FB ticket: FB16734033 just for reference. Thank you