Beyond the News
Sign in
Web DevelopmentCloud & InfrastructureCloud PlatformsDeployment & DevOpsDeveloper Tools Active dossier

Vercel KMS lets Functions sign tokens without holding private keys

Vercel Functions can now sign JWTs and arbitrary messages through managed asymmetric keys, keeping private keys out of application code and environment variables while preserving standard OIDC/JWKS verification.

Reviewed and published by Lars Jansen Updated 4 min read
First published

Key details

  1. Vercel announced KMS on August 18, 2026 and describes it as Public Beta.
  2. KMS supports RSA, ECDSA and EdDSA asymmetric signing keys.
  3. Vercel Functions authenticate to KMS using their Vercel OIDC token; the private key remains in the managed service.
  4. The `@vercel/kms` package can sign JWTs with custom claims and TTLs or sign raw bytes.
  5. Projects can receive signing grants per production, preview, development or custom environment.
  6. Grant policy can constrain requested claims and validate them against JSON Schema.
  7. Each issuer publishes OIDC discovery metadata and a JWKS endpoint for standards-based verification.

What builders should take away

  1. If you currently store JWT private keys in Vercel environment variables, evaluate KMS first for issuers whose signing path already runs inside Vercel Functions.
  2. Use separate grants for production and preview instead of sharing one broad signing permission across environments.
  3. Constrain claims and TTLs at the KMS grant layer so a compromised Function cannot mint arbitrary long-lived or over-privileged tokens even if application checks fail.
  4. Keep downstream verification standards-based via JWKS/OIDC so token consumers remain portable across hosting providers.
  5. Treat Public Beta status as an operational consideration: test key rotation, issuer availability and failure behavior before making KMS a single critical signing dependency.

What changed

On August 18, 2026, Vercel launched KMS in public beta for signing JWTs and arbitrary messages from Vercel Functions. Functions authenticate to the service with their Vercel OIDC token; private asymmetric keys remain inside Vercel KMS. Teams can create and rotate RSA, ECDSA and EdDSA signing keys, grant projects access per environment, constrain allowed JWT claims and expose standards-based OIDC discovery and JWKS endpoints for verification.

Why it matters

Many web apps still place long-lived signing keys in environment variables or application secret stores, which means a code-execution bug, misconfigured deployment or leaked environment snapshot can expose credentials capable of minting trusted tokens. A remote signing service changes that threat model: the workload receives permission to request signatures rather than possession of the private key itself. Per-environment grants and claim constraints also make it possible to reduce what a compromised deployment can sign.

The private key no longer lives with the Function

A Vercel Function uses its workload OIDC token to authenticate to KMS and requests a signature through the `@vercel/kms` package. Vercel says the private key never leaves KMS. The service supports JWT signing with configurable TTL and custom claims as well as signing arbitrary bytes.

Grants can limit where and what a project signs

KMS grants can be scoped by project environment, including production, preview, development and custom environments. Vercel also lets teams constrain which claims a project may request and validate token claims against JSON Schema. That creates a narrower authorization boundary than simply placing a reusable signing key in every environment that needs to mint tokens.

Verification remains portable

Each issuer exposes an OpenID Connect discovery document and JWKS endpoint under `kms.vercel.com`, so downstream services can verify tokens with standard OIDC or JOSE libraries rather than Vercel-specific verification code. This is important for architectures where Vercel issues credentials consumed by APIs running elsewhere.

What to watch next

  • Vercel KMS pricing and whether usage limits or plan restrictions change after beta.
  • Availability guarantees, auditability and key-management controls as KMS moves toward general availability.
  • Whether Vercel adds external key import, customer-managed HSM options or richer signing-policy primitives.

Still unclear

  • The launch announcement establishes functionality but does not yet provide the long-term pricing model, production SLA or independent security assessment details for KMS.

Sources

Direct reading behind this dossier.

1 sources
Continue reading
Artificial Intelligence

Railway Cloud Agents turn coding agents into persistent deployment-adjacent VMs

Railway Cloud Agents are managed, persistent development machines rather than a new model or harness. They reuse developers’ existing agent credentials, sleep when disconnected by default, retain disk state, and live inside Railway project environments—blurring the boundary between remote coding workspace and deployment platform.

Web Development

Vercel KMS lets Functions sign JWTs without holding private keys

Vercel KMS gives Functions OIDC-authenticated access to managed RSA, ECDSA and EdDSA signing keys. Builders can scope grants by project and environment, constrain JWT claims with JSON Schema, rotate keys centrally and publish standard OIDC/JWKS metadata for verification outside Vercel.