Hey guys, I'm building a managed macOS app (credential-provider extension) that needs an MDM-provisioned, hardware-bound, attested identity via the ManagedApp framework on macOS 27 which just released days ago, and I've hit a documentation contradiction. By reading through the docs, my understanding of the ManagedApp identity path is com.apple.configuration.app.managed → Identities → com.apple.asset.credential.acme. But the OS27 ACME schema says, for both HardwareBound and Attest: "On macOS, this is a required key. Set the value to false" (https://github.com/apple/device-management/blob/seed_OS_27_0/declarative/declarations/assets/credentials/acme.yaml#L66) — implying a software key. However, the macOS 27 release notes say ManagedApp deploys "hardware-bound identities" on macOS. So I am wondering that on macOS 27 + Apple silicon, can a ManagedApp-provisioned ACME identity actually be HardwareBound: true / Attest: true? If yes, is the acme.yaml "set to false on macOS" text just stale? If no, how is the documented "hardware-bound identities" capability delivered? And would that identity gonna be able to be used by the app / app extension? Thanks!

Are there any mechanisms to troubleshoot or test SiwA server-to-server notifications? I am not seeing any traffic from Apple for user account changes (e.g., revoking authorization for an app), but the URL that I have configured in my account matches my endpoint, it is available from the public internet, and other SiwA functions are working correctly. Any guidance will be appreciated.

There wasn't any update on the tap to login. Has the spec on tap to login been finalized? Can wallet passes now be issued to authenticate to macOS using tap to login?

We would like to implement Platform SSO with the new web authentication. Where is the protocol documented? I have the documentation from prior versions of PSSO but would like to see the updated documentation.

With the rapid advancement of on-device AI and Apple Intelligence, does Apple see a future where user identity can be continuously verified through behavioral patterns and contextual signals rather than relying solely on discrete authentication events such as Face ID, Touch ID, or passcodes? If so, what privacy, security, and battery-efficiency challenges would need to be solved before such an approach could become practical on Apple platforms?

Are there current plans to implement Microsoft 365 groups with Platform SSO to control administrator access in macOS 27? If so, would you be able to provide a rough estimate of when we can expect changes to be implemented by identity providers?

I saw the "Authenticated Guest Mode on iPad" in macOS 27. Is this related to PSSO Authenticated Guest Mode on macOS? Does it require cloud binding for a machine account like on macOS? How is it related to Shared iPad? Shared iPad requires supervised mode. Is there a new profile and keys? Where is this documented? Can you share information about how it works and how it can be tested?

Future of Behavioral Authentication on Apple PlatformsWith the rapid advancement of on-device AI and Apple Intelligence, does Apple see a future where user identity can be continuously verified through behavioral patterns and contextual signals rather than relying solely on discrete authentication events such as Face ID, Touch ID, or passcodes? If so, what privacy and security challenges would need to be solved before such an approach could become practical on Apple platforms?

with the advancement of on-device ai, do you see a future where devices continuously verify a user’s identity through behavioral patterns rather than discrete authentication events such as Face ID or password entry?

do you see a future where devices continuously verify a user’s identity through behavioral signals rather than discrete login events?

We are deploying Platform SSO using the Secure Enclave authentication method. However, users are still being prompted for their username and password during registration. This undermines our goal of going passwordless and is causing deployment friction with customers. Once the Secure Enclave method is deployed and initialized, is there a way to suppress or skip this password dialog so users only authenticate via hardware/biometrics?

Are there any Kerberos feature or behavior changes in macOS 27?

During PSSO User Registration, we use ASWebAuthenticationSession for OIDC. If the user's default browser isn't Safari (e.g., Chrome), the browser window stays stuck on top of the PSSO UI after authentication. This confuses users because they can't see the final PSSO registration screen. Are there any native macOS window-management APIs we can call inside the session's completion handler to force the PSSO window back to the foreground?

When a host app hasn't implemented ATT at all — which is still common in enterprise apps — what's the expected behavior for third-party SDKs that rely on tracking authorization? Should the SDK default to notDetermined handling indefinitely, or is there a recommended fallback experience?

For a third-party ads SDK embedded in host apps: the ATT authorization status is determined at the app level, but our SDK initializes before the host app necessarily calls ATTrackingManager.requestTrackingAuthorization(). What's Apple's recommended pattern for: SDK initialization that's ATT-status-agnostic at launch Receiving a callback or notification when ATT status changes post-initialization, without polling Is there a system notification or delegate pattern for ATT status changes that SDKs should be using in iOS 27? — Divya Ravi, Senior iOS Engineer

Throughout the years I've done a few integrations at my company with an iOS Application and an identity provider. I've implemented samples with UIWebView, WKWebview, Certificate based authentication through custom URLSession implementations and lastly through ASWebAuthentication. Also I gave the SSO Extension a try, but got stuck at some point (also Apple Forum didn't give me some solution -> https://developer.apple.com/forums/thread/117747) I'm having troubles digging through the Apple resources to find the best approach for big enterprises. We make use of a MDM solution, so I was hoping to find means to 'exploit it' and don't implement any custom authenticationframework anymore. Also, granting SSO between Apps and websites is what my ideal goal would be. Could you point me to some resources that can help me or give me some guidance on which of the frameworks/SDKs to use?

Hey there, I'm trying to building an iOS credential provider (ASCredentialProviderExtension, iOS 17+) that manages passkeys backed by keys generated in the Secure Enclave, attested via App Attest. My question is about the cross-device (FIDO2 hybrid / "passkey on a nearby device") flow, where a phone authenticates a sign-in initiated on a separate client device (e.g. a laptop browser). Specifically, Can a third-party credential provider serve as the authenticator in this flow, signing with its own key — or is the cross-device role reserved for iCloud Keychain? If it can, does the OS handle the BLE advertisement and tunnel/handshake on the provider's behalf? I ask because it seems like CBPeripheralManager.startAdvertising(_:) will not emit raw bytes, so an app can't emit a CTAP hybrid advert itself. If neither is supported, is there any supported API — including MDM-managed/supervised-device capabilities — for an app to act as a cross-device FIDO2 authenticator with a non-iCloud-Keychain key? Thanks!

We have a macOS app (io.formhealth.SideCore) that acts as a browser-style wrapper, embedding multiple web applications in WKWebView panes. We need the com.apple.developer.web-browser.public-key-credential entitlement so that WebAuthn/passkey flows (e.g. Google OAuth) work within the embedded webviews. The capability doesn't appear on macOS App IDs in the developer portal, and the entitlement request form at developer.apple.com/contact/request/system-extension returns "Your account can't access this page." What's the correct process to request this entitlement for a non-App-Store macOS app?

Hello everyone, I’m trying to better understand the expected behavior of Sign in with Apple after an app is transferred to another Apple Developer Team. Specifically, my question is about users who do not open or sign in to the app during the 60-day migration period after the app transfer. Here is the scenario we are concerned about: An existing user created an account using Sign in with Apple. The user is using a private relay email address. The app is transferred to another Apple Developer Team. The user does not sign in during the 60-day migration period. The user signs in again only after the 60-day period has ended. In this situation, is there any possibility that Apple may provide different user-related values compared to the values before the app transfer? For example, I am referring to values such as: sub private relay email address ID token claims any other API response value that may be used to identify the user The reason I’m asking is that if any of these values change after the transfer, our backend may not be able to match the user to the existing account in our database. In that case, the user could incorrectly be treated as a new user. My understanding is that the purpose of the Sign in with Apple migration process after an app transfer is to associate the user identifier from the original Team with the user identifier for the new Team. However, I would like to confirm what happens if the user was not processed during the 60-day migration period and signs in later. Do the values provided by Apple remain consistent in this case, or can they change after the migration period ends? If they can change, should we prepare our own account recovery or re-linking flow to handle these users? I would appreciate any clarification on Apple’s expected behavior and the recommended approach for this case. Thank you.

I'm trying to diagnose some issues with my AutoFill credential provider not loading on macOS. As far as I can tell I have all the entitlements and provisioning profiles correct, and ASSettingsHelper.requestToTurnOnCredentialProviderExtension() returns true with the Credential Provider showing up enabled in System Settings. However all other attempts to call into AuthenticationServices fail, and ASCredentialIdentityStore.shared.getState() always returns false for state.isEnabled Looking at the logs I don't see anything that stands out but I am not sure I've got the correct filter on the logs. I see discovery taking place 2026-05-29 08:43:09.389967-0700 0xd7d00 Default 0x83c0b1 26490 0 CredentialProviderExtensionHelper: (PlugInKit) [com.apple.PlugInKit:discovery] [d 88616305-672E-4143-81A6-832522BCD790] <PKHost:0x7e6c24900> Beginning discovery for flags: 0, point: com.apple.authentication-services-credential-provider-ui 2026-05-29 08:43:09.390070-0700 0xd7d00 Info 0x83c0b1 26490 0 CredentialProviderExtensionHelper: (PlugInKit) [com.apple.PlugInKit:discovery] [d 88616305-672E-4143-81A6-832522BCD790] <PKHost:0x7e6c24900> Query: { "LS:ExtensionPlatforms" = ( 1, 6, 2 ); NSExtensionPointName = "com.apple.authentication-services-credential-provider-ui"; NSUserElection = 1; } 2026-05-29 08:43:09.392893-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:sandbox] issued file extension for [/Applications/test.app/Contents/PlugIns/testIDCredentialProvider.appex] 2026-05-29 08:43:09.392936-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:ls] [u C85BFC1E-25E1-4917-A1D8-0123013482EE] [com.myapp.test.App.testid-credential-provider(7.35)] info [CFBundleIdentifier] => [com.myapp.test.App.testid-credential-provider] 2026-05-29 08:43:09.392947-0700 0xd79ee Debug 0x83c0b1 487 0 pkd: (PlugInKit) [com.apple.PlugInKit:sandbox] issued mach extension for [com.myapp.test.App.testid-credential-provider] And I see it being discovered correctly: 2026-05-29 08:43:09.394535-0700 0xd7d00 Default 0x83c0b2 26490 0 CredentialProviderExtensionHelper: (ExtensionFoundation) [com.apple.extensionkit:NSExtension] discovered extensions: attributes { "LS:ExtensionPlatforms" = ( 1, 6, 2 ); NSExtensionPointName = "com.apple.authentication-services-credential-provider-ui"; NSUserElection = 1; }, extensionSet {( <EXConcreteExtension: 0x7e71b41c0> {id = com.myapp.test.App.testid-credential-provider} )} I don't see any errors related to security or provisioning that I can tell. Any tricks I can use to see why I can't use my Credential Provider?