We maintain an SFAuthorizationPluginView-based authorization plugin (mechanisms registered in system.login.console) on macOS 26 (Darwin 25.x) and are seeing a cosmetic but user-visible issue at the login window that we believe originates in the host, not our code. We'd like to confirm whether it's expected behavior or a bug worth filing via Feedback. Setup Two local users, A and B. Our plugin adds a custom mechanism to the login chain, so after credential submission the host may present additional UI (our mechanism's view). Each authorization round runs in a fresh SecurityAgentHelper process (verified via PID in logs), so no state of ours survives between rounds. Reproduction Log out of user A at the login window. Select user B and type their password. Submit. Our mechanism (invoked after submission, e.g. an enrollment prompt for a not-yet-enrolled user) presents its UI. Observed For roughly 1.1–1.4 s between our mechanism's window appearing and covering the host's, the login window shows user A's name/avatar tile — the previously selected user — before our panel covers it. Instrumentation confirms: Our process logs willActivate(withUser:) delivering user A (the previous round's user) while the authorization context (GetContextValue on kAuthorizationEnvironmentUsername) correctly contains user B. The stale tile renders inside what appears to be the host's own window (class LUI2Window, created ~300 ms before our surface activates). Our code makes no writes to the engine context at that point (we log every SetContextValue; zero writes occurred during the flip window). The flip only happens when our mechanism round starts after credential submission. If the mechanism round starts before user selection (the normal login path), each user click produces a fresh willActivate with the correct name and no flip is visible. Question Why does the login window display the previous round's user (user A) after I've selected and submitted credentials for user B? The willActivate(withUser:) callback our mechanism receives still carries user A at that moment, while the authorization context already contains user B — the two disagree. Is the host intentionally re-showing the last logged-in user's tile when a mechanism presents UI after credential submission, and can a mechanism do anything to prevent it?

We develop an authorization plugin that replaces password entry at the login window and at screen unlock with a phone-based sign-in. The user scans a QR code with their phone, or the Mac reaches the phone over Bluetooth. Either way the plugin ends up with the user's password, which it hands to the authorization engine as if it had been typed. All networking runs in a LaunchDaemon that the plugin calls over XPC. Setup system.login.console: loginwindow:login → OurPlugin:login system.login.screensaver: rule use-login-window-ui → authenticate-session-owner-or-admin, with screenUnlockMode set to 2 authenticate: builtin:authenticate → OurPlugin:authenticate The UI is an SFAuthorizationPluginView subclass. On success we set username and password in the context (plus home at login) and call SetResult with kAuthorizationResultAllow. What we see on macOS 27 Since moving to macOS 27 on a MacBook Pro (M3 Pro), we hit these more often: Touch ID unlocks the Mac but leaves our view on screen. Open the lid and unlock with Touch ID. The desktop becomes usable, but our plugin view stays on top, and shortly after the screen locks again. Same symptom as thread 819454, where it was filed as FB22289735. Saved passwords disappear from apps after an unlock through our plugin. They come back only after the user logs out and in again. This looks like FB13128730 (thread 796487). The lock screen stays on the desktop after sign-in. The clock, the user picture and our view, with its filled-in password field, stay on screen while the menu bar and Dock are drawn on top of them. Similar to FB12074874. We also saw this once: the password field in our view would not take keyboard input at the lock screen. Every key press just played the system alert sound, and nothing was typed. Questions Is there any workaround for these on macOS 27? Or a supported way to stop macOS offering Touch ID while our plugin handles unlock? Is an SFAuthorizationPluginView plugin still a supported way to replace the login and unlock UI? If not, what should we move to? Is Platform SSO with the new web-based authentication in macOS 27 (login window, Lock Screen and FileVault unlock) the path you would recommend? If so, is there a supported option for offline sign-in, which we do over Bluetooth today?

We have observed significant UI changes to the SFAuthorizationPluginView login experience in the latest macOS Golden Gate Beta 5. After entering the account password at the SFAuthorizationPluginView screen, we were previously able to access the buttons and other child elements present in the SFAuthorizationPluginView using "accessibilityChildrenInNavigationOrder" . Currently the method returns that there are no child elements eventhough there are clearly child elements presents including apple's native Ok and Cancel buttons.This behaviour is consistently reproducible in our testing. Steps to Reproduce Configure and launch an unlock authorization plug-in using SFAuthorizationPluginView. Display the authorization UI in unlock. Enter the account password. Wait for the authorization UI to finish transitioning to the authenticated state. Query the SFAuthorizationPluginView accessibility hierarchy. Specifically query accessibilityChildrenInNavigationOrder. Observe that the method returns no child accessibility elements. Inspect the UI visually or using Accessibility Inspector and observe that child controls are still present, including the native OK and Cancel buttons. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.

Hello, We have an enterprise application that provides a security agent plugin with custom UI based on SFAuthorizationPluginView. We’ve been testing it on macOS 27 Developers Betas 1 through 4 and we noticed that if we set screenUnlockMode to 2, then after a screen is locked for the second time during one session, it can no longer be unlocked. Here are the concrete steps to reproduce: Open Terminal. Run sudo defaults write /Library/Preferences/com.apple.loginwindow.plist screenUnlockMode -int 2 Lock the screen. Observe the “You must enter the password to unlock the screen” dialog window. Enter the correct password and press OK. Lock the screen again. Expected result: The dialog “You must enter the password to unlock the screen” is displayed again. Entering the correct password unlocks the screen. Actual result: The screen is black with no visible UI. Rebooting the system seems to be the only way to leave this state. Displaying custom UI at the unlock screen is a part of our core functionality and it has been working fine with screenUnlockMode = 2 since at least macOS 14. I have filed a feedback FB23918474; if it is a known issue, please merge it with mine so that I can receive updates on the matter. In the meantime, do you have any suggestions on what can be done? Thanks.

We have a custom SecurityAgentPlugin that is triggered by multiple authorizationdb entries. Some customers report that the SecurityAgent process takes window focus even though no UI or windows are displayed. Our plugin explicitly ignores the _securityAgent user and does not show any UI for that user. However, in macOS 26.1, it appears that the plugin still causes the SecurityAgent to take focus as soon as it is triggered. Is this a change in macOS 26.1 or a bug? Can we do anything to prevent "focus stealing"?

When I install a new version in /Library/Security/SecurityAgentPlugins, the Mac keeps loading from the StagedPlugins folder. Probably due to the previous version crashing at some point.

I have enabled FileVault on macOS having a custom authorisation plugin , which will load our multi-factor authentication (MFA) window . This third-party custom authorisation plugin replaced loginwindow:login mechanism from authorisation db (system.login.console) .After these changes, during reboot, we observed that the focus isnt on our custom Xib window.We noticed that the custom Xib window is rendered on a completely black background . End user has to use mouse to click on the custom Xib window, so that the textbox gains its focus. The possible solutions we have tried, Simulating mouse click Making Window to gain focus using makeKeyAndOrderFront Steps to reproduce: Enable Filevault on the machine Remove loginwindow:login and add your custom authorisation plugin in its place with a textbox to capture password 3.Perform reboot of the machine 4.The custom xib window is rendered on a black window but the window doesnt gain focus. The user has to perform a mouse click on the window to gain its focus Any help would be greatly appreciated on the above mentioned issue

In macOS Tahoe 26.4.1 we noticed that when we use our custom authorisation plugin to perform unlock using SF Authorisation Plugin View, the SF window isnt focused. User has to manually click on it to type in the password. We also noticed that this wasnt the case in macOS Tahoe 26.2 . Can you kindly suggest us if any flags have to be enabled for the same? Any help on this issue is highly appreciated

We are using an SFAuthorizationPluginView-based authentication plug-in for screen unlock, and we are seeing focus/activation behavior on macOS Tahoe 26.4.1 that appears different from earlier macOS releases. In our lock-screen plug-in UI, the view is displayed correctly, but keyboard input does not go to our password field until the user physically clicks inside the plug-in view. We have already tried the documented focus-related hooks and standard AppKit approaches, including: Overriding firstResponder Overriding firstKeyView / lastKeyView Calling becomeFirstResponder Calling makeFirstResponder on the host window during activation Setting up the key view loop between controls Despite this, on Tahoe 26.4.1 the password field still does not accept typing until the first mouse click inside the plug-in view. Could you clarify the following: On macOS Tahoe 26.4.1, are there any known changes in SecurityAgent / SFAuthorizationPluginView behavior that affect firstResponder, firstKeyView, or keyboard activation during screen unlock? Is a physical click now required before keyboard input is delivered to an SFAuthorizationPluginView in this context? If not, what is the recommended supported way to ensure the password field becomes keyboard-active immediately when the plug-in view is shown? Are becomeFirstResponder / makeFirstResponder expected to work in this host context, or are only the SFAuthorizationPluginView hooks (firstResponder, firstKeyView, lastKeyView) supported? Is there any recommended host-window or activation API for this scenario, or is this considered a regression in Tahoe?

On Sonoma beta 7, if system.login.screensaver is updated to use “authenticate-session-owner-or-admin”, and then Lock Screen is not hiding the macOS Desktop. Step1. Update system.login.screensaver authorizationdb rule to use “authenticate-session-owner-or-admin”( to get old SFAutorizationPluginView at Lock Screen ). Step 2. Once the rule is in place after logout and login, now click on Apple icon and select “Lock Screen”. Even after selecting Lock Screen, complete macOS Desktop is visible with no control for the user to unlock the screen. To gain access we have to restart the MAC.

When implementing a custom right in macOS authorizationdb, the mechanism array element builtin:authenticate is displaying the message 'Enter the name and password of a user in the "(null)" group to allow this.' on the macOS credential prompt UI popup. I am trying to find a fix to avoid the reference to null group in the message label that is displayed just above the username and password input fields. The current plist uses class as the key and value as the evaluate-mechanisms. The mechanisms array includes mechanism array with elements "builtin:login-begin", "mycustombundle:mycustompreaction", "builtin:authenticate", "mycustombundle:mycustommechanism". I have tried specifying group in the plist, have tried setting hint in the MechanismInvoke for group, username, security, authority, prompt, reason among several other hints into the context duing the execution of mycustombundle:mycustompreaction, but none seem to fix the "(null)" in the message label. Any help is greately appreciated. There is not much of any documentation for developers implementing custom authorization in macOS.

Hi , I did The MFA(2FA) of Email OTP For MacOS Login Screen using, Authorization Plugin, Using This git hub project. It is working For Login Screen , Im trying to Add The Same plugin for LockScreen but it is not working at lock Screen , Below is the reffrense theard For The issue , https://developer.apple.com/forums/thread/127614, please Share The Code that should Present the NSwindow at Screen Saver (Lock Screen) MacOS .

Hello, I’m working on an authorization plugin which allows users to login and unlock their computer with various methods like a FIDO key. I need to add smart cards support to it. If I understand correctly, I need to construct a URLCredential object with the identity from the smart card and pass it to the completion handler of URLSessionDelegate.urlSession(_:didReceive:completionHandler:) method. I’ve read the documentation at Using Cryptographic Assets Stored on a Smart Card, TN3137: On Mac keychain APIs and implementations, and SecItem: Pitfalls and Best Practices and created a simple code that reads the identities from the keychain: CFArrayRef identities = nil; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)@{ (id)kSecClass: (id)kSecClassIdentity, (id)kSecMatchLimit: (id)kSecMatchLimitAll, (id)kSecReturnRef: @YES, }, (CFTypeRef *)&identities); if (status == errSecSuccess && identities) { os_log(OS_LOG_DEFAULT, "Found identities: %{public}ld\n", CFArrayGetCount(identities)); } else { os_log(OS_LOG_DEFAULT, "Error: %{public}ld\n", (long)status); } When I use this code in a simple demo app, it finds my Yubikey identities without problem. When I use it in my authorization plugin, it doesn’t find anything in system.login.console right and finds Yubikey in authenticate right only if I register my plugin as non-,privileged. I tried modifying the query in various ways, in particular by using SecKeychainCopyDomainSearchList with the domain kSecPreferencesDomainDynamic and adding it to the query as kSecMatchSearchList and trying other SecKeychain* methods, but ended up with nothing. I concluded that the identities from a smart card are being added to the data protection keychain rather than to a file based keychain and since I’m working in a privileged context, I won’t be able to get them. If this is indeed the case, could you please advise how to proceed? Thanks in advance.

