You Cannot Obfuscate Your Way Out of a Broken Trust Model

The EU's age verification app was bypassed twice in four months. The specification tells you why — and it has nothing to do with how well the binary was protected.

In April 2026, the European Commission launched a white-label age verification app, built by the T-Scy consortium (Scytáles AB and T-Systems International) under a contract reported at roughly €2 million against a framework valued up to €4 million. It was presented as the privacy-preserving answer to a genuinely hard problem: proving a user is over eighteen without handing a website their passport.

Within days, security researcher Paul Moore bypassed it. In July, after the app had been hardened and re-released as version 2026.07-1, he bypassed it again — twice, using two different techniques, with Chrome extensions he says he built in minutes using an AI assistant.

The second technique is the one that should worry everyone. Moore's extension detects the age verification QR code on a website and relays it to a remote, automated phone running the genuine app with a genuine credential. A real signature comes back in seconds. Nothing in the exchange is forged. He calls it an "automated relay bypass," and describes it as unfixable.

I'd put it differently:

The security industry is largely built on the assumption that the user and the app owner are on the same side and the attacker is a third party. Age verification inverts this assumption, as the user becomes the adversary. Almost none of our collective defensive playbook was designed for a world where the person you're protecting is the person trying to get around you. Pretending otherwise is how you end up calling a relay attack unfixable instead of just predictable.

Half of what Moore demonstrated is solvable. The other half is not solvable by any attestation technology — including ours. The difference between those two halves is the most important thing in this story, and almost nobody is talking about it.

The Specification Indicts Itself

You do not need to speculate about the architects' assumptions. They wrote them down.

The EU's published technical specification states that "the white label application features also include the use of obfuscation and code protection of the primary library of the app in binary format." It goes on to instruct implementers that "the app configuration and UI SHALL be further protected using code hardening and runtime application self-protection or similar security measures to protect the total application against malicious attacks."

Then, in the very next item, it says this:

"The app attestation checks are not included in scope (including anti-root measures, etc.), with implementation responsibility resting with the implementers."

Read those two passages together. Obfuscation and RASP: normative, in the blueprint, shipped. App attestation and root detection: explicitly out of scope, someone else's problem, left to whichever member state picks up the white label and runs with it.

That is the entire story in two sentences of procurement prose. The budget went into making the binary hard to read. The question of whether the thing talking to your API is a real app on a real device was deferred indefinitely.

Obfuscation is Priced in Analyst-hours. AI Just Crashed the Price

Code obfuscation has never been a security control. It is a delay. Its value proposition has always been economic: make reverse engineering expensive enough that the attacker moves on to a softer target. That model held reasonably well when the scarce resource was a skilled reverse engineer's time, billed in weeks.

That resource is no longer scarce.

Moore did not spend weeks with a disassembler. He described building his bypass in minutes with an AI assistant. Every hardening technique whose security derives from "this is tedious to figure out" is now being repriced in real time, and the new price is close to zero. Obfuscation didn't get weaker. The thing it was charging for got cheap.

There is a particular irony here. The EU app is open source, published on GitHub, deliberately and correctly so. Transparency is a legitimate design goal for public infrastructure. But obfuscating the binary of an application whose source code is a public repository is not defense in depth. It is a rounding error dressed as a control.

White-box cryptography deserves the same scrutiny. Its promise is that an attacker with full control of the execution environment still cannot extract the key. Set aside that white-box implementations have a long history of falling to differential computation analysis. Here is the disqualifying fact for this use case:

Perfect white-box cryptography would not have prevented a single one of Moore's bypasses.

The relay attack requires no key extraction whatsoever. The attacker doesn't need to steal the signing key. He asks a legitimate device, holding a legitimately issued credential, to perform the signature on his behalf. You can make key extraction mathematically impossible and the attack proceeds unaffected — because the attack was never about the key.

