We are developing an enterprise security solution for macOS that includes Wi-Fi awareness and network-based policy enforcement - WiFi Control. On current macOS releases, access to the connected Wi-Fi's SSID/BSSID appears to require Location Services authorization. In many corporate environments, end users do not have local administrator privileges and cannot enable Location Services themselves. Enabling it often requires coordination with IT administrators, which can be difficult to scale in large organizations with a geographically distributed workspace. This creates a deployment challenge for enterprise security products because network identification becomes unavailable on managed Macs, even when the device is enrolled and managed through MDM. As far as we understand: MDM on macOS does not provide a mechanism equivalent to managed-device Wi-Fi control available in iOS management scenarios. System Extension running with elevated privileges cannot obtain the current SSID/BSSID through frameworks such as CoreWLAN even when Location Services access is granted (it requires user session). Our questions are: Is there currently any supported API or entitlement that allows enterprise security products to determine the currently connected SSID/BSSID on managed macOS devices without requiring end users to enable Location Services? Are there plans to provide a managed-device exception, entitlement, or MDM-controlled authorization model for enterprise security vendors that need network identity information for security and compliance use cases? Would Apple consider exposing SSID/BSSID information to approved System Extensions or Endpoint Security-based products in managed corporate environments, while maintaining existing privacy protections for consumer devices? We fully understand the privacy rationale behind restricting Wi-Fi information, but enterprise security and compliance solutions often need to identify trusted and untrusted networks. Today, the Location Services dependency significantly complicates deployment and usability in managed corporate environments. Any guidance on recommended approaches or future platform direction would be greatly appreciated.

For a Swift package that requires app developers to set a String API key at the app level (one key per app, not per user), what is Apple’s recommended approach for allowing those keys to be securely rotated without requiring an App Store redeploy?

Are there any plans to add Endpoint Security support for intercepting or observing listen() calls, so SIEM and EDR products can reliably monitor when processes begin accepting inbound network connections?

For a Swift package that requires app developers to set a String API key at the app level (one key per app, not per user), what is Apple’s recommended approach for allowing those keys to be securely rotated without requiring an App Store redeploy?

Are there any plans to add camera-access or camera-activation events to EndpointSecurity.framework, so security products (like SIEM/EDR) can reliably detect when applications start or stop using the camera without relying on private APIs or log monitoring?

Hi Apple Community & Apple Team, 
Problem : Should be able to use my iDP password when I try to unlock my macOS local User Account.
 Password should sync across my macOS local User Account, when my User Account Password in iDP Changed
 Should have a provision to create a on-demand macOS local account with password of iDP Should be able to Create Primary Account in Automated Device Enrollment with password synced to iDP ( Simplified PSSO in Setup Assistant ) Solution : All the above Problems can be solved if the Identity Provider implements Platform SSO , but not being implemented by major Identity Providers Except Okta, Microsoft, Ping 
Since Platform SSO Offers the necessary framework and provision that satisfy the above needs I planned to make a open-source initiative to bridge in PSSO and Oauth ROPG to connect with Any OpenID Provider that supports Oauth ROPG ( Resource Owner Password Grant ) 
ITS RIGHT THAT PSSO DOESN’T MEANT FOR THIS AND NEEDS TO BE IMPLEMENTED BY IDENTITY PROVIDER, AND MEANINGFUL ID TOKENS CAN BE ONLY USED BY THEM TO HELP THE SSO EXTENSION 
But the native login Experience, FileVault Synchronization, Keychain Unlock everything being handled by OS in PSSO. I thought its best to go in this way The Attachment Includes the Components, Design Decisions of this Project , Questions in the PSSO Framework workflow. Including some Questions from new WWDC26 OpenID Authentication Method introduced in PlatformSSO Please help with the Questions in the Attachment and post if there is any suggestions on the workflow I described Filed a Feedback with ID FB23065453

Hi Apple Community, Problem : Should be able to use my iDP password when I try to unlock my macOS local User Account.
 Password should sync across my macOS local User Account, when my User Account Password in iDP Changed
 Should have a provision to create a on-demand macOS local account with password of iDP Should be able to Create Primary Account in Automated Device Enrollment with password synced to iDP ( Simplified PSSO in Setup Assistant ) Solution : These can be solved if the Identity Provider implements Platform SSO , but not being implemented by all major Identity Providers Except major iDPs like Okta, Microsoft, Ping 
