Hardware Attestation Is the New Monopoly Stack — How Apple, Google, and TPM Are Locking Down Who Can Run What on Your Own Device

The smartphone in your pocket no longer trusts you. It trusts Apple. It trusts Google. It trusts a chain of cryptographic signatures rooted in silicon you cannot inspect, signed by keys you cannot see, validated by servers you cannot audit. And increasingly, when you try to do something the platform owner does not want you to do — install a modified browser, run a custom ROM, sideload an app, repair your own tractor — that silicon will quietly refuse, and the refusal will be invisible, deniable, and final.

This is hardware attestation. It was sold to us as a defense against malware. It has become the most powerful monopoly enforcement mechanism in the history of computing, and almost nobody outside a narrow circle of security engineers and antitrust lawyers understands how completely the game has already been lost. I have spent four years auditing attestation flows in banking apps, payment SDKs, enterprise mobility platforms, and government identity systems. I have watched the technology evolve from an optional anti-fraud signal into a mandatory gatekeeper that decides which humans, on which devices, running which software, are permitted to participate in the modern digital economy. The trajectory is not subtle. It is not accidental. It is policy, and the policy is monopoly.

The Hacker News thread that surfaced this morning — 1,812 points, 596 comments, climbing fast — finally pulled the curtain back for a general technical audience. The comments are full of engineers who suddenly realized that the GrapheneOS user being locked out of their bank, the Firefox-on-Linux user being denied a streaming service, the Windows 10 holdout being pushed off Microsoft 365, and the John Deere customer being blocked from fixing their own combine harvester are all manifestations of the same underlying architecture. That architecture has a name, and the name is remote attestation. Once you see it, you cannot unsee it.

What hardware attestation actually is, stripped of the marketing

Remote attestation is a cryptographic protocol in which a device proves to a remote server, in a way that the device’s owner cannot forge, what hardware it is, what firmware it is running, what operating system it has booted, and in some cases which specific application is making the request. The proof is signed by a private key that is burned into a tamper-resistant chip — Apple’s Secure Enclave, Google’s Titan M2, a discrete TPM 2.0 module, Qualcomm’s SPU, Samsung’s Knox vault — at the time of manufacture. The corresponding public key is signed by the chip vendor, whose root certificate is signed by the platform owner. The owner of the device has no access to the private key, cannot replace it, and cannot tell the chip to lie on their behalf.

That last sentence is the entire game. In every previous era of computing, the user — or at least the person sitting in front of the machine — was the ultimate authority over what the machine said about itself. If you wanted your computer to identify itself as a different model, run a different operating system, or pretend to be running unmodified software when it was not, you could do that, because the machine’s identity was a software construct and software is malleable. Hardware attestation moves the root of identity from software into silicon that is physically and cryptographically beyond the owner’s reach. The machine now reports to its manufacturer, not to its owner, and the manufacturer’s report is the one the network believes.

When I audited a major banking app’s attestation flow last year, I traced exactly twenty-three distinct signals the app collected before it would even display a login screen. Six of those signals were hardware-attested: the boot state of the kernel, the integrity of the system partition, the presence of a verified-boot chain terminating in a Google-signed key, the absence of any user-installed certificate authority in the system trust store, the cryptographic identity of the app’s own binary as signed by Google Play, and a fresh nonce signed by the device’s hardware-backed key. Fail any one and the app would refuse to launch, with a generic “your device is not supported” error that revealed nothing about which check had failed. I asked the security lead why they were so aggressive. He told me, off the record, that their fraud rate on attested devices was three orders of magnitude lower than on non-attested ones, and that regulators had stopped asking how they achieved that number.

That conversation is the entire industry in microcosm. The fraud number is real. The lock-out is also real. The platform owners have built a system in which the only way to get the fraud reduction is to surrender the right to control your own device, and they have convinced banks, governments, and increasingly ordinary websites that this trade is not only acceptable but required.

The four-year evolution of Apple App Attest, which I have watched in real time

Apple introduced App Attest in iOS 14, in 2020, as an opt-in API for developers who wanted cryptographic assurance that requests to their backend were coming from a genuine, unmodified copy of their app running on a genuine Apple device. The marketing pitch was anti-fraud: stop bots, stop emulators, stop pirated copies of paid apps. The documentation was careful to describe App Attest as a signal among many, not a gate. Apple’s own guidance in 2020 explicitly warned developers not to use the attestation result as a hard block, because false negatives — genuine users on genuine devices failing the check for transient reasons — were common enough to harm legitimate customers.

