Apologies for a late reply.Thank you for a quick response.

Thank you very much for a quick response. I see you have already mentioned, "I’m not aware of a good workaround." Here are the steps to reproduce with Mac provided settings:- We modified the system.login.screensaver configuration to switch from the modern UI to the legacy UI method in order to support our custom SFAuthorizationPluginView. Specifically, we replaced use-login-window-ui with authenticate-session-owner-or-admin. Note: without our custom SFAuthorizationPluginView integration After this change, attempting to launch Keychain access app triggers two consecutive password prompts, and the application fails to launch. This issue is occurring with the released version of our agent, we would end up more support calls. Again, checking if there are any suggestions, this was completely broken in unlock the screen flow with legacy UI configuration authenticate-session-owner-or-admin. Any tentative release plans to get a fix for FB13128730 Any help would be highly appreciated.

Thank you for your response. We would greatly appreciate it if you could provide any recommendations, along with details(high-level) on the potential impacts of this issue. This information will help us prepare and include an appropriate advisory in the released version and upcoming releases.

Many thanks for getting back to me. Or whether that code will work in an authorisation plug-in? I’m looking for USB monitoring code that can function within an authorization plugin, specifically, a custom GUI AuthPlugin window that displays prompts when a FIDO key is inserted or removed.

Thanks again for your inputs. Yes, I started with a test app, and it worked as expected. Then I moved on to the authorization plugin, where the detection part isn’t behaving as expected. I later thought of checking with Apple in case there’s any limitation around the monitoring part within securityd. I’ll review it again based on your suggestions to see if I missed anything.

Thank you! The APIs listed below are utilized to identify FIDO HID devices exclusively, with their corresponding callback registration functions shown here. // Match only FIDO HID devices let matchingDict: [String: Any] = [ kIOHIDDeviceUsagePageKey as String: 0xF1D0 ] IOHIDManagerSetDeviceMatching(mgr, matchingDict as CFDictionary) // Register callbacks IOHIDManagerRegisterDeviceMatchingCallback(mgr, deviceAddedCallback, UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque())) IOHIDManagerRegisterDeviceRemovalCallback(mgr, deviceRemovedCallback, UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque())) // Schedule with current run loop IOHIDManagerScheduleWithRunLoop(mgr, CFRunLoopGetCurrent(), CFRunLoopMode.defaultMode.rawValue) let result = IOHIDManagerOpen(mgr, IOOptionBits(kIOHIDOptionsTypeNone)) Randomly it crashes at runloop Terminating Process: SecurityAgentHelper-arm64 [2303] Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x1883c9c34 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1883dc3a0 mach_msg2_internal + 76 2 libsystem_kernel.dylib 0x1883d2764 mach_msg_overwrite + 484 3 libsystem_kernel.dylib 0x1883c9fa8 mach_msg + 24 4 CoreFoundation 0x1884f6cbc __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1884f55d8 __CFRunLoopRun + 1208 6 CoreFoundation 0x1884f4a98 CFRunLoopRunSpecific + 572 7 HIToolbox 0x193f9727c RunCurrentEventLoopInMode + 324 8 HIToolbox 0x193f9a4e8 ReceiveNextEventCommon + 676 9 HIToolbox 0x194125484 _BlockUntilNextEventMatchingListInModeWithFilter + 76 I’m able to perform FIDO authentication with the key inserted via USB randomly crashes most of the time crash log shows runloop; however, NFC-based authentication does not work (NFC-over-HID devices (OMNIKEY): communication with ctkpcscd failed Could you please share any inputs

Thanks for your time and input. After making a few code changes, everything started working. I’ve moved the monitoring logic into an XPC daemon, and things are functioning as expected.