The Vercel breach was not a hack.

No zero-day. No novel protocol exploit. No sophisticated nation-state tooling. What happened between June 2024 and April 2026 was something more unsettling: a trust model collapsed exactly as designed, because a third-party application had been granted permission to do almost anything, and nobody noticed for 22 months.

That is the actual story. And it is happening everywhere, at increasing speed, and the device industry is next.

What Actually Happened at Vercel

Here is the attack chain, stripped of vendor euphemism.

In February 2026, a Context.ai employee downloaded a malicious Roblox “auto-farm” script — a Lumma Stealer delivery vehicle you can rent for a few hundred dollars. It harvested Google Workspace credentials from the support account.

Attackers used those credentials to obtain a valid OAuth token through Context.ai’s “AI Office Suite” Google OAuth app — which held “Allow All” permissions on a Vercel employee’s Google account. One OAuth grant, made at some point in the integration lifecycle, with no scope limitation, no rotation, and no monitoring. The OAuth token was the key. The “Allow All” scope was the open door.

From there: lateral movement into Vercel’s internal systems (MITRE T1199, T1078). The exfiltrated payload included NPM tokens, GitHub tokens, API keys, database credentials, and code signing keys. None encrypted. Why? They were classified as “non-sensitive” environment variables. The label made the security decision.

Sensitive variables — those Vercel had explicitly classified and encrypted — were untouched.

The dwell time: 22 months. The ransom demand: $2 million. The public disclosure gap after customers first reported leaked OpenAI API keys: 9 days.

Trend Micro named this an OAuth supply chain attack. That framing matters precisely because “supply chain attack” usually triggers images of nation-state actors and compiler-level compromises. This was neither. It was a third-party integration with excessive permissions, a credential-stealing script downloaded by a support employee, and an internal classification system that created a false sense of what “non-sensitive” means in practice.

The “Allow All” Problem Is Structural

Here is the nuance most coverage will miss: OAuth 2.1, properly deployed with DPoP binding (RFC 9449), short-lived tokens, fine-grained scopes, and mandatory rotation, closes the specific vectors Vercel’s attackers exploited. The protocol is not fundamentally broken.

The deployment model is.

“Allow All” is not a setting OAuth forces on anyone. It is a convenience choice made at integration time, normalized by developer culture that treats permission grants as a one-time friction point rather than a persistent security boundary. Token expiration is turned off because rotation breaks integrations. Scopes are maximized because future features might need them. Encryption is skipped for secrets that “aren’t really that sensitive.”

These are the choices that compound into a 22-month dwell time. And here is what makes this a 2026 problem rather than a 2016 problem: the attacker toolkit that exploits these choices has become dramatically cheaper and faster.

AI Didn’t Create This Problem. It Industrialized It.

Lumma Stealer is distributed through AI-generated lures at scale. The malicious Roblox script was not bespoke tradecraft — it was a commodity payload delivered through AI-assisted social engineering that increasingly defeats human skepticism.

Vercel CEO Guillermo Rauch attributed the attackers’ velocity in pivoting through internal systems to AI-augmented reconnaissance. Trend Micro confirmed that LLM-assisted endpoint probing, adaptive error recovery, and context-aware queries enabled faster scope mapping than manual techniques. Once inside, an AI-assisted attacker enumerates OAuth grants, identifies high-value tokens, and prioritizes exfiltration faster than a human security operations team can detect anomalous behavior.

The attacker-defender asymmetry, in numbers:

Defenders are responding with human-speed processes — quarterly permission audits, annual token rotation reviews, manual classification of “sensitive” — against attackers operating at AI-assisted speed with months of undetected access.

This Is Not an Isolated Incident

The Vercel breach is one data point in a pattern developing for 18 months.

In 2025, the Salesloft/Drift OAuth supply chain attack compromised over 700 Salesforce instances by exploiting stolen refresh tokens from a trusted chatbot integration. The malicious activity was indistinguishable from legitimate AI assistant behavior — exactly because the OAuth grants were legitimate and the activity stayed within the permissions that had been granted.

The Oracle Cloud SSO/LDAP compromise in 2025 exposed 6 million records across more than 140,000 tenants through a vulnerability in the authentication endpoint itself. The STORM-0558 case, still under CSRB regulatory scrutiny, demonstrated token forgery at scale against Microsoft’s cloud identity infrastructure.

In January 2026, ShinyHunters ran a coordinated MFA fatigue campaign exploiting SSO session tokens: McGraw Hill lost 13.5 million records, Amtrak 9.4 million, Rockstar 78.6 million. The European Commission lost 350GB.

