Skip to main content
Device integrity verification ensures that app credentials are enrolled from a legitimate, unmodified version of your app running on a real device. This applies to in-app verification methods. When enabled, the Authsignal Mobile SDK generates a platform-specific attestation during credential enrollment which is verified server-side by Authsignal.
  • iOS: Uses Apple’s App Attest service to generate an attestation bound to the device.
  • Android: Uses Google’s Play Integrity API to generate an integrity token.
Device integrity requires the following minimum SDK versions: iOS 2.4.0, Android 3.5.0, React Native 2.8.0.

​
Portal setup

Enable device integrity verification for your tenant in the Authsignal Portal.

​
Configuration

​
Failure mode
Controls how the server handles attestation results during credential enrollment.
  • Block - Enrollment is rejected if attestation fails or is not provided. When validating the challenge on your backend, the state will be BLOCK - your backend should handle this by denying access or preventing the user from proceeding.
  • Review required - Enrollment is allowed but the credential is flagged for review if attestation fails. When validating the challenge on your backend, the state will be REVIEW_REQUIRED - your backend should handle this appropriately, for example by restricting access to certain features or flagging the user for manual review.
​
Allow development environment
boolean
When enabled, accepts attestations from development builds. This should be enabled during development and testing, and disabled in production.
  • iOS: Accepts attestations from apps signed with a development provisioning profile (App Attest sandbox environment).
  • Android: Not applicable - Play Integrity requires distribution via the Google Play Store (including internal testing tracks). For local development builds not distributed via Play, set deviceIntegrity to false in your SDK calls.

​
Platform-specific configuration

​
Team ID
string
required
Your Apple Developer Team ID. Found in the Apple Developer Portal under Membership details.
​
Bundle IDs
string[]
required
The bundle identifiers of apps which are permitted to enroll credentials. Must match the bundle ID of your app as configured in Xcode.

​
SDK integration

To enable device integrity verification, pass deviceIntegrity: true when adding a credential. The token parameter is a short-lived token obtained by tracking an action from your backend. On the client side, call addCredential with deviceIntegrity: true: 
await authsignal.inapp.addCredential(token: "eyJhbGciOiJ...", deviceIntegrity: true)
The SDK handles all platform-specific attestation generation internally. No additional configuration is required in the mobile app. On your backend, you can validate the challenge to check the outcome of the attestation. For more details on the addCredential method, refer to the SDK documentation for in-app verification or push verification.

​
Handling client errors

If attestation fails (e.g. unsupported device, emulator, or network issue), addCredential will return an error.
You can safely ignore this error on the client side - the action will remain in a non-CHALLENGE_SUCCEEDED state, and your backend will handle it when calling validate challenge.

​
Server-side validation

Authsignal verifies the attestation server-side during credential enrollment. However, it is up to your backend to decide what to do with the result. After a user completes app verification, call validate challenge from your backend using the enrollment token. The response includes a state field that reflects the outcome of the attestation. Your backend should use this state to make business logic decisions - for example, provisioning services, issuing vouchers, or granting access to sensitive features. 
const response = await authsignal.validateChallenge({
  action: "addCredential",
  token: "eyJhbGciOiJIUzI....",
});

switch (response.state) {
  case "CHALLENGE_SUCCEEDED":
    // Device integrity check passed
    // Safe to provision services, issue vouchers, grant access, etc.
    break;

  case "BLOCK":
    // Attestation failed and enforcement mode is set to Block
    // Do not provision - the request may not be from a legitimate device
    break;

  case "REVIEW_REQUIRED":
    // Attestation failed but enforcement mode allows enrollment
    // The credential was enrolled but you may want to flag for manual review
    // or restrict access to certain features until reviewed
    break;

  default:
    // Handle unexpected states
    break;
}

​
Next steps