Hi, I make Akari, a Chromium-based browser for macOS (Developer ID, notarized). On 2026-09-23 I requested the Web Browser Public Key Credential entitlement (com.apple.developer.web-browser.public-key-credential) so people can use the passkeys saved in iCloud Keychain. Request ID A9LNZMTCS4. On 2026-10-12, Developer Support (case 102988458082) emailed to say the entitlement had been issued. It still hasn't shown up: Certificates, Identifiers & Profiles > io.0arch.akari > Capability Requests still shows "Web Browser Public Key Credential Requests" as Submitted, with no way to enable it. The App Store Connect API lists only In-App Purchase as a capability for the App ID. Developer ID provisioning profiles generated on 10-12 and 10-15 don't include the entitlement. I replied on the case with screenshots on 10-12 and again on 10-15, and submitted a follow-up on 10-18, but I haven't heard back. Phone support currently says it's unavailable. Two questions: Is there anything else I need to do for an approved entitlement to be applied to the App ID? My membership is an individual account. Is an individual account eligible for this entitlement, or does it need an organization account? Team ID: G9KB4QTS57 Bundle ID: io.0arch.akari Thanks, Joseph

~5% of our users when downloading the iOS application from the Apple Store for the first time are unable to enrol a Passkey and experience an error saying the application is not associated with [DOMAIN]. The error message thrown by the iOS credentials API is "The operation couldn't be completed. Application with identifier [APPID] is not associated with domain [DOMAIN]" We have raised this via the developer support portal with case id: 102315543678 Question: Why does the AASA file fail to fetch on app install and is there anything that can be done to force the app to fetch the file? Can this bug be looked at urgently as it is impacting security critical functionality? Other Debugging Observations We have confirmed that our AASA file is correctly formatted and hosted on the Apple CDN. Under normal circumstances the association is created on install and Passkey enrolment works as intended. We have observed that when customers uninstall/reinstall the app this often, but not always, resolves the issue. We also know this issue can resolve itself overtime without any intervention. We have ruled out network (e.g VPN) issues and have reproduced the issue across a number of different network configurations. We have ruled out the Keychain provider and have reproduced it across a variety of different providers and combinations of. We observed this across multiple versions of the iOS operating system and iPhone hardware including the latest hardware and iOS version.

I’m looking for technical clarification on how the standalone Apple Passwords app protects credentials on iOS 26 and iOS 27, specifically when a device is locked after its first unlock since boot (AFU). Apple’s Platform Security documentation identifies Safari website passwords as using the When Unlocked Keychain protection class: https://support.apple.com/guide/security/secb0694df1a/web However, it is unclear whether this documentation also describes the implementation of the newer standalone Passwords app. Keychain accessibility classes Does the Passwords app continue to store website and application passwords using kSecAttrAccessibleWhenUnlocked or an equivalent, more restrictive class? Do passkeys, TOTP verification-code secrets, and any intermediate keys necessary to decrypt stored credentials receive the same protection? Locked-AFU protection When an iPhone has been unlocked once since boot and subsequently locked again, are the cryptographic keys required to retrieve saved website passwords inaccessible until the user unlocks the device again? Specifically, does the When Unlocked class enforce this restriction cryptographically, or could a process with elevated operating-system privileges retrieve the protected material while the device remains locked? Full-filesystem and Keychain extraction Assuming an authorized forensic examiner obtains a full-filesystem extraction or privileged operating-system execution on a device that remains locked in AFU, but does not know the device passcode: Does filesystem access alone expose usable plaintext credentials stored in Apple Passwords? Are additional cryptographic keys or authentication steps required? What security guarantees remain for When Unlocked Keychain items under these conditions? I’m not requesting information about undisclosed vulnerabilities or specific forensic-tool exploits. I’m interested in the documented behavior and security boundaries of Apple’s Keychain architecture. Independent verification Are there any published technical assessments, research papers, forensic experiments, or Apple security documents that verify the actual accessibility classes used by the Passwords app on iOS 26/27? For context, a 2026 independent security assessment of Proton Pass identified its use of kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly for sensitive Keychain material as a defense-in-depth weakness and recommended kSecAttrAccessibleWhenUnlockedThisDeviceOnly. I’m trying to understand whether Apple’s native Passwords app provides a stronger cryptographic boundary against locked-AFU extraction, rather than merely a different user-interface authentication requirement. Any clarification from an Apple engineer or references to authoritative technical documentation would be greatly appreciated.

