EU age verification bypasses expose the limits of client hardening

At a glance

What this is: Approov argues that the EU age verification app’s two bypasses in four months reveal a structural failure in client-side trust, not a binary-hardening problem.

Why it matters: IAM, identity verification and mobile security teams should treat attestation, token binding and session-bound proof as governance requirements when the user can be the attacker.

Context

Age verification systems sit at the boundary between identity verification, privacy and application security. When the person being checked is also the person trying to defeat the control, client-side hardening alone cannot establish trust, because the verification must prove both the device and the live session are legitimate.

The EU case shows why binary protection, code obfuscation and runtime hardening do not address the real governance gap. The issue is not just whether the app is hard to reverse engineer, but whether the proof presented to the server is bound to a genuine, present user on a genuine device.

Key questions

Q: What breaks when age verification relies on client hardening instead of proof binding?

A: The system accepts a control that makes reverse engineering harder but does not verify who is holding the device or whether the proof belongs to the live session. That leaves relay attacks, replay and remote operation intact. The failure is not technical opacity but misplaced trust in the client path.

Q: Why do app attestation and device attestation not solve relay attacks on their own?

A: They prove that a genuine app is running on a genuine device, but they do not prove that the human using that device is the authorised user. A remote operator can still use a legitimate phone to produce a legitimate proof. Human presence has to be verified separately and bound to the transaction.

Q: What are the signs that a digital age verification flow is too easy to bypass?

A: A weak age verification flow often shows up when users can submit someone else’s photo, reuse captured images, or complete checks without meaningful liveness protection. Other warning signs are heavy dependence on manual review, inconsistent pass rates across user groups, and no clear defence against injection attacks or deepfake-style spoofing.

Q: When should organisations move from age assurance to stronger identity proofing?

A: Only when the business requirement justifies collecting more personal data and the lighter control cannot meet the risk threshold. If privacy-preserving age assurance is repeatedly bypassed, the organisation must decide whether to improve proof binding or accept that a stronger identity model is needed.

Technical breakdown

Why client hardening does not solve age verification trust

Code obfuscation, runtime application self-protection and white-box techniques make reverse engineering more expensive, but they do not create trust in the identity of the user or device. In this case, the attacker did not need to break the binary to win. The control failed because the system treated client resistance as a substitute for proof that the app instance, device and session were genuine. That is a design flaw, not a tooling flaw. Practical implication: move assurance decisions to the server and treat client hardening as delay, not validation.

Practical implication: enforce attestation and token checks on the server, not in client logic.

App and device attestation versus human presence

App attestation answers whether a genuine app is running on a genuine device, while human presence asks whether the person using that device is the rightful holder at the moment of proof. Those are different questions. A real, unrooted phone can still be operated by an attacker in a relay setup, so attestation alone cannot close the abuse path. The article highlights the boundary between technical integrity and identity assurance, which is where many privacy-preserving verification systems fail. Practical implication: require live session binding, not just device authenticity.

Practical implication: add live session binding and liveness checks where human presence matters.

Why token binding and request signing matter in relay attacks

Relay bypasses work because a valid proof can be detached from the request that created it and reused elsewhere. Token binding ties the credential to the attested instance, message signing ties the proof to the specific request, and dynamic certificate pinning reduces interception opportunities. Together they turn a captured proof into something much harder to replay. The important point is that these controls address the actual attack path, not an abstract concern about code secrecy. Practical implication: bind every verification artefact to one device, one session and one request.

Practical implication: bind verification artefacts to one device, one session and one request.

Threat narrative

Attacker objective: The attacker’s objective was to bypass age verification while preserving the appearance of a legitimate proof.

1. Entry occurred when a browser extension detected the age-verification QR code and relayed it to a remote phone running the genuine app.
2. Credential use followed when the real app and real credential produced a valid signature from a legitimate device under attacker control.
3. Impact was successful bypass of the age-verification control without forging the app, device or credential chain.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Client hardening is a misallocated control when the attacker is the user. Obfuscation and runtime protection can raise reverse-engineering effort, but they do not change the trust model. Once the user is the adversary, the decisive question becomes whether the server can verify a bound, genuine proof rather than whether the app is annoying to inspect. Practitioners should treat client hardening as a secondary layer, not the control that carries assurance.

