Built for Continuity: What Happens if Approov Goes Down?

What happens if Approov goes down? It's one of the most common questions we get, and we understand the concern when you're considering adding a service in your request path.

Many levels of internet infrastructure would need to fail before the Approov service would go down. But in that unlikely scenario, Approov uses multiple layers of redundancy, automatic failover, and business-continuity controls to ensure that apps protected by Approov will continue to work as intended.

Approov is designed to provide strong mobile app and API security without becoming a single point of failure. We do this in three different ways:

1. Your backend is unaffected. Approov tokens are standard JWTs that your backend verifies locally with a shared secret. It never calls Approov, so an Approov outage cannot stop your backend from validating the tokens it receives.
2. Your app keeps getting tokens. If the primary service can't be reached, the Approov SDK automatically fails over to an independent service in a different cloud, on a different domain, with no app update or configuration change.
3. If both were unavailable, you stay in control. The SDK reports a specific status the app can act on, and your backend's continuity policy — not Approov — decides what happens next.

We test failure scenarios several times each year to verify that they work as intended. This article explores in detail the different layers of protection we have in the case of a failure.

Continuity at a glance

Your backend never depends on Approov being up

An Approov token is a standard JWT signed with a symmetric secret allocated to your account. Your backend verifies it locally, using the same JWT libraries it already uses for authentication. There is no callback, no introspection endpoint, and no real-time dependency on the Approov cloud.

The consequence: Approov is not in the path of your API requests. Even during a total Approov cloud outage, every token already in circulation continues to validate exactly as normal for its lifetime. The only thing an outage could affect is the issuing of new tokens — which is what the remaining layers protect.

See Approov backend integration for the verification details.

A resilient primary service

The primary Approov service runs in AWS, with multiple frontend servers distributed globally across Availability Zones.

It scales automatically as demand changes, so traffic spikes are absorbed rather than queued. The multi-server, multi-zone deployment means an individual server failure, or a problem isolated to a single Availability Zone, does not take the service down.

Once an Approov token has been obtained, the SDK caches it, so subsequent API calls need no communication with the Approov cloud. That cache covers a brief interruption, so it can smooth over blips in a user network.

Automatic failover to an independent cloud

If the SDK cannot communicate with the primary service, or the service continually returns errors, it automatically attempts to contact the Approov failover service.

The failover service is deliberately isolated from the primary:

• It runs in Google Cloud, not AWS, providing isolation from large-scale AWS failures.
• It is reached on a different domain name using a different top-level domain (TLD), so a DNS or registry problem affecting one does not affect the other.

The failover service checks the health of the primary minute by minute and enables itself automatically when a failure is detected. No app update, configuration change, or manual customer action is required.

The failover service provides a subset of the primary service's full analysis capability, but it issues valid, correctly signed Approov tokens — so your backend needs no changes and behaves identically. Attestation continues; the deeper analysis resumes when the primary service does.

Approov's architecture documentation covers this multi-cloud design in more detail.

Intelligent handling inside the mobile app

Approov tells the app why a token was or was not obtained, so the app can respond appropriately instead of treating every failure the same way.

Every direct token fetch returns a status with a documented recommended handling. (Android constants are shown below)

Two distinctions matter here.

A connectivity problem is not a service problem. NO_NETWORK, POOR_NETWORK and MITM_DETECTED mean the app should hold the request and let the user retry — the SDK has already retried internally, and pushing the request through achieves nothing. NO_APPROOV_SERVICE is different: it means no token is coming, so the documented handling is to proceed without one and let the backend decide.

A failed attestation is not an error status. If a device fails attestation, the SDK still returns SUCCESS with a token — one that isn't signed with the correct secret. The app learns nothing it could use to work around the check; the backend rejects the token. This is why enforcement always belongs at the backend, and why an attacker can't read the SDK's status codes to probe your defences.

In the very unlikely event of complete service unavailability, the app recognizes NO_APPROOV_SERVICE and continues the API request without attaching a token. The request reaches your backend, where your business-continuity policy remains in control.

The Approov documentation covers fetch status handling and provides recommended code for each status.

What would happen in an exceptional failure?

The continuity flow works like this:

1. The SDK contacts the resilient primary Approov service in AWS.
2. If necessary, it automatically attempts the independent Google Cloud failover service.
3. If neither can respond, the SDK returns NO_APPROOV_SERVICE.
4. The app allows the API request to continue without an Approov token.
5. Your backend's controlled emergency policy — if you have activated one — maintains essential access until service is restored.

Throughout all of this, tokens already issued continue to validate, because your backend verifies them locally.

A complete loss of token issuance would require several independent layers of infrastructure and failover protection to fail at once. Even then, the integration can be designed so that Approov never becomes a single point of failure for your mobile service.

Resilience that is regularly tested

Continuity controls are only worth having if they work when needed.

Approov exercises failure scenarios several times a year to test our responsiveness and evaluate impact if AWS and Google Cloud were to be unavailable. We have multiple recovery processes in place and alerting mechanisms to ensure that the Approov service remains reliable for our customers.  

Approov customers can complement this work by testing how your app handles each fetch status, whether your backend continuity control actually works end to end, and whether your monitoring, escalation and restoration procedures do what you expect. If you'd like to exercise the NO_APPROOV_SERVICE path in a staging environment, contact us and we'll help you set it up.

Approov provides a health check endpoint, available via approov monitoring -getHealthCheckURL, that returns a HealthState of initializing, passed or failed. It reports the health of the primary service only. So if you see failed, it does not follow that token issuance has stopped — the failover service may already have taken over. During an incident, watch your own attestation success rate and API traffic for the real answer, and poll the health check no more than once a minute.

See the Approov service monitoring documentation for the endpoint details, usage metrics, and account alerting options. You can always reach our team at support@approov.io.

Protection and availability, by design

Approov's approach combines:

• Multi-Availability-Zone resilience in AWS.
• Automatic failover to Google Cloud on an independent domain and TLD.
• Offline, cryptographic token verification at your backend.
• Token caching in the SDK.
• Precise, actionable SDK status reporting.
• Customer-controlled backend continuity.
• Regular failure testing and health monitoring.

The result is mobile app security built for real operational requirements: strict app and API protection during normal operation, and a controlled continuity path for even the most unlikely failure.

Frequently asked questions

Is Approov a single point of failure?

No. Approov combines multi-Availability Zone primary infrastructure in AWS, automatic cross-cloud failover to Google Cloud, status-aware SDK behavior in the app, and customer-controlled backend continuity options. Your backend also verifies tokens locally, so it has no runtime dependency on the Approov cloud.

Does failover require a configuration change?

No. If the primary service cannot be reached, or continually returns errors, the SDK automatically attempts the independent failover service. The failover service monitors the primary minute by minute and enables itself without manual intervention.

What happens if neither Approov service is available?

The SDK returns NO_APPROOV_SERVICE. The documented handling is for the app to send the API request without a token, so your backend's continuity policy decides whether the request should proceed.

Should backends always accept requests without an Approov token?

No. A missing token indicates a spoofed request and should be rejected under normal operation. Tokenless requests should only ever be accepted through an authorized, time-limited emergency process. Otherwise, an attacker could bypass protection simply by omitting the token.

Does the backend need to contact Approov for every API request?

No. Approov tokens are standard JWTs verified cryptographically with your account's shared secret, so token validation never requires a call to the Approov cloud.

What does it mean if the health check endpoint reports "failed"?

It means the primary service has a fault in one or more components. It does not mean tokens have stopped being issued. The health check covers the primary service only, and the failover service is likely already serving tokens.