Authenticate Once, Access Forever: Zscaler's Lifetime Membership Plan

It began with something that had been bothering me for months: why did some iPhone never ask me to re-authenticate to Outlook or Teams when users changed their password? On my personal devices without our corporate VPN client, password changes triggered immediate re-authentication prompts.

But on my work phones with Zscaler Client Connector (ZCC) installed, nothing happened. It was like the password change never occurred on the phone, but the desktop applications did get that password reset.

This observation led me down a rabbit hole that would uncover a fundamental security flaw in how many organizations deploy Zscaler.

The First Clue: Compromised Accounts That Wouldn't Die

The standard procedure is simple, mark the account as compromised in Entra ID (formerly Azure AD), reset the password, and revoke tokens. This should immediately lock out any attacker.

But I noticed something strange: users with ZCC installed on their devices maintained access even after we marked their accounts as compromised and reset their passwords. Meanwhile, users who only used PAC files for proxy configuration were immediately forced to re-authenticate.

This didn't make sense. How could a security product bypass our identity provider's security controls?

The Mobile Device Mystery

The pattern became clearer when I compared behavior across different devices:

• Personal iPhone (no ZCC): Change password → Immediate prompt to re-authenticate to all Microsoft apps
• Work iPhone (with ZCC): Change password → Nothing. Outlook, Teams, OneDrive all continue working
• Windows laptop (with ZCC): Same as work iPhone - no re-authentication required
• Windows desktop (PAC file only): Immediate authentication challenge after password change

I realized this wasn't an device issue - it was a ZCC issue.

The MFA Bypass That Shouldn't Exist

Another piece of the puzzle fell into place when colleagues mentioned they never had to do MFA on their home laptops, despite our Conditional Access policies supposedly requiring it for untrusted locations. These same policies worked perfectly for users without ZCC, but anyone with the client connector installed seemed to have a permanent bypass.

Our Privilege Access Management (PAM) integration, designed to enforce privileged access management, was essentially useless for ZCC users. They authenticated once when they first set up their device and never again.

Finding the Authentication Settings

After extensive research and testing, I finally got read-only access to our Zscaler admin portal. What I found was shocking:

Authentication Settings → Authentication Profile → Authentication Frequency: "Only Once"

There it was. Users authenticate ONE TIME when they first install ZCC and then never again. Not daily. Not weekly. Not monthly. Once. Forever.

How This "Security" Product Defeats Security

Here's what actually happens with this configuration:

Day 1 - Initial Setup:

1. User installs ZCC
2. Gets redirected to Microsoft/Entra ID for authentication
3. Completes MFA (if required)
4. Microsoft issues a SAML token to Zscaler
5. Zscaler stores this token permanently
6. User is now authenticated "forever"

Day 2 Through Eternity:

1. User accesses Outlook/Teams/OneDrive
2. Traffic flows through ZCC
3. ZCC presents its stored token to Microsoft
4. Microsoft accepts the token (it's valid!)
5. User gets access
6. Microsoft never sees the actual user again

Why Nothing Works Anymore

With this "Only Once" setting, here's what breaks:

• Password resets: Meaningless. The old token in Zscaler remains valid.
• Mark as compromised: Useless. Microsoft can't revoke Zscaler's token.
• MFA requirements: Bypassed. After initial auth, MFA is never evaluated again.
• Conditional Access: Defeated. Policies are only checked on that first authentication.
• Location-based policies: Irrelevant. Microsoft sees Zscaler's location, not the user's.
• Risk-based authentication: Dead. No ongoing risk assessment occurs.
• Continuous Access Evaluation (CAE): Broken. Microsoft never gets to evaluate anything continuously.

The Travel Problem Finally Made Sense

I'd always wondered why when users traveled abroad, we had to uninstall and reinstall ZCC to get their access working properly. IT claimed it was a "directory synchronization issue," but that never made sense.

Now I understood: when we added users to travel exception groups, those new permissions were never evaluated because ZCC never re-authenticated. The only way to force it was to completely remove the app (destroying the old token) and reinstall it (creating a new authentication event).

Users essentially had a "frozen in time" snapshot of their permissions from whenever they first authenticated - which could have been years ago.

Shocking Vendor Recommendation

I assumed this was a misconfiguration by our IT team trying to reduce support tickets. But when I dug into Zscaler's official documentation, I found something jaw-dropping:

From Zscaler's own Reference Architecture Guide:

"Zscaler recommends a reauthentication interval of only once. This means your users are not forced to reauthenticate to use the service. Because Zscaler is not providing privileged access to applications, there is no security concern for users."

Zscaler actually RECOMMENDS this configuration as a best practice.

Their logic that there's "no security concern" because they're "not providing privileged access" is absurd. Email isn't privileged? Teams conversations aren't sensitive? OneDrive documents aren't confidential?

The Architecture Flaw

The fundamental issue is that Zscaler positions itself as a man-in-the-middle authentication proxy:

Without ZCC: User → Microsoft → Access Granted/Denied (with continuous evaluation)
With ZCC: User → Zscaler (permanent token) → Microsoft → Access Always Granted

Once that initial authentication happens, Zscaler becomes a permanent skeleton key that bypasses every security control Microsoft provides.

How can I check/fix this?

If your organization uses Zscaler, check this setting immediately:

1. Go to Administration → Authentication Settings
2. Look at Authentication Frequency
3. If it says "Only Once," you have a critical security vulnerability

The setting should be:

• Minimum: Weekly
• Better: Every 3 days
• Best: Daily

Conclusion

A security product that creates permanent, unrevokable authentication tokens that bypass password resets, MFA, and account compromise procedures isn't enhancing security - it's destroying it.

The fact that Zscaler not only allows this configuration but actually recommends it as a best practice should make every security professional question what other dangerous defaults might be lurking in their "security" stack.

If you're using Zscaler with "Only Once" authentication, you don't have zero trust - you have permanent trust. And in security, permanent trust is just another way of saying "no security at all"