Our app signs users up through ASWebAuthenticationSession (not ephemeral). The sign-up page is a normal HTML form that posts to our server. When sign-up succeeds, the server redirects to our custom-scheme redirect_uri, which closes the session, as expected. When the user types a password and submits, iOS shows the "Save Password?" modal inside the session. From there, iOS 26 and iOS 27 behave differently: iOS 26.5: iOS waits. The form isn't sent until the user answers the modal. Then the request goes out, the redirect closes the session, and the password has been saved. iOS 27.0 and 27.2 beta 2: iOS doesn't wait. The form is sent right away, the redirect closes the session in under a second, and the modal disappears with it. The user never gets to tap Save. Things we checked: Same server, same page, same device, same app build. Only the iOS version changes the result. prefersEphemeralWebBrowserSession is off. Safari itself never waited on neither versions. The waiting only happened inside ASWebAuthenticationSession. Saving passwords still works on the device otherwise, and every test used a new account and password. Questions: Is the iOS 27 behaviour intended? If so, is there any supported way to let the user answer the sheet before the redirect closes the session? If it's a bug, is it tracked somewhere? The only fix we've found is to show an extra page after sign-up and only redirect from there, which adds a step for every user. We'd rather not ship that if the iOS 26 behaviour is coming back.

Before promoting passkey registration, I would like to check whether the user device has platform authenticator (or passkey platform authenticator). While trying to search such feature in the docs, I cannot find it anywhere. Is this intended? If there is no such api, how can we know whether the user can register passkey?

I am creating passkeys using client side javascript and trying to see how the friendly name of the passkey is created. When the passkey gets created the publicKey the name for the relying party is ignored and iOS and MacOS retrieves the page of the relying party. It seems the Open Graph site_name meta tag is used for the friendly name. And the apple-touch-icon is the icon on iOS (but not on MacOS) in the passwords app and it needs to be over 180px. Is there anywhere this is documented and confirmed as once the passkey is enrolled updating the site_name or apple-touch-icon the image never gets updated.

Is it possible to get to the SymmetricKeys provided by a passkey as per the WebAuthn prf extension by just having to authenticate the user locally? The use case would be signing into an app and decrypting user data encrypted with those keys while the device is offline.

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!

When using passkeys stored in iCloud Keychain (Passwords app) via Passkey Autofill in browsers other than Safari, the userVerification parameter is ignored and user verification (UV) is not performed. As a result, relying party servers that require userVerification = required fail validation because the UV flag is not set, causing passkey authentication to fail. This issue occurs when the following setting is disabled: Settings → Face ID & Passcode → Use Face ID For → Password AutoFill The issue is reproducible only with the following combination: Non-Safari browsers (e.g. Chrome) Passkeys stored in iCloud Keychain (Passwords app) Passkey Autofill The issue does not occur in the following cases: Safari with passkeys stored in any credential manager Non-Safari browsers using credential managers other than iCloud Keychain Steps to Reproduce: Go to Settings → General → Autofill & Passwords, and enable the Passwords app under “Autofill From”. Go to Settings → Face ID & Passcode → Use Face ID For, and disable “Password AutoFill”. Open Chrome and navigate to https://webauthn.io Enter a username and tap “Register” to create a passkey using the Passwords app (iCloud Keychain). On webauthn.io, go to Advanced Settings → Authentication Settings, and set “User Verification” to “Required”. Reload the page, tap the input field, and perform Passkey Autofill. User Verification is not triggered, and “Authentication failed” is displayed on webauthn.io. === This issue has already been reported via Feedback Assistant as FB21756948. I am posting here to confirm whether this behavior is working as intended or represents a bug, and to make other developers aware of the current behavior.

