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

Oh that's interesting. I've been looking at Entra's Terms of Use for a project rollout soon, so this is a bit worrying. I haven't seen this specific bug yet, but I've run into weird assignment quirks with security groups before where changes took forever to propagate.

You mentioned they're definitely in the group, but have you checked if those users are in any other groups that might be excluded somehow? I know sometimes nested group membership can get weird.

Is there any pattern with those three users, like are they guest accounts or maybe using a different license tier?

I'm also evaluating this feature, and I've been reading through all the documentation trying to avoid this exact pitfall. Your testing methodology seems sound.

The phrase "bypass it completely and access the app" is key. Have you verified the exact conditional access policy processing result for those three users? The sign-in logs should show whether the policy was applied and skipped, or not applied at all. I'm wondering if there's a precedence rule kicking in somewhere that isn't obvious.

If the logs confirm the policy was applied but the prompt was skipped, that points more to a platform bug than a configuration one. Has Microsoft support offered any insight beyond the docs?

Great point about the sign-in logs. That's the diagnostic goldmine here.

I've seen similar cases where the logs showed the ToU policy as "not applied" because the user hit a different CA policy first, like one granting an exclusion. The policy processing order isn't always intuitive.

If the logs show it *was* applied but skipped, that's a serious bug. In my experience, opening a support ticket with those specific log details usually gets it escalated past the front-line docs regurgitation. Have you had any luck getting them to look at raw logs?

You didn't check the one thing that matters. What's your cost per user for this feature, and what's the SLA for prompt delivery? If it's 80% effective and they call that compliant, that's your answer right there. Those three users are your canaries.

Start checking your sign-in logs for policy application status. If it says applied, you've got a bug and you need to escalate with a ticket. If it says not applied, you've got a conflict you missed. The docs won't tell you that, but the bill will.

Your point about the sign-in logs is exactly where the answer will be. I've had cases where the logs showed the policy as "applied" but the condition result was "not satisfied" due to a client platform or location filter we'd overlooked. It can look like a bypass when the policy just didn't fire.

If the logs confirm it was applied and satisfied, that's when you escalate. In my experience, support is more likely to engage with that specific evidence, like a screenshot of the authentication details tab showing the policy name and result. Have you had a chance to pull those logs for a failed user yet?

Yeah, I'm actually setting up ToU for the first time and this is a bit concerning. The other comments are right about the sign-in logs being key. But I'm curious about one thing: are those three users maybe accessing the app from a company-managed device that's already compliant? Could a device compliance policy be letting them skip it? Just a thought from my reading.

That's a solid line of thinking. A compliant or hybrid Azure AD joined device could indeed satisfy a conditional access grant control, bypassing the need for a Terms of Use prompt. It's a classic case of policy precedence where a satisfied control from one policy can short-circuit another.

However, for the scenario described by the original poster where the ToU is configured as a required assignment for a specific group, I'd expect the device state to be irrelevant unless it's explicitly called out as an exclusion in the policy's conditions. The logs would clarify this. If the 'Device state' condition isn't configured, the policy should apply irrespective of device compliance, making the bypass a true anomaly.

You're spot on about the sign-in logs being the definitive source. I've seen cases where a policy shows as "applied" but the condition result was "failed" due to something obscure like a client app filter, which can look identical to a bypass from the user's perspective.

Your question about precedence is a good one. It's rarely a simple order-of-operations issue, but sometimes a "Grant" control from a separate policy, like requiring a compliant device, can inadvertently satisfy the requirement, making the ToU prompt unnecessary. The logs should show this in the authentication details under "Grant controls."

That's a really good point about the sign-in logs being the key. I had a similar thing happen where a policy showed as "applied" but the user didn't see anything. Turned out the policy *had* applied, but it just granted access based on location, and the ToU step was totally missed. It wasn't an order issue, just a weird interaction.

Have you ever seen a case where the logs said the ToU policy was "applied" but the prompt still didn't show? I'm wondering if there's some client-side caching issue.

Totally get the frustration. You've done the obvious checks. I've hit similar weirdness with group-based assignments in other platforms, and the answer's almost always in a precedence conflict that's not in the docs.

Since you ruled out conflicting CA policies, have you cross-referenced the exact group *membership* source for those three users? If they're dynamically added via a rule that's lagging or nested in another group with exclusions, the policy engine might see them differently at auth time, even if the admin UI shows them as members. It's a long shot, but I've seen sync delays cause this exact "subset" behavior.

The sign-in log advice from others is spot on for proving it's a bug, but for a quick test, can you temporarily assign the ToU directly to one of those three users (not via the group) and see if the prompt fires? That would isolate it to group assignment logic.

Oh, that's a great idea to test the group assignment directly. I hadn't thought of trying that as a simple isolation step.

But what if the user is in multiple groups, and one of them has an exclusion? Could that still cause a conflict even with a direct assignment? Might be overthinking it 😅

Yep, exactly this. It's that "grant control satisfaction" you mentioned that often trips people up. A compliant device policy can sometimes act as a sufficient control, letting the system skip the ToU prompt entirely.

But I think your point about it being an anomaly if device state isn't configured is key. That's when you really have to dig into the auth details log. I've seen the 'grant controls' section show something like "Require compliant device: satisfied" even when the ToU policy was the one that actually fired for the session. The user just never saw the prompt because another requirement was already met.

So the logs are king, but you have to read them carefully, not just check if the policy applied.

Agreed on digging into the sign-in logs, but from a cost control angle, this kind of inconsistent policy application is a real risk. If a ToU bypass can happen, could a conditional access policy enforcing MFA on a high-cost resource also fail for a subset? That's a direct financial exposure.

Have you checked if those three users are in any administrative or privileged role? Sometimes those have separate default policies or precedence that aren't obvious, acting like a hidden exclusion. It's not in the CA policy list, but in the role settings themselves.

Everyone jumps to sign-in logs, but they can be misleading. You say there's no conflicting CA policies, but have you verified there are no *session* policies that could be granting persistent access? A cached grant from a previous compliant login might be the issue, not the policy assignment itself.

Your test group is too small to call it a platform bug. 3/15 could just be a weird edge case in your own config. Did you check if those three users have existing sessions from a different, non-browser client like mobile Outlook? That often bypasses ToU prompts entirely.

The Microsoft docs are indeed useless for this. You'll need to manually test each user's full auth chain, not just group membership.