Just as an update, my appex is loaded. When I visit webauthn.io, and use it to register a passkey, my Credential Provider is loaded and prepareInterface(forPasskeyRegistration:) is invoked. However when I attempt to save the passkey we check is the credential store is enabled, and we receive false. If we remove the check and attempt to save the passkey anyway, the ASCredentialIdentiyStore.shared.saveCredentiaIdentities fails with error 1 (.credentialStoreDisabled). I'm really at a loss how to debug this as the logs (even with --debug) don't indicate any problems. If there's some secret log I can enable, some file I can check, etc. I'd be very appreciative.

Thanks for the reply. getState() doesn't return an error that I can see. I the Swift async variant also got false. open func getState(_ completion: @escaping @Sendable (ASCredentialIdentityStoreState) -> Void) - (void)getCredentialIdentityStoreStateWithCompletion:(void (^)(ASCredentialIdentityStoreState *state))completion I don't see any specific logs from syspolicyd or AuthenticationServicesAgent about missing entitlements. This is a dev build signed with a provisioning certificate, not DevID, but still can pass codesign. It's not notarized because I didn't see the point if I can't get a local dev build working. ❯ codesign -vv TestApp.app /Users/developer/sources/build/Mac/Debug/TestApp.app: valid on disk /Users/developer/sources/build/Mac/Debug/TestApp.app: satisfies its Designated Requirement Of course without notarization it doesn't pass gatekeeper (rejected). If that's to be expected, I guess I'll have to figure out how to test incremental builds...

This is all being done on macOS 26.5, but I should quantify and say I am using a virtual machine which I am wondering if it's part of the problem.

Thanks Quinn and eddiewangyw for the updates. One thing I guess worth clarifying also is what is meant by "user session". Our service(s) have no connection to CGS since they are root session only but other Apple daemons/services may—and I assume that's the real crux of the issue may make a difference. But if how a user is logged in—via physical console or SSH or VNC etc makes a difference could also be interesting. In our testing, the ANE and GPU were reliable when a user was logged in at the physical console. It's much harder to trigger these specific flows without some GUI console access (e.g. SSH would be hard) but over VNC it's definitely possible. Then I began to question if there's a difference with somebody logged in but at loginwindow, etc.