Since Platform SSO Offers the necessary framework and provision that satisfy the above needs I planned to make a open-source initiative to bridge in PSSO and Oauth ROPG to connect with Any OpenID Provider that supports Oauth ROPG 
I KNOW PSSO DOESN’T MEANT FOR THIS AND NEEDS TO BE IMPLEMENTED BY IDP, AND MEANINGFUL SSO TOKENS CAN BE ONLY ISSUED BY THEM TO HELP THE SSO EXTENSION 
But the native login Experience, FileVault Synchronization, Keychain Unlock everything being handled by OS in PSSO. I thought its best to go in this way The Attachment Includes the Components, Design Decisions of this Project , Questions in the PSSO Framework workflow. Including some Questions from new WWDC26 OpenID Authentication Method introduced in PlatformSSO Please help with the Questions in the Attachment and post if there is any suggestions on the workflow I described Filed Feedback with FB23065453

As an iOS developer, what should I make sure of so users can clearly see that privacy is considered in my app?

We have an application with multiple extension targets. We generate device check token using DCDevice.current.generateToken API. However while trying to validate the device using devicecheck.apple.com/v1/validate_device_token from our servers, we get success for our extension targets but failure for our app target. The transaction IDs are below For App target's device check token: 26050657-fa98-4d2e-8e28-eb0e4005cf15 For extension target's device check token: cfab83e0-8aa7-43e7-8343-f8baaec6ee651001 We assume this is because our main target has a different APPID prefix compared to our extension targets. Device validation API should not fail because the code signing is done from the same developer ID. Can you check on this? Or Can we use the device verify token from our extension targets for validating the app since extension targets are a bundled with app target by design?

Hi! I have not seen this year's video yet, so please forgive me if this is answered. I notice a couple of folks here saying that AppAttest is (at least partially) supported on macOS 27. Is this correct? My specific use case is a "designed for iPad" app running on macOS. We use App Attest to make high-value requests to our headend services and would really like this to work on macOS as well.

The wwdc session mentioned that attestation keys survive app updates but not reinstalls. So it seems like if I try to create an assertion after reinstall from the key I pull from keychain, and include that assertion in my API payload to my backend, my backend will reject the assertion. Is there any mechanism for us to ask the client framework "is this key still valid"? Thanks again, Lou

Are there any plans to increase the DC token validity or enable using attestations to set the device check bit states? The current implementation makes it challenging to set bit states once we identify a device as belong to a bad actor after the fact. We need to actor to re-engage with the platform to be able to collect a DC token which mostly doesnt happen since they use burner accounts and move on.

Apple has provided a number of Swift Packages for backend development, including some new tools for wallet passes! Is there anything like this for attestation and device check capabilities for a swift-on-server product to consume? If not, consider this a placeholder for a future feedback request.

My understanding from the App Attest wwdc session is that we store attestation keys in keychain on a per-user basis. For apps that don't require user login, I'm thinking of using StoreKit's AppTransactionID [1] as the identifier to discriminate keys. Do you have opinions on whether this is a valid pattern? [1] https://developer.apple.com/documentation/storekit/apptransaction/apptransactionid

Hi, The WWDC session noted App Attest is supported on macOS 27, but only for certain extension types (Action and SSO were the examples shown IIRC). Is there a definitive list of which extension types support DCAppAttestService on macOS 27 — and is the credential-provider extension (ASCredentialProviderExtension) among them? If credential-provider extensions are not supported, in an app that ships a credential-provider extension, can I add a separate (e.g. SSO or Action) extension — or use the containing app — to perform App Attest and generate/attest a key, then use that key from the credential-provider extension (e.g. via a shared keychain access group)? Or is the attested key inherently bound to the attesting process and not shareable? Thanks!

Since device check APIs (attestation) are not available for extensions like share extension and widget extension (at least in 26 and according to documentation still in 27) - is there any best practice how to still protect endpoints which are also called from these extensions? And subquestion: is there a technical limitation in iOS design that made it impossible to also support extensions.

Hi App Attest team, I was nodding along happily in the wwdc session, because it was seeming like an air tight solution to prevent API abuse while allowing "guest" access (e.g. not enforcing that users log in). Then I hit this line, "a compromised device can still pass attestations". How is that possible? Earlier in the session, the presenter said "[AppAttest] gives you the assurance that your app is running on a secure apple device". I'm trying to square these statements and understand the motivation of the 'fraud metric'. Thank you! Lou Ps. I'm so happy that AppAttest is available on Mac now. :D

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?