Hi, is it somehow possible to access a key that was generated by the DCAppAttestService generateKey() function? I need to be 100% sure that no actor from within or outside of my app can access the generated key with the DeviceCheck Framework. It would also be helpful to get some official resources to the topic. Thank you in advance, Mike

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 have an Autofill Passkey Provider working for Safari and Chrome via WebAuthn protocol. Unfortunately, Chrome will not offer my extension as a logon credential provider unless I add the credential to the ASCredentialIdentityStore. I wonder what is the best way to access the ASCredentialIdentityStore from an AutoFill extension? I understand I cannot access it directly from the extension context, so what is the best way to trigger my container app to run, based on a new WebAuthn registration? The best I can think of so far is for the www site to provide an App Link to launch my container app as part of the registration ceremony. Safari will offer my extension even without adding it to the ASCredentialIdentityStore, so I guess I should file a request with Chrome to work this way too, given difficulty of syncing ASCredentialIdentityStore with WebAuthn registration.

Hello, I'm an application developer related to Apple system extensions. I developed an endpoint security system extension that can run normally before the 14.x system. However, after I upgraded to 15.x, I found that when I uninstalled and reinstalled my system extension, although the system extension was installed successfully, a system warning box would pop up when I clicked enable in the Settings, indicating a failure. I conducted the following test. I reinstalled a brand-new MAC 15.x system. When I installed my applications, the system extensions could be installed successfully and enabled normally. However, when I uninstalled and reinstalled, my system extension couldn't be enabled properly and a system warning popped up as well. I tried disabling SIP and enabling System Extension Developers, but it still didn't work. When the system warning box pops up, I can see some error log information through the console application, including an error related to Failed to authorize right 'com.apple.system-extensions.admin' by client '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] for authorization created by '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] (3,0) (-60005) (engine 179) as shown in the screenshot. The same problem, mentioned in Cannot approve some extensions in MacOS Sequoia , but there is no solution

I'm working on integrating Passkey functionality into my iOS app (targeting iOS 16.0+), and I'm facing an issue where the system dialog still shows the "Save to another device" option during Passkey registration. I want to hide this option to force users to create Passkeys only on the current device. 1. My Current Registration Implementation Here’s the code I’m using to create a Passkey registration request. I’ve tried to use ASAuthorizationPlatformPublicKeyCredentialProvider (which is supposed to target platform authenticators like Face ID/Touch ID), but the "Save to another device" option still appears: `// Initialize provider for platform authenticators let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(relyingPartyIdentifier: domain) // Create registration request let registrationRequest = provider.createCredentialRegistrationRequest( challenge: challenge, name: username, userID: userId ) // Optional configurations (tried these but no effect on "another device" option) registrationRequest.displayName = "Test Device" registrationRequest.userVerificationPreference = .required registrationRequest.attestationPreference = .none // Set up authorization controller let authController = ASAuthorizationController(authorizationRequests: [registrationRequest]) let delegate = PasskeyRegistrationDelegate(completion: completion) authController.delegate = delegate // Trigger the registration flow authController.performRequests(options: .preferImmediatelyAvailableCredentials)` 2. Observation from Authentication Flow (Working as Expected) During the Passkey authentication flow (not registration), I can successfully hide the "Use another device" option by specifying allowedCredentials in the ASAuthorizationPlatformPublicKeyCredentialAssertionRequest. Here’s a simplified example of that working code: let assertionRequest = provider.createCredentialAssertionRequest(challenge: challenge) assertionRequest.allowedCredentials = allowedCredentials After adding allowedCredentials, the system dialog no longer shows cross-device options—this is exactly the behavior I want for registration. 3. My Questions Is there a similar parameter to allowedCredentials (from authentication) that I can use during registration to hide the "Save to another device" option? Did I miss any configuration in the registration request (e.g., authenticatorAttachment or other properties) that forces the flow to use only the current device’s platform authenticator? Are there any system-level constraints or WebAuthn standards I’m overlooking that cause the "Save to another device" option to persist during registration? Any insights or code examples would be greatly appreciated!

We are using Apple's PSSO to federate device login to out own IdP. We have developed our own extension app and deployed it using MDM. Things works fine but there are 2 issues that we are trying to get to the root cause - On some devices after restarting we see an error message on the logic screen saying "The registration for this device is invalid and must be repaired" And other error message is "SmartCard configuration is invalid for this account" For the 1st we have figured out that this happens when the registration doesn't happen fully and the key is not tied to the user so when the disk needs to be decrypted at the FileVault screen the issue is raised. For the "SmartCard configuration is invalid for this account" issue also one aspect is invalid registration but there has been other instances as well where the devices were registered completely but then also the the above error was raised. We verified the registration being completed by checking if the SmartCard is visible in the System Report containing the key. Has anyone seen the above issues and any possible resolution around it?

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.

