Vercel sets deadlines for vendors: static keys must go by 2027

Vercel is trying to do for API keys what Google and Let's Encrypt did for web traffic encryption. The company surveyed more than 1000 SaaS vendors and found that only 8.4% support secure service-to-service authentication. The rest still hand out database passwords and API keys with no expiration date. To move the market, Vercel is introducing hard deadlines for its Marketplace partners: from November 30, 2026, vendors that do not support Vercel's OIDC authentication and rely on long-lived secrets will get a "Not secure" label in their listing. From January 2027, such providers will be removed from the catalog.

Why static keys are a problem right now

A long-lived static secret is an API key or password that an application uses over and over, often with no expiration. Such a key can leak into a repository or a chat, or be stolen through a compromised dependency. Now there is another route: prompt injection, which tricks an agent into handing over its own credentials. Agents, meanwhile, get access to systems and data through keys whose permissions are often broader than a given task requires.

Encrypting secrets at rest does not help here: malicious code in production reads environment variables the same way the application itself does. Until a key expires or is revoked, anyone can use it. And rotation is expensive. According to Vercel, the team has already carried out several painful precautionary rotations and spent thousands of engineering hours on them. The company does not want to repeat that.

What Vercel offers instead of keys

The alternative has been known for a long time: OIDC. A trusted issuer hands out a signed, short-lived token that identifies the application, and the receiving service verifies it and decides what access to grant. A stolen token stops working once it expires. The application obtains new tokens programmatically, so there is no need to distribute a permanent key or change it by hand.

OIDC federation has been available on Vercel since 2024: applications exchange platform tokens for temporary AWS, Google Cloud and Azure credentials, according to trust policies configured for the project and environment. Now the company is extending the approach to its own Blob, AI Gateway and Sandbox services, as well as to the Vercel API and CLI, to remove long-lived tokens from deployment workflows.

The new tools:

• OIDC UI — a shadcn/ui component registry with a trust-policy configurator and a server-side token verifier. It includes ready-made forms for Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure and custom OIDC issuers.
• Vercel Connect — applications and agents request provider tokens at runtime based on the deployment's identity. In code, this is a single getToken call that specifies the user and scopes, for example for access to Linear.
• Custom audience — a token is bound to a single recipient service.
• Azure example — ClientAssertionCredential exchanges a Vercel token for access to Cosmos DB without a database key.

Latency and incentives

Vercel acknowledges that a static key has one advantage: it is already sitting in an environment variable, and no network request is needed. Obtaining and exchanging tokens adds latency. That is why Vercel functions receive the platform token in a request header, and the SDK reads it without an extra call. The platform reuses unexpired tokens, while Vercel Connect caches provider tokens in-process and refreshes them closer to expiry. Network calls remain only for custom audience and for exchanges for provider tokens.

Beyond convenience and speed, Vercel names a third obstacle: vendors have little incentive to do this work. This is where the Chrome example comes in: Chrome first labeled HTTP "Not secure," then set deadlines. Vercel intends to follow the same path and promises the same requirements for its own API and native integrations. The company also wants Marketplace integrations to set up secure authentication automatically when a service is connected, without a separate step.

What developers and providers should do

If you build a product for Vercel customers, you need to decide before November 30 whether you will accept OIDC tokens directly or exchange them for temporary credentials. The OIDC UI components mean you do not have to write either the trust-configuration form or the token verification from scratch. If you simply use services through the Marketplace, it makes sense to check in advance which connected providers you hold permanent keys for in environment variables, and to draw up a plan to replace them.

For agent applications, a logical starting point is Vercel Connect: a token scoped to a specific user and specific scopes limits the damage from prompt injection. After migration, old keys should be revoked, not just left unused.