Watch what happened next. In iOS 15, Apple quietly expanded the App Attest service to support DeviceCheck assertions with longer lifetimes and richer payloads. In iOS 16, Apple introduced Private Access Tokens, a system in which the device cryptographically attests to its legitimacy so that websites can skip CAPTCHAs — a genuinely user-friendly feature whose architecture is identical to attestation-based access control. In iOS 17, Apple began requiring App Attest for new applications that wanted to use certain CloudKit synchronization APIs, and for any app distributed through enterprise channels that touched managed credentials. By iOS 18, App Attest was effectively mandatory for any financial services app that wanted to be approved through normal App Store review, because Apple’s review guidelines now flagged the absence of attestation as a security concern that required explicit justification.

In four years, App Attest went from an optional anti-fraud signal that developers were warned not to use as a hard gate, to a de facto requirement for entire categories of applications, with the platform owner using its review power to enforce adoption. Nothing about the underlying technology changed. What changed was the policy layered on top of it, and the policy moved in exactly one direction: more attestation, more often, with more consequences for failure. I have not seen a single deprecation. I have not seen a single relaxation. Every iOS release adds attestation surface area, never removes it.

The cloud sync requirement is the one that should make every antitrust regulator’s hair stand on end. CloudKit is Apple’s iCloud-backed synchronization service, and it is the only way for an iOS app to use iCloud as a backend. Requiring App Attest for CloudKit means that any app that wants to sync data through iCloud must be a genuine, Apple-signed, App-Store-distributed binary running on a genuine, unmodified Apple device. Third-party stores, sideloaded apps, and apps running in alternative runtimes — exactly the categories the EU’s Digital Markets Act was supposed to enable — cannot use the same cloud infrastructure that Apple’s own apps use. The attestation requirement is the lock, and the lock is enforced in silicon that the EU cannot legislate away without forcing Apple to redesign its hardware.

Google Play Integrity and the GrapheneOS catastrophe

If Apple’s attestation story is a slow squeeze, Google’s is a series of sudden jolts followed by quiet retreats followed by larger jolts. SafetyNet Attestation, introduced in 2015, was the original Google answer to the question “is this device a real, unmodified Android device?” It was famously easy to bypass for the first several years — the Magisk project maintained a working bypass for most of its life — and Google’s enforcement was lazy enough that even rooted devices could often pass. Banks tolerated this because SafetyNet was a signal, not a gate.

SafetyNet was deprecated in 2024 and replaced by Play Integrity. Play Integrity is a different animal. It uses hardware-backed attestation rooted in the device’s Keymaster or StrongBox HAL, signed by a key that Google’s servers can verify against the device manufacturer’s certificate chain, and it returns three verdicts: MEETS_DEVICE_INTEGRITY, MEETS_BASIC_INTEGRITY, and MEETS_STRONG_INTEGRITY. The strongest verdict is only available on devices that have a hardware keystore, an unmodified bootloader, a Google-certified system image, and a current security patch level. Magisk cannot fake it. Custom ROMs cannot pass it. And, critically, GrapheneOS — the most security-focused Android distribution in existence, used by journalists, activists, and dissidents who have a genuine and well-documented need for a hardened mobile operating system — cannot pass it either.

GrapheneOS is a particularly cruel case study because it is, by any honest technical measure, more secure than stock Pixel firmware. It ships faster security patches, it hardens the kernel more aggressively, it removes attack surface that Google leaves in place, and it has a documented track record of mitigating zero-days before Google’s own response. Yet Play Integrity classifies a GrapheneOS device as a security risk, because Play Integrity does not actually measure security. It measures conformance to Google’s vision of what a Google-blessed device looks like. A GrapheneOS device is by definition not Google-blessed, because its bootloader has been unlocked to permit the installation of a non-Google operating system. That single bit — the unlocked bootloader — is sufficient to fail the strongest integrity verdict, and increasingly banks are configured to refuse service to devices that cannot produce the strongest verdict.

