Skip to content
  • There are no suggestions because the search field is empty.

Approov Offline Security Mode

Approov Offline Security Mode supports local verification scenarios in which a mobile app must authenticate to a remote hardware device that does not have a direct internet connection—for example, IoT equipment, vehicle systems, or medical devices accessed over Bluetooth or another local channel.

After an initial online provisioning step, the app can generate fresh integrity or device measurement proofs while offline. The remote hardware verifies the proof before allowing a protected operation. This helps prevent unauthorized, modified, or otherwise noncompliant app instances from controlling the device, subject to the verification policy and authorization controls implemented by the hardware.

Operational Flow

1. Online provisioning

Before offline use, the app must complete an online Approov attestation and provisioning flow.

  • The app initiates the designated Approov measurement request, using the integration pattern required by the deployed SDK and backend.
  • The Approov SDK performs runtime integrity checks and communicates with the Approov Cloud service.
  • On a successful result, the app receives the standard Approov token result and the measurement configuration required for offline proof generation.
  • The app sends the Approov token to its backend. The backend validates the token before provisioning a measurement token intended for the specific remote hardware device.
  • The backend protects the measurement token for the target hardware—for example, by encrypting it with the hardware’s public key—and returns it to the app.
  • The app stores the measurement configuration and hardware-targeted measurement token in platform-protected local storage. Define explicit expiration, refresh, and invalidation rules.

2. Offline proof and hardware verification

When the app needs to perform a protected local operation without internet connectivity:

  • The hardware and app establish a fresh challenge nonce. Prefer a nonce generated by the hardware, and require it to be cryptographically random, single-use, and time-limited.
  • The app calls getIntegrityMeasurementProof or getDeviceMeasurementProof, as appropriate for its assurance requirements, using the nonce and stored measurement configuration.
  • The app sends the proof, the hardware-targeted measurement token, and any required command authorization data to the remote hardware over the local channel.
  • The hardware decrypts or otherwise validates the measurement token, derives or retrieves the verification material, and validates the proof against the received nonce.
  • The hardware must reject expired tokens, replayed nonces, invalid proofs, and unauthorized requested operations. Comparisons of cryptographic values should use constant-time operations.
  • If validation succeeds, the hardware may authorize the requested operation according to its local policy.

Choosing the Proof Type

Use getIntegrityMeasurementProof when the protected operation requires assurance about the app’s integrity and runtime state. Use getDeviceMeasurementProof only when device-focused assurance is appropriate for the threat model.

Do not describe device measurement as merely a “resilient” replacement for integrity measurement: it can have different security properties and may not detect an app modification that an integrity-oriented policy is intended to catch.

Recovery and Diagnostics

A new online provisioning cycle may be required after an app update, a relevant device or OS state change, a policy change, token expiry, storage loss, or a failed offline proof.

Treat offline-proof failure as a deny condition for the protected function; do not silently downgrade to an unverified local command.

For investigation of unexpected measurement changes, the existing diagnostic guidance can remain, with a small caveat:

When connectivity is restored, set the user property to $error using Approov.setUserProperty("$error") and perform a standard, non-measurement Approov token fetch. Use this diagnostic flow in accordance with your organization’s privacy, telemetry, and support policies.