Should mobile teams keep API keys inside the app or deliver them at runtime?

Why runtime delivery beats hard-coding for mobile API keys

For mobile apps, the key question is whether the secret must exist on the client at all. If it does, runtime delivery is usually the safer pattern because the backend can make a fresh trust decision before issuing it. That keeps static keys out of distributed app copies, where they are easier to extract, replay, and reuse.

The practical difference is trust location. An embedded key becomes part of the app package and can be recovered from the binary, memory, logs, or instrumented devices. A runtime-issued key or token can be bound to app attestation, device posture, or a short-lived session, which limits how useful a stolen value remains after extraction.

When the app only needs to call one backend, the better design is often to avoid a reusable API key in the client entirely and use a backend-mediated exchange instead. That may mean short-lived credentials, scoped tokens, or a token broker that issues access only after the app proves it is a legitimate build running in an acceptable environment.

What changes when the secret is delivered at runtime

Runtime delivery does not make a mobile client “secret-free”, but it changes the blast radius. The backend becomes the control point for who receives a credential, for how long, and for what scope. That lets teams revoke, rotate, or narrow access without waiting for a new app release, which is important when a leaked value would otherwise live on in every installed copy.

It also changes the failure mode. With embedded keys, the main risk is mass compromise through reverse engineering and cloning. With runtime delivery, the main risk shifts to the strength of the server-side gating logic, attestation, and session binding. If those checks are weak, an attacker can still automate retrieval, but the compromise is no longer baked into the shipped binary.

For mobile, this is especially relevant when the API key is really acting as a bearer credential. If the backend cannot distinguish a legitimate app instance from a copied script or patched binary, then a runtime-delivered secret loses much of its value. In that case, the real control is not where the key lives, but whether the server can verify the caller before issuing or accepting it.

What mobile teams should use instead of a static client key

The strongest pattern is to keep long-lived secrets off the device and use a trust exchange that can fail closed. A mobile app can authenticate the user or app instance, obtain a short-lived access token, and then call the API through a backend that enforces scope, expiry, and revocation. That is more resilient than giving every client the same durable key.

Where attestation is available, it should be part of the decision, not an afterthought. Runtime delivery is most useful when the backend can answer a concrete question: is this request coming from an expected app build, on an acceptable device, in an acceptable state? If the answer cannot be verified, the backend should prefer denial over issuing a reusable secret.

When teams must ship some client-side credentialing, they should treat it as a constrained dependency, not a general-purpose secret. Scope it narrowly, keep it short-lived, monitor for abuse, and assume it will be recovered eventually. The goal is not to make extraction impossible, but to make extracted material less reusable and less valuable.

Risk and Threat Considerations

Hard-coded API keys in mobile apps are exposed to binary extraction, traffic interception, memory inspection, repackaging, and clone abuse. Once copied, a key can be replayed from many devices and integrated into automated abuse without needing further access to the original app.

Failure mechanism: The attacker extracts a bearer-style secret from a distributed client, then reuses it outside the intended device, build, or session context. If the backend cannot verify the request origin or bind the credential to an attested app instance, the secret remains valid after theft.

Impact: The result can be quota theft, API abuse, data exposure, service fraud, or a broader compromise path if the key also unlocks privileged backend functions. Long-lived embedded secrets are especially damaging because revocation requires coordinated cleanup across all shipped clients and any downstream integrations that copied the value.

Practitioner Guidance

What to prioritise: Remove any client-side secret that is not strictly required for the app to function. If a secret must exist on the client, make it short-lived, narrowly scoped, and issued only after a server-side trust check.

What to verify: Confirm that the backend can distinguish an attested app instance from a repackaged or scripted client before issuing credentials. Also verify that you can revoke the credential centrally without waiting for a mobile release cycle.

Common mistake: Treating “runtime delivery” as sufficient on its own. If the runtime secret is issued to any caller that knows the endpoint, the app has only moved the static secret from the binary to the network.

Practitioner takeaway: The real decision is whether the backend can make an enforceable trust decision before any credential is issued; if it cannot, the safest API key is the one the mobile app never receives.

Related resources from NHI Mgmt Group

• Guide: API Key Management Guide
• What do teams get wrong when they keep API keys and other secrets inside development tools or local environments?
• Why do leaked API keys in mobile apps create account takeover risk even when attackers only find them in app code?
• How should security teams decide when API keys are too risky to keep?
• Why do mobile security teams need runtime verification for app controls?