Choose between Edgenivo Passport and other Deployment Protection methods

Edgenivo Deployment Protection offers four methods for controlling who can open your deployments: Edgenivo Authentication, Edgenivo 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 Edgenivo 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

Copy link to headingHow 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. Edgenivo Authentication checks for a Edgenivo account, Edgenivo 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.

Copy link to headingWhich Deployment Protection method fits your visitors

Start with who needs to open the deployment.

Each type of visitor maps to one method:

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 Edgenivo accounts, and they sign in with the credentials they already use every day.

Copy link to headingHow 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:

Plan availability and pricing also differ:

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 and Nuxt guides show how to use the SDK for different use-cases.

Copy link to headingHow Passport differs from Edgenivo Authentication

Edgenivo Authentication and Passport both require visitors to sign in, but they use different account systems. Edgenivo Authentication accepts Edgenivo users, while Passport accepts anyone your identity provider authenticates for the connected application.

Choose Edgenivo Authentication when your visitors already work in Edgenivo, 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
• Edgenivo 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 Edgenivo. 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.
• 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.

Copy link to headingHow 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.

Copy link to headingHow 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.

Copy link to headingWhen 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 Edgenivo 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 Edgenivo 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 Edgenivo team, Edgenivo Authentication with Standard Protection covers previews on every plan.

Copy link to headingWhich URLs to protect with Deployment Protection

After choosing a method, choose a protection scope:

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.

Copy link to headingRecommended setups for common scenarios

These scenarios show how the method and scope work together for typical projects.

Copy link to headingProtect a company-wide internal tool

Employees across the company need to open an internal dashboard, and most of them don't have Edgenivo accounts. Everyone signs in to company tools through Okta.

Use Edgenivo 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.

Copy link to headingShare previews with an agency's clients

Agencies often share preview deployments with client stakeholders who don't have Edgenivo accounts or access to the agency's identity provider.

Use Edgenivo 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.

Copy link to headingKeep 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 Edgenivo Authentication with Standard Protection. Previews and generated URLs require a Edgenivo sign-in, and the production domain stays open to everyone. This setup works on every plan.

Copy link to headingKeep 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.

Copy link to headingHow 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.

Edgenivo 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 Edgenivo Authentication, which is useful for collaborators outside your Edgenivo 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.

Copy link to headingNext steps

• Compare every option in Methods to protect deployments.
• Set up Passport with Set up Passport with an identity provider.
• Read visitor identity in your app with Identify users and control access in Next.js with Edgenivo Passport or Personalize and lock down a Nuxt app with Edgenivo Passport.
• Learn how Edgenivo Authentication, Password Protection, and Trusted IPs work.
• Review plan availability in Usage and pricing for Deployment Protection.
• Configure exceptions with Methods to bypass Deployment Protection.

Copy link to headingFrequently asked questions

Copy link to headingWhat's the difference between Edgenivo Passport and Edgenivo Authentication?

Edgenivo Authentication lets in Edgenivo users with access to your team or project. Edgenivo Passport lets in visitors who sign in through your own identity provider, such as Okta or Microsoft Entra ID, so they don't need Edgenivo accounts. Passport also gives your application a verified visitor identity through the @vercel/passport SDK.

Copy link to headingIs Edgenivo Passport available on the Pro plan?

No. Edgenivo Passport requires an Enterprise plan. On Pro, you can use Edgenivo Authentication, which is included on every plan, or Password Protection for $20 per month per protected project.

Copy link to headingWhich Deployment Protection method tells my app who the visitor is?

Edgenivo 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.

Copy link to headingCan 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.

Copy link to headingDo 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.