Hey everyone, I'm hitting a really frustrating issue with App Attest. My app was working perfectly with DCAppAttestService on October 12th, but starting October 13th it started failing with DCError Code 2 "Failed to fetch App UUID" at DCAppAttestController.m:153. The weird part is I didn't change any code - same implementation, same device, same everything. I've tried switching between development and production entitlement modes, re-registered my device in the Developer Portal, created fresh provisioning profiles with App Attest capability, and verified that my App ID has App Attest enabled. DCAppAttestService.isSupported returns true, so the device supports it. Has anyone else run into this? This is blocking my production launch and I'm not sure if it's something on my end or an Apple infrastructure issue.

I recently turned on the enhanced security options for my macOS app in Xcode 26.0.1 by adding the Enhanced Security capability in the Signing and Capabilities tab. Then, Xcode adds the following key-value sets (with some other key-values) to my app's entitlements file. <key>com.apple.security.hardened-process.enhanced-security-version</key> <integer>1</integer> <key>com.apple.security.hardened-process.platform-restrictions</key> <integer>2</integer> These values appear following the documentation about the enhanced security feature (Enabling enhanced security for your app) and the app works without any issues. However, when I submitted a new version to the Mac App Store, my submission was rejected, and I received the following message from the App Review team via the App Store Connect. Guideline 2.4.5(i) - Performance Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issue before resubmitting a new binary. Entitlement "com.apple.security.hardened-process.enhanced-security-version" value must be boolean and true. Entitlement "com.apple.security.hardened-process.platform-restrictions" value must be boolean and true. When I changed those values directly in the entitlements file based on this message, the app appears to still work. However, these settings are against the description in the documentation I mentioned above and against the settings Xcode inserted after changing the GUI setting view. So, my question is, which settings are actually correct to enable the Enhanced Security and the Additional Runtime Platform Restrictions?

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?

Hello, Thanks for the new video on Memory Integrity Enforcement! Is the presented app's sample code available (so that we can play with it and find & fix the bug on our own, using Soft Mode)? Thanks in advance!

Hello everyone, We recently transferred our iOS app from one Apple Developer account to another, and after the transfer, we encountered a serious issue where all previously stored Keychain data and the local database became inaccessible. As a result, all users are automatically logged out and lose access to their locally stored data (such as chat history) once they update to the new version signed with the new Team ID. We understand that Keychain items are tied to the App ID prefix (Team ID), which changes during an app transfer. However, we’re looking for possible workarounds or best practices to avoid user data loss. Questions: Is there any reliable method to maintain or migrate access to old Keychain data after an app transfer? Would reverting the app back to the original developer account and releasing an update from there (to persist or migrate data) before transferring it again be a viable solution? Has anyone faced a similar issue and found a practical way to handle data persistence during an app transfer? Any guidance, technical suggestions, or shared experiences would be highly appreciated. This issue is causing major impact for our users, so we’re hoping to find a safe and supported approach. Thank you, Mohammed Hassan

I'm trying to setup device attestation. I believe I have everything setup correctly but the final step of signature validation never succeeds. I've added validation on the client side for debugging and it doesn't validate using CryptoKit. After the assertion is created, I try to validate it: assertion = try await DCAppAttestService.shared.generateAssertion(keyId, clientDataHash: clientDataHash) await validateAssertionLocallyForDebugging(keyId: keyId, assertionObject: assertion, clientDataHash: clientDataHash) In the validateAssertionLocallyForDebugging method, I extract all the data from the CBOR assertionObject and then setup the parameters to validate the signature, using the key that was created from the original attestation flow, but it fails every time. I'm getting the public key from the server using a temporary debugging API. let publicKeyData = Data(base64Encoded: publicKeyB64)! let p256PublicKey = try P256.Signing.PublicKey(derRepresentation: publicKeyData) let ecdsaSignature = try P256.Signing.ECDSASignature(derRepresentation: signature) let digestToVerify = SHA256.hash(data: authenticatorData + clientDataHash) print(" - Recreated Digest to Verify: \(Data(digestToVerify).hexDescription)") if p256PublicKey.isValidSignature(ecdsaSignature, for: digestToVerify) { print("[DEBUG] SUCCESS: Local signature validation passed!") } else { print("[DEBUG] FAILED: Local signature validation failed.") } I have checked my .entitlements file and it is set to development. I have checked the keyId and verified the public key. I have verified the public key X,Y, the RP ID Hash, COSE data, and pretty much anything else I could think of. I've also tried using Gemini and Claude to debug this and that just sends me in circles of trying hashed, unhashed, and double hashed clientData. I'm doing this from Xcode on an M3 macbook air to an iPhone 16 Pro Max. Do you have any ideas on why the signature is not validating with everything else appears to be working? Thanks

