Exposure check Contact
Exposure check Contact

Application security feature

Mobile app attestation

Otukan gives your backend fresh, request-bound evidence of app authenticity and device environment, verified on your server alongside platform attestation.

Discuss your app protection requirementsCheck your app's exposure
  • Android
  • iOS
  • Flutter
  • React Native
Scripted and forged calls is met at the server verification boundary before it reaches the appScripted and forged callsServer verificationYour app

  • Proof of the caller

    Your backend learns whether a request comes from your genuine app, in an environment you accept, before it trusts the data inside.

  • Fresh and single-use

    Evidence is bound to a server challenge or to the request itself, so a captured result is rejected when it is replayed.

  • Checked on your server

    Your backend or gateway verifies every result and applies your policy. The app never reports its own verdict.

Attacks your backend can refuse

Select an attack to see how Otukan detects it, how your backend responds and what your team receives.

Scripted API clients

  1. Detect

    Without your app's request-bound evidence, a scripted call fails verification on your server.

  2. Respond

    Your backend rejects or steps up the call according to the endpoint's policy.

  3. Report

    The failed verification is recorded with endpoint, reason and time.

Repackaged app copies

  1. Detect

    App authenticity evidence and Otukan's integrity checks show the app differs from the release you signed.

  2. Respond

    Sensitive endpoints refuse requests from the modified copy.

  3. Report

    Your team sees the failed integrity result, the app build and the platform.

Emulator farms

  1. Detect

    Environment evidence from the platform and Otukan's runtime checks identifies virtual devices.

  2. Respond

    Your policy allows, limits or refuses sessions from emulated environments, per endpoint.

  3. Report

    Emulator signals are recorded so volume and trends are visible.

Replayed evidence

  1. Detect

    Single-use challenges, request hashes and, on iOS, increasing assertion counters expose reuse.

  2. Respond

    The server rejects stale or repeated evidence before the request is processed.

  3. Report

    Replay attempts are logged as a signal in their own right.

Hooked or debugged app

  1. Detect

    Runtime checks inside the app detect hooking frameworks and debuggers and include the result in the evidence.

  2. Respond

    Your backend refuses high-risk actions from a client under instrumentation.

  3. Report

    The signal carries the check, app build, platform and OS version.

What Otukan attestation proves

Otukan keeps three questions apart, so your backend trusts exactly what the evidence proves.

  • App authenticity

    The calling app matches the release you signed and distributed, not a script, an emulator farm or a repackaged copy.

  • Device environment

    Runtime checks report rooted or jailbroken devices, hooking, debugging and emulators, next to the platform's own verdicts.

  • Request freshness

    Evidence is produced for this challenge or request, within a short validity window, and accepted once.

  • Session binding

    The app instance's key is tied to the session, so a token moved to another device fails verification.

How it works

  1. Issue a challenge

    Your server issues a one-time challenge, or the app binds evidence to a hash of the request.

  2. Collect evidence

    The protected app gathers platform attestation and Otukan's runtime evidence for that challenge.

  3. Verify on the server

    Your backend checks signatures, app identity, freshness and verdicts before trusting the request.

  4. Apply your policy

    Each endpoint allows, steps up or refuses according to the result and your rules.

  5. Bind the session

    The verified app instance is tied to the session, so later calls stay attributable.

Free for app publishers

Check your app's exposure

A passive review of your published app by an Otukan engineer. No files, no access to your systems. Findings go by email to the verified publisher.

You finish the request on the next page.

Your backend can verify a mobile request with evidence the app attaches to it, and Otukan supplies that evidence. It proves three things: the calling app is your genuine, unmodified release; it runs on a device in a state you accept; and the evidence was made for this request, not replayed. Otukan combines platform attestation, Play Integrity on Android and App Attest on iOS, with its own runtime checks, and your server verifies every result. Attestation proves something about the software and device, not the user, so it strengthens your authentication rather than replacing it.

This control is part of mobile API protection.

Evidence meaning

A single “attested” flag hides three different claims. Otukan reports them separately, so your backend knows exactly what it is relying on.

App authenticity

The request comes from your app as you signed and released it. On Android, Play Integrity’s app integrity verdict reports whether Google Play recognises the app. On iOS, App Attest keys are tied to your team and app identifier, and each assertion is signed by a key held in the Secure Enclave. Otukan’s integrity checks add evidence that the code and resources match your release. Together, this separates your app from scripts, emulator farms and repackaged copies.

Device environment