Age verification exposes a verification trust gap that privacy designs must confront directly. The core tension is between anonymity and assurance, and the article shows that hardening the client does not resolve it. Where the user can delegate, relay or automate the proof, the governance problem shifts to session binding, liveness and proof-of-presence controls. Identity teams should design for that tension rather than assume it can be abstracted away.

App attestation without human binding creates a false sense of completeness. A genuine app on a genuine device can still be operating under attacker direction, which means attestation proves platform integrity, not user legitimacy. That distinction matters for any identity verification flow that treats local unlock, biometric prompts or device trust as sufficient evidence. Practitioners should narrow what attestation is allowed to claim and broaden what the server must independently verify.

Security theatre appears whenever procurement rewards visible hardening over effective trust controls. The article’s most important named concept is the verification trust gap: the distance between an apparently protected client and an actually trustworthy proof. That gap closes only when the proof is bound to the live session, not when the binary is harder to read. Teams buying age assurance or similar identity controls should demand controls that survive relay, replay and remote operation.

Publicly failed verification schemes tend to drift toward more invasive identity collection. When a privacy-preserving model is repeatedly bypassed, decision-makers often respond by tightening identity proofing rather than improving proof binding. That pattern can push systems from age assurance toward full identity verification. Practitioners should evaluate whether their chosen control can survive abuse without escalating personal-data collection.

What this signals

Verification trust gap: age-assurance systems fail when the control validates software integrity but not live human presence. For practitioners, the question is not whether the app is hard to inspect, but whether the proof is bound to the session, the device and the person using it.

The operational lesson is that privacy-preserving identity checks can be undermined by relay if the server accepts a proof detached from its origin. Teams should evaluate whether their assurance model can survive remote delegation before they scale it across production journeys.

For practitioners

• Implement server-side attestation enforcement Treat app and device attestation as a server decision, not a client-side assertion. Refuse verification results that are not bound to a genuine app instance and uncompromised device.
• Bind proofs to the live session Require token binding and request signing so a verification result cannot be replayed from another browser, device or session.
• Require human-presence signals at proof time Use liveness and proximity checks at the moment of verification, then bind those signals to the presentation so a remote relay cannot satisfy the flow.
• Separate cosmetic hardening from assurance controls Keep obfuscation and RASP if they help delay inspection, but do not count them as evidence that the verification path is trustworthy.

Key takeaways

• The EU age verification case shows that obfuscation and runtime hardening do not substitute for proof binding when the user is the adversary.
• Relay bypasses succeed because genuine apps and genuine devices can still be operated by the wrong person.
• Server-side attestation, token binding and human-presence checks are the controls that address the actual failure mode.

Key terms

• Age Assurance: Age assurance is the set of controls used to determine whether a person can access content or services restricted by age. It can include document checks, biometrics, in-band verification and decision logging, but the governance requirement is the same: the organisation must be able to justify the outcome.
• App Attestation: App attestation is a trust decision that checks whether a mobile app and its device environment meet policy before sensitive actions are allowed. It can use device integrity, app integrity, and telemetry to decide whether requests should be trusted, restricted, or denied.
• Relay Attack: A relay attack extends the communication path between a vehicle and its genuine key so the system believes the key is nearby. The attacker does not need to steal the key physically, only to forward the signal fast enough to satisfy the vehicle’s proximity check.
• Token Binding: Token binding links a token to a specific device, certificate, or connection so it cannot be reused elsewhere without the bound proof. It reduces replay risk by making theft alone insufficient, although it does not remove the need for monitoring and revocation.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, human identity and identity lifecycle alongside the controls that govern trust boundaries. It is designed for practitioners who need to connect identity assurance to broader security and risk decisions.