Vercel is ending support for static API keys, mandating OpenID Connect (OIDC) and short‑lived, identity‑based tokens for most integrations. The change applies to Marketplace vendors, who must comply by January 2027 or face delisting, and a “Not secure” warning will appear on non‑compliant listings after November 30. At the same time, Vercel’s official GitHub Actions deployment guide continues to require a long‑lived VERCEL_TOKEN secret, exposing a mismatch between policy and tooling.
Policy shift and compliance timeline
Vercel’s CTO disclosed a survey of over 1,000 SaaS vendors, finding only 8.4% support the authentication methods the company now deems secure. In response, Vercel is extending OIDC support across its API and CLI, aiming to retire static credentials from deployment workflows. Marketplace partners that do not adopt the new model will see a security warning on their listings by the end of November, and any that remain non‑compliant after the January 2027 deadline risk removal from the marketplace.
Static API keys vs short‑lived tokens
The core of the change is a move from indefinite tokens to credentials that expire automatically. Short‑lived tokens reduce the window of exposure if a secret is leaked, aligning with Vercel’s messaging that stolen keys should behave like “self‑destructing” credentials. However, the company’s own deployment flow for GitHub Actions still instructs users to store a persistent VERCEL_TOKEN in the CI environment, meaning developers must manage two contradictory models simultaneously.
Impact on CI/CD pipelines and agent workloads
Practitioners using Vercel in CI/CD pipelines need to evaluate the following:
- Credential rotation: Existing pipelines that reference
VERCEL_TOKENwill continue to work, but the token will not expire automatically, requiring manual rotation to meet the new security posture. - OIDC integration: Vercel’s OIDC support is available for its API and CLI, but not yet for the GitHub Actions deployment step. Teams must decide whether to wait for future updates or implement a custom OIDC flow outside the provided guide.
- Connect service usage: Vercel Connect can issue scoped, just‑in‑time credentials at runtime, but it still permits static API keys for providers lacking OAuth. Engineers should prefer the runtime‑issued credentials where possible, while recognizing that static keys remain an option.
- Enterprise‑managed authorization: A public beta adds Okta‑backed control over which services Connect can access, offering a way to centralize policy for agents that need external credentials.
Related CloudNinjas coverage: DevOps.
What This Means For Practitioners
Teams should treat the announced deprecation as a prompt to audit all Vercel‑related secrets in their environments. Immediate actions include:
- Identify every CI/CD job that stores
VERCEL_TOKENand document its rotation schedule. - Explore Vercel’s OIDC endpoints for API and CLI usage and prototype a token‑exchange step that can replace the static token in future pipelines.
- Evaluate Connect’s runtime credential feature for workloads that can avoid static keys, especially for agents that interact with external services.
- Monitor Vercel announcements for updates to the GitHub Actions deployment flow, and plan a migration path that aligns with the January 2027 marketplace deadline.
By aligning CI/CD processes with short‑lived authentication, engineers can reduce the risk surface associated with leaked secrets and stay compliant with Vercel’s evolving security requirements.
