On 22 October 2026 Vercel published "Death to long-lived static credentials". Most posts like this argue that API keys are risky and stop there. This one sets dates.
The two dates, and who they apply to
The deadlines are for vendors listed on the Vercel Marketplace, the catalogue of third-party databases, content management systems, observability tools and other services that developers connect to their Vercel projects. In Vercel's words:
"By November 30, 2026, vendors who do not support OIDC auth from Vercel to their services and use long-lived secrets for authentication will have a similar 'Not secure' message on their listing. By January 2027, vendors who do not offer secure auth will be delisted."
The "similar" refers to Chrome, which labelled plain HTTP pages "Not secure" before it set its own deadlines. Vercel also says: "We are holding the Vercel API and our own native integrations to the same bar."
If you sell a service through the Marketplace, those are your dates. If you build on Vercel and use Marketplace integrations, you may see that label on some of them. If you do neither, nothing changes for you on 30 November. But the question Vercel is asking still applies to you.
What's wrong with a long-lived key
Vercel defines long-lived static credentials as "secrets such as API keys and database passwords that applications keep reusing, often with no expiration." The problem is what happens once one gets out. Those credentials "can leak into a code repository or chat, be stolen when a service or dependency is compromised, or be exposed when prompt injection leads an agent to reveal them." Until the key expires or is revoked, whoever holds a copy has all of its permissions.
Cleaning up is expensive, and Vercel is candid about it: "At Vercel, we've previously spent thousands of engineering hours on multiple, very painful key rotations out of an abundance of caution, and we never want to have to do this again." That matches what we described in our post on LiteLLM's compromised release, where a large part of the clean-up was rotating every key and secret the affected hosts could reach.
What replaces it
The alternative Vercel is pushing is OIDC: "A trusted issuer provides a signed, short-lived token identifying the application, and the receiving service verifies that token before deciding what access to grant." And a stolen token, Vercel adds, "stops working when it expires". Instead of a key that lives in an environment variable for years, the application asks for a fresh, short-lived credential when it needs one.
Alongside the deadlines, Vercel announced OIDC UI, a component registry that gives service providers trust-policy forms and token-verification code, and Vercel Connect, which lets applications and agents request provider tokens at runtime without storing long-lived secrets in environment variables.
Why most teams still use keys
Vercel says it surveyed more than 1,000 SaaS vendors and found that "only 8.4% supported secure authentication methods." The post doesn't publish the survey's method or define "secure authentication methods" precisely, so treat that as Vercel's figure rather than an industry rate. The broader point holds either way: for many services, a key is the only option on offer.
And even where a better option exists, Vercel notes that "developers often choose a static key because it can be simpler to use." It names three barriers: setup and tooling that make secure authentication more complicated than a key, extra latency from fetching or exchanging tokens on the request path, and weak incentives for vendors to offer it. That is Vercel's case for a deadline. As it puts it, HTTPS everywhere "did not win on ergonomics alone."
What to do this week: an inventory
The useful action for most teams is not to adopt OIDC everywhere by Friday. It's to find out what you're holding.
- Which long-lived keys exist across your projects? Check environment variables, CI settings, deployment platforms and any shared password store. Old projects count too: a key created years ago for a project nobody touches may still work.
- What can each one reach? A key scoped to one bucket and a key with full account access are very different risks, even if they look the same in an env file.
- When was each one last rotated, and who would do it? If nobody knows, a leak becomes a scramble.
- Which of your vendors offers something better? Short-lived tokens, OIDC federation or scoped credentials. Where a vendor doesn't, that's worth knowing too, and worth asking them about.
That list doesn't require changing anything yet, it doesn't depend on which platform you host on, and it turns "we should really sort out our keys" into a short list of specific ones to sort out first.
Source: Vercel, "Death to long-lived static credentials" (published 22 October 2026, read 23 October 2026).