Twingate

What the product connects and how: a managed gateway VPN with shared or dedicated gateways and dedicated static IPs, a peer-to-peer mesh between devices and servers, access per application or resource (ZTNA), site-to-site links between offices and cloud networks (AWS, Azure, Google Cloud), connectors behind a firewall without inbound ports, the protocols (WireGuard, IPsec, OpenVPN, a vendor protocol), split tunnelling and full tunnelling, always-on and auto-connect, clients for Windows, macOS, Linux, iOS, Android and ChromeOS, the gateway and relay locations, NAT traversal and relays, and access for contractors without a managed device.

0 — Gives no remote access of its own; a browser extension, a consumer VPN for anonymous browsing or a security tool that only filters traffic.

3 — A VPN client that connects users to one gateway or network; site-to-site, per-resource access, the clients per platform and the locations are basic or not described.

5 — Clients for Windows, macOS, Linux, iOS and Android, a modern protocol (WireGuard or IPsec), access to private networks through a gateway or connector without inbound firewall rules, split tunnelling, dedicated static IPs or self-run gateways, site-to-site or cloud network links, and the gateway or relay locations named.

8 — Access per application or resource rather than whole networks, peer-to-peer connections with relays as fallback, always-on and auto-connect, connectors for the major clouds and Kubernetes, gateways in many named regions, private DNS and split DNS, clientless browser access for contractors, and the protocol and encryption choices documented.

10 — Connectivity a distributed company runs on: every access model above in one product, high-availability gateways and connectors with failover documented, performance and throughput published per gateway type, post-quantum or equivalent key exchange documented, and an exit path to run the same network on self-hosted components.

Whether access follows identity and the state of the device rather than the network: single sign-on with Microsoft Entra ID, Google Workspace, Okta or any OIDC/SAML provider, SCIM or directory sync so a leaver loses access, multi-factor authentication, groups and per-resource access policies, least-privilege defaults, device posture checks (operating system version, disk encryption, EDR or MDM status, managed device certificates), just-in-time or time-limited access with approval, session lifetimes and re-authentication, and access revoked when a device is lost.

0 — No user identity at all; a shared key or configuration file grants access to the whole network.

3 — User accounts with a password or one identity provider; groups, per-resource policies and device checks are basic or not described.

5 — Single sign-on with Entra ID, Google Workspace and Okta, multi-factor authentication, user groups, access policies that restrict groups to named networks, resources or ports, automatic or SCIM-based deprovisioning, and basic device posture checks such as operating system version.

8 — SCIM provisioning from the major identity providers, per-resource policies with least privilege by default, device posture from EDR or MDM tools (for example CrowdStrike, SentinelOne, Intune, Jamf), just-in-time access with approval and expiry, session re-authentication, policies kept as code, and the policy model documented.

10 — Access control a security team can audit and trust: continuous evaluation of identity and device state during a session, policies tested before they apply, emergency revocation documented, device identity bound to hardware, and the decision for every connection explainable from the logs.

What can be seen and proven afterwards: connection and access logs (who reached which resource from which device, when), admin and configuration audit logs, how long logs are kept per plan, log export and streaming to a SIEM (Splunk, Microsoft Sentinel, Datadog, an S3 bucket), alerts on unusual access, a view of active sessions and the ability to end them, DNS logs where DNS filtering is part of the product, and what the vendor states it does not log, such as the content of traffic.

0 — No logs of any kind; the admin cannot see who connected.

3 — A list of connected users or devices; access logs, admin audit logs, retention and export are basic or not described.

5 — Connection or access logs per user and device, an admin audit log of configuration changes, the retention period stated, log export by CSV or API, a view of active sessions or devices with the option to disconnect or revoke them, and a statement of what traffic data is and is not logged.

8 — Log streaming to named SIEM tools, network flow logs per resource, retention of a year or more stated per plan, alerts or webhooks on security events, logs filterable by user, device and resource, and the log schema documented.

10 — An audit trail that holds up in an investigation: every access decision and admin action recorded with its policy and reason, logs signed or tamper-evident, evidence suitable for ISO 27001, NIS2 or DORA audits, full export in an open format, and the customer able to keep logs entirely on its own infrastructure.

How the product is rolled out and run by a small IT team or a service provider: time to the first connection, deployment of clients through MDM (Intune, Jamf, Kandji) with preconfigured settings, a central admin console, a documented REST API, a Terraform provider or configuration as code, roles for administrators, several teams, sites or customer tenants in one account, a multi-tenant console for managed service providers, a self-hosted or on-premises edition, the update process for clients and gateways, and support channels and hours.

