aka: “Why is MFA asking me the same question twice?!
ZScaler is still new to us, and we’re still learning—but at least now we’ve conquered one of its many hidden boss fights.
TL;DR
If you’re switching ZScaler SSO from ADFS to Entra ID, update both ZPA and ZIA at the same time.
Don’t stagger it. Don’t “come back later.”
If one stays on ADFS and the other moves to Entra, the ZScaler Client logs into both simultaneously and will happily hit you with MFA twice, because why annoy you once when it can annoy you twice?
During our POV phase with ZScaler, we kept things classic and used ADFS for SSO for both ZIA and ZPA. Life was simple. Then we moved to production and thought, “Hey, let’s modernize, let’s move to Entra ID!”
The migration itself was pretty painless thanks to our PS engineer, Chris F, and ZScaler’s documentation, which was surprisingly actually correct (a rare moment of joy in IT). We tackled ZPA first, disabled all ADFS configurations related to it, and turned off the Relying Party Trusts in ADFS. Smooth sailing… or so we thought.
The Problem? Dual MFA Prompt. Yes! TWICE.
After the cutover, suddenly we were being hit with MFA two times in a row.
Not once. Twice.
For the record:
- Once is security.
- Twice is harassment.
We figured maybe it needed time to replicate or catch its breath, so we gave it a day.
Nope. Still double-MFA’ing like it was being paid per prompt.
Meanwhile we had another go-live around the corner, so Ken, one of our Azure Engineers who helped set up Entra ID looked at me and said, “No, we’re fixing this first.”
(You know it’s serious when someone cancels go-live prep.)
What We Investigated
Ken checked all the usual Entra ID suspects:
- Conditional Access conflicts
- Per-user MFA settings
- Application-level MFA
- Session token lifetimes
- Nested group inheritance weirdness
Everything looked squeaky clean on the Entra side.
I checked the ADFS side:
- ADFS logs
- ZPA Relying Party Trust (changed it, permitted all, even disabled it)
- Global MFA settings (we were using Azure MFA already)
- PowerShell commands
- Claims rules
Also clean. No smoking gun.
At this point, we were dangerously close to using the classic “Not us!” finger-pointing response that every IT team is secretly fluent in.
The Breakthrough
Then I did one thing—just one—almost out of curiosity:
I disabled the ZIA Relying Party Trust in ADFS.
Seconds later, Ken messages me:
“I can’t log in. Did you change something?”
Me: “Yes. I nuked the ZIA RP.”
From there, the light bulb finally lit.
We quickly configured ZIA to use Entra ID, just like we had already done for ZPA—and instantly the dual MFA prompts disappeared.
Why This Happened
The ZScaler Client authenticates ZPA and ZIA at the same time.
ZPA was on Entra ID.
ZIA was still clinging to ADFS like Windows XP in a hospital.
So what happens when two identity providers collide?
MFA × 2.
The login equivalent of being asked for your ID after you already showed your ID.
Lesson Learned
- Switch BOTH ZPA and ZIA to the new identity provider—don’t stagger it.
- ZScaler Client signs into both services simultaneously, so mismatched SSO = chaos.
- Troubleshoot together. Don’t blame ADFS, Entra, ZScaler, the firewall, DNS, or the universe.
- Share documentation—the more eyes, the faster you escape troubleshooting purgatory.
- And above all: Expect the unexpected with SSO. It’s always the thing you don’t think about.
Tech Dad 