Why there's always code — and what really matters is where it runs, how secure it is, and how much control you have.

The Need for Attestation

Generative AI is enabling synthetic identities at scale and in parallel, agentic AI is making it easy to create perfect looking API requests with tools and scripts. It's therefore no surprise that API abuse is spiking.

In response, mobile businesses are increasingly evaluating approaches to continuous app and device attestation — in order to prevent manipulated or fake apps from being weaponized to attack backend APIs.

There are different approaches to this but basically you need a way to cryptographically distinguish real apps from impostors — even when the traffic looks perfect. You must check that the app is:

• Genuine

• Untampered

• Running in a secure environment

To do this, you need eyes on the app and device to get contextual signals in real time - inspecting traffic at the backend is not sufficient. The “code” we are talking about gathers and uses these mobile signals.

Busting the “No-Code” Attestation Myth

One way some vendors describe their mobile attestation solutions is as “no‑code,” usually meaning that developers don't have to write code themselves to deploy the solution. Of course, how easy the solution is to deploy and manage is a key consideration (Approov, for example makes deployment fast and easy and we will even do it for you if you want)

But in practice, this no-code framing is misleading — and can hide important architectural tradeoffs, which impacts security.

There needs to be code somewhere in order to carry out the required checks: The real question isn’t whether code exists — it’s where that code runs, who controls it, and how resilient it is to tampering.

We can break down three ways runtime attestation code is deployed:

• in the underlying mobile OS
• in an SDK integrated with the mobile app
• by instrumenting the app code before deployment.

Let's look at each one in turn.

OS-Based Attestation (Apple App Attest, Play Integrity API)

In this case, the code to do the checks is in Android or iOS (or HarmonyOS). OS-based attestation can provide strong, hardware-backed signals, but there are shortcomings of iOS and Android security and of course it’s not “no-code,” and it’s not cross-platform or flexible across platforms.

SDK-Based Attestation

SDK-based attestation uses a lightweight software development kit integrated into the app to handle runtime integrity checks and generate attestation signals. These SDKs typically interact with a backend service that evaluates the device and app integrity, and may issue a signed token or response that the backend can validate.

In general, SDK-based attestation aims to balance control, visibility, and flexibility — without requiring constant modification of application code.

Instrumented “No-Code” Attestation (e.g Appdome)

As we mentioned, some companies such as Appdome offer an approach which is marketed as no-code. These solutions effectively wrap apps post-build with security protections (e.g., anti-tampering, root detection, jailbreak detection, API encryption etc.) . Developers upload their compiled app (APK or IPA), and then the binary is modified to inject security routines without changing source code.

It's not “no-code”, since your code is modified: The app is modified externally via binary instrumentation, and security controls are hard-coded into the app at build time. The app binary is in fact deeply altered, requiring regression testing and making troubleshooting tricky. Also, any policy update generally requires re-wrapping and re-signing the app.

Rather than "Low-Code" or "No-Code" - What Really Needs to be Considered?

In reality, “no-code attestation” is a misnomer, and a distraction. When you evaluate an attestation solution, here is a better checklist:

• Requires minimal integration effort
• Protects attestation logic from tampering
• Has the most extensive checks
• Supports over-the-air updates as threats evolve
• Keeps security logic outside the app
• Supports cross-platform development and performs consistently across platforms
• Lets you update policies and secrets instantly, without redeploying your app
• Provides transparent runtime signals to backend systems in a way that's standards-based and easy to integrate

Where Approov Fits

Approov takes an SDK-based approach to mobile attestation, but with a clear architectural goal: minimize what lives inside the app, and maximize what can be verified and controlled externally.

The Approov SDK performs runtime checks on the app and device, but the trust decisions, policies, and enforcement logic live in the Approov cloud and your backend — not hardcoded into the client. This allows teams to adapt to new threats, rotate secrets, and enforce access controls without rebuilding or re-instrumenting the app.

Approov is minimal‑code, tamper‑resistant, and operationally flexible — designed for teams that need strong app‑to‑API trust without locking security logic into the binary.

Are you ready to move beyond marketing myths and evaluate what really works for securing mobile APIs? Let’s talk through your use case and show you how Approov can help implement tamper-resistant, runtime-verified attestation — across platforms, with minimal overhead.