I faced the same issue and was able to get around it by running the network request as root from a Privilege Helper daemon.

It does look like that except that our authorization plugin is successfully intercepting login requests by modifying the auth.db entry for system.login.console as follows: Replace: loginwindow:login With: TrusonaAuthorizationPlugin:trusonaLogin I suspect the bug is that the FUS code path is no longer using the system.login.console entry in auth.db. Somehow it is going directly to the login window bypassing the auth.db list of mechanisms for system.login.console. It might be interesting to test with your modified system.login.console.plist and corresponding plugins GUIAuthPlugin.bundle and LoggingAuthPlugin.bundle . Kind regards, - Peter

Thanks for the quick response. I really appreciate the way you monitor the forums. Bug number is FB11705643 filed 2022-10-19. Best regards, - Peter (K1AV)

Thanks! I think I have some idea what's happening. My bigger concern is making Apple aware and whether a fix can be expected. Can open a DTS incident if it helps.

I noticed it in the Release Candidate last week but suspect it was present in earlier betas.

I'm still seeing this error on very rare occasions when loading our authorization plugin for privilege escalation: Replace: builtin:authenticate With: TrusonaAuthorizationPlugin:trusonaLogin The observed behavior is that clicking on the lock icon in "System Preferences > Security & Privacy" displays "Authenticating..." and just hangs there. Our plugin isn't being loaded. The solution I've found so far is to do a Restart. I've read "There's a code signing oddity in Apple systems where the kernel caches information about the signature and doesn’t flush that cache when you rewrite the Mach-O image file". The problem typically happens after installing a new version of the software on an M1 Mac mini hosted at Mac Stadium and running macOS Monterey. Once the problem occurs, it doesn't seem to matter which plugin image we use. The problem appears so rarely it's hard to reproduce. Can you offer any ideas for how to resolve this or track down the underlying cause?

I have submitted feedback (FB10705684) with a sysdiagnose and two videos. One showing the unexpected behavior in iOS 15.5 and the other showing the expected behavior in iOS 16 beta 3. Additional Observations: It works in iOS 16 beta 3 The problem is still present in iOS 15.6 beta. We would really like a work-around or some assurance this will be fixed in a future version of iOS 15 since customers are likely to be on this version for some time.

I installed iOS 16 beta 3 and was able to verify the problem has been fixed. However, we still need a work around for iOS 15.5 . We replaced element re-rendering with a full page refresh window.location.reload() . Unfortunately, the problem still persists on iOS 15.5 until you do a manual refresh. Any ideas?