The pattern: delegation-based trust with insufficient constraint is the attack surface. OAuth grants, SSO sessions, refresh tokens — wherever a trust relationship is established by configuration and then left to persist, attackers will find it, sit inside it, and use it.

The Device Industry Is Replicating This Pattern in Hardware

Cloud OAuth tokens and device identity certificates are not the same thing. They operate in different threat environments, have different lifecycle constraints, and are governed by different regulatory frameworks. Anyone who tells you otherwise is oversimplifying.

But the underlying trust architecture failure is structurally identical.

OAuth grants trust through a token representing a permission decision made at configuration time. Device identity grants trust through a certificate representing an enrollment decision made at provisioning time. In both cases: if the credential is long-lived, stored in software rather than hardware, granted broad rather than scoped permissions, and not continuously monitored — it becomes an “Allow All” grant waiting to be discovered.

The Salesloft/Drift breach exploited OAuth tokens for chatbot integrations that behaved like legitimate AI assistants. The device equivalent: an OTA update credential that behaves like a legitimate firmware signer, because it is a legitimate firmware signer, with keys stored in an environment variable rather than a hardware security module.

CVE-2025-2884 (TCG TPM 2.0 reference implementation) is the structural device-layer equivalent: a flaw in shared reference code that propagates to every OEM device using that codebase. The Vercel breach propagated through a shared OAuth integration. Both demonstrate that the attack surface is the trust chain itself, not any individual endpoint.

Fig. 3 — Cloud OAuth and device identity trust models share the same architectural failure mode · CRA Article 13 mandates the hardware-rooted fix for device OEMs

For device OEMs, the risk is compounding: AI-assisted firmware analysis and hardware side-channel tooling are following the same cost curve as AI-assisted OAuth reconnaissance. The techniques that industrialized credential theft in cloud environments will industrialize device identity attacks as the target density increases.

CRA Is the Forcing Function — But Only for the Right Scope

The EU Cyber Resilience Act does not regulate how Vercel manages its OAuth grants. That matters for precision.

What CRA does regulate — mandatory conformity for manufactured digital products on the EU market — is directly responsive to the trust architecture failure this breach illustrates.

What Hardware Binding Actually Solves (And What It Doesn’t)

I want to be honest about the limitations of the hardware-rooted identity thesis, because overclaiming weakens the argument.

TPM binding, HSM-stored keys, and hardware attestation are meaningful defense-in-depth. They ensure that a key used for device authentication or code signing cannot be simply copied from an environment variable or file system. The private key never leaves the hardware boundary.

But hardware binding shifts the attack surface; it does not eliminate it. ROCA and TPMBleed demonstrated extractable RSA keys from specific TPM implementations. HSM PKCS#11 interfaces have been exploited for authenticated brute-force in certain configurations. Cold-boot extraction can recover key material from systems that did not properly clear memory.

Hardware-rooted identity is a necessary condition for a defensible device trust model under AI-assisted attack. It is not a sufficient condition. Scoped credentials, anomalous behavior monitoring, short-lived certificate lifetimes, and revocation infrastructure are all required to complete the picture.

What hardware binding categorically prevents is the Vercel breach pattern: an attacker who finds a code signing key stored as plaintext in an environment variable cannot use it if the key was never there.

What Needs to Change

“Allow All” is no longer a configuration choice. It is a liability.

The Vercel breach is not a story about a hack. It is a story about a trust model — delegation-based, configuration-dependent, scope-unlimited, rotation-free — that worked exactly as designed while attackers used it for nearly two years.

The AI-assisted attacker toolkit is not creating new attack surfaces. It is compressing the time between “configuration choice made” and “configuration exploited.” The 22-month dwell time will become 12 months. Then 6. The detection gap that felt acceptable in a world of manual reconnaissance becomes catastrophic when the adversary’s scope mapping runs at LLM inference speed.

The architectural response is not novel. Hardware-rooted identity. Sender-constrained tokens. Scoped delegation. Continuous behavioral monitoring. Short-lived credentials with revocation infrastructure. These have been in the standards for years.

The question is whether the industry deploys them at regulatory mandate speed or at breach consequence speed. CRA is betting on mandate speed for device OEMs. The Vercel breach suggests cloud platforms will keep relearning the lesson at breach speed until the regulatory environment forces the same discipline.

Tim McAllister is Regional Field CTO at DigiCert, leading customer-facing technical strategy for device trust, PKI, and post-quantum cryptography. He participates in NIST, SAE EVPKI, Matter, and CharIN standards bodies. Views are his own.

Key Sources