0 — No central administration; every client is configured by hand with no console.

3 — A web console to add users and gateways; the API, MDM deployment, admin roles and multi-tenant set-up are basic or not described.

5 — A central admin console, a documented REST API, client deployment through MDM with preconfigured settings, admin roles, several networks or sites in one account, client updates managed centrally, and support channels and response times stated per plan.

8 — A Terraform provider or configuration as code, a multi-tenant console for service providers or several organisations, granular admin roles, a self-hosted or on-premises edition documented for production, gateways deployable as containers or cloud images, and webhooks or integrations with ticketing and chat tools.

10 — Administration that scales across many sites and tenants: every setting reachable by API and code with parity stated, staged rollouts of client and gateway updates, a self-hosted edition with feature parity stated, reseller or MSP billing per tenant, and an exit path for configuration and users documented.

How the product is built and how its claims are proven: a published architecture showing what the coordination servers, relays and gateways see, whether traffic passes through the vendor or end to end between devices, encryption and key management, open-source clients or servers, independent security audits and penetration tests with reports or summaries published, a vulnerability disclosure or bug bounty programme, high availability and failover of the vendor's control plane, what happens to existing connections when the vendor's service is down, the vendor's own public status page and incident history, and an SLA.

0 — Nothing is published about how the product works or is secured.

3 — Encryption is mentioned in marketing terms; architecture, audits, availability and the vendor's status page are basic or not described.

5 — An architecture overview of clients, gateways and the control plane, the encryption protocol and key handling named, an independent security audit or penetration test stated, a vulnerability disclosure contact, the vendor's public status page, and an availability SLA on the business plans.

8 — A security whitepaper with the data flow and what the vendor can see, open-source clients or core components, audit or pentest reports or summaries published by the auditor, a bug bounty, high availability of the control plane documented, existing connections kept alive when the control plane is down, and the incident history public with post-mortems.

10 — Assurance a regulated buyer can verify: fully open-source and reproducible components, recurring independent audits published in full, the control plane self-hostable with no call home, a documented failure mode for every vendor component, and several years of availability published.

Who the contracting entity and the parent company are, where account data, user and device identities, connection logs and configuration are stored and processed, which party runs the coordination servers, relays and gateways the traffic passes through, and who the subprocessors are (hosting, identity, email, support and payment tools). Independently sourced by the sovereignty pipeline. Gateway and exit locations outside Europe are part of what the product does and are not counted against it; where the logs and identities are stored and who processes them is. A self-hosted or open-source edition the customer runs on its own European servers counts as the customer's chain, whatever the vendor's seat.

0 — Non-EU vendor and contracting entity, hosting of the control plane and logs unstated, subprocessors unnamed, and no data processing agreement offered.

3 — A privacy policy and a data processing agreement exist, but the location of the control plane and logs is unstated or non-EU and the subprocessors are not listed.

5 — EU hosting of logs and account data available and an EU contracting entity or EU representative, but parts of the chain (relays, support, identity, payment) run through non-EU providers without a stated safeguard.

8 — EU hosting on named infrastructure for the control plane and logs, EU contracting entity, subprocessors listed with their locations, a data processing agreement published, and security certifications (ISO 27001, SOC 2) stated — or a self-hosted edition documented that keeps every record and connection on the customer's own servers.

10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, or a self-hosted open-source edition with no call home, data export and deletion documented, and certifications published with their scope rather than implied.

Whether a buyer can compute the real annual cost from public pages alone: price per user or per device and tier, minimum seats, what dedicated gateways, static IPs, extra networks or sites cost, which features (SSO, SCIM, device posture, log streaming, longer retention, site-to-site) need a higher tier, the free tier and its limits, the price of a self-hosted or on-premises licence, monthly versus annual billing, minimum term and VAT.

0 — No public prices at all; every customer is a sales call or a partner quote.

3 — A starting price or a free tier exists, but how cost scales with users, devices, gateways or features is unclear.

5 — Tiers are public with a price per user and their main inclusions, but at least one commonly needed piece (dedicated gateways or IPs, extra sites, SSO or SCIM, log retention, the self-hosted licence) is unpriced or "on request".

8 — Every tier priced publicly with its scaling rule (users, devices, gateways, networks), dedicated IPs and gateways priced, add-ons priced, minimum seats, minimum term and VAT treatment stated.

10 — Complete price computability: annual cost derivable for a given team size, number of sites, gateways and devices, with every add-on, overage and support fee and the cancellation and data-return terms published.