I'm looking to implement USB monitoring for FIDO2 authentication through a custom Authorization Plugin, specifically for the below ones. This plugin applies to the following macOS authorization mechanisms: system.login.console — login window authentication system.login.screensaver — screensaver unlock authentication The goal is to build a GUI AuthPlugin, an authorization plugin that presents a custom window prompting the user to "Insert your FIDO key”. Additionally, the plugin should detect when the FIDO2 device is removed and respond accordingly. Additional Info: We have already developed a custom authorization plugin which is a primary authentication using OTP at login and Lock Screen. We are now extending to include FIDO2 support as a primary. Our custom authorization plugin is designed to replace the default loginwindow:login mechanism with a custom implementation. Question: Is there a reliable approach to achieve the USB monitoring functionality through a custom authorization plugin? Any guidance or pointers on this would be greatly appreciated.

I've been spending days trying to solve the memory leak in a small menu bar application I've wrote (SC Menu). I've used Instruments which shows the leaks and memory graph which shows unreleased allocations. This occurs when someone views a certificate on the smartcard. Basically it opens a new window and displays the certificate, the same way Keychain Access displays a certificate. Whenever I create an SFCertificateView instance and set setDetailsDisclosed(true) - a memory leak happens. Instruments highlights that line. import Cocoa import SecurityInterface class ViewCertsViewController: NSViewController { var selectedCert: SecIdentity? = nil override func viewDidLoad() { super.viewDidLoad() self.view = NSView(frame: NSRect(x: 0, y: 0, width: 500, height: 500)) self.view.wantsLayer = true var secRef: SecCertificate? = nil guard let selectedCert else { return } let certRefErr = SecIdentityCopyCertificate(selectedCert, &secRef) if certRefErr != errSecSuccess { os_log("Error getting certificate from identity: %{public}@", log: OSLog.default, type: .error, String(describing: certRefErr)) return } let scrollView = NSScrollView() scrollView.translatesAutoresizingMaskIntoConstraints = false scrollView.borderType = .lineBorder scrollView.hasHorizontalScroller = true scrollView.hasVerticalScroller = true let certView = SFCertificateView() guard let secRef = secRef else { return } certView.setCertificate(secRef) certView.setDetailsDisclosed(true) certView.setDisplayTrust(true) certView.setEditableTrust(true) certView.setDisplayDetails(true) certView.setPolicies(SecPolicyCreateBasicX509()) certView.translatesAutoresizingMaskIntoConstraints = false scrollView.documentView = certView view.addSubview(scrollView) // Layout constraints NSLayoutConstraint.activate([ scrollView.leadingAnchor.constraint(equalTo: view.leadingAnchor), scrollView.trailingAnchor.constraint(equalTo: view.trailingAnchor), scrollView.topAnchor.constraint(equalTo: view.topAnchor), scrollView.bottomAnchor.constraint(equalTo: view.bottomAnchor), // Provide certificate view a width and height constraint certView.widthAnchor.constraint(equalTo: scrollView.widthAnchor), certView.heightAnchor.constraint(greaterThanOrEqualToConstant: 500) ]) } } https://github.com/boberito/sc_menu/blob/dev_2.0/smartcard_menu/ViewCertsViewController.swift Fairly simple.

