Vercel KMS puts JWT signing behind managed keys: adopt the signer, not the platform
Vercel KMS beta gives Vercel Functions managed asymmetric keys, scoped grants, and public JWKS; test it for token issuance while keeping a whole-stack migration off the table.
Decision: test Vercel KMS now if a Vercel Function issues JSON Web Tokens (JWTs) to another service. The beta moves private signing keys out of code and environment variables, while the rest of your stack can stay where it is. 1
The quick read
| Signal | What changed | Who should care | Action window | Main constraint |
|---|---|---|---|---|
| New security primitive | Vercel KMS lets Vercel Functions sign JWTs and arbitrary messages with Vercel-managed asymmetric keys. | Teams that currently store signing keys in deployment variables or application secrets. | Test now in one preview environment. | The service is in beta, and signing requests run through Vercel. 1 |
| Scoped access | A project can receive signing access per environment, with claim constraints and JSON Schema validation. | Platform teams separating production, preview, development, and custom environments. | Adopt for a bounded issuer after mapping callers. | Vercel recommends a separate issuer for each project and environment. 2 |
| Portable verification | Each issuer publishes public keys through JWKS and OpenID Connect discovery. | Services that verify tokens outside Vercel. | Plan the verifier first, then issue a test token. | Symmetric HS* keys are outside the documented KMS model. 2 |
| Availability | KMS is in beta and available on all plans; the changelog calls for Vercel CLI 59.1.0 or later. | Teams that want to try the primitive without a plan upgrade. | Watch beta behavior before making it a universal identity dependency. | Beta features can change before general availability. 1 |
Vercel published the KMS update on August 18, 2026. The date appears in Vercel's official Atom feed, while the changelog page supplies the implementation details. 3
What Vercel KMS changes
A Vercel Function can call the
@vercel/kms package to sign a JWT or raw bytes. The deployment's Vercel OIDC token authorizes the signing request. The private key remains inside Vercel KMS. 1The receiving service verifies the signature with a public JWKS. The verifier fetches public keys from the issuer and selects the correct key through the JWT
kid header. Verification therefore works with standard JOSE or OpenID Connect libraries, without a Vercel-specific verifier. 2The model has four useful boundaries:
- Issuer: a stable signing identity owned by your team.
- Grant: permission for a project and selected environments to sign.
- Claims: the subject, scope, audience, and other fields that the token carries.
- Verifier: any service that trusts the issuer's public keys and checks the token's claims.
Vercel KMS supports RSA, ECDSA, and EdDSA signing families. The docs also describe key rotation with a grace period, so older tokens can remain verifiable while clients learn about a new active key. 2
The change removes one recurring deployment risk: a private signing key copied across local files, CI variables, preview settings, and production settings. The change also gives each environment a place to own its issuer instead of sharing one key across the deployment lifecycle.
The operational boundary
Vercel KMS handles proof of origin. A service can verify that a trusted issuer signed a token. Your application still owns authorization: tenant access, roles, resource permissions, token audience, and the actions each scope permits.
That distinction matters during migration. Replacing an environment variable with
signToken() improves key custody. The replacement does not define whether scope: write:billing is safe for a particular user or service.The issuer layout deserves the same care as the claims. Create separate issuers for production, preview, and development. A preview issuer can then be trusted by test services without giving preview deployments a production signing identity. Vercel recommends this project-and-environment separation to limit the blast radius of rotation or revocation. 2
A second boundary is provider location. A Vercel Function signs through Vercel KMS. A worker or service running elsewhere needs network access to the signing path or a different issuer. The public verification side remains broadly portable because relying parties consume standard public-key metadata.
How it compares with the alternatives
| Option | Key and signing boundary | Verification path | Migration consequence |
|---|---|---|---|
| Vercel KMS | Vercel manages asymmetric signing keys. A Vercel Function signs through @vercel/kms, authorized by deployment OIDC. | Vercel publishes issuer metadata and JWKS for standard libraries. | Small change for Vercel-hosted issuers: replace key loading and signing code, then keep the token contract stable. 2 |
| AWS KMS | AWS KMS creates and controls keys used to encrypt and sign data. Applications call AWS KMS for cryptographic operations, with AWS IAM and token-issuer plumbing around it. | Your application or identity service publishes whatever verification metadata its consumers need. | Strong fit for AWS-centered or multi-runtime systems, with more integration work outside the key operation itself. 4 |
| Cloudflare Workers Secrets | Cloudflare stores encrypted text values as Worker bindings. Worker code reads a secret through env, much like an environment variable. | Your application supplies the signing library and distributes the public key or verifier configuration. | Good for storing a token or API secret in a Worker; a Vercel-style issuer and JWKS workflow remains application work. 5 |
The useful comparison is the location of the work. Vercel KMS packages key custody, signing authorization, issuer identity, and public-key discovery around Vercel Functions. AWS KMS supplies the cryptographic key service, while Cloudflare Workers Secrets supplies encrypted runtime values.
Adopt now when the workload looks like this
Vercel KMS deserves a real pilot when all of these conditions are close to true:
- A Vercel Function issues short-lived JWTs to an API, job runner, or internal service.
- The current private key lives in environment variables, CI configuration, or a secrets store that the Function reads directly.
- External services can verify standard JWT signatures through a public JWKS.
- Production and preview can use separate issuer IDs and audiences.
- Your team can accept a beta dependency for the first rollout.
The payoff is operational. A rotation changes the issuer's active key rather than forcing a private key through every deployment surface. A grant can limit signing to one project and environment. A verifier can keep using standard JOSE tooling.
Watch before making it universal
Keep the rollout narrow when the requirements point elsewhere:
- A workload requires symmetric
HS*signing. - Compliance rules require private-key custody outside the hosting provider.
- The same issuer must sign from active runtimes across several clouds.
- A non-Vercel runtime must issue tokens during a Vercel outage or deployment pause.
- Your identity contract depends on behavior that the beta documentation may still change.
Those cases call for a design review rather than a provider-wide migration. Vercel KMS can still serve one Vercel-hosted issuer, while a separate system remains authoritative for the shared identity contract.
A low-risk rollout
- Inventory the current signing path. List every issuer, private-key location, token audience, signing algorithm, caller, and verifier.
- Create a preview issuer. Use a distinct issuer for one project and the preview environment. Keep its audience separate from production.
- Grant the smallest signing scope. Allow only the chosen project and environment to sign. Constrain claims where the grant supports that policy. 1
- Verify outside Vercel. Fetch the issuer's JWKS from the service that consumes the token. Check signature, issuer, audience, expiry, and required scopes.
- Exercise rotation and failure paths. Test a key change, a stale JWKS cache, an expired token, a revoked issuer, and a denied signing request before production traffic depends on KMS.
- Promote one production path. Keep the existing issuer available as a rollback path until every machine caller has passed the new verification checks.
Verdict: adopt the signer, watch the platform dependency
Vercel KMS is worth testing now for Vercel Functions that issue asymmetric JWTs. It removes private-key handling from application deployments, scopes signing by project and environment, and gives external verifiers a standard public-key discovery path. 1
The migration is local. Move the signing boundary first, keep the token contract stable, and leave the rest of the hosting stack in place. Watch beta behavior and provider dependency before making Vercel KMS the issuer for a multi-cloud identity system.
References
- 1
- 2
- 3Vercel official Atom feed
vercel.com
- 4AWS Key Management Service
docs.aws.amazon.com
- 5Secrets · Cloudflare Workers docs
developers.cloudflare.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.