Anyone else having issues with the 'Terms of Use' feature not showing for some users?

Good point about existing sessions. Mobile apps are notorious for this - they'll cache an old authentication grant and skip anything new, like a fresh ToU. It's like they live in their own little world.

But the whole "test group is too small to call it a bug" line? Nah. 20% of a targeted group failing is a significant pattern, not an edge case. That's enough to raise a proper support ticket, not just shrug it off as config weirdness. Microsoft's own "works on my machine" logic shouldn't fly.

Your session theory is solid for the 'why', though. I'd add: check if those three users are frequent mobile/desktop app users, while the others are mainly browser-based. That'd be the smoking gun.

Everyone's fixated on sign-in logs, but the logs won't show you a missing assignment at the policy engine level. I've seen this exact pattern.

You said "no conflicting CA policies," but that's from your view in the portal. The system evaluates them in a specific order, and a grant control from a separate, lower-priority policy can satisfy the requirement before your ToU even gets a chance to fire. The user sees it as a bypass.

Try this: create a test CA policy that *only* requires the ToU for the same app and assign it directly to one of the three users. If they still skip it, then you've got a platform bug. If they don't, you've got a policy interaction problem in your main setup.

That's a great isolation test. I've used a similar approach before, but it only works if you clear all existing sessions first. A user with a cached session from a prior compliant login might still bypass your new test policy, making you think it's a bug when it's actually old state.

The policy order point is spot on, and it's a headache because the portal doesn't show you that evaluation sequence. Makes you wish for a proper simulation tool.

So the 3 users who bypass it completely, are they all using mobile apps? I had a similar glitch where cached grants in Teams mobile skipped new ToU prompts, even after clearing browser sessions. Might explain why it's only a subset.

>cached grants in Teams mobile skipped new ToU prompts

Oh, that's a really good catch. Mobile apps holding onto old permissions could totally explain a subset of users having issues. It's like they're not part of the fresh auth flow at all.

So how do you even clear a cached grant from the mobile side? Is it just uninstalling/reinstalling the app, or is there a sign-out option somewhere that actually works?

Been there, chased that ghost. You cleared browser sessions, but that's just the tip of the iceberg. The real culprit is almost always cached grants in native clients, like Outlook or Teams mobile.

The other posters aren't wrong about policy order, but if you've truly isolated it to just a ToU requirement, my money's on a stale authentication artifact. Those three users probably have a long-lived refresh token from a desktop app or mobile client that's considered a compliant grant. The system sees it as a satisfied control and skips the fresh prompt entirely.

You need to force a full token refresh. For a clean test, have them sign out of *all* Office or Entra-integrated apps, then revoke their sessions in the Entra portal under the user's sign-in activity. Then try again from a fresh browser. If they still skip it, you've got a real head-scratcher and a ticket to Microsoft is justified.

That's a solid step-by-step for a clean test. Revoking sessions in the portal is the nuclear option I usually recommend as well.

Just a practical heads-up: getting users to sign out of *all* integrated apps, especially on mobile, can be a support headache. They often miss one, like the OneDrive client running quietly in the background. I've found it's worth specifying they need to use the "Sign out of all apps" option in their Microsoft account security page, not just close the apps. Even then, it's a bit of a coin toss.

Ah, the classic "Terms of Use bypass" mystery. Everyone's pointing at mobile caches and policy order, which are valid, but there's another layer to this that often gets missed.

You said you configured the policy for a security group. Are those three users nested inside multiple groups, by any chance? I've seen a situation where a user inherits from a parent group that already has a different, satisfied conditional access grant. The system sees a compliant session from that *other* policy and treats it as "good enough," even though your specific ToU policy hasn't been evaluated for the current app. It's not a conflict, it's a precedence shortcut. The portal summary view won't show you that dance.

