Zero Trust Network Access
Network access
without the network.
Twingate retires VPNs, jump hosts, and IP allowlists. Every connection is bound to a verified identity, scoped to a single resource, and torn down the moment it shouldn't exist, with nothing exposed to the public internet.
Alex Marshall
MacBook Pro
San Francisco, CA
aws-us-west-1-dev
No open inbound ports
Direct peer-to-peer tunnel
Continuous re-evaluation
The perimeter left the building. Trust has to follow the user.
For thirty years we trusted whatever was inside the firewall. But your team isn't inside anymore, and neither are your infrastructure or apps. ZTNA replaces network location with identity as the unit of trust. Here's what changes, line by line:
Unit of trust
Default posture
Attack surface
When access is checked
Offboarding
An IP address inside the firewall
Allow-by-default once you're on the LAN
Inbound VPN concentrators on the public internet
Once, at login
A ticket, a runbook, a few days
A continuously verified identity on a healthy device
Deny-by-default, allow per resource
Zero open inbound ports, outbound-only connections
Policy enforcement verified continuously, on every connection
Same instant your IdP deactivates the user
Most ZTNA vendors rebuilt VPN. We built something new.
Twingate Security Policies support four types of controls: authentication (re-authentication frequency and MFA requirements), device security (trusted device verification through MDM/EDR integrations plus posture checks like disk encryption and minimum OS version), location (country-level allowlists or denylists, available on Enterprise), and time and usage limits (access that expires automatically or locks after a period of inactivity). Controls can be combined and applied per Resource, per Group, or network-wide.
Identity-first by design
Every TCP/UDP connection carries a verified identity. Not bolted on, not optional.
No reroute, no choke point
Direct peer-to-peer tunnels between user and resource. Traffic doesn't bounce through our cloud.
Deny by default, always
There is no implicit allow. If a policy doesn't grant access, the packet never leaves the device.
Resource-based policy model
Apply fine-grained security policies on the resource level, giving you granular control over access.
1
Deploy in minutes
Choose a deployment method and get up and running in minutes. Pick the method that works for your team: Docker scripts, Terraform, Helm Charts, and more.
2
Define your Resources
Resources are individually isolated and hidden endpoints. They can be any network address you want accessible via Twingate: private DNS resources, private IPs, CIDR ranges, etc.
3
Set up security policies
Twingate Security Policies apply controls at the Resource level, such as minimum authentication requirements, MFA, device controls, minimum usage, location requirements, and more.
4
Get to work
Twingate maintains 99.99% reliability and is up to 86% faster than traditional VPNs, meaning your team can stop chasing errors and focus on the work that matters.
Click it. Or commit it.
Toggle a control in the Twingate Admin Console, or define your entire access surface as code. Choose the interface that fits your team.
Require device posture
Step-up MFA on prod-db
Allow contractor group
Geolocation requirements
resource "twingate_resource" "prod_db" {
name = "prod-db"
address = "db.prod.acme.internal"
protocols {
tcp { policy = "RESTRICTED" ports = ["5432"] }
}
access {
group_ids = [twingate_group.eng.id]
usage_based_autolock_duration_days = 14
}
}
Not all secure access is created equal.
Legacy VPNs grant broad network access, a liability when one compromised credential exposes everything. Mesh VPNs improve connectivity but still think in networks, not resources. Twingate was built differently: every user gets access only to what they need, nothing more.
Identity attached to every connection
Deploy without re-cutting your network
No inbound ports exposed
Direct peer-to-peer tunnels
Manage as code (Terraform / K8s operator / GraphQL)
Auto-revoke via IdP
Source-available data plane
No
No
No
No
No
Partial
No
No
No
Yes
Partial
Partial
Yes
No
TWINGATE
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Expand the impact of your security stack with out-of-the-box integrations with major IdPs, MDM/EDRs, SIEMs, CI/CD pipelines, and more.
Frequently Asked Questions
How is Twingate different from a traditional VPN?
Traditional VPNs operate on a perimeter security model, granting broad network-wide access once a user authenticates. Twingate takes a fundamentally different approach based on Zero Trust: users only get access to the specific resources they're authorized for, not the entire network. Twingate also hides your infrastructure entirely, eliminating public-facing gateways that attackers can target. There's no hardware to procure, no network reconfiguration required, and traffic routes directly to resources rather than being backhauled through a central server, which means better performance. You can deploy Twingate in under 15 minutes alongside your existing VPN and migrate gradually.
How does Twingate implement Zero Trust principles?
Twingate's architecture is built so no single component can independently decide to allow traffic. Four components work together: the Controller, Clients, Connectors, and Relays. No single Twingate component can independently make a decision to allow traffic to flow to another component or Resource in your Remote Networks. Authorization for user access or data flow is always confirmed with a second, or even with a third—component depending on the sensitivity of the decision being authorized. Rather than trusting a network location (like being inside a corporate firewall), Twingate verifies identity, device posture, and authorization on every request, regardless of where the user is connecting from.
Does Twingate require changes to my existing network infrastructure?
No. Twingate deploys without any network reconfiguration or VPN server setup. The core deployment is a lightweight Connector that runs on a single host inside your existing network, no inbound firewall ports required. You can be up and running in under 15 minutes, and you can run Twingate in parallel with your existing VPN while you migrate. There's no hardware to procure and no rip-and-replace required.
How does Twingate verify user identity before granting access?
Twingate delegates authentication to your existing Identity Provider (IdP) rather than managing credentials itself. It integrates with Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin, Keycloak, and SCIM-compatible providers. Users authenticate once through their IdP and receive a signed access control list that determines exactly which resources they can reach, with no static credentials or separate authentication tokens required. Access decisions also incorporate device posture and contextual signals, so identity verification is just one layer of a multi-factor access decision.
Can Twingate enforce device posture checks?
Yes. Twingate can require that devices meet specific security standards before access is granted, including OS type, screen lock status, disk encryption, and enrollment in an MDM or EDR platform. Twingate integrates with Intune, Jamf, CrowdStrike, and SentinelOne to delegate posture verification to the security tools you already use. Policies are enforced at the edge on the client device rather than in the cloud, and you can configure device requirements programmatically via Twingate's public API.
Does Twingate integrate with developer tooling like Terraform, CI/CD pipelines, and APIs?
Yes. Twingate is built with infrastructure-as-code workflows in mind. It offers an official Terraform provider and a Pulumi provider for provisioning Connectors and Resources programmatically, a GraphQL-based Admin API that supports full CRUD operations across the platform, JavaScript and Python CLIs for automation and scripting, and example CI/CD configurations for pipeline integration.
What types of controls do Twingate Security Policies support?
Twingate Security Policies support four types of controls. Authentication controls set re-authentication frequency and MFA requirements. Device controls enforce native posture checks like disk encryption, screen lock, and minimum OS version, and can also require verification through your MDM or EDR. Location controls block or allow access by country on the Enterprise plan. Time and usage controls expire access automatically or lock it after inactivity. Controls can be combined and applied per Resource, per Group, or network-wide.
Does Twingate work for hybrid and multi-cloud environments?
Yes. Twingate is designed for modern infrastructure and supports AWS, Microsoft Azure, Google Cloud Platform, and Kubernetes environments including GKE and Amazon EKS. Users can access multiple clouds or multiple environments, such as development and staging, simultaneously through a single client. Because the Twingate Connector is a lightweight component that deploys on a single host, it can be placed inside any network, whether on-premises, cloud, or a combination, with no network reconfiguration needed.
How do I migrate from a VPN to Twingate?
Twingate is designed for low-risk, gradual migration. You can deploy it alongside your existing VPN without any disruption: no hardware changes, no network reconfiguration. Start by deploying a Connector (it takes under 15 minutes) in the network you want to secure, connect it to your existing IdP to onboard users, and define resource-level access policies. Twingate provides specific migration guides for replacing AWS VPNs, securing site-to-site connections, and managing vendor and contractor access. Twingate also supports Terraform, Pulumi, and Kubernetes for teams migrating via infrastructure-as-code.
Does Twingate help with compliance (SOC 2, HIPAA, etc.)?
Yes. Twingate's security model directly supports a range of compliance frameworks including SOC 2, HIPAA/HITRUST, PCI DSS (Requirement 7.3), GDPR/CPRA, SOX, FedRAMP, and FIPS 140-2/3. Its least-privilege access controls, MFA enforcement at the application level, and centralized access management give you the audit evidence compliance teams need. Extensive logging and analytics provide visibility into network activity for anomaly detection and reporting. Offboarding is also simplified: when an employee leaves, a single action revokes access to all Twingate-secured resources at once, reducing the risk of stale access that often creates compliance gaps.