Thank you for your answer. I would like to ask follow-up questions, if you don't mind. [quote='913004022, DTS Engineer, /thread/853951?answerId=913004022#913004022'] Which isn’t to say that the SE-protected credentials are useless. If you use them to communicate with a server, then the combination of SE protection and App Attest is useful signal. [/quote] Doesn't App Attest only verify that a user is running my genuine app (i.e. an app that has the same App ID as my app has) on a real Apple hardware, but it does not check if iOS itself is "compromised"? The documentation regarding App Attest does not suggest that App Attest can detect when an attacker is running my ("non-compromised") app on a compromised device (i.e. a device where the attacker has control over the kernel). In such scenario, couldn't an attacker simply attach a debugger to my app and generate App Attest tokens which would pass all checks? My understanding is that App Attest only guards against someone running a modified version of my app (i.e. a re-signed app with a different App ID), but it cannot guard against the case when someone runs my genuine app, attaches a debugger to it and uses the debugger to execute arbitrary instructions. Is my understanding correct? Maybe that is why you said App Attest is a useful signal (implying that it cannot be trusted alone)? A related question: Assuming a device with non-modified kernel, does there exist an entitlement or a configuration in Info.plist, which makes iOS reject any attempts at debugging my app, so attaching a debugger to my app would require modifying Info.plist, and thus re-signing my app with a different App ID? I imagine such hypothetical protection would be a bit stronger than PT_DENY_ATTACH.