The isolation test suggested earlier is your best bet, but go one step further: create a brand-new test user, put them only in that one security group, and try from a pristine, never-before-used browser on a clean device. If the new user sees the prompt but your three problem users still don't, you've ruled out platform bug and confirmed it's an artifact of their existing session state or group inheritance. Then you can start hunting those cached mobile tokens with a real target.

You're absolutely right about the device state condition not being configured. The logs should show the policy as "not applied" with a reason of "device filter," but the original poster hasn't confirmed what they're seeing.

My caveat to your point is that Azure's policy evaluation can still be surprising. Even without a device state condition, if another policy with a "Require compliant device" grant is triggered first for the same user and app, it creates a compliant session. Subsequent policies, including the ToU one, might then see that compliant session as a satisfied requirement and skip their own prompts. It's less of a true anomaly and more of an undocumented evaluation order quirk.

This is why the isolation test, assigning a ToU-only policy directly to a user, is so critical. It removes the potential for any other policy to interfere.

Yep, hit this exact wall last month. The group assignment looks right, but the policy engine's logic can be a black box.

Everyone's jumping to caching (valid), but before you go nuclear with session revoking, check one quick thing: are those three users on corporate-owned devices already marked as compliant in Intune? If the CA policy doesn't explicitly exclude "Require compliant device" as a grant, the system might see the device state as a satisfied control and skip the ToU. It's a silent pass.

The isolation test is your next move for sure. But for a faster data point, pull the sign-in logs for one of those users. Filter for the app and look at the "Conditional Access" tab. Does it show the ToU policy as *Applied* (failed/not satisfied) or *Not Applied*? If it's "Not Applied" with a reason, that's your clue where the logic went sideways.

Yes, I've seen that exact split behavior in testing. It's almost always about the authentication artifacts already in play for that subset.

You mentioned checking for conflicting CA policies, but did you verify the order of evaluation? If those three users have a satisfied grant from *any* prior policy (even for a different app), the ToU requirement can be silently skipped. The portal's "Assigned" view doesn't show you this precedence.

Pull a sign-in log for one bypassing user, and filter for that app. Look at the Conditional Access status details. If it says "Not applied" with a reason like "Grant controls already satisfied," that's your answer. It's not a bug, just an undocumented shortcut in the policy engine.

Exactly. The silent pass from a compliant device grant is a classic, and it's one of the first data points I eliminate in testing. Your mention of checking whether the ToU policy shows as *Not Applied* in the logs is crucial.

A related nuance I've measured: if the sign-in log shows the policy as "Applied" but with a result of "Success" rather than "Require Terms of Use," that points to a different, earlier-evaluated policy fulfilling the grant. It's not just a device compliance shortcut, but any satisfied control from *any* policy for that user can cause the ToU to be skipped. The log detail is the only way to see this precedence in action.

For a truly controlled benchmark, I'd create a test user with no group memberships except the one targeting your ToU policy, and force a sign-in from a non-compliant, non-corporate device. If the ToU still doesn't trigger, then you're squarely in token artifact territory.

Yeah, that mobile vs browser split makes a lot of sense. I'm new to managing this, so I have to ask: how would you even check that usage pattern easily? Is there a report for "primary sign-in client" somewhere, or do you just have to ask the users directly?

Check the sign-in logs first. Don't guess.

Filter for one of your three bypassing users and the target app. Look at the Conditional Access tab.

If the ToU policy shows as "Not Applied" with a reason like "grant controls already satisfied," then an earlier policy is giving them a compliant session. The system shortcuts and skips the prompt.

If it shows "Applied" and "Success," then something else satisfied the requirement, like a compliant device state. That's your benchmark.

It's not a bug, it's how the policy engine works. The docs won't tell you this.

The precedence shortcut theory others mentioned is probably right. I've chased this exact ghost before.

One angle I haven't seen mentioned: check if those three users were recently added to the security group *after* signing in to the target app. The assignment can lag behind. Try temporarily assigning the ToU directly to one of the problem users, bypassing the group, and test again. That'll rule out a group propagation delay, which can look like a bug.