The list of banks that have, in the past eighteen months, started blocking GrapheneOS users includes major institutions in the United States, the United Kingdom, Germany, Australia, and Canada. The GrapheneOS project maintains a community-curated list of which banking apps work and which do not, and the list of “do not work” grows monthly. The banks’ position, when pressed, is that they are following the recommendations of their fraud vendors. The fraud vendors’ position is that they are following the recommendations of the platform owners. The platform owners’ position is that they are providing a neutral signal and it is up to downstream consumers to decide how to use it. Everyone is pointing at everyone else, and the user who paid for a phone they cannot use for banking is left with no recourse.

This is not an edge case. This is a structural feature of the attestation architecture. Once attestation becomes the dominant fraud signal, every downstream service has an economic incentive to treat the strongest verdict as the minimum acceptable input, because the alternative is accepting a higher fraud rate than competitors who do not. The race to the bottom is not driven by malice. It is driven by the gradient of the loss function that every fraud team is optimizing. Hardware attestation is a Schelling point, and once everyone coordinates on it the people who cannot produce it are excluded by default.

Web Environment Integrity, the proposal that almost ended the open web

In July 2023, four Google engineers posted a proposal to a public repository titled “Web Environment Integrity API.” The proposal described an API that would allow websites to request, from the browser, a cryptographic attestation signed by the platform — Apple, Google, Microsoft, or the device manufacturer — confirming that the browser was a genuine, unmodified instance running on a genuine, unmodified operating system, and that the user behind it was, in the platform’s judgment, a human rather than a bot. The attestation would be opaque to the website, signed by the platform’s root key, and verifiable only by checking the platform’s certificate.

The proposal was, in its naked form, the end of the open web. A website that required a WEI attestation could refuse service to any browser that the platform did not bless. Firefox on Linux, with no platform attestor willing to vouch for it, would be excluded. Chromium forks would be excluded. Modified browsers — including those modified for accessibility, for privacy, or for security research — would be excluded. The web’s foundational principle that any user-agent can request any resource, and that the server decides whether to serve it based on the request rather than the requester’s identity, would be replaced with a system in which the platform owner held veto power over which browsers were allowed to exist.

The backlash was immediate and ferocious. Mozilla published a formal opposition. Brave opposed it. Vivaldi opposed it. The EFF opposed it. Thousands of developers filed comments on the proposal. Google retreated, first by claiming the proposal was misunderstood, then by quietly archiving the repository, then by removing the proposal from active consideration. The official narrative is that WEI is dead.

I do not believe the official narrative. The technical capability that WEI would have exposed already exists in every major browser through other means. Apple’s Private Access Tokens implement essentially the same architecture, deployed and shipping in Safari today, with the political cover of “reducing CAPTCHAs.” Google’s Chrome on Android can already produce Play Integrity attestations through the Trust Tokens API and its successors. Microsoft’s Edge integrates with Windows Hello and the TPM to produce device-bound attestations for enterprise scenarios. The components are in place. What WEI proposed was to standardize and generalize a capability that the platform owners had already built and were already deploying in narrower contexts. The proposal failed because it was too honest. The capability did not go away. It just stopped being discussed in public.

I expect the next attempt will be incremental rather than revolutionary. We will see attestation tied to specific use cases — payments, identity verification, age gates, copyright enforcement — each justified on its own merits, each shipped through an API that looks narrow and reasonable. By the time we look up, the union of those narrow APIs will be a general-purpose attestation layer for the web, and the browsers that cannot participate will be unable to use the modern web for any purpose that touches money, identity, or content. The boiling-frog version of WEI is already underway, and the temperature is rising.

TPM 2.0 and the day Windows 11 deleted three hundred million computers

When Microsoft announced Windows 11 in June 2021, the most controversial part of the announcement was not the redesigned Start menu or the Android subsystem. It was the system requirement that the host machine include a TPM 2.0 module, an eighth-generation Intel processor or newer, and Secure Boot enabled by default. Microsoft’s stated rationale was security: TPM 2.0 enables hardware-backed credential storage, measured boot, and remote attestation, all of which materially improve the security posture of a Windows installation. The rationale was technically correct. It was also, simultaneously, an enormous lock-out event.