Hi, I have a certificate, how can I display the certificate content in my Mac app just like Keychain Access app does. Can I popup the certificate content dialog just like Keychain Access app?

Hi Team, We are trying to understand deep sleep behaviour, can you please help us clarifying on the below questions: When will we configure Hibernate 25, is it valid for M series MacBooks? Is Hibernate 25 called deep sleep mode? What are the settings I need to do on Mac, to make my Mac go in to deep sleep? When awakening from deep sleep , what would be macOS system behaviour? If we have custom SFAuthorization plug in at system.login.screensaver, what would be the behaviour with deep sleep?

Hi, I have a set of plugins which are registered for login. One of them is a custom ui view for the login screen. The scenario: 1.DisableFDEAutoLogin is false. 2.The User logs in to the file vault login screen. 3.The security plugins are activated, and working. 4.We get any kind of an error from the plugins, and therefore the login fails. 5.We get a native login screen, after the denial of authorization. 6.In case that DisableFDEAutoLogin is true, I do get the custom login screen, after the file vault login. My question: Why dont I see the custom login screen, after the auto login fails? Cheers Sivan

Hi, A user logs in to the file vault, and DisableFDEAutoLogin is false. The file vault login succeeds, but the login to the selected user fails. The user gets the login screen again. If the user puts an invalid password to try and login again, the loginwindow:FDESupport plugin will change the user's password to the invalid one.

Testing my security agent plugin on Tahoe and find that when unlocking the screen, I now get an extra window that pops up over the SFAuthorizationPluginView that says "macOS You must enter a password to unlock the screen" with a Cancel (enabled) and OK button (disabled). See the attached photo. This is new with Tahoe. When unlocking the screen, I see the standard username and password entry view and I enter my password and click OK. That is when this new view appears. I can only click cancel so there is no way to complete authenticating.