I use Zwift on my work laptop for several reasons—performance, convenience (all my Bluetooth devices like the trackpad and earbuds are connected), and access to corporate webinars or recordings that I watch while riding/exercising, especially when I’m catching up on work. However, with the increasing emphasis on cybersecurity, enhanced security measures recently broke Zwift. This may also highlight some changes the Zwift team might want to consider in the app.
For example, SSL Inspection is becoming more common in corporate environments, and once it was implemented on my network, Zwift stopped working:
[11:37:34] [ECONOMY] login request with use_computed=true, recompute=false
[11:37:35] [ERROR] Curl error: [60] 'SSL peer certificate or SSH remote key was not OK' for: GET https://us-or-rly101.zwift.com/api/auth
[11:37:35] [ERROR] Error finding authorization server: [30] SSL peer certificate or SSH remote key was not OK
[11:37:35] [ERROR] Could not attend to access token [27] Could not acquire access token because credentials are missing
[11:37:36] [ERROR] Failed to get telemetry config
After investigating with the security team, they identified the issue as being related to “certificate pinning” on the Zwift authentication server. Their feedback was:
“This is a well-known scenario. SSL decryption won’t work if the server uses certificate pinning for security, especially for authentication traffic. In such cases, we allow a bypass, but Zwift is using /api/auth, which makes it hard to bypass only specific endpoints and may force us to bypass the entire wildcard domain.”
I’m aware that some might suggest “just don’t use Zwift on your work device,” but that’s not a realistic solution. Instead, Zwift’s configuration might need to evolve in line with modern cybersecurity practices. Interestingly, other indoor cycling apps didn’t experience this issue, which makes me wonder if there’s an opportunity for Zwift to review its implementation.