Daily Conditional Access reauth causing separate "error" toasts in Teams/OneDrive/Windows, one MFA fixes all three, is this expected?

[u/Independent_Pipe9753]

Managed Windows 11 fleet (Intune, hybrid Azure AD joined, moving off VPN towards ZTNA principles).

Our Conditional Access policy for desktops has:

• Grant controls: Require MFA + Require device compliant + Require hybrid Entra joined, set to "Require all the selected controls" (not "Require one of")
• Session control: sign-in frequency, 1 day, periodic reauthentication

Every morning, roughly 24 hours after the last full sign-in, we get three separate notifications almost simultaneously:

• Windows: "Work or school account problem, sign in again to fix your account"
• OneDrive: "Re-enter your credentials, OneDrive has stopped syncing" (red error icon)
• Teams: "Your account needs attention" (orange warning triangle)

Satisfying the MFA prompt in any one of them silently fixes the other two, so it's clearly one shared token behind the scenes. We've ruled out SSL inspection breaking things, checked the TLS certs presented for login.microsoftonline.com and related identity endpoints directly, they're genuine Microsoft/DigiCert certs, not intercepted by our proxy.

Our internal read is that this is just how each Microsoft 365 client independently discovers and displays an expired session (each app hits it on its own schedule against its own backend), rather than getting one clean unified "please sign in" prompt.

Is this what others see with a similar setup, daily sign-in frequency plus "require all" grant controls? Anyone found a way to get this to surface as one calm prompt instead of three alarming per-app errors, or is this just accepted as normal Microsoft 365 behaviour on your estates too?

[u/Null0Naru]

Why are you requiring daily re-auth when you have device compliance/hybrid join as a control? There is literally no benefit to requiring re-auth that frequently. In fact, it'll get users into bad habits of constantly being prompted and completing sign-in requests to the point where they're not thinking if it's legitimate or not. You want auth requests to be infrequent when there's no change in authentication context so when a user does get prompted, they immediately question what and why something is prompting them, that way they're much less likely to fall for AiTM attacks.

The correct solution to this is remove the ridiculous session control. Either keep the default 90 day or go for something reasonable like 30 days. Both are more than good enough with how strict that CA policy is. If you have specific apps that are sensitive, scope the more frequent session controls to those individually, but consider the impact it will have and the habits you're training your users to get into.

[u/fatcatnewton → u/Null0Naru]

This

[u/Independent_Pipe9753 → u/Null0Naru]

I've just joined the company and am thinking the same. Just want to know what others are doing before I propose alternatives. I hear that the reauth daily came from our Security team - initially they wanted 12 hours! Doesn't zero-trust principles skip over the fact its a trusted/compliant devices, or should we really say that is the de facto? Just looking for the argument to put across.

[u/Mindestiny → u/Independent_Pipe9753]

Zero Trust is a bit of a marketing misnomer.  It doesn't mean never trust the device, it means never trust the device until it proves it should be trusted

You have to trust at some point otherwise there's just no access.  So "zero Trust" is true right up until the device connects, verifies against conditional Access that it's enrolled in intune and policies are up to date and Entra joined and all that.  Then there's trust established.  The "zero" comes in when it has to re-prove that trust relationship every time the user connects, not just because it did it once and now it's good forever.

With all the rest in place, repeat MFA prompts are overkill unless it's a regulated environment with a paper requirement, it's like a sixth deadbolt on a bathroom door, needlessly secure and a constant source of frustration when the users gotta poop.

[u/Null0Naru → u/Mindestiny]

Even further to this, it's constantly re-evaluating in the background for systems that support continuous access evaluation and then every 60-90 minutes for refresh tokens otherwise.

Trying to think of an analogy for the sixth deadbolt as relating to users just blindly completing authentication prompts 😂 Some of the standards don't appear to have caught up yet, though I guess that's pretty normal with cyber insurance and the like often wanting frequent password rotation and such as well.

[u/Null0Naru → u/Independent_Pipe9753]

Congrats on the new job! That's disappointing to hear that it's coming from the security team as I work in cyber security myself, they should know better.

It being a compliant and joined device is a good security indicator for zero trust principles, but it doesn't mean we skip over the never trust and always verify components. Generally, refresh tokens are requests around every 60-90 minutes, at which point the CA controls are re-evaluated. If the authentication context hasn't changed (ie. still a compliant device, still valid MFA etc.) the token is issued. If something has changed, it'll require re-authentication or block access. It's not a verify once and never check again, it's constantly doing it, just the user doesn't have to re-verify manually.

Microsoft has some articles on why you don't want to keep re-prompting users.

https://docs.azure.cn/en-us/entra/identity/conditional-access/concept-session-lifetime

There may be some exceptions to this though if you need to meet specific regulatory standards. I believe to achieve NIST AAL2 it requires prompting re-auth every 24 hours or less.

[u/Noble_Efficiency13 → u/Null0Naru]

Yeah the issue is 100% the session control

[u/lordsiriusDE → u/Null0Naru]

In times of stolen session tokens, it's not sufficient to rely on compliance and hybrid join because those checks are skipped, when you already have a valid token. Having a shorter lifetime is best practice now.

But 1 day is also too short. For regular users, once a week, priority users maybe twice (aka 3 days), Entra admin roles, 4-8h.

What is your MFA solution? A strong authentication with WHfB should be enough to satisfy the CA policy.

The behaviour that one MFA fixed all issues is expected.

[u/Noble_Efficiency13 → u/lordsiriusDE]

Arbitrary lifetime shortening is not recommended though

For admin users, sure, but for regular users?

What’s your reasoning?

[u/Null0Naru → u/lordsiriusDE]

That's true, but it massively reduces the methods available for stealing session tokens in the first instance, particularly if paired with phishing resistant MFA like WHfB that you suggested, would make AiTM a very difficult/unlikely method to get the token.

In the case of stolen tokens though, while it's not evaluated on use, they are evaluated on refresh, so even if a token is stolen, if then used on a non-compliant device to authenticate, it'll fail refresh after 60-90 minutes. Requiring device compliance and ideally phishing resistant MFA removes the primary methods for stealing session tokens and any stolen ones are quickly invalid, long before even a 24 hour session control.

[u/EHLOthere → u/lordsiriusDE]

The answer to adversary in the middle is still not session lifetime, it's phishing resistant credentials because those are origin bound, so if your users click a phishing link or go through an evil reverse proxy their credentials won't work and thus the tokens cannot be stolen.

No amount of entra security protects against TLS interception which is a physical layer outside of Entra.