When a defensive technique is irrelevant to the actual attack, continuing to fund it is not risk management. It's security theatre with a large invoice attached.

What was Actually Solvable

Moore's first bypass was a Chrome extension that replicated the app with the ID checks stripped out. A client with the verification logic removed should never have reached a live verification endpoint and been accepted. That is a solved problem in mobile security, and solving it is API-side work, not binary-side work:

App and device attestation, enforced at the API. Not as a client-side check the attacker can patch out, but as a server-side decision. Is this a genuine, unmodified app instance on a genuine, uncompromised device? The EU spec put this out of scope. It should have been the first requirement, not an optional extra.

Token binding. A credential or session token that is cryptographically bound to the attested app instance cannot be lifted and replayed from somewhere else. Several reports describe Moore's extension reusing a successful attestation across sessions. Bound tokens make a captured proof worthless outside the instance it was issued to.

Message signing. Signing the request payload, not just the channel, means a proof cannot be detached from its original request and stapled onto a different one.

Dynamic certificate pinning. Pinning kills the trivial man-in-the-middle path, and doing it dynamically means you can rotate certificates without shipping an app update — which is precisely why static pinning gets abandoned in production.

None of this is exotic. It is standard practice in mobile banking, and it would have closed the cloned-client attack. It was left out of scope while the binary got obfuscated.

What was Never Solvable, and Why that Matters More

Now the harder half. Attestation — ours, Google's Play Integrity, Apple's App Attest, anyone's — proves that a genuine app is running on a genuine device. It does not prove, and cannot prove, who is holding that phone.

In the relay, everything is authentic. Real app. Real unrooted device. Real credential, issued to a real adult who really did scan a real ID. Real signature. There is no forged artifact anywhere in the chain for attestation to detect. The only false thing is the assumption that the human at the browser is the human the credential describes — and that assumption lives outside every attestation product's threat model, including ours.

The spec does require that "an Age Verification Instance SHALL authenticate its User in a reliable manner." But a PIN or biometric that unlocks a farm phone under the attacker's control authenticates nothing useful. Local unlock is not proof of presence at the moment of proof.

Closing that gap requires binding the credential holder to the live session: proximity constraints between the browser and the wallet, liveness checked at proof time and bound into the presentation, channel binding that makes a remote signature invalid. Every one of those measures costs some fraction of the anonymity that was the project's entire selling point.

That is the catch-22 the Commission has walked into. The honest version of "anonymous age verification" is that the anonymity and the assurance are in direct tension, and you cannot buy your way out of that tension with a hardening SDK.

The Escalation Path is the Real Risk

Here is what I expect to happen, and why I think this matters beyond one app.

When the privacy-preserving approach visibly fails — and it is failing in public, on a quarterly cadence — the conclusion drawn in Brussels will not be that the goal was wrong. It will be that the checks weren't strict enough. Every bypass becomes an argument for something more invasive. Prove your age becomes proving your identity, and the privacy-first framing that justified the program becomes the casualty of its own ineffectiveness.

Shipping a system that can be defeated by a browser extension, and marketing it as a privacy breakthrough, is the most efficient path I can think of to age verification that isn't private at all.

What to Do Instead

If you are building or procuring an age verification system, three things:

Get the trust boundary right before you buy any hardening. If your security depends on the client behaving honestly, obfuscation buys you time, not safety. Decisions belong on the server.

Fund attestation before cosmetics. App and device attestation, token binding, message signing and dynamic pinning close the attacks that are actually closeable. Leaving them "out of scope" while mandating obfuscation is spending real money on the wrong half of the problem.

Be honest about what's left. Attestation is necessary and insufficient. It will not tell you who is holding the phone. Any vendor claiming otherwise is selling you the same client-side trust that just failed the European Commission twice in four months.

We built Approov on the first two. We're clear-eyed about the third. In a market full of people promising unbreakable clients, being straight about where the line sits is the only position that survives contact with a researcher like Paul Moore.