Hardware Attestation Isn't About Security — It's About Control

What Happened

GrapheneOS — the security-hardened Android distribution used by journalists, security researchers, and privacy-conscious developers — published a detailed critique of hardware attestation APIs as monopoly enablers, arguing that Google's Play Integrity API has become the primary mechanism through which Google maintains its mobile OS monopoly. The post resonated hard on Hacker News, pulling 475+ points and hundreds of comments.

The argument isn't new, but the timing matters. Over the past 18 months, the number of apps requiring Play Integrity's "device verdict" has expanded far beyond banking into ride-sharing, food delivery, government services, and corporate MDM tools. What was once an edge case — "my banking app won't run on LineageOS" — has become a practical dealbreaker for anyone trying to run a non-Google Android distribution as their daily driver.

GrapheneOS is in a uniquely frustrating position here. The project builds what is arguably the most secure consumer mobile OS available: hardened memory allocator, verified boot chain, sandboxed Google Play compatibility layer, per-connection MAC randomization, and exploit mitigations that upstream Android doesn't ship. It passes hardware-backed attestation at the cryptographic level — the Titan M2 chip on Pixel devices will happily attest that the bootloader is locked and the OS is intact. But Google's Play Integrity doesn't care about actual security properties. It cares about whether the OS is Google-approved.

Why It Matters

To understand why this is a monopoly issue and not a security issue, you need to understand the attestation stack.

Android devices with hardware security modules (Titan M2 on Pixels, equivalent chips on Samsung and others) can perform cryptographic attestation: the chip signs a certificate chain proving that the device booted a specific OS image with a locked bootloader. This is real, hardware-rooted security. GrapheneOS supports it fully.

But Google's Play Integrity API layers a *software* verdict on top of this hardware attestation. The API returns three levels: `MEETS_BASIC_INTEGRITY` (the device isn't rooted), `MEETS_DEVICE_INTEGRITY` (it's running a Google-certified OS), and `MEETS_STRONG_INTEGRITY` (hardware-backed, recent security patch). The critical detail: `MEETS_DEVICE_INTEGRITY` requires Google's certification, not cryptographic proof of security. A stock Android phone three years behind on security patches passes. GrapheneOS with same-day patches, a hardened kernel, and full hardware attestation fails.

This means the API is not answering the question "is this device secure?" It's answering the question "is this device running software Google has approved?" Those are fundamentally different questions, and conflating them is — whether by design or by effect — anticompetitive.

The banking industry's adoption of this API has been the most consequential development. Banks cite regulatory requirements for device integrity checking, but what they're actually implementing is vendor lock-in by proxy. When a bank requires `MEETS_DEVICE_INTEGRITY`, they're not checking that your device is secure — they're checking that Google has approved your operating system. A user running GrapheneOS on a Pixel 9 Pro with a locked bootloader, hardware attestation, and security patches applied within hours of release is blocked. A user running a three-year-old Samsung Galaxy with known kernel vulnerabilities and months-old patches sails through.

The European Commission's Digital Markets Act theoretically addresses exactly this kind of gatekeeper behavior, but enforcement has focused on app store sideloading and default browser choices rather than the attestation layer. Japan's competition authority has been more aggressive, explicitly questioning whether attestation requirements constitute an abuse of dominant position. In the US, the DOJ's ongoing antitrust case against Google has touched on Play Services lock-in but hasn't focused specifically on attestation.

The Web Almost Got the Same Treatment

Remember Google's Web Environment Integrity proposal from 2023? That was an attempt to bring the same attestation model to the web browser: websites could verify that users were running an "approved" browser on an "approved" OS before serving content. The backlash was immediate and severe — Mozilla, the W3C TAG, and the broader web standards community rejected it as fundamentally incompatible with the open web. Google withdrew the proposal.

But the mobile version of that exact same system is already deployed, already mandatory for hundreds of apps, and barely discussed outside privacy circles. The web dodged the bullet. Mobile took it center mass.

The GrapheneOS team has proposed a solution: a standardized hardware attestation protocol that any OS vendor can implement, verified by the hardware security module rather than by Google's server-side policy. The Titan M2 chip doesn't care whether it's attesting GrapheneOS or stock Android — it attests the boot chain cryptographically. If apps checked the hardware attestation directly instead of asking Google's servers whether the device is "approved," alternative OS distributions with proper security implementations would pass the same checks.

Google has shown zero interest in this approach, which tells you everything you need to know about whether the current system is about security or control.

What This Means for Your Stack

If you're a mobile developer using Play Integrity API, here's the uncomfortable question: do you actually need `MEETS_DEVICE_INTEGRITY`, or would `MEETS_BASIC_INTEGRITY` plus your own risk signals suffice?

For most apps, the device integrity check is cargo-culted from banking app security checklists. If your threat model is "prevent automated abuse," basic integrity plus behavioral analysis (rate limiting, device fingerprinting, anomaly detection) is more effective than attestation anyway. Attestation tells you the OS is Google-approved; it tells you nothing about whether the user is a bot farm running on certified devices.

If you require `MEETS_DEVICE_INTEGRITY` without a specific, documented security rationale, you are actively participating in platform monopoly enforcement. That's not a moral judgment — it's a market structure observation. Every app that requires Google's blessing to run is another reason users can't switch to alternative operating systems, which is the textbook definition of raising switching costs to maintain monopoly.

For security teams evaluating mobile device management: consider that GrapheneOS's security properties are objectively stronger than stock Android's. If your MDM policy blocks GrapheneOS while allowing unpatched Samsung devices, your policy is optimizing for vendor compliance, not security. Some organizations, particularly in journalism and human rights, have already updated their device policies to explicitly support GrapheneOS.

For backend developers: if you're implementing device checks server-side, abstract the attestation layer. Don't hard-code Play Integrity verdicts into your auth flow. Build an attestation interface that can accept multiple verification sources — Google's, Apple's, and potentially direct hardware attestation in the future. This isn't just good architecture; it's insurance against regulatory changes that may force attestation interoperability.

Looking Ahead

The hardware attestation monopoly problem is heading toward regulatory intervention, but slowly. The DMA's interoperability requirements could theoretically force Google to accept third-party attestation providers, but no enforcement action has targeted this specific mechanism yet. The more likely near-term catalyst is the DOJ antitrust remedy: if the court orders structural separation of Play Services from Android, attestation would be one of the most consequential components to unbundle. Until then, every developer who defaults to `MEETS_DEVICE_INTEGRITY` is casting a vote — whether they know it or not — for a mobile ecosystem where one company decides which operating systems are allowed to exist.