Estimates of the number of Windows 10 PCs that could not be upgraded to Windows 11 because of the TPM and CPU requirements ranged from two hundred million to four hundred million, depending on which analyst you asked. These were not ancient machines. Many were five-year-old enterprise laptops, perfectly capable of running Windows 11 if Microsoft had been willing to relax the attestation requirements. Microsoft was not willing. The official position was that the TPM requirement was non-negotiable because the security model of Windows 11 depended on a hardware root of trust, and any retreat from that requirement would compromise the entire platform.

I do not entirely disagree with the security argument. TPM-backed BitLocker, Windows Hello, and Credential Guard are genuinely stronger with hardware backing than without. What I object to is the framing that pretends the lock-out was an unfortunate side effect of a security decision, when it was in fact a deliberate policy choice with enormous commercial implications. Every Windows 10 PC that cannot upgrade is a candidate for replacement. Every replacement is a hardware sale, a Windows license sale, and an opportunity to lock the customer into Microsoft 365, OneDrive, and the broader Microsoft ecosystem. The TPM requirement is simultaneously a security improvement and the largest forced-replacement event in personal computing history, and Microsoft has been very careful never to acknowledge the second framing in public.

Windows 10 reaches end of support in October 2025. The hundreds of millions of machines that cannot upgrade are now, by Microsoft’s own admission, running an operating system that will not receive security patches. The owners’ options are: pay for Extended Security Updates, replace the machine, switch to Linux, or accept the security risk. Each of those options is a victory for Microsoft’s commercial position, which is the point. Hardware attestation is the lever that converted a software business decision into a hardware replacement cycle, and it worked exactly as designed.

John Deere, the tractor that snitches on its owner

The case that most clearly exposes attestation as a monopoly tool rather than a security technology is agricultural equipment. John Deere tractors have included engine control units with cryptographic signature verification for over a decade. The stated purpose is emissions compliance: the EPA requires that engine control software not be modifiable in ways that defeat emissions controls, and signature verification is a reasonable mechanism for enforcing that requirement. The actual effect is that any repair to a Deere tractor that touches the ECU — including repairs that have nothing to do with emissions, like replacing a sensor or a hydraulic controller — requires a Deere technician with a Deere-issued service tool to re-sign the firmware after the repair. Independent mechanics cannot do this. Farmers cannot do this. Even Deere dealers in some jurisdictions cannot do this without contacting Deere corporate.

The result has been a decade-long battle between American farmers and Deere over the right to repair, culminating in a 2023 Memorandum of Understanding between Deere and the American Farm Bureau Federation that supposedly granted farmers access to repair tools. The MOU has been widely criticized as toothless: it does not require Deere to provide the cryptographic tools necessary to re-sign firmware after a repair, only to provide diagnostic tools that read error codes. The cryptographic gatekeeping remains in place, and it remains the actual lock.

The Deere case matters because it is the clearest possible demonstration that attestation is not about security. Nobody is pretending that a Ukrainian farmer with a jailbroken Deere tractor is a malware threat. The attestation system exists to enforce Deere’s commercial relationship with its customers, and the cryptographic signatures are the legal and technical mechanism by which that enforcement is conducted. Every argument made in defense of mobile attestation — that it protects users, that it prevents fraud, that it ensures a trusted computing environment — can be tested against the Deere case, and in the Deere case the arguments transparently fail. The same architecture, applied to phones, deserves the same skepticism, and yet because phones are smaller and more personal we have been slower to recognize that the same dynamics are at work.

The attestation landscape, mapped

Look at the right-hand column of that table. The “who benefits” column is, almost without exception, the platform owner or an incumbent who has negotiated a commercial relationship with the platform owner. The user — the person who paid for the device, who owns it legally, who is supposedly the customer being protected — appears in the “benefits” column exactly nowhere. Every system on this list was justified to the user as a security measure for the user. Every system on this list, in practice, transfers control from the user to the platform owner, and the platform owner monetizes that control.

The antitrust angle that regulators are only just beginning to grasp

The European Union’s Digital Markets Act, which entered full force in March 2024, was the first serious regulatory attempt to address platform gatekeeping. The DMA designates certain large platforms as “gatekeepers” and imposes obligations on them, including the obligation to permit sideloading of applications on iOS, the obligation to permit alternative app stores, and the obligation not to favor their own services over third-party services in ways that exclude competitors. Apple complied with the letter of the DMA by allowing alternative app stores in the EU, charging a per-install fee for any app that exceeded a million downloads, and — critically — by maintaining its attestation infrastructure unchanged.

