Just finished a PoC - sharing the exact test cases we used for access revocation speed

Franklin · 2026-08-18T19:05:54Z

We just concluded a three-week PoC for Twingate, with a primary focus on evaluating its real-world security posture, specifically the speed and reliability of access revocation. This is often a weak point in many ZTNA and legacy VPN solutions, where "instant" revocation is more theoretical than practical. Our test plan was designed to simulate common offboarding and security incident scenarios. We used a mix of Windows and macOS endpoints, with Twingate's local client installed. The critical test cases were: 1. **User Deactivation in IdP:** We toggled a test user's account to "disabled" in Azure AD and measured the time until the Twingate client on that user's device lost the ability to establish new connections and showed a "no access" state. We repeated this with the user actively connected to a resource. 2. **Group Membership Removal:** We removed the test user from the Azure AD security group that granted access to a specific application. The metric was the time until access to that specific resource was blocked, while access to other resources (via different groups) remained functional. 3. **Connector-Level Denial:** We used Twingate's admin console to manually revoke a user's access directly at the Connector policy level. This tested the administrative override path. The results were definitive. In all cases, the access revocation propagated and was enforced in under 60 seconds, with the majority of tests concluding in the 15-30 second window. The key observation was that existing TCP sessions were not just allowed to linger; they were actively terminated. An open SSH session or a persistent database connection was cut off, not just prevented from re-establishing. This performance is a direct function of their architecture, where the Connectors poll the Control Plane for policy updates at a high frequency. It validates their claims on this front. For anyone running a similar evaluation, I recommend testing with actual long-lived application sessions, not just pings or HTTP requests. That's where you'll see the difference between a true zero-trust model and a repackaged network gateway.

Page 2 / 2 Prev

Twingate Reviews

Last Post by Cassie2 1 month ago

16 Posts

15 Users

0 Reactions

18 Views

RSS

Cassie2

(@cassie2)

Honorable Member

Joined: 2 months ago

Posts: 546

19/08/2026 7:14 am

You're right, that timeline is everything. We pushed on the "optimized retry logic" in our calls and finally got them to admit the initial fallback poll is set to 30 seconds. So that's your floor for the gap, not zero.

Even if the WebSocket reconnects in 5 seconds, you've still got that 30-second window where the connector is blind to any revocations that happened during the outage. That feels like the critical metric they never advertise.

ReplyQuote

Page 2 / 2 Prev

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed