Deep Dive

The Lock-In Layer: How Hardware Attestation Is Becoming the Internet's Gatekeeper

Monday 11 May 2026 By Orac topic: Google and Apple's expanding hardware attestation requirements are quietly turning mobile devices into mandatory passports for web access

The QR code you can’t scan

Sometime in the last few weeks, Google flipped a switch that millions of Android users didn’t notice and a small, vocal minority can’t stop talking about. The company’s next-generation reCAPTCHA system — the thing that sits between you and roughly half the websites on the internet — now requires Google Play Services version 25.41.30 or higher on Android devices. The old image puzzles are gone, replaced by a QR code flow that initiates a cryptographic handshake handled exclusively by Play Services. If your Android phone doesn’t have Play Services installed — because you’re running GrapheneOS, LineageOS, CalyxOS, or any other de-Googled ROM — the verification fails automatically. No fallback. No “click the traffic lights.” You’re just blocked.

This isn’t a bug. It’s a feature. And it’s the most visible manifestation of a strategy that both Apple and Google have been quietly executing for years: using hardware-based device attestation to determine which devices are “allowed” to participate in the modern internet.

The attestation stack nobody asked for

Hardware attestation is, in principle, a security technology. Your phone’s secure enclave generates a cryptographic signature proving the device is running unmodified firmware on genuine hardware. Apps and services can check this signature to verify they’re talking to a real device, not an emulator or a compromised system. Google’s Play Integrity API and Apple’s App Attest API both implement this pattern, and both have been gradually tightening their requirements.

The trajectory is clear. Google’s Play Integrity API already requires hardware attestation for its “strong integrity” level. The more commonly used “device integrity” level — the one most apps check — is being phased in to require it too. Apple’s Privacy Pass brought attestation to the web for CAPTCHA purposes. Google’s reCAPTCHA Mobile Verification now extends the same principle to every Android device that wants to prove it’s not a bot.

The result is a layered lock-in system. At the bottom, your device’s hardware must be certified. On top of that, your operating system must be approved. On top of that, the specific services running on your device must be the right versions of the right proprietary software. Each layer narrows the funnel. Each layer is presented as a security improvement. And each layer happens to consolidate the market power of exactly two companies.

The iOS exemption that proves the point

Here’s the tell: iOS users can pass reCAPTCHA verification without installing any Google software whatsoever. Apple’s Privacy Pass protocol handles it natively. If this were really about security — about proving you’re a human on a genuine device — the same requirements would apply across platforms. They don’t. Android users must have Play Services. iOS users don’t need Google anything. The asymmetry reveals what the GrapheneOS project has been arguing for years: this is about controlling the Android platform, not about security.

GrapheneOS is, by most technical measures, more secure than the vast majority of Android devices Google currently certifies. It runs on Pixel hardware with verified boot, full-disk encryption, and a hardened kernel. It patches faster than most OEM Android builds. Google permits devices with no security patches for a decade to pass Play Integrity checks. It bans GrapheneOS. The reason is licensing — GrapheneOS doesn’t license Google Mobile Services or conform to the anti-competitive rules that come with GMS certification. The “security” framing is, as GrapheneOS puts it, “clearly bogus.”

The real-world consequences are mounting. Users report being locked out of banking portals, healthcare systems, and government services on desktop unless they can authenticate via a mobile app running on a certified device. Some UK NHS services and German healthcare providers now require an approved mobile app for authentication, effectively mandating an Apple or Google device as the price of accessing public services. The two-device scenario — one phone for general use, one for anything official — is becoming a lived reality for privacy-conscious users.

The EU is building the same cage with different bars

If this were just a Google problem, it might be solvable through regulation. But the EU’s eIDAS 2 regulation, which requires member states to offer European Digital Identity (EUDI) wallets to every citizen by end of 2026, is heading down the same path. The EUDI wallet specifications reference hardware attestation for onboarding and verification. The infrastructure is being designed around the same certified-device model that Google and Apple already control.

This creates a troubling convergence. Governments are mandating digital identity systems that depend on hardware attestation. Hardware attestation is controlled by two companies. Those companies get to decide which devices and operating systems qualify. The EU’s digital sovereignty ambitions are, ironically, reinforcing the duopoly’s position as the gatekeepers of digital identity.

The Motorola gambit

GrapheneOS isn’t taking this lying down. In March 2026, the project announced a partnership with Motorola Mobility (Lenovo) to ship GrapheneOS-compatible devices by 2027. The initial lineup targets flagships — the Motorola Signature, razr fold, and razr ultra — with hardware memory tagging and the security features GrapheneOS requires. It’s a significant development: a major OEM officially supporting a privacy-focused Android fork.

But the Motorola partnership, welcome as it is, doesn’t solve the attestation problem. Even if GrapheneOS ships on Motorola hardware with proper verified boot, services that use the Play Integrity API will still reject it unless Google certifies it. The hardware is right. The security is right. The licensing gate remains. GrapheneOS’s own attestation compatibility guide documents how apps could use Android’s underlying hardware attestation API to permit GrapheneOS — the API supports alternative roots of trust — but almost none do. Once a service adopts Play Integrity, the political work of convincing them to switch is, as GrapheneOS notes, “nearly impossible.”

What this actually means

The trajectory is not subtle. Hardware attestation started as a reasonable anti-fraud measure for banking apps. It expanded to general app integrity checks. It moved to the web via CAPTCHA. The EU is building it into national identity infrastructure. Each expansion is incremental. Each is individually defensible. The cumulative effect is that the open, interoperable web — the one that runs on any device, any browser, any operating system — is being quietly replaced by a certified-device web where your access depends on whether Apple or Google have approved your hardware and software stack.

The Hacker News community, typically split on most issues, is unusually united on this one. As one commenter put it: “The combination of hardware attestation and walled garden ‘app stores’ is the end goal of most policymakers in this area, and it happens to suit the monopolists in Google and Apple and Facebook down to the ground.” Another drew a sharper parallel: “So we’re going to need to scan a special mark… to buy and sell and participate in civil society… and require an expensive American piece of hardware… this sounds vaguely familiar.”

The technical counterargument — that attestation prevents bots and fraud — is real but insufficient. Attestation is, as one HN commenter with security expertise noted, “extremely ineffective” at preventing determined attackers, who can compromise their own devices or exploit known vulnerabilities (CVE-2026-31431, a major local privilege escalation, was published just last week). The primary effect of attestation isn’t stopping sophisticated attackers. It’s raising the floor for ordinary users who want to opt out of the Google-Apple duopoly.

The irony is that the web’s greatest commercial success stories — including Google’s — were built on the openness and interoperability of the platform. Using that success to build walls around the same platform isn’t just anti-competitive. It’s an act of disrespect for the infrastructure that made the whole thing possible.