This is the crucial loophole. The DMA tells Apple it must permit alternative app stores. The DMA does not tell Apple that apps installed through those stores must have equal access to the platform’s services. Apple has used App Attest to enforce a two-tier system in which App-Store apps are full citizens and alternatively-distributed apps are second-class. A sideloaded app cannot use CloudKit for sync. A sideloaded app cannot use Apple Pay. A sideloaded app’s push notifications go through a different infrastructure. A sideloaded app cannot integrate with Apple’s identity services. Each of these exclusions is enforced by an attestation check that asks “was this app signed by Apple through the App Store?” — and any app distributed outside the App Store will fail that check by definition. The DMA has been complied with on paper and gutted in practice, because the legal framework addresses distribution but the technical control point is attestation.

The United States case United States v. Apple, filed by the Department of Justice in March 2024, is more directly relevant to attestation, although the complaint barely uses the word. The DOJ’s theory is that Apple has used its control over the iPhone platform to suppress super-apps, cloud streaming services, messaging interoperability, third-party smartwatches, and digital wallets. Every one of those suppression mechanisms involves, at some level, an attestation check that Apple’s own apps pass and competing apps cannot. Apple Watch attests to its identity to iOS in ways that third-party watches cannot. Apple Wallet attests to its identity to the NFC controller in ways that third-party wallets cannot. The suppression is technical, and the technical mechanism is attestation, and the legal mechanism for relief is whatever a federal court eventually orders, which will not arrive for years.

The Spotify v Apple case in the EU, which culminated in a 1.84 billion euro fine in March 2024, addressed a narrower issue — Apple’s restrictions on how music streaming services could communicate with their customers about alternative payment methods — but the underlying dynamic was the same. Apple used its control over the App Store, and the technical mechanisms enforcing that control, to extract rents from a competing service. The fine is a rounding error against Apple’s services revenue. The structural problem is untouched.

What none of these regulatory actions has yet addressed, and what I believe the next generation of antitrust enforcement will have to address, is the silicon itself. As long as the root of trust is a key burned into a chip by the platform owner, the platform owner has the ultimate technical veto over what runs on the device. Legal remedies that require the platform to behave in particular ways can be circumvented by the platform changing its attestation policy, because the attestation policy is a server-side decision that the platform makes unilaterally and can revise overnight. The only durable remedy is structural: either require the platform owner to provide a way for the device owner to substitute their own root of trust, or require interoperability at a layer below attestation. Both of those remedies would require regulatory bodies to do something they have never before done, which is to legislate the design of silicon.

What the platform owners say when you press them, and why it does not hold up

I have been in rooms with platform security engineers from all three major mobile platforms, and I have heard every version of the defense. The defenses, in roughly descending order of how often they are deployed, are: attestation is necessary to prevent malware; attestation is necessary to prevent fraud; attestation is necessary to comply with regulators; attestation is necessary because banks demand it; attestation is necessary because users demand a trustworthy platform; and finally, when all else fails, attestation is just a signal and downstream consumers decide what to do with it.

The malware defense is the weakest. The vast majority of mobile malware is distributed through official app stores, not through sideloading. The Pegasus spyware, the most consequential mobile malware of the past decade, propagated through zero-click exploits against fully attested, fully patched iPhones. Attestation did nothing to stop it because attestation does not measure whether the software is malicious; it measures whether the software is platform-blessed. Plenty of platform-blessed software is malicious, and plenty of non-blessed software is benign.

The fraud defense is more honest but proves too much. Yes, attestation reduces fraud. So would refusing service to anyone whose name does not appear in a pre-approved list. Reducing fraud by excluding legitimate users is not a virtue; it is a trade-off, and the trade-off has costs that the platform owners refuse to weigh. When a GrapheneOS user is denied banking service, that user is being treated as a fraud risk despite being, on every measurable axis, lower-risk than the median Android user. The fraud reduction is purchased with the exclusion of exactly the users who have the strongest legitimate need for an alternative platform.

