Vercel demands OIDC from its partners while its own GitHub Actions pipeline still needs a static token
On October 22, 2026, Vercel declared static credentials dead after surveying more than 1,000 SaaS vendors and finding only 8.4% support OIDC authentication. Two Marketplace deadlines are now set, yet Vercel’s official GitHub Actions deployment guide still requires a long-lived token.
October 22, 2026. Vercel publishes “Death to long-lived static credentials,” signed by CTO Malte Ubl. October 22, 2026, the same day. CEO Guillermo Rauch sums it up on X: it is time to “kill static credentials.” October 23, 2026. Developers notice that Vercel’s official GitHub Actions deployment guide still requires a long-lived VERCEL_TOKEN. The contradiction lands on day one: Vercel is asking its partners to do something it has not finished doing itself.
For a CISO, this is less a lesson in hypocrisy than a lesson in timing: migrating an entire authentication chain to OIDC takes time, and the platform’s biggest vendor has not managed it internally yet.
One number, two deadlines
Ubl’s post rests on a single figure: Vercel surveyed more than 1,000 SaaS vendors and found that only 8.4% supported what the company counts as secure authentication methods — chiefly OIDC and short-lived tokens. The stated parallel with HTTPS Everywhere is central: machine-to-machine authentication today resembles the web of 2010, when encryption was still the exception rather than the default.
The announcement does not stop at observation. It sets two milestones for the Marketplace, which distributes third-party databases, CMSs, and observability tools:
- November 30, 2026: integrations that do not support OIDC from Vercel and still rely on long-lived secrets will carry a “Not secure” label on their listing.
- January 2027: vendors that still offer no secure authentication will be delisted.
Vercel says it is holding its own API and native integrations “to the same bar.” The survey itself, however, is not reproducible: no methodology is published, the surveyed vendors are not named, and the number of partners that must change their systems is not disclosed.
Why Vercel thinks the static token is dead
The underlying argument comes down to three points, all of them sound. First, AI agents are handed more credentials to act on external systems, and a non-expiring token stays usable until it is revoked — even after a leak goes unnoticed. Second, rotating a compromised secret is expensive: Vercel says it has spent “thousands of engineering hours” on painful key rotations it does not want to repeat. Third, the standards already exist: OIDC lets an application obtain a signed, short-lived token without ever storing the provider’s key.
The company also ships concrete building blocks. OIDC UI, a shadcn/ui registry, provides trust-policy forms and a server-side token verifier for GitHub, GitLab, Google, AWS, Azure, and custom issuers. Vercel Connect requests scoped provider tokens at runtime using the deployment identity. And Vercel’s OIDC federation, available since 2024, already exchanges identity tokens for temporary AWS, GCP, or Azure credentials.
The three barriers slowing adoption
The post names three obstacles that explain why, even when a service offers a secure method, developers keep pasting in a static key. The first is tooling: configuring a trust policy and verifying an OIDC token is still more work than pasting a key into an environment variable. The second is latency: fetching or exchanging a token on the request path adds a network round trip that an already-present key avoids. The third is incentive: a SaaS vendor has little reason to prioritize secure authentication if its customers do not ask for it.
Vercel answers each in turn. Vercel Functions receive a platform-issued token in the request header, read without an extra network call; unexpired tokens are reused, and Vercel Connect caches provider tokens in process and refreshes them near expiry. As for incentive, that is precisely the job of the two Marketplace deadlines: turn the “Not secure” label into a commercial cost, exactly as Chrome did for unencrypted HTTP.
The urgency is backed by recent history. In October 2026 alone, the LiteLLM 1.107.0 compromise showed a credential collector could siphon provider keys, cloud identities, and CI/CD secrets the moment Python started, and the Railway breach exposed deployment environment variables. Every such incident turns a long-lived token into an asset that stays usable for weeks. Vercel’s argument — a stolen credential should behave like a self-destructing key — is not marketing posture; it is the direct consequence of those cases.
The hole in the dogfooding
This is where the story cracks. Vercel’s official GitHub Actions deployment guide still instructs developers to authenticate with a VERCEL_TOKEN secret — a long-lived token, exactly the kind of credential the campaign wants eradicated. Developer Yordis Prieto, a senior engineer at Fanatics, captured the irony: Vercel “invented” OIDC federation, yet his CI pipeline still leans on a long-lived access token.
The October 22 post notes that Vercel is “extending OIDC support across the API and CLI” to retire long-lived tokens from deployment workflows. In other words: at launch, that migration was not finished. The GitHub OIDC authentication added for the Container Registry in late September does not remove the VERCEL_TOKEN requirement from the documented GitHub Actions flow either.
The gap is all the more visible because Vercel Connect still accepts static API keys for providers without OAuth: the documentation describes storing those secrets centrally and pulling them at runtime, while the underlying key can remain valid indefinitely.
How to audit your own exposure
The practical question is quick to ask: does your chain still depend on long-lived secrets, and which ones? Three checks are enough for a first audit. First, list the secrets in your CI/CD — deployment tokens, registry keys, provider credentials — and note for each whether it expires. Second, check whether your Marketplace integrations use Vercel OIDC or a static key: that is precisely the criterion that triggers the “Not secure” label on November 30. Third, test the token exchange on a pilot service, if only to measure the added latency before rolling it out.
Verdict
The direction is right and the timetable is aggressive — possibly too aggressive. If you are a vendor listed on the Vercel Marketplace, you have roughly five weeks to implement OIDC or show a “Not secure” label, plus a further window before delisting. Check now whether your connector accepts Vercel OIDC, or plan for temporary token exchange instead of a persistent key.
If you are a Vercel customer on GitHub Actions, you still depend on a VERCEL_TOKEN today: scope it as tightly as you can, store it in repository secrets, rotate it regularly, and watch for the promised OIDC switchover in your workflow. The cross-cutting lesson applies to any platform: a “zero static secrets” campaign only becomes credible on the day its own tooling no longer needs the very secret it is telling everyone else to give up.