macOS 27 Beta 6 Has No New Identity APIs—Settled in June

Here’s the blunt version, so you can close the tab if it’s all you needed: macOS 27 Golden Gate Beta 6, build 26A5416b, released August 17, adds no new identity entitlements, no new SSO extension APIs, and no changes to the passkey or LocalAuthentication surface that show up in the SDK or the public schemas. If your deployment depends on Platform SSO, an Extensible SSO extension, Kerberos, or credential-provider passkeys, nothing in this build asks you to rewrite code.

That is not a shrug. It’s the expected outcome, and the interesting part is why it was already decided months ago—and where the actual risk in a build this late in the cycle really lives. It isn’t in the header files.

June: the surface got frozen and nobody sent a memo

Apple’s identity API surface for a major release is set at the first developer seed alongside WWDC, not incrementally dripped across the summer. When the Xcode 27 SDK shipped, that’s when the new symbols in AuthenticationServices, LocalAuthentication, and the declarative management schema landed—or didn’t. Betas 1 through 3 are the last realistic window for genuinely new entitlements or a new SSO extension capability, because vendors and enterprise teams need runway to build against them.

By the time you reach a sixth beta in mid-August, you are in bug-fix and behavior-tuning territory. New public API this late would be an act of aggression against every MDM vendor trying to certify before GA. Apple knows this. So the honest expectation walking into a Beta 6 audit is: the syntax is stable, and anything that changed is behavioral. That reframes the whole exercise.

August 17: what the audit actually checks

“No documented identity changes” is a claim you have to earn, not assume from a marketing changelog that was never going to mention entitlements anyway. Three things are worth diffing on your own machine, and none of them require trusting me.

SDK header diffs. The framework headers in the beta SDK are the ground truth for what’s callable. Pull them and compare against the previous major SDK:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# Point at the beta SDK's AuthenticationServices headers
XCODE_BETA="/Applications/Xcode-beta.app"
SDK="$XCODE_BETA/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk"
AS="$SDK/System/Library/Frameworks/AuthenticationServices.framework/Headers"
​
# Diff against the previous stable SDK's copy
diff -rq \
  "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AuthenticationServices.framework/Headers" \
  "$AS"
​
# Same drill for the auth-adjacent frameworks
for FW in LocalAuthentication CryptoTokenKit DeviceManagement; do
  echo "== $FW =="
  diff -rq \
    "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/$FW.framework/Headers" \
    "$SDK/System/Library/Frameworks/$FW.framework/Headers"
done

A clean diff here is the whole “no new API” finding. It’s five minutes of work and it beats reading any blog post—including this one.

Entitlement inventory. New capabilities usually announce themselves as new entitlement keys before there’s documentation. Dump what a shipping binary declares and grep for the identity-relevant ones:

1
2
3
4
5
6

# What identity entitlements does the running AuthenticationServices stack expose?
codesign -d --entitlements :- /usr/libexec/AuthenticationServicesAgent 2>/dev/null | \
  grep -iE 'sso|webcredentials|autofill|shared-web|keychain|associated-domains|relying-party'
​
# Broad sweep of your own app's granted entitlements before you resign it
codesign -d --entitlements :- ./YourApp.app 2>/dev/null

The declarative management schema. This is the one people forget, and it’s the one that reshapes fleets with no announcement. Apple publishes the MDM and declarative management schema in the open. Diff the repo, don’t guess:

1
2
3
4
5
6
7

git clone https://github.com/apple/device-management.git
cd device-management
git log --since="2026-06-01" --oneline -- declarative/ mdm/
# Watch specifically for new Configuration declarations touching
# authentication, SSO, or account/identity payloads
git diff HEAD~20 -- declarative/declarations/configurations/ | \
  grep -iE 'sso|kerberos|account|identity|passkey|credential'

Run those three, and for Beta 6 you land where I did: the Extensible SSO payload (com.apple.extensiblesso), the Platform SSO configuration keys, and the passkey/credential-provider entry points are unchanged from what shipped in the prior major release. The declarative configuration set didn’t grow an identity declaration in this window. That’s the documented finding, and it’s reproducible.

The trap: “no API change” is not “no behavior change”

This is where a lazy audit gets someone paged in October. Late betas are precisely where behavior drifts under a frozen API. Same function signatures, different runtime reality. Four things I’d put on a test rig before GA regardless of what the diffs say:

Platform SSO token renewal and re-registration. The registration handshake and background token refresh are exactly the kind of flow that gets touched by “reliability” fixes with no API footprint. Enroll a fresh device against your Entra or Okta Platform SSO config, then force the ugly cases: expired refresh token, network partition mid-renewal, a password change at the IdP while the Mac is asleep. Watch whether the extension re-registers cleanly or wedges into a state that needs a profile removal to recover.

iCloud Keychain and passkey sync timing. Passkeys created through ASAuthorizationPlatformPublicKeyCredentialProvider depend on Keychain sync propagation you don’t control. A relying party that assumes a passkey is available on the second device the instant it was created on the first is testing your users’ patience, not the OS. Re-run your cross-device registration and assertion flows and measure the propagation window on the beta.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import AuthenticationServices
​
// Sanity-check that platform passkey assertion still behaves on Beta 6.
// The API is unchanged—you're testing runtime behavior, not compilation.
func requestPasskeyAssertion(challenge: Data, rpID: String,
                             presentation: ASAuthorizationController.PresentationContextProviding) {
    let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(relyingPartyIdentifier: rpID)
    let request = provider.createCredentialAssertionRequest(challenge: challenge)
​
    let controller = ASAuthorizationController(authorizationRequests: [request])
    controller.presentationContextProvider = presentation
    controller.performRequests()
    // What you care about on a beta: does the system sheet appear promptly,
    // does iCloud Keychain surface the credential, and does the assertion
    // round-trip validate server-side without clock-skew surprises?
}

LocalAuthentication and the Secure Enclave gate. The API is stable, but the policy evaluation around biometric re-prompts and LAContext reuse windows is fair game for tuning. If your app caches an evaluated context and assumes it stays valid for a fixed interval, verify that assumption holds on this build rather than in front of a customer.

1
2
3
4
5
6
7
8
9
10
11
12
13

import LocalAuthentication
​
let context = LAContext()
var error: NSError?
guard context.canEvaluatePolicy(.deviceOwnerAuthenticationWithBiometrics, error: &error) else {
    // On beta, confirm the failure reason here matches expectations—
    // policy availability, not a silent fallback you didn't design for.
    return
}
context.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics,
                       localizedReason: "Confirm it's you") { success, evalError in
    // Test the re-prompt cadence and how long this context stays "warm."
}

Managed Apple ID federation round-trips. If you federate Managed Apple IDs with Entra or Google through Apple Business Manager, don’t assume the sign-in redirect behaves identically on a beta OS. Test a full federated sign-in on a wiped device, including the case where the IdP session is already live in Safari and the case where it isn’t. Federation breakage tends to look like a hang, not an error, which is worse.

What’s on the calendar

Next up is the next developer seed. If Apple follows its own pattern, there’s at least one more beta before a release candidate, and history says late-cycle behavioral fixes for exactly the token-renewal and Keychain-sync flows above are more likely than any new symbol. Re-run the three diffs on the next build—the header diff, the entitlement dump, and the apple/device-management log—before you re-run your behavioral suite. If the diffs stay clean and your flows stay green across the next seed and the RC, you can ship your fleet to GA without holding your breath.

The mistake isn’t trusting that Beta 6 changed nothing. It’s trusting a changelog to have told you. Diff the SDK yourself, then go test the things that break silently. That’s the whole job.