Security Dashboard

The Security Dashboard aggregates the security posture of every account and project on your team into a single view. It runs a set of security checks against your team's members, tokens, projects, deployments, and environment variables, then flags the checks that fail and explains how to fix them.

As your team grows and coding agents make it faster to spin up projects, small oversights accumulate such as:

a member without two-factor authentication
a preview deployment left publicly reachable
a long-lived credential used where a short-lived one would do

The Security Dashboard surfaces these gaps in one place so you can address them before they turn into incidents.

How to Access the Security Dashboard

You reach the Security Dashboard from your team settings:

From your team, go to Settings, then open the Security & Privacy tab.
In the Security Dashboard card, review the score summary, then select Visit to open the full dashboard.

The Security & Privacy tab is the main entry point. Its card shows the same score bar as the dashboard, so you can see your team's posture at a glance without leaving settings.

How the Security Dashboard Works

The Security Dashboard runs a fixed catalog of security checks against your team. Each check inspects one type of misconfiguration and reports the entities that violate it, called findings. For example, the members-no-mfa check reports each team member who can sign in without a second factor.

Every check has a risk level that determines how it affects your score:

Risk level	Effect on the dashboard
High	Counts toward your score. Shown first, with a red segment in the progress bar.
Medium	Counts toward your score. Shown with an amber segment in the progress bar.

The dashboard groups checks into two categories: Account and authentication and Projects, deployments, and environment variables, and orders them by risk level so the highest-priority work is at the top.

Your Security Score

At the top of the dashboard, a progress bar summarizes how many checks pass and how many still need attention. The headline reads like 2 high and 1 medium issues remaining, or All recommended protections in place when every check passes.

The bar has three segments:

Red: high-risk checks with findings.
Amber: medium-risk checks with findings.
Blue: checks that pass or have every finding muted.

Account and Authentication Checks

These checks cover your team's members and access tokens.

Check	Risk	What it checks	How to resolve
Team members without multi-factor authentication	High	Members who can sign in without a second factor, so a stolen password alone can take over the account.	Enforce two-factor authentication for the team so every member needs a second factor.
Team owners to review	High	Fires when more than 30% of your team are owners. Extra owners widen the blast radius of a compromised account.	Review member roles and demote owners who don't need full access.
Personal access tokens that never expire	High	Personal access tokens with no expiration, which stay valid until someone revokes them manually.	Recreate the token with an expiration from account tokens.

Projects, Deployments, and Environment Variables Checks

These checks cover your team's projects, their deployment settings, and their environment variables.

Check	Risk	What it checks	How to resolve
Long-lived credentials where OIDC is available	High	Static credentials stored as environment variables where a short-lived token would work instead.	Replace the static credential with OIDC federation so your app exchanges a short-lived token at runtime.
Projects without Git fork deploy prevention	High	Projects where forked pull requests can deploy and read your environment variables without review.	Turn on Git fork protection in the project's security settings.
Projects without preview deployment protection	High	Preview deployments that anyone with the URL can reach.	Enable deployment protection so only authorized users can open preview URLs.
Environment variables not marked Sensitive	Medium	Values that can be read back from the dashboard or API after they are written.	Mark the variable as Sensitive so new values can't be read back once saved. Because the existing value was readable, rotate it when you make the change.
Environment variables older than 90 days	Medium	Variables that have not been rotated in over 90 days.	Rotate the secret, or delete the variable if it's no longer needed.
Environment variables exposed via a web application framework	Medium	Variables a web application framework exposes to the client, which increases the risk of a leak.	Review your framework environment variables and keep secrets server-only.

Card States

The dashboard shows each check as a card. Its badge and icon reflect the check's current state:

What the card shows	Meaning
A `High` or `Medium` risk badge	The check has findings and counts against your score. High-risk checks show a red badge, medium-risk an amber one.
A blue check-circle	The check passes with no findings.
A blue check-circle with a `Check muted` badge	The whole check is muted and excluded from your score.
An `N muted` badge next to the risk badge or check-circle	Some of the check's findings are muted and excluded from your score.
A `Data Unavailable` overlay	The check couldn't be computed. When your role lacks permission to read the data, the overlay reads `Insufficient Permissions`.

Act on Findings

Each check appears as a card with its title, a short explanation of the risk, the number of findings, and the affected entities. Select an entity to jump to the setting where you can fix it, such as a member's row in your team settings or a project's deployment protection settings.

Cards also include actions that take you to the relevant settings, such as Enforce 2FA for the multi-factor authentication check or Deployment Protection Settings for preview protection. Once you resolve the underlying setting, the check shows as passing, with a blue check-circle, the next time the dashboard refreshes its checks.

Mute a Check or Finding

Mute a check to hide its current and future findings, or mute a single finding to dismiss one entity while keeping the rest of the check active. Use muting for findings you have reviewed and accepted, so they stop counting against your score without hiding new issues elsewhere.

Muted checks and findings are excluded from your score and listed separately, so your headline reflects only the work that remains.
You can add a reason when you mute, which is recorded alongside who muted it and when.
Muting requires permission to manage your team. Members without that permission can view checks but cannot mute them.

To reverse a mute, select the bell icon on the check again to unmute it, or unmute an individual finding from its row.

Export Findings to CSV

Export findings to a CSV file to share them or track them outside Vercel. Use the Export CSV button in the dashboard header to export every check, or export a single check from its card.

The CSV has four columns:

Column	Description
Exported At	The timestamp of the export.
Check	The name of the check.
Finding	The affected entity. Grouped findings appear as `group / finding`.
Muted	`Yes` if the finding is muted, otherwise `No`.

Run Checks from the CLI

The vercel security command runs the same checks as the Security Dashboard in your terminal. Use it to review your posture without leaving the command line, or to pipe the report into scripts and coding agents:

the terminal

# Run every check for the current team
vercel security

# List the individual findings behind each check
vercel security check --findings

# Scope the report to a single project
vercel security check --project my-app

The command outputs JSON in non-interactive environments, so you can run it in CI. A failing check still exits 0, so gate a CI step on the report contents rather than the exit code. Because the report lists security findings, treat its output as sensitive and avoid writing it to shared or public logs. See the vercel security reference for the full list of options.

Who Can Access the Security Dashboard

Access to the Security Dashboard depends on your team role. Some checks read data that requires elevated permissions: when your role can't read the data behind a check, its card shows a Data Unavailable overlay labeled Insufficient Permissions, and the vercel security command reports the check as no access. Muting checks and findings requires permission to manage your team. For an overview of team roles and what each can do, see access roles.