I downloaded Vivaldi specifically for its tiling feature. Four panes — docs, terminal, PR, Slack — all in one window, no tab switching. It’s the kind of UX that makes you wonder why every browser doesn’t do this.
Then I tried to log into my work GitHub.
Redirect. Redirect. Vague “you can’t access this” page. No error code. No explanation. Just a polite wall.
The invisible hand of Conditional Access has opinions about your browser choice.
The auth chain you didn’t know existed
Here’s what happens when you click “Sign in with SSO” on a GitHub Enterprise Managed Users (EMU) org:
- GitHub redirects to your SAML SSO endpoint
- SAML redirects to Entra ID (formerly Azure AD)
- Entra ID authenticates you — password, MFA, the usual
- Before granting the token, Entra evaluates Conditional Access (CA) policies
- CA checks: Is this device compliant? Is this an approved app? Is this browser trusted?
- If all checks pass, you get your token and land back on GitHub
Steps 1-3 work in any browser. Step 4 is where Vivaldi dies.
The thing is, Edge isn’t just a Chromium fork that Microsoft ships. It has native integration with WAM — the Web Account Manager, which is Microsoft’s device-level identity broker. When a CA policy says “require a compliant device,” Edge can actually prove compliance because it talks to Intune through WAM. It’s not sending a user-agent string and hoping for the best. It’s presenting a device certificate.
Vivaldi is also Chromium-based. Same rendering engine, same JavaScript runtime, same DevTools. But it doesn’t have the WAM integration. So when Entra asks “is this device compliant?”, Vivaldi just… can’t answer. And silence is a no.
What’s actually blocking you
There are three CA policies that typically cause this. Your org might have one, might have all three:
Compliant device requirement. The policy says “only allow access from Intune-enrolled devices.” Edge proves enrollment through WAM. Vivaldi can’t. You’re on the same device, same enrollment status, same everything — but the browser can’t present the proof.
Approved client app restriction. Microsoft maintains a list of “approved” apps that support modern auth. Edge is on it. Vivaldi is not. This one’s straightforward — if your CA policy restricts to approved apps, any browser not on the list is out.
MAM (Mobile Application Management) policies. These wrap the session in data protection controls — things like “don’t allow copy-paste to personal apps” or “require app protection.” Edge supports MAM on desktop. Vivaldi doesn’t.
The frustrating part: you’ll rarely see which specific policy blocked you. If you’re lucky, the error page includes AADSTS53003 somewhere — that’s the Entra error code for “Conditional Access policy blocked this request.” If you’re unlucky, you just get a redirect loop or a generic “can’t access” screen.
The diagnostic move
If you want to know exactly what’s happening, check the Entra sign-in logs:
- Go to Entra admin center → Sign-in logs (or ask your IT admin)
- Filter by your UPN and the timestamp of the failed login
- Look at the Conditional Access tab on the sign-in event
- It’ll show you which policies evaluated and which one returned “Failure”
This is the only way to get a straight answer. The browser error page is useless. The sign-in log tells you the policy name, the grant controls that weren’t satisfied, and the client app that was evaluated. Armed with that, you can have an actual conversation with IT instead of “my browser doesn’t work.”
The workarounds, ranked
I tried a few things. Here’s the honest assessment.
1. Microsoft Single Sign-On Chrome extension
There’s a Chrome extension — “Microsoft Single Sign On” — that’s supposed to bridge the WAM gap for non-Edge Chromium browsers. Install it in Vivaldi, sign in, and it should handle the device identity handshake.
Reality: ~30% success rate. It depends on which specific CA policies your org has. If the policy is “require compliant device” and the extension can surface the device certificate, it works. If the policy is “approved client app only,” the extension doesn’t change the app identity — Vivaldi is still Vivaldi. If it’s MAM, forget it.
Worth trying. Install it, attempt the login, check sign-in logs to see if the failure changes. Sometimes it’s enough.
2. Edge for auth, Vivaldi for everything else
This is the pragmatic answer. Open Edge. Log into GitHub EMU. Get your session cookie. Close Edge. Open Vivaldi for actual work.
Except it’s not quite that simple — the session is per-browser. You can’t transfer cookies between browser profiles. So you end up keeping Edge open for anything that hits the EMU org — PR reviews, code browsing, Actions logs — and using Vivaldi for everything else.
Two browsers. Permanently. Because an identity policy made a decision about your UX.
This is what I actually do. It’s annoying and it works.
3. Ask IT for a browser exception
CA policies are configurable. Your IT admin can add browser exceptions, exclude specific applications from the compliant-device requirement, or create a separate policy for GitHub that’s less restrictive.
Will they? Depends on your org. In a large enterprise, the answer is usually “we can’t make exceptions because policy” — which is the security team’s version of “it’s DNS.” But it’s worth asking, especially if you can demonstrate that the SSO extension doesn’t work and you’re the third person this week who asked.
Frame it as: “The CA policy for GitHub EMU is blocking non-Edge Chromium browsers despite device compliance. Can we adjust the policy to allow compliant devices regardless of browser, or add Vivaldi to the approved app list?”
Specificity helps. AADSTS53003 is your friend.
4. The nuclear option: browser profiles
Some people solve this by running Edge with a work profile and a personal profile, and just… giving up on Vivaldi entirely. Edge has tab groups now. It’s not tiling, but it’s something.
I couldn’t do it. I tried. The tiling is too good.
The real problem
None of this is a bug. Every component is working exactly as designed. Entra is enforcing policy. Edge is presenting credentials. Vivaldi is a standard Chromium browser that doesn’t implement Microsoft’s proprietary identity broker. GitHub EMU requires SAML. SAML goes through Entra. Entra checks CA. CA requires things only Edge can provide.
The system works. The experience is that your browser choice is silently overridden by an identity policy that was probably written by someone who’s never heard of Vivaldi and was thinking about iOS devices when they checked “require approved client app.”
This is the hidden cost of enterprise identity management. Not the configuration complexity — that’s well-documented. The cost is the UX lock-in that nobody tells you about. Your IT admin set a Conditional Access policy eighteen months ago. It works great for the 95% of employees using Edge or Chrome on managed devices. And it creates an invisible wall for anyone who wants to use a different tool.
The worst part is the failure mode. There’s no popup that says “Hey, your org requires Edge for this.” There’s no link to a support article. There’s a redirect loop, or a blank page, or a vague error that you have to already understand Entra to interpret. The developers who would benefit most from knowing about CA policies — the ones trying alternative browsers, configuring custom environments, optimizing their workflow — are exactly the ones who hit this wall with zero context.
Security policies that fail silently are just gatekeeping with plausible deniability.
I’m keeping Vivaldi for tiling. I’m keeping Edge for auth. And I’m keeping the resentment tucked away in a clean little blog post.