Hello, I’m working on a security agent plugin for Mac. The plugin provides a mechanism with custom UI via SFAuthorizationPluginView and a privileged mechanism with the business logic. The plugin needs to support unlocking the device, so I changed the authorize right to invoke my agent: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>evaluate-mechanisms</string> <key>created</key> <real>731355374.33196402</real> <key>mechanisms</key> <array> <string>FooBar:loginUI</string> <string>builtin:reset-password,privileged</string> <string>FooBar:authenticate,privileged</string> <string>builtin:authenticate,privileged</string> </array> <key>modified</key> <real>795624943.31730103</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>1</integer> </dict> </plist> I also changed the system.login.screensaver right to use authorize-session-owner: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>rule</string> <key>comment</key> <string>The owner or any administrator can unlock the screensaver, set rule to "authenticate-session-owner-or-admin" to enable SecurityAgent.</string> <key>created</key> <real>731355374.33196402</real> <key>modified</key> <real>795624943.32567298</real> <key>rule</key> <array> <string>authenticate-session-owner</string> </array> <key>version</key> <integer>1</integer> </dict> </plist> I also set screenUnlockMode to 2, as was suggested in this thread: macOS Sonoma Lock Screen with SFAutorizationPluginView is not hiding the macOS desktop. In the Display Authorization plugin at screensaver unlock thread, Quinn said that authorization plugins are not able to use Touch ID. However, on a MacBook with at touch bar, when I lock the screen, close the lid, and then open it, the touch bar invites me to unlock with Touch ID. If I choose to do so, the screen unlocks and I can interact with the computer, but the plugin UI stays on screen and never goes away, and after about 30 seconds the screen locks back. I can reliably reproduce it on a MacBook Pro with M1 chip running Tahoe 26.1. Is this a known macOS bug? What can I do about it? Ideally, I would like to be able to integrate Touch ID into my plugin, but since that seems to be impossible, the next best thing would be to reliably turn it off completely. Thanks in advance.

I have a custom NSWindow that I want to exclude from screen capture by setting its sharing state to kCGWindowSharingStateSharingNone. The goal is to prevent this window from appearing in the content captured by ScreenCaptureKit. [window setSharingType:NSWindowSharingType::NSWindowSharingNone]; However, on macOS 15.4+ (Sequoia), the window is still captured by ScreenCaptureKit and appears in the shared content. Does anyone know if kCGWindowSharingStateSharingNone is still effective with ScreenCaptureKit on macOS 15.4 and later?

Since October 3rd, I've stopped receiving responses to the Private Access Tokens challenge. I'm using this link: https://demo-issuer.private-access-tokens.fastly.com/.well-known/token-issuer-directory. I receive tokens from Fastly and return a header to the iOS app, but then I don't receive another authentication request from iOS. The user has automatic verification enabled on their phone. The problem is global and affects all my mobile app users. Has anyone encountered a similar problem and found a solution?

What Has Been Implemented Replaced the default loginwindow:login with a custom authorization plugin. The plugin: Performs primary OTP authentication. Displays a custom password prompt. Validates the password using Open Directory (OD) APIs. Next Scenario was handling password change Password change is simulated via: sudo pwpolicy -u robo -setpolicy "newPasswordRequired=1" On next login: Plugin retrieves the old password. OD API returns kODErrorCredentialsPasswordChangeRequired. Triggers a custom change password window to collect and set new password. Issue Observed : After changing password: The user’s login keychain resets. Custom entries under the login keychain are removed. We have tried few solutions Using API, SecKeychainChangePassword(...) Using CLI, security set-keychain-password -o oldpwd -p newpwd ~/Library/Keychains/login.keychain-db These approaches appear to successfully change the keychain password, but: On launching Keychain Access, two password prompts appear, after authentication, Keychain Access window doesn't appear (no app visibility). Question: Is there a reliable way (API or CLI) to reset or update the user’s login keychain password from within the custom authorization plugin, so: The keychain is not reset or lost. Keychain Access works normally post-login. The password update experience is seamless. Thank you for your help and I appreciate your time and consideration

