--- title: Choose between Vercel Passport and other Deployment Protection methods description: Compare Vercel Passport with Vercel Authentication, Password Protection, and Trusted IPs to choose the right Deployment Protection method. url: "https://vercel.com/kb/guide/vercel-passport-vs-deployment-protection" published: 2026-10-14 last_updated: 2026-10-14 authors: Ben Sabic install_vercel_plugin: npx plugins add vercel/vercel-plugin --- Vercel Deployment Protection offers four methods for controlling who can open your deployments: Vercel Authentication, Vercel Passport, Password Protection, and Trusted IPs. The right method depends on who your visitors are, how they already sign in, and which plan your team is on. Passport is for teams whose visitors already have accounts in a company identity provider such as Okta or Microsoft Entra ID, while the other methods are for Vercel collaborators, small groups of reviewers, or visitors on a trusted network. In this guide, you'll learn: - How Deployment Protection separates the method from the scope - How Passport compares with the three other protection methods - When Passport is the right choice and when another method fits better - Which setup to use for four common scenarios ## How Deployment Protection decides who can open a deployment Deployment Protection combines two settings that you configure at the project level. The protection method decides who gets in, and the protection scope decides which URLs the method protects. Each of the four methods checks something different about a visitor. Vercel Authentication checks for a Vercel account, Vercel Passport for sign-in via your identity provider, Password Protection for a shared password, and Trusted IPs for allowlisted IP addresses. You choose a scope based on which URLs need protection. Standard Protection covers every deployment except your production domains, and All Deployments covers production too. Deployment Protection requires authentication for all requests to a protected URL, including requests to Routing Middleware, so a protected deployment stays protected regardless of how your app handles routing. ## Which Deployment Protection method fits your visitors Start with who needs to open the deployment. Each type of visitor maps to one method: | Your visitors | Method | | ---------------------------------------------------------------------- | --------------------- | | Members of your Vercel team or project | Vercel Authentication | | Employees or contractors with accounts in your identity provider | Vercel Passport | | Small groups of reviewers without Vercel or identity provider accounts | Password Protection | | Anyone connecting from your corporate network, VPN, or proxy | Trusted IPs | If your visitors are employees who sign in to other company tools through Okta, Microsoft Entra ID, or another OpenID Connect provider, Passport is usually the closest fit. These visitors don't need Vercel accounts, and they sign in with the credentials they already use every day. ## How Passport compares with the other methods The four methods differ in what a visitor needs, how you manage individual access, and whether your application learns who the visitor is: | Method | Visitors need | Per-person access | Identity for your app | | --------------------- | ------------------------- | ------------------------------ | --------------------- | | Vercel Authentication | Vercel account | Yes, through Vercel team roles | No | | Vercel Passport | Identity provider account | Yes, in your identity provider | Yes | | Password Protection | Shared password | No | No | | Trusted IPs | Allowlisted IP address | No | No | Plan availability and pricing also differ: | Vercel Authentication | All plans | Included | | --------------------- | --------------- | -------------------------------------------------------- | | Vercel Passport | Enterprise | Contact your Vercel account team | | Password Protection | Pro, Enterprise | $20 per month per project on Pro, included on Enterprise | | Trusted IPs | Enterprise | Included | Passport is the only method that gives your application code a verified identity. After a visitor signs in, the `@vercel/passport` SDK returns a stable visitor ID, the visitor's email and name when your identity provider returns them, and allowlisted claims such as `groups`. Your app can use that identity to personalize pages, restrict sensitive routes by group, and record who performed each action. The [Next.js](https://vercel.com/kb/guide/vercel-passport-nextjs) and [Nuxt](https://vercel.com/kb/guide/vercel-passport-nuxt) guides show how to use the SDK for different use-cases. ### How Passport differs from Vercel Authentication Vercel Authentication and Passport both require visitors to sign in, but they use different account systems. Vercel Authentication accepts Vercel users, while Passport accepts anyone your identity provider authenticates for the connected application. Choose Vercel Authentication when your visitors already work in Vercel, such as developers, designers, and reviewers. It lets in: - Team members with at least the Viewer role - Project members - Members of an access group with access to the project - Vercel users you approve through access requests You can also share individual deployments with people outside your team through Shareable Links. Choose Passport when your visitors live in your identity provider rather than in Vercel. Passport gives you: - **Central access management:** Access follows your identity provider assignments, so onboarding and offboarding happen where your IT team already manages them. - **Oversight for employee-built apps:** These apps often start without company review and are a common source of [shadow AI](https://vercel.com/i/what-is-shadow-ai). - **Sign-in records:** Each successful sign-in creates a `passport-access-granted` event in the Activity Log and Audit Logs, recording the visitor, hostname, and project. Only team Owners can manage Passport. Owners can set a team default so new projects inherit the same identity provider connection, or assign one Connect application to many existing projects at once. ### How Passport differs from Password Protection Password Protection gates a deployment behind a single shared password. It works for visitors who have no account anywhere, which makes it useful for short reviews with people outside your organization. Shared passwords don't identify anyone. Everyone who has the password gets the same access, and removing one person's access means changing the password for everyone. Passport ties access to individual identity provider accounts instead, so removing a person in your identity provider removes their access without affecting anyone else. Password Protection is available on Pro for $20 per month per protected project and is included at the team level on Enterprise. It isn't available on Hobby. ### How Passport differs from Trusted IPs Trusted IPs restricts access by network location rather than by person. Requests from allowlisted IPv4 addresses and CIDR ranges get through, and requests from other IP addresses receive a 404. This fits apps that should only be reachable through a corporate VPN or an external proxy. Many people can connect from the same allowlisted network, and your app can't tell them apart. If you need to know which person is using the app, or need to grant access to people regardless of where they connect from, use Passport. Trusted IPs is also the only method that can protect production deployments alone, without protecting previews. Both Trusted IPs and Passport require an Enterprise plan. ## When Passport isn't the right choice Passport protects every path on a protected URL, which makes it a good fit for internal apps and a poor fit in these cases: - Your team isn't on an Enterprise plan: Use Vercel Authentication on any plan, or Password Protection on Pro. - Your visitors aren't in your identity provider: Clients, agencies, and other outside reviewers usually don't have accounts in your identity provider. Use Vercel Authentication with Shareable Links, or Password Protection. - Anonymous visitors need to reach some pages: Public marketing sites and customer sign-up flows can't sit behind Passport, because Passport sends every visitor without a session to your identity provider. Keep public pages unprotected and use your app's own authentication for customer accounts. - You only need to keep previews private: If your visitors are already on your Vercel team, Vercel Authentication with Standard Protection covers previews on every plan. ## Which URLs to protect with Deployment Protection After choosing a method, choose a protection scope: | Scope | What it protects | Availability | | --------------------------- | -------------------------------------------------------------------- | ------------ | | Standard Protection | All deployments except production domains | All plans | | All Deployments | All URLs, including production domains and generated deployment URLs | All plans | | Only Production Deployments | Production URLs only, through Trusted IPs | Enterprise | Standard Protection is the recommended scope for most projects, because it keeps previews and generated URLs private while your production domain stays public. Use All Deployments for internal apps where the production domain must also stay private, which is the usual scope for a Passport-protected app. When you enable Standard Protection, the production generated deployment URL becomes restricted. Update any server-side `fetch` calls that use `VERCEL_URL` or `VERCEL_BRANCH_URL` to target the domain the visitor requested instead. ## Recommended setups for common scenarios These scenarios show how the method and scope work together for typical projects. ### Protect a company-wide internal tool Employees across the company need to open an internal dashboard, and most of them don't have Vercel accounts. Everyone signs in to company tools through Okta. Use Vercel Passport with All Deployments. Employees sign in with their Okta credentials, the production domain stays private, and the app can read each visitor's identity to show their own records. To limit admin pages to a specific team, request the `groups` claim and check group membership in your server-side code. Passport decides who can open the app, but your code still decides what each person can do inside it. Keeping those two checks separate is central to how you [govern employee-built AI apps and agents](https://vercel.com/i/govern-employee-built-ai-apps-and-agents). ### Share previews with an agency's clients Agencies often share preview deployments with client stakeholders who don't have Vercel accounts or access to the agency's identity provider. Use Vercel Authentication with Standard Protection, and send clients a Shareable Link for each deployment they need to review. For a client who needs repeated access across many deployments, Password Protection on Pro or Enterprise saves you from sending a new link for each one. ### Keep previews private for a public website Marketing sites usually need to stay public in production, while preview deployments should only be visible to the team building the site. Use Vercel Authentication with Standard Protection. Previews and generated URLs require a Vercel sign-in, and the production domain stays open to everyone. This setup works on every plan. ### Keep an app on the corporate network Your compliance team requires that an internal app only be reachable from the corporate VPN. Use Trusted IPs with the VPN's egress IP addresses or CIDR ranges. Requests from outside the network receive a 404. If the app also needs to know which employee is signed in, use Passport, which identifies each person no matter where they connect from. ## How to let automation through a protected deployment Protected deployments block automated requests that can't sign in, such as webhooks, Cron Jobs, and end-to-end tests. Vercel provides bypass methods for these cases: - **Protection Bypass for Automation**: Lets automated workflows through when they send a predefined secret as an HTTP header or query parameter. For Passport-protected deployments, send the secret with the original request, because Passport runs before your deployment's routes and middleware. - **Shareable Links**: Let anyone with a specific link open a deployment protected by Vercel Authentication, which is useful for collaborators outside your Vercel team. - `OPTIONS` **Allowlist**: Lets CORS preflight `OPTIONS` requests through, so cross-origin requests from allowed paths don't fail before they reach your app. - **Deployment Protection Exceptions**: Make specified pre-production domains publicly accessible. ## Next steps - Compare every option in [Methods to protect deployments](https://vercel.com/docs/deployment-protection/methods-to-protect-deployments). - Set up Passport with [Set up Passport with an identity provider](https://vercel.com/docs/passport/set-up-identity-provider). - Read visitor identity in your app with [Identify users and control access in Next.js with Vercel Passport](https://vercel.com/kb/guide/vercel-passport-nextjs) or [Personalize and lock down a Nuxt app with Vercel Passport](https://vercel.com/kb/guide/vercel-passport-nuxt). - Learn how [Vercel Authentication](https://vercel.com/docs/deployment-protection/methods-to-protect-deployments/vercel-authentication), [Password Protection](https://vercel.com/docs/deployment-protection/methods-to-protect-deployments/password-protection), and [Trusted IPs](https://vercel.com/docs/deployment-protection/methods-to-protect-deployments/trusted-ips) work. - Review plan availability in [Usage and pricing for Deployment Protection](https://vercel.com/docs/deployment-protection/usage-and-pricing). - Configure exceptions with [Methods to bypass Deployment Protection](https://vercel.com/docs/deployment-protection/methods-to-bypass-deployment-protection). ## Frequently asked questions ### What's the difference between Vercel Passport and Vercel Authentication? Vercel Authentication lets in Vercel users with access to your team or project. Vercel Passport lets in visitors who sign in through your own identity provider, such as Okta or Microsoft Entra ID, so they don't need Vercel accounts. Passport also gives your application a verified visitor identity through the `@vercel/passport` SDK. ### Is Vercel Passport available on the Pro plan? No. Vercel Passport requires an Enterprise plan. On Pro, you can use Vercel Authentication, which is included on every plan, or Password Protection for $20 per month per protected project. ### Which Deployment Protection method tells my app who the visitor is? Vercel Passport is the only method that gives your application code a verified identity. Use `getIdentity()` from the `@vercel/passport` SDK in server-side code to read the visitor's stable ID, email, name, and allowlisted claims such as `groups`. ### Can I protect only my production deployment? Yes, on an Enterprise plan with Trusted IPs. Trusted IPs is the only method that can protect production URLs without protecting previews. The other methods use Standard Protection or All Deployments as their scope. ### Do webhooks and Cron Jobs work with a Passport-protected deployment? Yes, if each request includes a Protection Bypass for Automation secret. Passport sends any request without a session to your identity provider, so the secret must be part of the original request rather than added later in your app's routing or middleware.