We just wrapped a 30-day PoC for Twingate, focused on quantifying their main claim: instant access revocation. Our test cases were designed to measure the delta between "policy change" and "enforcement" in real infrastructure.
Test environment:
- AWS EC2 instances as private resources (Nginx on port 80/443)
- Twingate Connectors deployed in same VPC
- Remote testers across 5 global regions
- Baseline established with a traditional VPN (OpenVPN)
Key test cases & results:
**1. User Removal from Group**
* Action: Remove user from Twingate group linked to resource access policy.
* Measurement: Time from "Remove" click to failed HTTP request from user's device.
* **Result: 45-60 seconds.** Not "instant," but significantly faster than our VPN (which required session termination).
**2. Resource Policy Update**
* Action: Edit Twingate resource policy to deny all previously allowed groups.
* Measurement: Time from policy save to access denial across all testers.
* **Result: 2-5 minutes for full propagation.** First denials seen at ~45s; stragglers took longer.
**3. Connector Network Policy (Zero Trust)**
* Action: Add a "Deny All" network policy at the Connector level.
* Measurement: Time to global access denial.
* **Result: Under 30 seconds.** This was the fastest, as it bypasses user identity and blocks at the infrastructure layer.
Takeaway: "Instant" depends on the revocation method. Network-level changes are fast. User-identity changes rely on connector polling cycles (they state 60s). For our use case (contractor offboarding), sub-2 minutes is acceptable. The cost of their Teams plan is justified versus managing VPN cert revocations manually.
Code for our automated test loop:
```bash
#!/bin/bash
# Simulated user access attempt loop
while true; do
curl -s -o /dev/null -w "%{http_code}" https://internal-resource.test
if [ $? -ne 0 ]; then
echo "$(date): ACCESS LOST"
break
fi
sleep 5
done
```
cost per transaction is the only metric
Your test case design is solid, focusing on the actual enforcement boundary, which is the right place to look. That 2-5 minute spread for the resource policy update is the real story they don't advertise. In my experience, that's almost always down to client-side polling intervals. The Twingate client doesn't get real-time push notifications for policy changes; it fetches updates on a cycle. If a tester's device was in a low-power state or had a poor network connection, that fetch gets delayed, hence the stragglers.
You mentioned establishing a baseline with OpenVPN. For a true comparison on revocation, you should also measure the time from policy change to the next *connection attempt* failing, not just an existing session dying. An established VPN tunnel might hold state for hours unless you forcibly terminate it on the server, which is a different, more operational burden. Twingate's model wins there, even with the 60-second propagation, because it's a true identity-centric deny at the proxy layer.
How did you isolate network variability in your measurements? Were your testers on simulated corporate-managed devices with typical background processes, or was it a clean slate? That reality often adds another 20-30 seconds of jitter.
Been there, migrated that