We've filed FB22448572 for this, but posting here in case others are hitting the same issue. After upgrading macOS from 26.3.2 to 26.4, SecItemCopyMatching returns errSecAuthFailed (-25293) when reading kSecClassGenericPassword items from the default login keychain. The keychain reports as unlocked, but all authenticated operations fail. The error doesn't self-resolve — we've observed it persisting for 7+ minutes across repeated calls and process restarts. The only workaround we've found is SecKeychainLock(nil) followed by SecKeychainUnlock(nil, 0, nil, false), which prompts the user for their password and clears the stale state. Apple's own security CLI tool also fails while the keychain is in this state: $ security show-keychain-info ~/Library/Keychains/login.keychain-db security: SecKeychainCopySettings .../login.keychain-db: The user name or passphrase you entered is not correct. The trigger seems to be process lifecycle — a new process accessing the keychain early in startup (e.g., from the app delegate) can hit this state after the OS upgrade. It's probabilistic: not every machine and not every restart, but once it happens, it sticks until manual intervention. We're an enterprise app using legacy keychain APIs (SecKeychainCopyDefault, kSecUseKeychain) deployed to thousands of managed devices. We've reproduced this on multiple machines (M1, M2) and have reports from customers in the field after the 26.4 upgrade. I noticed a possibly related thread — Calling SecKeychainUnlock with a locked keychain and an invalid password returns errSecSuccess on macOS 26.4 — where SecKeychainUnlock stopped properly validating passwords after 26.4. Our symptom is different (reads fail on an unlocked keychain rather than unlock succeeding with wrong password), but both appeared after 26.4 and both point to something changing in securityd's authentication handling. Wondering if these could be related. A couple of questions: Is there a known issue with securityd's keychain authentication after 26.4? Could this be related to the CVE-2026-28864 fix ("improved permissions checking" in the Security component)? Would migrating to the data protection keychain (kSecAttrAccessible instead of kSecUseKeychain) avoid this class of issue entirely? Is there a way to detect and clear this stale state programmatically without the user entering their password? Any guidance appreciated.

Hello Apple Developer: I encountered some issues during development. I encrypted the secret key and stored it in the Keychain, but it failed when I tried to read it. I would like to ask if there is any problem with the code I wrote. Below is my code, including the storage and retrieval NSMutableDictionary *query = [[NSMutableDictionary alloc] initWithObjectsAndKeys:(id)kSecClassGenericPassword,(id)kSecClass, serviceID,(id)kSecAttrService, @YES,(id)kSecReturnData,nil]; CFTypeRef dataTypeRef = NULL; NSLog(@"SecItemCopyMatching"); OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)(query), &dataTypeRef); NSLog(@"SecItemCopyMatching end status = %d",status); if (status == errSecSuccess) { *privateData = CFBridgingRelease(dataTypeRef); return 0; }else{ return status; } NSMutableDictionary *attributespri = [[NSMutableDictionary alloc] initWithObjectsAndKeys: (id)kSecClassGenericPassword, (id)kSecClass, serviceID, (id)kSecAttrService, outData, (id)kSecValueData, nil]; CFTypeRef dataRef = NULL; OSStatus priStatus = SecItemAdd((__bridge CFDictionaryRef)attributespri, &dataRef); if (dataRef) CFRelease(dataRef); return priStatus == noErr;

I’m using a custom Installer plug-in (InstallerPane) to collect sensitive user input (username/password) during install. After the payload is laid down, I need to send those values to a newly installed agent (LaunchAgent) to persist them. What I tried I expose an XPC Mach service from the agent and have the plug-in call it. On the agent side I validate the XPC client using the audit token → SecCodeCopyGuestWithAttributes → SecCodeCheckValidity. However, the client process is InstallerRemotePluginService-* (Apple’s view service that hosts all plug-ins), so the signature I see is Apple’s, not mine. I can’t distinguish which plug-in made the call. Any suggestion on better approach ?

