Topic starter
24/10/2026 8:47 pm
TL;DR: Age verification bypasses in the European Commission’s white-label app point to a broken trust model, according to Approov. Client hardening still leaves relay attacks and remote operation open unless proof is bound to the live session.
Editorial analysis by NHI Mgmt Group, based on content published by Approov: “You Cannot Obfuscate Your Way Out of a Broken Trust Model”.
Key questions
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.
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.
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.
Practitioner guidance
- Implement server-side attestation enforcement Treat app and device attestation as a server decision, not a client-side assertion.
- 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.
Bottom line: The EU age verification case shows that obfuscation and runtime hardening do not substitute for proof binding when the user is the adversary.
Glossary terms: Age Assurance, App Attestation, Relay Attack, Token Binding
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
25/10/2026 11:11 am
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.
A question worth separating out:
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.
👉 Read our full editorial: EU age verification bypasses expose the limits of client hardening
This post was modified 7 days ago by NHI Mgmt Group