I've come across strange behavior with the userID property on the returned credential from a passkey attestation. When performing a cross-device passkey assertion between iOS and Android by scanning the generated QR code on my iPhone with an Android device the returned credential object contains an empty userID. This does not happen when performing an on device or cross-device assertion using two iPhones. Is this expected behavior, or is there something I'm missing here? I couldn't find any more information on this in the documentation. iOS Version: 26.0.1, Android Version: 13

I have a project with a single app target that serves two environments, and two schemes, one for each env, using xcconfig files for defining environment-specific stuff. I'm trying to figure this out for months, so I've tried multiple approaches throughout this period: Have a single domain in "Associated domains" in Xcode, defined as webcredentials:X where X gets replaced using a value from xcconfig. Have two domain entries in "Associated domains" webcredentials:PROD_DOMAIN and webcredentials:STAGING_DOMAIN. Have a different order of domains Results are very interesting: whatever I do, whatever approach I take, password autofill works on staging, but doesn't work on production. I'm aware that we need to test production on Test Flight and AppStore builds. That's how we're testing it, and it's not working. Tested on multiple devices, on multiple networks (wifi + mobile data), in multiple countries.. you name it. The server side team has checked their implementation a dozen times; it's all configured properly, in the exact same way across environments (except bundle ID, ofc). We tried a couple websites for validating the apple-app-site-association file, and while all of those are focused on testing universal links, they all reported that the file is configured properly. Still, password autofill doesn't work. I prefer not to share my app's domains publicly here. Ideally I would contact Apple Developer Support directly, but they now require a test project for that, and since 'a test project' is not applicable to my issue, I'm posting here instead.

The header documentation for the (deprecated) LAContext.evaluatedPolicyDomainState property contains the following: @warning Please note that the value returned by this property can change exceptionally between major OS versions even if the state of biometry has not changed. I noticed that the documentation for the new LAContext.domainState property does not contain a similar warning. I also found this related thread from 2016/17. Is the domainState property not susceptible to changes between major OS versions? Or is this generally not an issue anymore?

Hi Apple team, For our iPhone app (App Store build), a small subset of devices report DCAppAttestService.isSupported == false, preventing App Attest from being enabled. Approx. impact: 0.23% (352/153,791) iOS observed: Broadly 15.x–18.7 (also saw a few anomalous entries ios/26.0, likely client logging noise) Device models: Multiple generations (iPhone8–iPhone17); a few iPad7 entries present although the app targets iPhone Questions In iPhone main app context, what conditions can make isSupported return false on iOS 14+? Are there known device/iOS cases where temporary false can occur (SEP/TrustChain related)? Any recommended remediation (e.g., DFU restore)? Could you share logging guidance (Console.app subsystem/keywords) to investigate such cases? What fallback policy do you recommend when isSupported == false (e.g., SE-backed signature + DeviceCheck + risk rules), and any limitations? We can provide sysdiagnose/Console logs and more case details upon request. Thank you, —

Hello, I’m storing some values in the Keychain with the attribute ‘ksecattraccessibleafterfirstunlockthisdeviceonly’ (https://developer.apple.com/documentation/security/ksecattraccessibleafterfirstunlockthisdeviceonly). When I migrate user data between iPhones via iCloud, this behaves as expected and the keys are not preserved. However, when I migrate using a direct connection between two devices, the keys are preserved, which seems to contradict the attribute’s intent. Is this a known behavior, and if so, is there a workaround?

For testing purposes we have code that calls SecTrustEvaluateAsyncWithError() with a trust object containing a hardcoded leaf certificate and the corresponding intermediate certificate required to form a valid chain. Because the leaf certificate has since expired we pass a date in the past via SecTrustSetVerifyDate() at wich the certificate was still valid, but trust evaluation fails: Error Domain=NSOSStatusErrorDomain Code=-67825 "“<redacted>” certificate is not standards compliant" UserInfo={NSLocalizedDescription=“<redacted>” certificate is not standards compliant, NSUnderlyingError=0x600000c282a0 {Error Domain=NSOSStatusErrorDomain Code=-67825 "Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;" UserInfo={NSLocalizedDescription=Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;}}} I know that App Transport Security enforces Certificate Transparency by default, but is there a way around that here?

Hello, We received a rejection on one of our IOS applications because we were doing Microsoft MSAL login through the user's browser. The representative recommended that we use Webview to do in-app logins. However when we tried to handle the custom app uri redirection (looking like myapp://auth/), Webview does not seem to send the user back to the application. Does anyone have a fix for this? Thanks!