iGaming app integrity requirements should define which app and device signals a native client presents, how the backend verifies them and what each result may change for a sensitive action. An attestation verdict is useful risk evidence, but it is not proof of the player’s identity, location, eligibility or intent.
For an operator CTO, mobile product owner, application-security lead, fraud lead, release lead or procurement buyer, the decision is where integrity evidence belongs in the player journey without turning one platform service into the authority for account or wagering state. The useful delivery artifact is a versioned integrity policy pack that joins a signal inventory, server verification contract, action-response matrix, exception paths, rollout controls and acceptance tests.
Treat integrity as evidence rather than authority
App integrity evidence should change the confidence attached to a request, not replace authentication, authorization, fraud controls or server-owned transaction rules. Apple describes App Attest as a way for a legitimate app instance to support more confident access decisions for sensitive server resources, while also warning that no single policy eliminates all fraud and that App Attest cannot definitively identify every compromised operating system.
Google similarly presents Play Integrity verdicts for recognized app binaries, licensing and device environments. Its guidance says the API works best beside other anti-abuse signals rather than as the sole mechanism. The architecture consequence is direct: a valid verdict does not authorize a withdrawal, accept a wager or prove who is holding the device. The backend still evaluates the authenticated account, current session, action, resource, market and platform state.
Write those limits into the requirements. Distinguish app authenticity, installation channel, device environment and recent activity from player identity, geolocation, account standing and transaction validity. A control is easier to test when every signal has one stated meaning and an explicit list of decisions it cannot make.
Map sensitive actions before choosing an attestation API
An integrity policy should start with sensitive actions and threats before it starts with Apple or Android methods. Inventory sign-in, authenticator enrollment, recovery, payment-instrument changes, deposits, withdrawals, wager submission, bonus claims, personal-data access, device registration and support-assisted account changes when those journeys exist in the product.
For each action, record the protected asset, likely abuse, required user presence, other available signals, acceptable latency and consequence of a false positive. Then decide whether integrity evidence is needed at enrollment, once per app instance, periodically or immediately before a high-risk command. Requesting a verdict on every screen can add cost and failure modes without improving the decision.
Great Britain’s remote gambling security requirements apply to critical systems that handle authentication information, account balances and entry or exit points to those systems. They also identify endpoint devices, malware protection, secure development, application security, testing and change management among relevant control areas. That is jurisdiction-specific scope, not a rule that mandates one mobile attestation product, but it supports tracing app integrity requirements to the critical journey they protect.
Verify assertions on the server and bind them to the request
Integrity assertions should be verified by the backend and bound to the current request so a captured result cannot be replayed as approval for a different action. The client can collect platform evidence, but it cannot be the final judge of evidence that is meant to expose a modified client.
Apple’s server-validation guidance uses a unique one-time server challenge in the attestation or assertion flow. The server validates the certificate chain and app identity, stores the verified public key for the app instance, checks signed client data and advances the assertion counter. Google requires Play Integrity tokens to be sent to the backend for decryption and verification before the backend decides how to respond.
Define the data contract around a stable action identifier, account and session context, app release, platform, challenge, issue time, expiry, requested action and policy version. Keep raw platform evidence out of ordinary analytics and support views unless a reviewed need requires it. Record the normalized decision and the minimum evidence needed to explain it without turning security telemetry into an uncontrolled device dossier.
Use an action-response matrix instead of one global block
An integrity action-response matrix should define a proportionate result for each combination of action and evidence state. Useful normalized states can include verified, failed, unavailable, unsupported, stale and service-degraded, but the implementation must preserve the distinctions exposed by each platform.
The response may allow a low-risk read, request fresh evidence, require reauthentication, restrict a high-risk action, route a case for review or deny a command when the threat model and applicable policy justify it. Do not silently convert an infrastructure outage into an accusation of fraud. Do not let a permissive fallback make integrity evidence ceremonial either.
OWASP’s mobile resilience standard describes anti-tampering and platform-integrity controls as defense in depth. It also warns that platform-specific checks can exclude legitimate users, create false positives or increase lock-in, and it says resilience must not substitute for secure architecture and server-side validation. A reviewable matrix makes those tradeoffs visible to product, security, fraud, support and compliance owners before code decides them implicitly.
Design unavailable and unsupported states as real journeys
Integrity controls should have explicit journeys for unsupported devices, missing platform services, network failure, throttling, stale keys and backend verification outages. These are expected operating states, not edge cases that can all share a generic error.
Apple exposes whether App Attest is supported and recommends gradual production onboarding. Its preparation guidance separates sandbox and production keys and warns teams to handle dynamic rate limits. Google’s guidance recommends planning how the backend behaves during Play Integrity service disruption or device-key revocation and giving users an actionable message when they can retry or correct a device condition.
Define which actions remain available, which need another verified route and which must wait. Preserve account access to appropriate support and recovery paths without promising that every sensitive action can continue. The passkeys rollout guide covers authentication, step-up and recovery boundaries that integrity evidence may inform but must not replace.
Roll out in observe evaluate and enforce stages
Integrity enforcement should begin with an observe-only stage that measures verdict availability and policy impact without silently changing player outcomes. Google explicitly recommends gathering telemetry and understanding the existing audience before acting on Play Integrity verdicts. Apple recommends staged onboarding so a large installed base does not create an avoidable attestation surge.
Define the cohort, duration, expected evidence states, privacy review, false-positive investigation path and decision owner before observation begins. Evaluate results by app version, supported platform category, journey and action rather than treating one total failure rate as a product truth. Then enable narrowly scoped responses through a versioned server policy that can be paused independently of a store release.
The rollout plan should also state how the team changes or withdraws a rule. A store rollout can leave several app versions active at once, so backend compatibility and policy versioning must cover the supported release window. The third-party SDK governance guide provides the adjacent inventory and removal controls when an integrity implementation includes supplier code.
Accept the control against an exact app release
An app-integrity acceptance pack should bind the policy, platform configuration, server verifier and test evidence to one exact mobile release and backend policy version. A passing screenshot or one successful token is not enough to show that replay, downgrade, outage and false-positive paths behave as designed.
Require the threat and action inventory, platform capability matrix, registered app identifiers, environment separation, key and credential ownership, server verification logic, challenge lifetime, replay defenses, normalized states, response matrix, user messages, observability fields, retention rules, support runbook, staged rollout plan, exception approvals and rollback procedure. Test valid and altered builds where authorized, wrong app identifiers, reused challenges, stale assertions, unsupported devices, lost connectivity, vendor outage, key rotation and simultaneous policy or app-version changes.
The pack cannot prove that the client will never be modified or that a platform verdict will always be available. It gives the buyer a reproducible answer to what evidence the exact release produces, how the backend interprets it and what happens when the evidence is absent or adverse.
For teams commissioning a player-facing native product, Wizards app development can turn sensitive journeys, platform evidence and server decisions into an integrity contract and release acceptance pack.
Frequently asked questions
What should iGaming app integrity requirements include?
iGaming app integrity requirements should include the protected actions, platform signals, server verification, challenge and replay controls, normalized evidence states, response matrix, exception paths, rollout stages, user messages and release-bound acceptance tests.
Does a valid integrity verdict prove the player is legitimate?
No. A valid integrity verdict can increase confidence in an app instance or device environment, but it does not prove player identity, location, eligibility, account standing or intent. Those decisions still need their own trusted evidence and server controls.
Where should App Attest or Play Integrity be verified?
App Attest and Play Integrity evidence should be verified on a trusted backend. The server should bind the result to the current challenge, app identity, release, session and requested action before applying a versioned policy.
Should an iGaming app block every failed integrity check?
No. The response should follow the action’s risk and the meaning of the evidence state. A policy may allow, retry, step up, restrict, review or deny, while distinguishing a failed verdict from unavailable, unsupported, stale or degraded service.
How should integrity enforcement be rolled out?
Integrity enforcement should begin with controlled observation, impact review and a narrow staged policy. The team should measure supported devices, evidence availability, false positives and service failures before expanding enforcement.
What evidence should an app integrity supplier deliver?
An app integrity supplier should deliver the exact platform configuration, server verification contract, threat and action matrix, replay defenses, failure behavior, telemetry, rollout and support procedures, negative tests and evidence tied to the accepted app and backend releases.
