Insider Threat Containment
Employees can only access the VPNs they have been explicitly granted. A developer cannot reach the finance team's VPN - not because of a firewall rule, but because they were never given access.
Zero Trust VPN Access
When you deploy a VPN on PrivyNet, only you have access. Every other user is locked out by default - regardless of whether they have credentials. Access must be explicitly granted, per user, per VPN. No open doors. No implicit trust.
The Default: Nobody Gets In
Most VPN solutions treat credentials as access - if you can authenticate, you can connect. PrivyNet separates the two entirely.
Traditional VPN
A user receives credentials. They can now connect. The VPN trusts anyone who can authenticate - there is no second gate.
- Credential compromise = network access
- No visibility of who should have access
- Offboarding requires manual credential removal
PrivyNet
A VPN is deployed. Only the deploying admin has access. Every other user - regardless of their credentials - is locked out until an admin explicitly grants them access.
- Credentials alone cannot connect you
- Every grant is intentional and auditable
- Revoking a grant terminates access immediately
How Explicit Access Grant Works
Four steps from deployment to a connected user - every one of them intentional
Deploy Your VPN
Create a new VPN from the dashboard. Your infrastructure is provisioned with a dedicated node and static IP. You are the only person with access.
Select Users to Grant
Open the VPN's access panel. Select the users who need access to this specific VPN. Each grant is recorded with a timestamp and the admin who made it.
Users Connect Immediately
Granted users can now authenticate and connect. Users without a grant will be rejected - even if they have valid credentials for another VPN.
Revoke in Seconds
Remove a user's grant at any time. Their active session is terminated and they cannot reconnect until access is re-granted. No waiting, no ticket queues.
Access is managed per user per VPN. A user can be granted access to the engineering VPN and not the finance VPN - even if they have valid credentials.
Why Default Deny Matters
The access model is your first line of defence - before encryption, before authentication, before anything else
Contractor and Third-Party Safety
When you bring in a contractor, they get access to exactly the VPN they need - nothing more. When the engagement ends, their access is revoked. They never had visibility of any other VPN in your organisation.
Clean Offboarding by Default
Removing a user from the dashboard revokes their access across every VPN they were granted. There is no separate VPN account to decommission - the access list is the source of truth.
No Over-Provisioning Risk
Traditional VPNs grant network access to anyone with credentials. PrivyNet requires an admin decision for every user on every VPN. Over-provisioning requires deliberate action - it cannot happen by accident.
Traditional VPN Access vs PrivyNet Zero Trust
The difference is not in the encryption or the protocol - it is in what the access model assumes by default
| Aspect | Traditional VPN | PrivyNet |
|---|---|---|
| Default at deployment | Anyone with credentials can connect | Only the deploying admin has access |
| How new users get access | Receive credentials - they can connect | Admin explicitly grants access per user per VPN |
| Access scope | Typically: all users, one VPN | Per user, per VPN - fine-grained and explicit |
| Contractor access | Same credentials as employees - same access | Grant access to one specific VPN only |
| Offboarding | Credentials must be disabled or removed manually | Remove user from dashboard - access revoked immediately |
| Over-provisioning risk | High - default is permissive | None - default is deny; every grant is intentional |
Frequently Asked Questions
Common questions about PrivyNet's zero trust access model
What happens when I deploy a new VPN in PrivyNet?
When you deploy a VPN, only the admin who deployed it has access. Every other user in your organisation is locked out by default. No one else can connect until you explicitly grant them access from the dashboard.
Can I give a user access to some VPNs but not others?
Yes. Access is managed per user per VPN. A user can be granted access to the engineering VPN but not the finance VPN. The same credentials work across all VPNs the user has been granted - only the DNS endpoint changes.
What happens if someone has the VPN credentials but was never granted access?
They cannot connect. Having credentials is not enough - the user must have an explicit access grant on that specific VPN. Authentication will be rejected without a grant in place.
Is zero trust access a setting I can toggle off?
No. Default deny is enforced at the infrastructure level - it is not a configurable option. Every user on every VPN must have an explicit grant. This is intentional: it makes accidental over-provisioning impossible.
How do I revoke access?
Remove the user's grant from the VPN access panel in the dashboard. Their active session is terminated immediately and they cannot reconnect until a new grant is issued. See our instant session revocation page for full details.
Does this work with RADIUS authentication?
Yes. RADIUS handles credential validation through your identity provider - Active Directory, FreeRADIUS, or any RADIUS-compatible provider. PrivyNet's access grants are enforced on top of that: a user must both have valid credentials and hold an explicit access grant to connect.
Default Deny. Explicit Grant. No Exceptions.
Every PrivyNet VPN starts with zero users and one admin. Every additional access grant is a deliberate decision - and every grant can be revoked in seconds.
Default deny at deployment
Explicit grant per user per VPN
Revoke in seconds