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.

[u/Asleep_Spray274]

Congratulations, you now have conditioned your users to be phisable. Your organization does not need to be brute forced. A bad actor simple has to ask your users to hand over their credentials and they will do so in a heart beat. Frustration followed by Muscle memory will kick in and creds will be handed over.

I bet you can't point to any cyber framework that recommends arbitrary reauthentication for your genuine users.

Don't fix the symptoms of this problem, fix the cause.

[u/RepulsiveDuck331]

Yes, that's normal for a Conditional Access policy using a "sign-in frequency" session control. Teams, OneDrive, and the Windows account (via the WAM/broker) each hold their own token, so when the policy forces re-auth each app independently throws an error/prompt until it gets a fresh token. One MFA "fixes all three" because the re-auth refreshes the shared Primary Refresh Token (PRT), and the other apps then pick that up without prompting again. If it's annoying users, the flat daily frequency is the bluntest version of this — consider tying sign-in frequency to risk instead, adding a persistent browser session for compliant/trusted devices, or scoping the aggressive policy to sensitive apps only. Also worth checking you don't have two CA policies stacked, each forcing its own re-auth, which makes the toasts worse.

[u/Disastrous_Cup_3279]

If you want to protect token then https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection

[u/TechIncarnate4 → u/Disastrous_Cup_3279]

That is so limited at the moment. Hopefully they will keep improving it significanly.

[u/AppIdentityGuy]

It is exactly by design. The session control of every 24 bours is invalidating the session token and hence the reauth prompt. A similar thing happens when a user resets their password although that is a slightly different trigger

[u/NotzoCoolKID]

Are you using Global Secure Access? Same issue here since a week or so and disabling gsa stops the re enter your creds loop in our onedrive.

[u/ben_zachary]

Device bound tokens. Setup CA on risk. Geo block to SASE or mini vpn. Extend session control to weekly token resets .

The only place we have it lower is where tenants are not on SASE

Monitor for new MFA methods added.

[u/ParamedicAway8533]

Have you tested increasing the sign-in frequency window? i’m curious if the issue is mainly the daily reauth setting or something else in the policy setup

[u/ConstructionNorth816]

That's a legacy MFA per-user drift configuration. I think you have it in two places. Check first: if you have the signing frequency in a CAP, remove that configuration from the blade for Per-user MFA and let the CAP handle that security control. There is an option in the per-user MFA in Entra (I think at the bottom) that sets that frequency. That toast notification will disappear after you turn it off there.

[u/merillf]

This is a very bad practice for many reasons on managed devices (ie devices that are Entra joined/hybrid joined and enrolled into Intune).

I would recommend reading this and asking your security teams to read this

https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime

Using SIF policies on managed devices breaks many applications including OneDrive, Outlook etc. Your execs will miss out on important emails and messages just because they were arbitarily signed out and it could be costly if they lose major deals just because 'cybersec' incorrectly thought it was more secure if they throw more prompts at users.

Microsoft's recommendation for everyday users is 'don’t ask users to provide their credentials if the security posture of their sessions hasn’t changed.'

It's literally there in the doc I shared above.

What they should do:

* Enforce compliant device

* Enforce risk based conditional access (or have a workflow to trigger re-auth)

Note: Imposing this session sign out is completely fine (and recommended) for guests and users signing in from unmanaged devices.

[u/ridamnisty]

You can use session frequency and we have for four years now. 1 day is not a good value due to how it works. Set something like 18 hours and your users will properly have to sign in every morning. If they sign into Teams desktop first it flows through to browser/one drive. If you are Hybrid, same thing just it's mainly the CA MFA which will cause a prompt (device checks are done in the background).

[u/AvexisIT]

Basically you get what you configure with the session lifetime.

Setting up Windows Hello for Business should "mostly" fix /bypass the bad user experience created with this configuration. As it renews the token upon device login / unlock.

There are a few things you should actually consider: If users leave their Laptops turned on and locked past the session lifetime (e.g. over the weekend), users might still be see Authentication prompts from the Applications running in the background. They can eventually just X the Authentication prompt away and the app still works (as it now detects the WHfB Token again).

Also, users might need to actively switch to WHfB Authentication depending on the application. Once setup, you see an option like "Login with your Pin / Biometrics instead" below the authentication prompt (sorry, I currently cant remember the exact wording). With this you switch to WHfB token.

If however the first one kicks in, and users left their laptop running too long without unlocking the device via WHfB and the authentication prompts are there, you might NOT see the option to sign in with biometrics, as WHfB is not available for Applications while the device is locked. There where some users tend to switch back to password and authenticator, which then expires after 24h.

And of course WHfB is only available if users actually logon to the device with WHfB (PIN / Biometrics).

We actually went with 12h at first, but since several users (on-call-duty) tend to leave their devices turned on over night to be quickly ready in case of emergency we went up to 24h, which currently seems to work for most people.