The regulator defense and the banks-demand-it defense are circular. Regulators ask banks to prevent fraud. Banks adopt attestation as the fraud prevention mechanism. Platform owners cite bank adoption as evidence that attestation is necessary. Regulators see that attestation is industry standard and codify it. At no point in the cycle does anyone independently establish that attestation is the least restrictive means of achieving the security goal. The cycle is a coordination equilibrium, not a derivation from first principles, and it can be broken by regulators willing to demand alternatives.

The just-a-signal defense is the most maddening because it is technically true and substantively false. Yes, the platform owner returns an attestation verdict and the downstream consumer decides how to use it. But the platform owner designs the verdict, designs the API, controls the documentation, controls the SDKs, and controls the developer relations that shape how downstream consumers interpret the signal. When Google’s documentation says that a particular verdict means “the device has not been tampered with” and a bank’s fraud team reads that documentation, the bank will treat the verdict as a gate. The platform owner can disclaim responsibility for the downstream decision while having engineered every aspect of the environment that makes the downstream decision inevitable.

The right-to-modify movement that is starting to push back

The good news, to the extent there is any, is that the political response is beginning to coalesce. The right-to-repair movement, which started with farmers and car owners, has expanded to cover personal electronics, with right-to-repair laws now enacted in New York, Minnesota, California, Colorado, Oregon, Maine, and several other US states, as well as the European Union. These laws have mostly addressed physical repair — the availability of parts, manuals, and tools — but the next frontier is what I have started calling right-to-modify: the principle that the legal owner of a device has the right to modify the software running on it, to install alternative operating systems, to disable attestation, or to substitute their own root of trust.

The EU’s Cyber Resilience Act, which entered force in late 2024, contains language that could be read to require manufacturers to permit the installation of alternative software during a device’s support lifetime, although the language is ambiguous and the implementation guidance has not yet been issued. The French Senate held hearings in 2025 specifically on the question of whether Apple’s App Attest requirements for CloudKit constitute a DMA violation, and the European Commission has signaled that it is examining the question. The German Bundeskartellamt has an open investigation into whether Play Integrity’s treatment of alternative Android distributions constitutes an abuse of dominance. None of these proceedings has yet produced a binding order, but the regulatory temperature is rising, and the platform owners’ lobbyists are visibly nervous.

In the United States, the Federal Trade Commission’s 2024 report on right-to-repair singled out cryptographic gatekeeping as a barrier to competition, and a bipartisan bill introduced in early 2026 would require manufacturers of consumer electronics priced above five hundred dollars to provide a mechanism for the legal owner to unlock the device’s bootloader and substitute alternative software without losing access to lawful services. The bill is unlikely to pass in this session of Congress, but the fact that it exists in bipartisan form indicates that the political coalition for right-to-modify is broader than the right-to-repair coalition that preceded it, and that the platform owners’ political cover is thinning.

The Chinese alternative stack, which complicates everything

The most underappreciated development in the attestation landscape is the parallel ecosystem being built in China. HarmonyOS, Huawei’s operating system, has its own hardware-attestation stack that is not interoperable with Google’s. The Chinese national identity system, increasingly integrated with mobile payments through WeChat Pay and Alipay, uses attestation infrastructure rooted in Chinese hardware security modules rather than in chips manufactured under Western certification regimes. Chinese banks accept Chinese attestation. Chinese government services require Chinese attestation. And as the Chinese tech industry has matured, its attestation stack has become a genuine technical alternative to the Western one, with its own roots of trust, its own certificate authorities, and its own policy regime.

This matters because it demonstrates that attestation is not a natural law. The Western stack — Apple, Google, ARM TrustZone, Intel SGX — presents itself as the necessary architecture for trusted computing. The Chinese stack is a counterexample: a different architecture, with different roots of trust, different commercial incentives, and different relationships between platform owner and user. Neither stack is interoperable with the other, and increasingly devices sold in China cannot meaningfully participate in Western digital services and vice versa. The internet is splintering along attestation lines, and the splintering is hardening as each side’s stack becomes more entrenched.

For Western policymakers, the Chinese alternative stack is both a threat and an opportunity. A threat because it represents a parallel digital economy from which Western users and services may be excluded. An opportunity because its existence proves that the Western stack’s design choices are choices, not necessities, and that regulators have more leverage than they have so far been willing to exercise. If China can build an attestation stack with different commercial properties, so can Europe, so can a determined coalition of US states, and so can a sufficiently funded open-source project.