Play Integrity returns device integrity labels, and Android Keystore key attestation can report verified boot state and bootloader lock status. iOS offers no comparable device-integrity verdict. Otukan fills that gap with runtime checks on both platforms for jailbreak detection, root detection, hooking, debugging and emulators, reported with each sensitive request.

User identity

Attestation does not identify the user, and Otukan keeps it that way by design. Login, multi-factor authentication and session management answer who is using the app. Attestation tells you how much to trust the client carrying those credentials.

Verification

Freshness

Otukan binds evidence to a specific request. With Play Integrity standard requests, the app passes a hash of the request; with classic requests, your server issues a nonce. With App Attest, your server issues a one-time challenge for key attestation, and later assertions sign a hash of the request data.

Replay defence

Otukan’s verification contract builds replay defence in:

  • challenges are issued on the server, single-use and short-lived;
  • evidence is bound to the request body, so it cannot move to another call;
  • App Attest assertion counters are stored per key, and a value that does not increase is rejected;
  • rejected evidence is logged, because repeated replays are a signal in themselves.

For deployments with several backend instances, verification uses a shared store of used challenges and a reliable time source, so the same evidence is accepted once across the whole service.

Server-side checks

Every result is verified on your server. For Play Integrity, the token is decoded server-side and the package name, request hash or nonce, timestamp and verdicts are checked. For App Attest, the certificate chain is validated to Apple’s App Attest root, along with the app identifier and challenge, and the public key is stored for later assertions. Otukan’s own evidence is verified in the same step. The app never reports its own verdict. How attestation fits a device-bound session is covered on device binding.

Dependencies

Otukan builds on the platform mechanisms and adds its own evidence. Each source has its own conditions, and Otukan labels them clearly.

MechanismPlatformWhat it attestsDepends on
Play IntegrityAndroidApp recognised by Google Play, device integrity labelsGoogle Play services, request quotas
Keystore key attestationAndroidKey properties, verified boot stateHardware-backed Keystore, varies by manufacturer
App AttestiOS 14 and laterGenuine app instance, key in the Secure EnclaveSupported hardware and Apple’s servers; not available in the simulator
DeviceCheckiOSTwo bits of per-device state set by your serverApple’s servers
Otukan runtime evidenceAndroid and iOS, scoped per platformApp integrity, hooking, debugging, emulator and root or jailbreak signals, bound to the requestThe protected app

How Otukan complements platform attestation

Platform verdicts are signed by Google or Apple, which makes them hard to forge. Otukan adds what they do not report: runtime signals from inside your app, and one verification contract across Android and iOS. Every result states which evidence came from the platform and which from Otukan, so your backend weighs each on its own terms.

Otukan also handles devices where platform attestation is unavailable, such as Android devices without Google Play services. Your policy decides whether those requests proceed on Otukan’s evidence alone, step up or stop.

Protection fits your existing build and release pipeline, and your signing keys stay with you.

Sector requirements are covered on mobile banking app security, healthcare mobile app security and crypto wallet app security. The difference between app and device attestation is covered on app attestation vs device attestation, and verification steps are covered on how to verify mobile app attestation.

Common questions

  • Is app attestation the same as user authentication?

    No. Attestation tells your backend which software and environment produced a request; authentication tells it which person is behind it. You need both. Otukan attestation lets your backend reject scripts and modified clients, so your login, multi-factor and session controls work with a client you can trust.

  • We already use Play Integrity and App Attest. What does Otukan add?

    Those services are a strong foundation, signed by Google or Apple and verified on your server. Otukan builds on them with runtime evidence they do not report, such as hooking, debugging and emulator signals, and gives both platforms one verification contract. Each result stays labelled by source, so your backend weighs platform verdicts and Otukan evidence on their own terms.

  • What happens when a genuine user cannot attest?

    It happens: platform services have outages and quotas, old app versions lack the check, and some devices cannot attest. You decide per endpoint whether to allow and record, step up or refuse. Start in observe mode, measure the rate on real traffic, and keep login open during a platform outage.

  • How often should the app attest?

    A common pattern is a full attestation at install or login, then lighter per-request evidence for sensitive calls such as payments and account changes. That keeps evidence fresh where it matters and stays within platform quotas. Otukan lets you set the balance per endpoint and per platform.

On the mobile engineering team?

How protection fits your build, signing and release, platform by platform.

Related

Let your backend trust the caller

Tell us the platforms and app framework, where your API verification runs and which calls you need to protect. We do not ask for binaries, signing keys, API secrets or production credentials.

Discuss your app protection requirementsGet a free app exposure check
Or request a technical demo