Mobile Threat

Mobile Threat is a separate, native surface of Identity Intelligence. Where the web snapshot fingerprints a browser session, Mobile Threat evaluates a native mobile app: it fuses hardware-backed attestation, app-clone detection and man-in-the-middle interception intelligence into the same risk snapshot, exposed through the mobile* fields. It is delivered by a dedicated native mobile SDK — the web SDK does not produce these signals.

Mobile Threat is an evidence provider. Every evaluation returns a classification, a confidence and a set of findings — it never blocks on its own. You feed the verdict into your own logic and decide what to do.

⚠️

A native mobile SDK is required. The attestation and interception signals come from device-level APIs that only a native app can reach. An attestation that is declared but has no verifiable token is never treated as trusted — it returns an explicit not-verifiable result, not a pass.

How it works

Embed the native SDK

Integrate the Lunixi mobile SDK into your Android and/or iOS app. It collects a hardware attestation and the device-integrity telemetry that the server evaluation needs.

Register the app (once)

Declare your app IDs, minimum SDK/app versions and attestation requirements in the mobile app registry. Registration is what turns a raw attestation into a trust decision — an unregistered app is reported, not trusted.

Evaluate a session (server)

From your backend, call POST /identity/mobile-threat/evaluate with the SDK-provided attestation and your business context. You get back a snapshot with the mobile* classification fields.

Bind a sensitive action (optional)

For a high-assurance action — a transfer, a beneficiary add — issue a one-time trusted action token after a passing evaluation and consume it at the action endpoint, proving the action ran under the evaluated risk posture.

Attestation coverage

Platform	Mechanism	Status
Android	Play Integrity — hardware-backed attestation of a genuine, unmodified app and device	Live
iOS	App Attest — an Apple-attested app key	Requires per-app enrollment (register the App Attest key)
iOS	DeviceCheck — Apple device-level bit store	Requires DeviceCheck credentials in the environment

Play Integrity works as soon as the Android app is registered. The iOS mechanisms are configurable: App Attest needs the app's attestation key enrolled through app-attest/register-key, and DeviceCheck needs its Apple credentials configured server-side. Until then, iOS attestation reports as not-verifiable rather than failing closed on your behalf.

App Attest enrollment (iOS)

App Attest binds a per-app cryptographic key that Apple vouches for. Enroll it in two steps from your backend:

POST /identity/mobile-threat/app-attest/bootstrap-challenge — obtain a one-time challenge to hand to the SDK.
POST /identity/mobile-threat/app-attest/register-key — register the SDK-generated, Apple-attested key against your app.

Once a key is registered, subsequent evaluate calls for that app can verify App Attest assertions.

Clone & interception intelligence

Beyond attestation, the evaluation reports how the app is being run and how its traffic is being carried:

Domain	What it detects
Clone intelligence	The app running under dual-space / app-cloning tools or inside an Android work profile — multiple instances of one app on one device
MITM intelligence	Traffic carried through a manual proxy or VPN transport, or resolved through a custom private DNS — the transport shapes that precede interception

Request

POST /identity/mobile-threat/evaluate — server-side, Authorization: Bearer <secret key>.

curl https://api-gateway.lunixi.com/api/v1/identity/mobile-threat/evaluate \
  -H "Authorization: Bearer at_live_5f3e2b1a..." \
  -H "Content-Type: application/json" \
  -d '{
    "subjectType": "customer",
    "subjectId": "cus_8f2a9c",
    "productContext": "money_transfer",
    "action": {
      "actionType": "transfer_submit",
      "beneficiaryHash": "bnf_abc",
      "challenge": "nonce_123"
    },
    "issueTrustedActionToken": true,
    "device": { "...": "attestation + integrity telemetry from the native SDK" }
  }'

POST /identity/mobile-threat/simulate runs the same evaluation pipeline against a hypothetical input so you can rehearse how a given attestation state maps to a classification — without recording a live decision. Stream lifecycle context with POST /identity/mobile-threat/timeline-event.

Snapshot

The evaluation returns the same gateway envelope ({ success, message, code, data, meta }); data is the risk snapshot, carrying the mobile fields on top of the shared identity fields.

{
  "identityRiskLevel": "medium",
  "riskScore": 58,
  "confidenceScore": 0.88,
 
  "mobilePlatform": "android",
  "mobileAppId": "io.example.app",
  "mobileAppTrusted": true,
  "mobileIntegrityClassification": "genuine",
  "mobileIntegrityConfidence": 0.93,
  "mobilePolicyStatus": "pass",
 
  "reasonCodes": ["private_dns_detected"],
  "findings": [
    { "code": "private_dns_detected", "severity": "medium", "scoreDelta": 14, "source": "mobile" }
  ]
}

Signals

Field	What it tells you
`mobileIntegrityClassification`	The integrity verdict for the app/device (e.g. genuine vs tampered vs not-verifiable)
`mobileIntegrityConfidence`	Confidence in that classification
`mobilePolicyStatus`	Whether the evaluation satisfies the policy declared for this app in the registry
`mobileAppTrusted`	Whether the app resolves to a registered, trusted app entry
`mobilePlatform`	`android` or `ios`
`mobileAppId` / `mobileAppVersion`	The declared app identifier and version

The canonical verdict is identityRiskLevel (clean | low | medium | high | critical) — Identity's own evidence-grade assessment, not a payment or fraud action. See The Risk Snapshot.

Trusted action tokens

Bind a passing evaluation to one sensitive action so the action cannot run under a different, unverified posture:

Issue

After a passing evaluate, call POST /identity/mobile-threat/trusted-action-token to mint a one-time token scoped to the action.

Consume

At your action endpoint, call POST /identity/mobile-threat/trusted-action-token/consume with the token. It is single-use — consuming it proves the action ran under the evaluated risk posture.

Reading decisions

Every evaluation is recorded, merchant-scoped and queryable:

GET /identity/mobile-threat/decisions — recent mobile evaluations.
GET /identity/mobile-threat/decisions/:id — one evaluation in full.
GET /identity/mobile-threat/trace/:traceId/decisions — the mobile decisions tied to a given trace.

Mobile app registry

The registry is what makes attestation meaningful — it declares which apps you trust and to what standard:

GET /identity/mobile-apps — list your registered apps.
POST /identity/mobile-apps — declare an app ID, minimum SDK/app version and attestation requirement.
PATCH /identity/mobile-apps/:id — update an app entry.

An app that is not registered can still be evaluated, but it resolves to mobileAppTrusted: false — the attestation is reported, not trusted.

Notes

Native SDK required. These signals exist only through the native mobile SDK — do not expect them on a web session.
Declared ≠ verified. A missing or invalid attestation token yields a not-verifiable result, never an implicit pass.
Configurable per platform. Android Play Integrity is live on registration; iOS App Attest requires key enrollment and DeviceCheck requires environment credentials.

Next steps

The Risk Snapshot — the full field reference
POS / Terminal Threat — the in-store B2B surface
Server-side API & Queries — reading and querying analyses
Identity Assertions & JWKS — non-repudiable verification of a decision

Bot & Automation POS / Terminal Threat