I've been trying over the past few days to use a PIV-programmed Yubikey to perform mTLS (i.e. mutual client cert auth) in my custom app. My understanding is that I need to feed NSURLSession a SecIdentity to do so. Yubico's instructions state that I need their Yubico Authenticator app for this, but this directly contradicts Apple's own documentation here. I dont need NFC/lightening support, and I only need support for my specific app. When I plug in my key to my iPhone and have TKTokenWatcher active, I DO see "com.apple.pivtoken" appear in the logs. And using Yubico's SDK, I CAN get data from the key (so I'm pretty sure my entitlements and such are correct). But using the below query to get the corresponding (fake? temporary?) keychain item, it returns NULL no matter what I do: let query: [String: Any] = [ kSecClass as String: kSecClassIdentity, kSecReturnRef as String: true, kSecAttrTokenID as String: "apple.com.pivtoken", // Essential for shared iPads kSecMatchLimit as String: kSecMatchLimitOne ] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &item) "status" is always -25300 (which is "not found"). I've also created a CTK extension (as Yubico's authenticator does) and tried to use self.keychainContents.fill(), and then tried to access it with kSecAttrTokenID as ":Yubico YubiKey OTP+FIDO+CCID", as that's what shows via TKTokenWatcher, and this also doesn't work. I've also tried just the app extension ID, and that doesn't work. Both my extension and my main app have the following entitlements: <key>com.apple.developer.default-data-protection</key> <string>NSFileProtectionComplete</string> <key>com.apple.security.application-groups</key> <array/> <key>com.apple.security.smartcard</key> <true/> <key>keychain-access-groups</key> <array> <string>$(AppIdentifierPrefix)com.apple.pivtoken</string> <string>$(AppIdentifierPrefix)myAppExtensionId</string> </array> As one final test, I tried using the yubikey in safari to access my server using mTLS, and it works! I get prompted for a PIN (which is odd because I've programmed it not to require a PIN), but the request succeeds using the key's default PIN. I just cannot get it working with my own app. Can anyone here (or preferably, at Apple) point me in the right direction? I have a feeling that the documentation I've been reading applies to MacOS, and that iOS/ipadOS have their own restrictions that I either need to work around, or which prevent me from doing what I need to do. It's obviously possible (i.e. the Yubico Authenticator sort of does what I need it to), but not in the way that Apple seems to describe in their own documentation.

I've contacted Apple support about this topic, and they've directed me to this forum. I regularly perform Pentests of iOS applications. To properly assess the security of iOS apps, I must bypass given security precaution taken by our customers, such as certificate pinning. According to a number of blog articles, this appears to only be viable on jailbroken devices. If a target application requires a modern version of iOS, the security assessment can't be properly performed. As it should be in Apple's best interest, to offer secure applications on the App Store, what's the recommended approach to allow intrusive pentesting of iOS apps?

I have reached out to support and they simply tell me they are unable to help me, first redirecting me to generic Apple support, after following up they provided the explanation that they only handle administrative tasks and to post on the forums. I am unable to change my App Tracking Transparency it provides no real error, though network traffic shows a 409 HTTP response from the backend API when trying to save. Here is a screenshot of the result when trying to save. Does anyone have any suggestions on how to get this resolved? I've commented back to the reviewers and they simply provided help documentation. I have a technical issue and am unable to get anyone to help resolve this.

I am not very well versed in this area, so I would appreciate some guidance on what should be enabled or disabled. My app is an AppKit app. I have read the documentation and watched the video, but I find it hard to understand. When I added the Enhanced Security capability in Xcode, the following options were enabled automatically: Memory Safety Enable Enhanced Security Typed Allocator Runtime Protections Enable Additional Runtime Platform Restrictions Authenticate Pointers Enable Read-only Platform Memory The following options were disabled by default: Memory Safety Enable Hardware Memory Tagging Memory Tag Pure Data Prevent Receiving Tagged Memory Enable Soft Mode for Memory Tagging Should I enable these options? Is there anything I should consider disabling?

I can see the user’s real daily Screen Time perfectly inside a DeviceActivityReport extension on a physical device. It’s right there. But the moment I try to use that exact total inside my main app (for today’s log and a leaderboard), it dosnt work. I’ve tried, App Groups, Shared UserDefaults, Writing to a shared container file, CFPreferences Nothing makes it across. The report displays fine, but the containing app never receives the total. If this is sandboxed by design, I’d love confirmation. Thanks a lot

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 .

I am developing a daemon-based product that needs a cryptographic, non-spoofable proof of machine identity so a remote management server can grant permissions based on the physical machine. I was thinking to create a signing key in the Secure Enclave and use a certificate signed by that key as the machine identity. The problem is that the Secure Enclave key I can create is only accessible from user context, while my product runs as a system daemon and must not rely on user processes or launchAgents. Could you please advise on the recommended Apple-supported approaches for this use case ? Specifically, Is there a supported way for a system daemon to generate and use an unremovable Secure Enclave key during phases like the pre-logon, that doesn't have non user context (only the my application which created this key/certificate will have permission to use/delete it) If Secure Enclave access from a daemon is not supported, what Apple-recommended alternatives exist for providing a hardware-backed machine identity for system daemons? I'd rather avoid using system keychain, as its contents may be removed or used by root privileged users. The ideal solution would be that each Apple product, would come out with a non removable signing certificate, that represent the machine itself (lets say that the cetificate name use to represent the machine ID), and can be validated by verify that the root signer is "Apple Root CA"

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.

[Q] When is the kTCCServiceEndpointSecurityClient set by macOS and in which conditions? From what I'm gathering, the kTCCServiceEndpointSecurityClient can not be set by a configuration profile and the end user can only grant full disk access. I searched for documentation on Apple's develop website (with the "kTCCServiceEndpointSecurityClient" search) and did not get any useful result. Using a more complete search engine, or the forum search engine, only points to the old annoying big bug in macOS Ventura. The problem I'm investigating is showing a process being listed as getting granted kTCCServiceEndpointSecurityClient permissions in the TCC database when: it's not an Endpoint Security client. it does not have the ES Client entitlement. the bundle of the process includes another process that is an ES Client and is spawn-ed by this process but I don't see why this should have an impact. This process is supposed to have been granted kTCCServiceSystemPolicyAllFiles via end user interaction or configuration profile. AFAIK, the kTCCServiceEndpointSecurityClient permission can only be set by macOS itself. So this looks like to be either a bug in macOS, an undocumented behavior or I'm missing something. Hence the initial question. macOS 15.7.3 / Apple Silicon

Hi, I’m seeing a production issue on iOS 26+ that only affects some users. symptoms: It does NOT happen for all users. It happens for a subset of users on iOS 26+. If we write a value to Keychain and read it immediately in the same session, it succeeds. However, after terminating the app and relaunching, the value appears to be gone: SecItemCopyMatching returns errSecItemNotFound (-25300). Repro (as observed on affected devices): Launch app (iOS 26+). Save PIN data to Keychain using SecItemAdd (GenericPassword). Immediately read it using SecItemCopyMatching -> success. Terminate the app (swipe up / kill). Relaunch the app and read again using the same service -> returns -25300. Expected: The Keychain item should persist across app relaunch and remain readable (while the device is unlocked). Actual: After app relaunch, SecItemCopyMatching returns errSecItemNotFound (-25300) as if the item does not exist. Implementation details (ObjC): We store a “PIN” item like this (simplified): addItem: kSecClass: kSecClassGenericPassword kSecAttrService: <FIXED_STRING> kSecValueData: kSecAttrAccessControl: SecAccessControlCreateWithFlags(..., kSecAttrAccessibleWhenUnlockedThisDeviceOnly, 0, ...) readItem (SecItemCopyMatching): kSecClass: kSecClassGenericPassword kSecAttrService: <FIXED_STRING> kSecReturnData: YES (uses kSecUseOperationPrompt in our async method) Question: On iOS 26+, is there any known issue or new behavior where a successfully added GenericPassword item could later return errSecItemNotFound after app termination/relaunch for only some users/devices? What should we check to distinguish: OS behavior change/bug vs. entitlement/access-group differences (app vs extension, provisioning/team changes), device state/policies (MDM, passcode/biometrics changes), query attributes we should include to make the item stable across relaunch? Build / Dev Environment: macOS: 15.6.1 (24G90) Xcode: 26.2

While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.

I'm seeing some odd behavior which may be a bug. I've broken it down to a least common denominator to reproduce it. But maybe I'm doing something wrong. I am opening a file read-write. I'm then mapping the file read-only and private: void* pointer = mmap(NULL, 17, PROT_READ, MAP_FILE | MAP_PRIVATE, fd, 0); I then unmap the memory and close the file. After the close, eslogger shows me this: {"close":{"modified":false,[...],"was_mapped_writable":false}} Which makes sense. I then change the mmap statement to: void* pointer = mmap(NULL, 17, PROT_READ, MAP_FILE | MAP_SHARED, fd, 0); I run the new code and and the close looks like: {"close":{"modified":false, [....], "was_mapped_writable":true}} Which also makes sense. I then run the original again (ie, with MAP_PRIVATE vs. MAP_SHARED) and the close looks like: {"close":{"modified":false,"was_mapped_writable":true,[...]} Which doesn't appear to be correct. Now if I just open and close the file (again, read-write) and don't mmap anything the close still shows: {"close":{ [...], "was_mapped_writable":true,"modified":false}} And the same is true if I open the file read-only. It will remain that way until I delete the file. If I recreate the file and try again, everything is good until I map it MAP_SHARED. I tried this with macOS 13.6.7 and macOS 15.0.1.

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