Steps to reproduce: register a passkey on device A authenticate on device A, using the prf extension and a constant salt. Note the prf output go to device B. wait for iCloud sync authenticate on device B using the prf extension and the same constant salt. Note the prf output The prf outputs are different. Note: Repeat the authentication on each device. The prf output is identical for a given device, which seems to point towards the inclusion of a device specific component in the prf derivation. In my scenario, I need the prf output to be the same regardless of the device since I use it as the recovery key for my app data. Could you confirm that this is the expected behavior or not? Thanks,

Hello Apple Developer Team, I am developing a general-purpose web browser for iOS using WKWebView. Current status: • The app is distributed through TestFlight (Internal Testing). • The app is registered in App Store Connect. • The browser supports standard web browsing with multiple tabs and arbitrary websites. My goal is to support WebAuthn passkey authentication for websites such as Google, GitHub, Microsoft, and other websites that support passkeys. While reviewing Apple's documentation, I found: "Passkey use in web browsers" "Authenticating people by using passkeys in browser apps" These documents mention that browser apps on iOS can support passkeys using: ASAuthorizationWebBrowserPublicKeyCredentialManager and the entitlement: com.apple.developer.web-browser.public-key-credential However, I could only find a request form titled: "Request the macOS Web Browser Public Key Credential Entitlement" which specifically asks: "Is your app a web browser on macOS?" My application is an iOS web browser, not a macOS browser. In addition, I previously requested the Default Web Browser entitlement, but my request was declined. My questions are: Is there a separate application process for requesting the Web Browser Public Key Credential entitlement for an iOS browser? Is approval of the Default Web Browser entitlement required before an iOS browser can use WebAuthn passkeys? Can an iOS browser request only the Web Browser Public Key Credential entitlement without becoming the system default browser? Is there any official documentation describing the entitlement request process for iOS browser apps? I know that third-party browsers such as Aloha Browser appear to support system Passkeys on iOS, so I would like to understand the correct implementation and entitlement process for an iOS browser. Thank you very much for your guidance.

Hi everyone, was hoping I could get some help. Recently I've been trying to implement passkeys on my app and one of the use cases was that we don't allow users to create duplicated passkeys from the same device they are on. I passed the excludedCredentials into the registration and tried creating a passkey twice, on the 2nd time I am unable to create a passkey but instead of triggering the .matchedExcludedCredentials from the ASAuthorizationError like I hoped, I get a WKErrorDomain code 8 with the localized description At least one credential matches an entry of the excludeCredentials list in the platform attached authenticator. Been debugging but I still couldn't find the answer as to why the AS error is not triggered.

We are a financial institution and are considering to introduce passkeys as login mechanism for our web banking application. We see this as an important step to curb phishing. But we saw that there is a way to share passkeys with others - https://support.apple.com/guide/iphone/share-passwords-iphe6b2b7043/ios - and are wondering if this can be disabled by us for our passkeys. Social engineering attacks are very sophisticated nowadays and we are afraid attackers would be able to manipulate customers to share their passkeys with them. thanks for your help stefan

Hello, I'm implementing the wallet extension but I found a problem in the passEntries function. This following part is giving nil ando I don't know why if let entry = PKIssuerProvisioningExtensionPaymentPassEntry( identifier: element.id, title: element.cardType ?? "Card", art: self.testImage()!, addRequestConfiguration: config! ) { entries.append(entry) } I debug and all the arguments have information but it doesn't create the entry

