I think this is just how macOS 15 and 26 work. I hadn't noticed it in the past because my view completely covered the earlier view on macOS 15. It doesn't quite cover it on os 26. Not a bug. The earlier mechanism is HYPR. Not sure why its UI stays up.

This is a statement about how SFAuthorizationPluginView works with multiple mechanisms: The first mechanism displays its view and later sets its result. The view continues to display. Then the other mechanism displays its view over the top of the first view. (The first mechanism was not developed by me.) Question: How can a mechanism take down its own view? Is this supposed to happen automatically after the mechanism sets its result?

I have resolved my issue, but I want to confirm that if multiple mechanisms use SFAuthorizationPluginView then multiple views will appear when unlocking the screen.

It appears that Tahoe handles multiple mechanisms that display UI differently that previous OS versions.

As of today, My Mac is up to date with macOS Tahoe Beta 26. My plugin is added to system.login.screensaver.

Feedback is FB18207031 and mentions TN3179

My virtual Mac is running 15.2.

The right to change these switches is com.apple.system-extensions.admin

I believe it is not possible to use SMAppService.agent from a process that is not running in the console. That is why you can get it to work when you launch it, but not when installing from an MDM. https://forums.developer.apple.com/forums/thread/737038

It looks like you are trying to import data in PKCS12 format. There is an API for doing that SecPKCS12Import. Are you considering if the private key blob needs a password?

Have you looked at SecPKCS12Import? I use this for my mutual auth and it works fine. Much less code too.

I think your trouble is due to sandboxing the launch daemon. I have a launch daemon that is not sandboxed, and it can use the System keychain, but has to run as root. Not ideal but the keychain stuff works fine for creating keypairs, using them for encrypt/decrypt and for adding an internet password. I wish Apple had better support for launch daemon access to their own private keychain. They should support a launchd plist key pointing to a keychain, and an entitlement to get unlocked access to it. The system should enforce that only the launch daemon can read the keychain file/db based on developer provided code signing requirements for the keychain.

I have modified QAuthPlugins to verify the issue with SecStaticCodeCheckValidityWithErrors. I have filed a bug report FB14783775 "SecurityAgentPlugin can't verify NSXPCConnection using setCodeSigningRequirement."

It turns out that a security agent plugin can't even verify a signature using SecStaticCodeCheckValidityWithErrors.

It appears that the trust evaluation fails. I assume that my security agent plugin is failing to trust the code signing cert chain used to sign my launch daemon.