Hardware Attestation: How a Security Tool Became a Gatekeeping Weapon

Posted on 10.05.2026

For most people, the phrase "hardware attestation" sounds like something that belongs in a server room, not a debate about competition policy. But over the past few years a quiet shift has been happening inside the phones, laptops and browsers we all use. The chips in our devices are increasingly being asked to vouch for us — to prove to a remote server that we are running an "approved" operating system, an "approved" browser and an "approved" app, on hardware blessed by the right vendor.

That sounds reasonable, until you ask the obvious question: approved by whom?

What hardware attestation actually is

At its simplest, hardware attestation is a cryptographic process that lets a device prove things about itself to a third party. A small, tamper-resistant chip — Apple's Secure Enclave, Google's Titan M, a TPM (Trusted Platform Module) on a Windows PC, or an ARM TrustZone region — holds a private key that was burned in at the factory. When a server asks "are you really an unmodified iPhone running iOS 17?", the chip can sign a statement to that effect, and the server can verify the signature against the manufacturer's public key.

The key property is that the user can't fake it. Not easily, anyway. Unlike a software check that a determined developer can patch out, hardware attestation roots the answer in silicon that the device's owner doesn't fully control.

This is genuinely useful technology. It underpins secure boot, disk encryption, passkeys, and the ability of a corporate IT department to know that a laptop logging into the VPN hasn't been quietly replaced with a clone. Banks use it to make sure a payment is being authorised on a real phone with a real fingerprint sensor, not a script in a data centre in another country.

The slide from "is this device secure?" to "is this device approved?"

The problem is not attestation itself. The problem is what the question being asked has quietly become.

A decade ago, attestation answered narrow technical questions: is the boot chain intact, is full-disk encryption on, is the screen lock enabled? Today, the questions have crept outwards. Google's Play Integrity API, which replaced SafetyNet, lets app developers ask whether a phone is running a Google-certified build of Android — meaning the device shipped with the Play Store and passed Google's compatibility tests. Apple's App Attest does the equivalent for iOS apps. Browsers have flirted with similar ideas, most controversially in Google's now-shelved Web Environment Integrity proposal, which would have let websites demand a cryptographic attestation that the browser and OS were on an approved list before serving content.

Each step seems individually defensible. Each step also narrows the universe of "acceptable" computing environments. And the gatekeepers of those lists are, almost without exception, the same handful of companies that already dominate mobile operating systems, app stores and browser engines.

Who gets locked out

Walk through the practical consequences and the picture sharpens.

  • Custom Android builds. Privacy-focused operating systems like GrapheneOS or LineageOS run on the same hardware as stock Android and are often more secure. But because they aren't "Google-certified", banking apps, streaming services, government ID apps and even some public transport apps refuse to run on them. The phone is fine; the chip says so. The app vendor has simply chosen to trust only Google's flavour.
  • Rooted or jailbroken devices. Users who want full administrative control over hardware they paid for — to install a firewall, block ads at the system level, or run unsigned software — are routinely locked out of mainstream apps, even when their use case has nothing to do with security.
  • Older or independently repaired devices. Right-to-repair advocates have flagged cases where swapping a screen or battery with a non-OEM part can trip attestation checks, downgrading or disabling features. The chip dutifully reports the modification; the manufacturer decides what that means.
  • Alternative browsers and engines. If web attestation ever goes mainstream, the browsers most likely to pass are the ones built by the same companies that ship the operating systems. Independent forks, accessibility-focused browsers and research projects could be quietly de-platformed by the web itself.

None of this requires a conspiracy. It just requires the default question to be "is this environment on the approved list?" instead of "is this environment doing anything actually harmful?".

Why this is a competition issue, not just a security one

The reason hardware attestation matters for competition policy is that it converts a security primitive into a permissioning system. The companies that issue the signing keys become the companies that decide which operating systems are commercially viable, which browsers websites can require, and which app stores can plausibly exist.

For Australian users, this lands in a familiar context. The ACCC's long-running Digital Platforms Inquiry has repeatedly highlighted how control of mobile operating systems, app stores and default settings entrenches the dominance of a small number of overseas firms. Hardware attestation is a deeper layer of the same problem: even if a regulator forced Apple or Google to allow third-party app stores tomorrow, attestation-gated services could still refuse to function unless the device was running the original vendor's OS.

It also has implications for the government's own digital identity ambitions. If a Digital ID, a MyGov login or a state-issued driver's licence app will only run on "certified" devices, the state has effectively outsourced part of its citizenship infrastructure to two American companies' allow-lists.

The legitimate-use defence — and its limits

The standard defence from platform vendors is that attestation prevents real harm: bot fraud, account takeovers, cheating in games, money laundering through fake devices. All true. The question is whether the same goals can be achieved without the collateral damage.

In most cases they can. Risk-based authentication, behavioural signals, transaction limits, server-side anomaly detection and good old-fashioned 2FA solve the great majority of fraud problems without demanding that the user's device be locked to a specific vendor's blessed configuration. Banks operated online for two decades before Play Integrity existed. They were not, in fact, ruined.

The convenient thing about hardware attestation, from a platform owner's perspective, is that it's cheap for them and expensive for everyone else. Pushing fraud prevention down into a chip-level allow-list externalises the cost onto users with non-standard setups, repair shops, smaller competitors and alternative OS projects — none of whom were sitting at the table when the spec was written.

What users and policymakers can actually do

There is no clean technical fix; the cryptography works as advertised. The fixes are mostly governance ones.

  • Separate "is this device secure" from "is this device made by us". Attestation APIs should be required to expose narrow security properties (verified boot, encryption on, OS patch level) rather than vendor-identity flags that effectively encode brand loyalty.
  • User-controlled keys. Owners of a device should be able to enrol their own signing keys after unlocking the bootloader, so a self-installed OS can attest to its own integrity rather than being treated as inherently untrustworthy.
  • Regulatory scrutiny of attestation as a market practice. Competition regulators, including the ACCC, can treat attestation-based exclusion of compliant alternative platforms the same way they treat other forms of self-preferencing.
  • Pressure on app developers. Banks and government services in particular should be asked, publicly, why their app refuses to run on a more secure operating system than the one it requires.

The deeper question

Hardware attestation forces a question the tech industry has spent years avoiding: whose computer is it, anyway? If the device in your pocket can be compelled to testify against you — to tell a remote server that you have, say, installed a different operating system, or replaced your own battery, and to have you locked out of your bank as a result — then ownership has quietly become tenancy.

The technology isn't going away, and shouldn't. But the next decade of digital policy will largely be a fight over who gets to ask the questions, and what counts as an acceptable answer. Australians have a stake in making sure those answers aren't decided entirely in Cupertino and Mountain View.

Related on Bleen

Sources

Comments 0