Limitations

Rampart raises the cost of attacking your app. It does not make attacks impossible. Be honest with yourself and your security reviewers about the following:

1. A device the attacker fully controls can lie. With root or a jailbreak plus an instrumentation framework, any on-device check — Rampart's or anyone else's — can be hooked, patched or stubbed. Native code paths, redundancy and obfuscation make this slower, not impossible.
2. Root and jailbreak hiding is an arms race. Well-maintained hiding setups can make file, package and property checks look clean.
3. Property-based signals are easy to spoof on a rooted device: emulator, bootloader, debugging and developer-mode flags.
4. Capture protection is not absolute. It stops screenshots and recordings by the OS and by other apps, not a second phone pointed at the screen, and it can be disabled on rooted devices.
5. Some signals have false positives. VPNs, developer options and work profiles are common among legitimate users. Rampart marks these low confidence by default.
6. iOS exposes less. Several Android signals (ADB, developer mode, user CA certificates, overlays, third-party accessibility services) have no public iOS equivalent; Rampart says "guidance only" instead of guessing.

What you can rely onCopy Anchor Link

Results that Google or Apple sign and that your server verifies with a fresh nonce: Play Integrity verdicts, App Attest attestations and assertions, Android key attestation, and StoreKit AppTransaction. Make decisions about payments, health data and account recovery on those, and use Rampart's on-device signals as supporting risk input. See Server verification.