iCloud KeySyc is a privacy-focused feature that securely syncs a user’s personalized keyboard learning across all Apple devices through iCloud. Today, when users upgrade to a new iPhone or begin using a new iPad or Mac, the keyboard often loses much of the personalization it has developed over time. Users must re-teach autocorrect, rebuild custom vocabulary, and wait for the keyboard to relearn their typing habits. iCloud KeySync would allow users to move seamlessly between devices while keeping the keyboard experience familiar from day one. Problem Statement Apple’s keyboard becomes more useful over time as it learns: Frequently used words and phrases Personal slang and abbreviations Emoji preferences Autocorrect adjustments Writing patterns and typing habits When users switch devices, much of this personalization is lost or takes time to rebuild. This creates friction during device upgrades and reduces the feeling of continuity within the Apple ecosystem. Proposed Solution iCloud KeySync securely synchronizes keyboard personalization data across Apple devices. The feature would: Learn and store personalized keyboard behavior on-device. Encrypt and sync personalization data through iCloud. Restore keyboard preferences automatically when signing into a new device. Keep keyboard learning consistent across iPhone, iPad, and Mac. Key Features Personalized Vocabulary Sync Synchronizes user-added words, nicknames, slang, and frequently used phrases. Emoji Preference Sync Maintains commonly used emoji patterns across devices. Autocorrect Learning Sync Preserves learned corrections and accepted custom spellings. Typing Behavior Continuity Allows devices to share keyboard learning so users receive familiar suggestions regardless of which Apple device they use. User Controls Enable or disable iCloud KeySync. Reset keyboard learning at any time. View privacy information and storage usage. Privacy and Security Privacy should remain the foundation of the feature. All keyboard learning occurs on-device. Personalization data is end-to-end encrypted. Raw message content is never uploaded. Users retain full control over synchronization settings. Security protections match the standards used by iCloud Keychain. User Benefits New devices feel familiar immediately. Less time correcting autocorrect mistakes. Faster onboarding after device upgrades. Consistent typing experience across the Apple ecosystem. Improved customer satisfaction and retention. Example User Scenario A user upgrades from an older iPhone to a new iPhone. After signing into iCloud and restoring their device, the keyboard immediately recognizes their commonly used phrases, preferred emoji, custom words, and learned typing patterns. The new device feels personalized from the first message typed, without requiring weeks of retraining Business Value Improves the upgrade experience. Strengthens ecosystem continuity. Reinforces Apple’s privacy-first approach to AI and machine learning. Creates a subtle but meaningful quality-of-life improvement for millions of users. Switch phones. Keep your vibe.

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?

I’m trying to build and run a brand-new Xcode project created from the Audio Unit Extension App template for local macOS development on a brand-new Mac, and I’m blocked by a signing/keychain issue. Environment: macOS on a brand-new Mac Xcode 26.4.1 Build version 17E202 Personal Team Targeting My Mac Project type: Audio Unit Extension App Main symptom: During build/run, Xcode repeatedly shows this prompt: codesign wants to access key "Apple Development: Sam Magnant (...)" in your keychain It asks for the login keychain password. Important detail My current Mac password successfully unlocks the login keychain manually in Keychain Access every time. So the issue seems specific to Xcode / codesign using the Apple Development private key, not a general inability to unlock the keychain. What I’ve already tried Reset the default keychain Logged out and back in after reset Changed my Mac account password to a new password Confirmed the login keychain unlocks manually with the current Mac password Deleted and recreated local Apple Development certificate/private key where possible Removed and re-added my Apple account in Xcode Checked the private key in Keychain Access Confirmed the private key exists under the Apple Development certificate Confirmed Allow all applications to access this item is already checked on the private key Removed App Groups and other extra capabilities to simplify the project Tried security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k '' ~/Library/Keychains/login.keychain-db Tried switching the project to simpler signing configurations, then switched back to standard Apple Development signing What’s confusing Xcode appears to know about an Apple Development certificate/private key Keychain Access shows the identity under login > My Certificates The login keychain unlocks fine manually But codesign still prompts, and the machine reports 0 valid identities found Questions What would cause Keychain Access to show the Apple Development identity, but security find-identity -v -p codesigning to report 0 valid identities found? Is this most likely a broken certificate/private key pairing, trust chain issue, or something specific to Personal Team signing? Is there a recommended way to fully repair the local Apple Development signing identity on the current macOS user account without creating a new macOS user? Are there known issues with the Audio Unit Extension App template and Personal Team local development on macOS?

Hello, I am using the prf extension for passkeys that is available since ios 18 and macos15. I am using a fixed, hardcoded prf input when creating or geting the credentials. After creating a passkey, i try to get the credentials and retrieve the prf output, which works great, but i am getting different prf outputs for the same credential and same prf input used in the following scenarios: Logging in directly (platform authenticator) on my macbook/iphone/ipad i get "prf output X" consistently for the 3 devices When i use my iphone/ipad to scan the qr code on my macbook (cross-platform authenticator) i get "prf output Y" consistently with both my ipad and iphone. Is this intended? Is there a way to get deterministic prf output for both platform and cross-platform auth attachements while using the same credential and prf input?