Topic starter
24/10/2026 8:52 pm
TL;DR: Its mobile app attestation design avoids becoming a single point of failure by using offline backend JWT verification, automatic failover from AWS to Google Cloud, and app-side continuity handling when token issuance is unavailable, according to Approov. The architectural lesson is that enforcement must sit with the backend, not the attestation service.
Editorial analysis by NHI Mgmt Group, based on content published by Approov: “Built for Continuity: What Happens if Approov Goes Down?”.
Key questions
Q: What breaks when mobile attestation depends on a live service call?
A: The control becomes an availability dependency, so a service outage can block token issuance even when the app and backend are healthy.
Q: When should organisations allow tokenless access during an attestation outage?
A: Only when an authorised continuity policy explicitly permits it and the exception is time-limited.
Q: What signs show that an attestation control is failing in practice?
A: Look for repeated NO_APPROOV_SERVICE events, declining token issuance, unexpected dependence on a single cloud or domain, and API traffic that stops even though the backend is otherwise healthy.
Practitioner guidance
- Define a tokenless emergency path Document when API requests may proceed without an attestation token, who approves that state, and when the temporary exception is revoked.
- Verify backend-local JWT enforcement Confirm that the backend validates attestation tokens locally with a shared secret and does not rely on a live callback to approve requests.
- Test failover as an operational control Exercise the primary-to-failover transition in staging and production-like drills, including the independent cloud, different domain, and no-app-change path.
Bottom line: Mobile attestation fails operationally when the security service becomes a live dependency in the request path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →