Vouch
Security

Security overview

Prove a request came from a genuine build of your app on a genuine device, and decide what to do when it did not.

Module B answers one question about every request: is this a real device running the app we published? It answers it in three steps, and each one is designed to be switched on without breaking anyone.

Attest

The SDK asks Apple or Google to vouch for the device and the build. Vouch verifies their answer and records a verdict: pass, degraded or fail.

Sign

A successful attestation returns a short-lived run token. The SDK signs every later request with it, so a captured request cannot be replayed or edited.

Decide

Your policies say what a verdict is worth on which endpoints. Until you say otherwise, they only watch.

Start in monitor mode

This is the part to understand before anything else. A new app is in monitor, where every request is evaluated exactly as enforcement would evaluate it, the decision is recorded, and nothing is ever refused.

That gives you a real answer to the only question that matters: if I switched this on today, who would I lock out? Some of the devices a rule would block are not attackers. They are customers on a handset that cannot fully attest. Vouch counts those separately so you can see them before you make a decision you cannot see the consequences of.

See Monitor mode.

A degraded device is not a bad device

degraded means Vouch could not fully check the device, not that the check failed. No Play Integrity credentials configured, Google unreachable, a de-Googled handset, an older operating system. These are real users, often paying ones.

The verifier never fails a degraded device. Your policy decides what it is worth, which is why the distinction exists at all.

What is never stored

The platform token from Apple or Google is read once and discarded. It is never stored, never written to a log, and never returned to you. Run tokens, nonces and signatures are treated the same way.

Where to go next

On this page