App attestation FAQ
For security leads, mobile leads and backend engineers evaluating or running TrustPin app attestation. Each answer is short and links to the page with the detail.
Cost and licence
What does attestation cost?
Nothing extra. Attestation is included in every TrustPin plan, the Free plan too, at no extra charge, because you run the verifier yourself. Your verifiers’ policy fetches don’t count as sessions. Your own costs are the infrastructure the verifier runs on and, if you use it, Google’s Play Integrity quota. See App attestation.
Does TrustPin host the verifier for us?
No. The verifier runs only in your infrastructure, as the container image trustpincloud/attest-verifier, 1.0.0 or later. There is no TrustPin-hosted verifier today. See Deploying the verifier.
How many verifier instances may we run?
Any number, in your own infrastructure, while your TrustPin plan is active. A service provider may run the verifier for a client, for that client’s TrustPin projects. See Image, versions and licence.
What TrustPin sees, and privacy
Does TrustPin see our attestation traffic?
No. TrustPin runs no attestation service. Evidence, tokens and your API’s requests go only between your apps, your verifier and your API. TrustPin’s only runtime role is serving your signed policy from its CDN. From your verifiers’ policy fetches it records request counts, verifier versions and platforms, the CDN location, and counts of distinct verifier IP addresses, which you see in the console. None of it is device or end-user data. See What TrustPin sees.
What does TrustPin store?
Identifiers only: Team IDs, bundle IDs, package names, signing-certificate digests and the Google Cloud project number, in your policy. Never your verifier’s signing keys, challenge secrets or Google credentials: those are environment variables of your verifier. See Who runs what.
What does the SDK send, and to whom?
Evidence and tokens go only to your verifier, nothing to TrustPin. Only a SHA-256 of a bound value leaves the device. The SDKs collect no device or user identifier, and the iOS frameworks ship privacy manifests. With a Google Cloud project number configured, an Android app talks to Google Play services, which belongs in your Play Console Data safety form. See the Privacy section of each SDK page, for example Android.
Can we use the token’s sub as a device ID?
No. sub names the device key, which changes on reinstall, at each new attestation and after a reset. It is not a device, installation or user identifier. See Token format.
What it protects
What does attestation prove?
That a request comes from an unmodified build of your app on a genuine device that meets your policy. See App attestation.
Is it runtime protection, or root and jailbreak detection?
No. It doesn’t detect hooking, debugging, tampering, root or jailbreak while the app runs, and it doesn’t stop a genuine user from misusing your API. See What attestation is not.
Does it replace certificate pinning?
No, it builds on it. Pinning tells the app it talks to your real server; attestation tells your API it talks to your real app. The SDK pins its own calls to your verifier, so the verifier’s domain must be registered in your TrustPin project. See What it adds to certificate pinning.
Does attestation block requests by itself?
No. The SDKs never block a request: without a token, it goes out without the header. Your API or gateway decides what an unattested request may do, per endpoint. See Requests without the header.
Architecture and availability
Why do we run the verifier ourselves?
So that everything in the request path stays in your infrastructure: your apps attest against your verifier, and your API verifies tokens with your verifier’s keys, without depending on TrustPin at runtime. Your keys, secrets and Google credentials never leave your environment, and you place the verifier next to your API. See Who runs what.
What happens if TrustPin’s CDN is down?
Running verifiers keep their last good policy and keep serving. A verifier that restarts during the outage starts from its policy cache (TRUSTPIN_POLICY_CACHE_DIR), if it has one. See Policy updates.
Can we host the policy file ourselves?
Yes. Set TRUSTPIN_ATTEST_CONFIGURATION_URL to your copy of the signed policy file; the TrustPin CDNs stay the fallback. Keep the copy in step with every publish. Air-gapped deployments set it and block the CDNs. See Policy loading.
What happens if Apple or Google is down?
New attestations fail until the service is back (when the verifier can’t reach Google, it answers 502 upstream_unavailable), and the SDKs back off and retry. Existing tokens stay valid until they expire, and renewals don’t call Apple or Google. See Incident response.
What happens if our verifier is down?
Apps keep their tokens until they expire, then send requests without the header, and your API’s rule for unattested requests applies. Your API keeps verifying tokens with its cached keys. See Incident response.
Does our API call the verifier on every request?
No. Your API verifies each token locally, with the verifier’s public keys (JWKS), which it caches. It calls the verifier only to fetch those keys, and to check an assertion on a sensitive operation. See How your API and the verifier work together.
Does the verifier need a database?
Not for one instance. Several instances of one environment share a Redis or Postgres store for replay protection. See Choose the store and Scaling.
Environments, modes and rollout
How do staging and production work?
One TrustPin project serves every environment and shares one policy. Each environment runs its own verifier, with its own URL, issuer, secrets and domain registration, and tokens from one environment are refused by the other’s API. See Staging and production.
How do we test on simulators and emulators?
With debug tokens. They work only on a verifier given TRUSTPIN_DEBUG_TOKEN_HASHES, normally staging, and only while the policy has Allow debug tokens on. Production verifiers have no hashes, and production APIs refuse tokens with tp.env debug. See Staging: debug tokens.
What is the difference between monitor and enforce?
In Monitor, a device that fails a policy check still gets a token, marked tp.result fail, so you can measure what enforcing would refuse. In Enforce, it gets none. Separately, your API decides per endpoint whether to refuse requests without a valid token. Forged evidence and apps the policy doesn’t list get no token in either mode. See Modes and Rolling out.
How quickly does a policy change reach devices?
Verifiers load a new version within 5 minutes. Removing an app, switching to enforce and similar changes reach each device at its next token renewal, within one Access token lifetime. Tightened device checks apply at each device’s next attestation, within one Key certificate lifetime (30 days by default). See When changes take effect.
Which access token lifetime should we choose?
The default, 1 hour, suits most apps. A shorter lifetime means more frequent renewals, which are cheap and don’t call Apple or Google, but a faster cut-off after a policy change. See Mode and tokens.
Can we roll back?
Yes. The fastest rollback is your API’s per-endpoint rule. The policy’s mode can go back to monitor with a new publish; verifiers never accept an older version, so a rollback is a new version with the old settings. See Rolling back.
Apps and devices
Which platforms and SDK versions support attestation?
Swift 7.1.0 (TrustPinAttestKit), and Kotlin, Flutter and React Native 7.1.1, on iOS 15, macOS 13, tvOS 15, watchOS 9, visionOS 2 and Android API 25 or later. Flutter covers iOS, macOS and Android; React Native covers iOS and Android. See Platforms.
Which verifier version do the SDKs need?
Every 7.1.x SDK needs verifier 1.0.0 or later. Within 1.x, upgrading the verifier never needs an app release. With an older verifier, the SDK reports verifierIncompatible and sends no header until the verifier is upgraded. See Image, versions and licence and Upgrading.
What happens on devices that can’t attest?
The SDK reports it, for example unsupportedDevice on a Mac without App Attest, and sends requests without the header. Your API decides how to treat them. See Devices without App Attest.
What happens when a device is offline, or the verifier is slow?
The SDK never holds a request for long: if no token is ready within a short, bounded time, the request goes out without the header. A token it already has stays usable until it expires, and the SDK renews it before then. See the “Send the header” section of each SDK page, for example iOS and macOS.
How often do devices contact Apple or Google?
Once per device key: on first use, when the key certificate expires (30 days by default), after a reinstall or a reset, and after a refusal, after a wait. Renewals in between don’t contact them. On Android under Either, an app configured with a project number spends one Play Integrity request on every attestation. See The flow.
Do Apple or Google limit attestation?
Yes. Google’s Play Integrity API has a daily quota per Cloud project (10,000 requests a day by default, which you can ask Google to raise); see Google’s Play Integrity documentation . Apple asks large apps to ramp App Attest up gradually; see Apple’s guidance and Rolling out on iOS. In monitor mode, devices that fail the policy attest again about once per access-token lifetime, which also costs quota. See Measure.
Do we need Play Integrity?
No. With Evidence set to Key Attestation only, or Either without a project number in the app, Android devices attest with Key Attestation alone and need no Google Cloud setup. See Android apps.
Do attestation keys survive a backup or a new phone?
No. Keys and key certificates are never backed up. A restored or reinstalled app attests a new key. See Reset and backups.
Can projects signed with FIDO use attestation?
Not in this release. See Before you start.
Next steps
- App attestation overview, and its six-stage setup path
- Troubleshooting attestation