Is Vercel Safe? What the Certificates Cover and What They Don't

Vercel’s bulletin of 19 April 2026 confirmed that an attacker had reached its internal systems and pulled customer environment variables out of them. The bulletin defines the exposed set as the variables that decrypt to plaintext, which is exactly what a variable marked Sensitive is not. Sensitive is a per-variable toggle that ships switched off.

Vercel is safe as a platform, and the certifications behind that answer are public and specific enough to check one at a time, which turns out to be worth doing. Where the trouble sits is the half that starts after the deploy. Across the 21 third-party apps in the AxonBuild audit corpus, reviewed in June and July 2026, the Deployment & Operations pillar averaged 37.0 out of 100, third-worst of the twelve pillars scored. The certificate is a statement about Vercel. That 37.0 is a statement about what gets put on it.

Is Vercel safe? Yes at the platform layer, and the risk moves to your build

Vercel is safe at the platform layer, backed by ISO 27001 certification, a SOC 2 Type 2 attestation, and PCI DSS v4.0 attestations of compliance covering both service providers and merchants. Each is an audited claim about how Vercel runs its own systems.

Vercel publishes that list itself, along with a Data Privacy Framework certification, TISAX Assessment Level 2 (the automotive industry’s assessment, which Vercel has completed), and HIPAA support for enterprise customers.

One detail there is worth catching before you paste it into a questionnaire. As of 2026-07-29 the page reads “Yes, Vercel is ISO 27001:2013 certified,” and every ISO 27001:2013 certificate stopped being valid on 31 October 2025, when the three-year transition to the 2022 revision closed. The likeliest explanation is a page nobody has updated, and it carries no last-updated date to tell you how old the claim is. Ask Vercel for the certificate and read the revision printed on it.

What Vercel secures for you, and where the line actually falls

Vercel secures the machine, the network and the edge: TLS certificates issued and renewed for you, AES-256 encryption at rest, automatic DDoS mitigation on all plans, and the physical controls its auditors sign off on. Authentication, authorization, and whatever your build ships to the browser sit on your side of the line, inside no auditor’s scope.

A multi-tenant B2B operations tool I audited, Next.js on Vercel, reached AWS through Vercel’s OIDC federation instead of a long-lived access key. That is the harder half of the setup and it got it right, scoring 91 out of 100 on Secrets & Credentials. None of it decided who could read the customer list, because that decision lived in a cookie the browser was free to edit. The full read on that app, alongside seven others, has the rest of what the code showed, and the Lovable data breach is the same failure with a public write-up attached.

Vercel’s certificate covers the box your app runs in. It says nothing about what you put in the box.

Did the April 2026 Vercel breach expose my environment variables?

The April 2026 Vercel breach exposed environment variables that decrypt to plaintext, for a limited subset of customers. Vercel traced the entry point to a compromised third-party AI tool used by one of its own employees, and the exposed set is defined by that plaintext property rather than by plan tier or region.

Vercel’s bulletin, published 19 April 2026 and updated through the 24th, names the origin: “The incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee.” It scopes the exposure to “a limited subset of customers whose non-sensitive environment variables stored on Vercel (those that decrypt to plaintext) were compromised,” and reports that no npm package Vercel publishes was compromised. The boundary of the breach was a property of the variable.

The control that sets that property is opt-in, one variable at a time. Vercel’s documentation defines Sensitive variables as ones “whose values are non-readable once created,” and converting an existing variable means deleting it and adding it back with the switch on. The option covers Production and Preview only; select Development and the toggle refuses to enable. A team owner can enforce it team-wide from Settings, under Security & Privacy, so every new Production or Preview variable arrives Sensitive. Among Vercel’s recommended actions afterwards was to start using the feature.

The incident is not an argument against Vercel. A supply-chain compromise reached a vendor with real controls, the bulletin went up the same day and kept being updated through the 24th, and the control that would have kept those variables unreadable already existed. It was off, because it ships off.

Vercel security ends at your build: four failures a green deploy misses

Vercel security covers everything up to your build output and nothing inside it. Four failures survive a green deploy: a secret compiled into the browser bundle, a build told to ignore its own errors, an expensive route nobody rate-limits, and errors that nothing records.

Start with the naming convention that carries a security consequence. In Next.js, any variable prefixed NEXT_PUBLIC_ gets inlined into the bundle at build time: the documentation says the value “will be inlined into any JavaScript sent to the browser.”

// app/checkout/page.tsx
'use client';

// The NEXT_PUBLIC_ prefix is the entire mechanism. After next build,
// this literal value sits in the JavaScript every visitor downloads.
const client = createClient(process.env.NEXT_PUBLIC_PAYMENTS_SECRET);

Six of the 21 third-party apps I audited shipped a real secret somewhere, one of them handed to every visitor’s browser. Typing a value into Vercel’s dashboard is not what keeps it on the server; the prefix decides that, at build time. What an environment variable is and where it has to be set is the wider version of the same confusion.

