Okay, looks like I figured out the issue. I was running my app (which contains the SSO extension) as a launch agent from /Library/<MyCustomFolder>, and it worked fine for classic Platform SSO where enrollment is triggered from the notification. However, for Simplified Setup to work, I had to place the app in /Applications. Is this expected behavior, or is it a bug? I mean either it should work with /Library/<MyCustomFolder> in all the cases including simplifed setup or doesn't work at all.

I was trying to debug this further by checking the setup assistant logs and I see below logs.... 2026-05-20 10:08:50.666674+0530 0xc8dd Error 0x5b0e1 4203 0 Setup Assistant: (AppSSOCore) [com.apple.AppSSO:SOErrorHelper] Error Domain=com.apple.AppSSO.AuthorizationError Code=-1000 "No valid IdP extension with bundle ID: <REDACTED_BUNDLE_ID>" UserInfo={NSLocalizedDescription=No valid IdP extension with bundle ID: <REDACTED_BUNDLE_ID>} 2026-05-20 10:08:50.666677+0530 0xc8dd Default 0x5b0e1 4203 0 Setup Assistant: (AppSSO) [com.apple.AppSSO:SOExtensionFinder] findExtensionWithBundleIdentifier: (null), error: Error Domain=com.apple.AppSSO.AuthorizationError Code=-1000 "No valid IdP extension with bundle ID: <REDACTED_BUNDLE_ID>" UserInfo={NSLocalizedDescription=No valid IdP extension with bundle ID: <REDACTED_BUNDLE_ID>} 2026-05-20 10:08:50.666680+0530 0xc8dd Error 0x5b0e1 4203 0 Setup Assistant: (AppSSO) [com.apple.AppSSO:SOExtensionManager] extension not found: <REDACTED_BUNDLE_ID>, error: Error Domain=com.apple.AppSSO.AuthorizationError Code=-1000 "No valid IdP extension with bundle ID: <REDACTED_BUNDLE_ID>" UserInfo={NSLocalizedDescription=No valid IdP extension with bundle ID: <REDACTED_BUNDLE_ID>} 2026-05-20 10:08:50.666683+0530 0xc8dd Error 0x5b0e1 4203 0 Setup Assistant: (PlatformSSO) [com.apple.AppSSO:POExtension] PlatformSSO extension not found (<REDACTED_BUNDLE_ID>) 2026-05-20 10:08:50.666694+0530 0xc8dd Default 0x5b0e1 4203 0 Setup Assistant: (PlatformSSO) [com.apple.AppSSO:POExtension] -[POExtension _unload] on <private> 2026-05-20 10:08:50.666695+0530 0xc8dd Error 0x5b0e1 4203 0 Setup Assistant: (PlatformSSO) [com.apple.AppSSO:PORegistrationManager] Platform SSO extension not found 2026-05-20 10:08:50.666713+0530 0xc8dd Default 0x5b0e1 4203 7 Setup Assistant: [com.apple.macbuddy:MacBuddyX] Skipping flow item PlatformSSOUserRegistration because it does not need to run Its quite strange that during device registration extension was discovered and device registration completes but during user registration it fails to find the extension. Could this be a bug ?

Yes my bad... Here is the correct ticket: FB22598899

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

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.

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

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?

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 ?

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.

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 again for the clarification. With Platform SSO enabled, is it possible to support a fully passwordless experience at the macOS login window and lock screen, without requiring a local account password fallback ?

Any update ?

In this case, the parent process would be the installer, since the plugin runs under the host. While this setup would prevent the process from being launched by any other source, an attacker could still create a malicious installer, embed my program within their plugin, and successfully carry out the attack — correct ?

I was wondering — if I include the child process in my installer plugin, wouldn’t that allow an attacker to extract the executable using pkgutil and then run the child process manually with their own parameters? Are you referring to using a root process, such as an SMJobBless Helper? If so, spawning it from the installer would also require root privileges, which isn’t ideal since I’d prefer not to prompt for elevated permissions twice — once during installation and again when launching the process.

NVM I found the solution. let context = LAContext() context.localizedReason = "Authenticate to sign your transaction" // Main prompt text context.localizedCancelTitle = "Cancel" // Cancel button text context.localizedFallbackTitle = "Use Passcode" // While fetching the private key pass the context let query: [String: Any] = [ kSecClass as String: kSecClassKey, kSecAttrApplicationTag as String: "com.example.key".data(using: .utf8)!, kSecReturnRef as String: true, kSecUseAuthenticationContext as String: context // Associate the context ]