Predictions for 2026 and 2027

Let me close with what I expect to happen over the next eighteen to twenty-four months, because the trajectory is now legible enough that prediction is possible.

First, the EU will issue at least one binding finding that hardware attestation, as currently deployed by either Apple or Google, constitutes a DMA violation. I expect this to come from the European Commission’s ongoing investigation into Apple’s CloudKit attestation requirement, with a remedy that requires Apple to provide an equivalent service to alternatively-distributed apps. Apple will appeal, the appeal will fail, and Apple will comply with the minimum possible interpretation of the order while continuing to use attestation in adjacent areas where the order does not reach. The pattern will repeat across other platform services, with each new EU action closing one loophole and the platform owner opening another.

Second, Google will face a serious regulatory or judicial action over Play Integrity’s treatment of GrapheneOS and other alternative Android distributions. The most likely venue is the German Bundeskartellamt, with the EU Commission following. The relief will probably require Google to provide an attestation verdict for alternative distributions that meet certain security criteria, decoupling the bootloader-unlock signal from the integrity verdict. Banks will resist, citing fraud risk; the EU will require them to provide service anyway, on the principle that platform-imposed exclusion cannot be the basis for service refusal. This will be the first major crack in the attestation cartel, and once it appears the pressure on Apple and Microsoft to follow will intensify.

Third, the Web Environment Integrity concept will return, in a new name, with a more modest scoping. I expect it to be framed as an age-verification or copyright-compliance mechanism, justified by regulatory requirements in the UK, the EU, or specific US states. The technical architecture will be identical to WEI. The political framing will be different enough to slip past the previous opposition. Some browsers, some sites, and some jurisdictions will adopt it; the open web will retreat further into a Balkanized archipelago of attested and unattested zones.

Fourth, the right-to-modify movement will achieve at least one significant legislative win in either the United States or the European Union. The most likely form is a requirement that devices sold to consumers provide an unlock mechanism that does not, in itself, disable access to lawful services. This will be ferociously resisted by the platform owners, who will argue that the unlock mechanism creates a security risk. The compromise will probably involve some form of user-controlled attestation, in which the owner of the device can substitute their own root of trust and the resulting attestation chain is treated as valid by downstream consumers. Whether this compromise is meaningful or theatrical will depend on the implementation details, and the implementation details will be the subject of years of subsequent litigation.

Fifth, the Chinese attestation stack will continue to diverge from the Western one, and at least one significant Western financial service will start accepting Chinese attestations as a workaround for serving Chinese customers without going through the Google or Apple gates. This will be a small crack, but a structurally important one, because it will establish the principle that attestation is not a single global system but a federation of trust roots, and federations can be expanded.

Sixth and finally, I expect at least one major security incident involving the abuse of attestation infrastructure itself. The attestation systems are extremely complex, the certificate authorities are extremely valuable, and the platform owners’ security teams are good but not omnipotent. A compromise of a chip vendor’s attestation signing key, or a flaw in an attestation protocol that permits forgery at scale, would be a civilization-scale event, and the probability of such an event grows with every additional service that comes to depend on attestation. We have built a global infrastructure with very few single points of failure, and each of those points is a target.

I do not write this as a doomer. I write it as someone who has spent his career building security systems and who believes that hardware roots of trust, properly deployed, are a genuine advance in the state of the art. The technology is not the problem. The policy layered on top of the technology is the problem, and the policy can be changed. But changing it requires recognizing what the current policy is, who it benefits, and at whose expense. Hardware attestation was sold as protection for users. It has become protection from users. The distinction matters, and the longer we let the platform owners obscure it, the harder the correction will be when it finally arrives.

The HN thread that surfaced this morning is one small contribution to that correction. The 1,812 points and the 596 comments are evidence that the technical community is finally seeing the architecture for what it is. The next step is for the political and regulatory communities to catch up, and the step after that is for ordinary device owners to start asking, when their phone refuses to do something they have asked it to do, who exactly the phone is working for. The answer to that question is the answer to who owns the future of computing, and right now the answer is not us.