Then there is the build that was told not to check itself.

// next.config.js
module.exports = {
  typescript: { ignoreBuildErrors: true },
  eslint: { ignoreDuringBuilds: true },
};

In one audited project both flags sat on top of a strict: true TypeScript config, so the types were real and the build was simply told not to consult them. At least 17 of the 21 third-party apps had no deploy gate of any kind. Those projects deploy green, and green means the build finished.

The last two belong to other posts. Vercel caps how long a function may run, which says nothing about how many requests arrive, and why Vercel functions time out is its own subject. Quieter still is the route where nothing records the failure, so the first report arrives from a customer, which is most of what sits behind an app that works locally but not in production.

None of the four shows up in a demo or on a deployment dashboard. A Beyond the Demo Audit is a pass that reads every variable, build flag, and route the way an attacker would, with each finding verified against the code rather than pattern-matched.

What Vercel Deployment Protection covers on the Hobby, Pro and Enterprise plans

Vercel Deployment Protection decides who can open a deployment URL, and Vercel Authentication, its default method, is available on every plan including Hobby. Since November 2023 it has been switched on automatically for new projects, at a scope that gates previews and generated URLs while leaving your production domain public.

Preview deployments on a new Vercel project are therefore not public. Vercel turned Deployment Protection on by default for new projects and did not apply the change retroactively, so a project created before November 2023 is the one worth opening the settings for.

Methods and availability from Vercel’s Deployment Protection documentation, last updated 26 June 2026.

Scope is the second setting, and the one people skip. Standard Protection, on every plan, covers all deployments except production domains. All Deployments, on Pro and Enterprise, covers the production domain too. The docs leave that one ambiguous: All Deployments reads as a plain Pro and Enterprise scope in one place and as part of the $150 add-on in another, so confirm the price with Vercel.

What all of it gates is who can open the URL. A stranger stopped at a login screen and a signed-in customer reading another customer’s rows are different problems, and Deployment Protection only touches the first.

Is Vercel safe for production? A ten-minute check on your own project

Vercel is safe for production once you have checked the five things the platform cannot check on your behalf. All five together take about ten minutes, need no security background, and use nothing but your dashboard and a browser window you are not signed into.

The five run identically on Hobby and on Enterprise, and what they turn up is your list for the week. The broader version is whether your AI-built app is ready to launch, where deployment is one pillar of twelve.

Is Vercel or Netlify safer for a vibe-coded app in production?

Vercel and Netlify are equally safe as platforms and hand back the same half of the problem. Both publish audited certifications, both encrypt variables at rest, and neither reads what your build produces, which is where all four of the failures above live.

What differs is where your side of the line sits. On Vercel there is a framework server you did not write, running code you did, which is why the four failures above are mostly about what the build handed that server. On a static Netlify build there is often no server at all, so the bundle becomes the only place a check could live. The pair is meant to be read together, and the other half is is Netlify safe, the same question answered for the other default host. Which host to pick before you have built anything belongs in a deploy-target comparison rather than here.

Common questions about Vercel security

Is Vercel legit?

Yes. Vercel is the company behind Next.js, with published ISO 27001, SOC 2 Type 2, PCI DSS v4.0 and Data Privacy Framework credentials, and a public bulletin process when something goes wrong. Legitimacy is the easy half of this question; the app you deploy is the half that varies.

Is a .vercel.app link safe to open?

Treat it like any link from a stranger. A .vercel.app address tells you where a page is hosted and nothing about who built it, so judge the page rather than the domain. If it redirects you to a Vercel sign-in screen, that is Deployment Protection on a preview build, not a phishing attempt.

Was my data affected by the Vercel breach?

Check whether your variables were marked Sensitive. Vercel’s bulletin scopes the exposure to non-sensitive environment variables, the ones that decrypt to plaintext, for a limited subset of customers. Its recommended actions were to rotate those variables, enable multi-factor authentication, and review account activity logs.

Does Vercel encrypt environment variables?

Yes, all of them at rest, with one distinction that shaped the April 2026 outcome. Ordinary variables decrypt to plaintext for anything holding account access. Variables created with the Sensitive option are non-readable once created, and you cannot convert one in place: delete it and add it again with the switch on. Sensitive covers Production and Preview, never Development.

Is Vercel HIPAA compliant?

Vercel’s security page states that it supports HIPAA compliance for enterprise customers, which makes it a plan-tier and contract question first. Whether protected health information actually leaks depends on which rows your app returns to which signed-in user, and no vendor’s attestation page answers that.

What would change this answer

Two things, and neither is a breach. The first is the ISO revision on that security page: once it reads 27001:2022, the paperwork half of this post is settled. The second is yours. Every variable you add is a fresh decision about a prefix and a Sensitive toggle. The platform answer holds still for years at a time. Your half of it changes on the next deploy.