Microsoft Entra Suite Tech Accelerator
Aug 14 2024, 07:00 AM - 09:30 AM (PDT)
Microsoft Tech Community

Conditional Access Policy will not save "Validating Policy"

Brass Contributor

I have a conditional access policy to enable MFA. It's all set and good. I have it shown here.conditional-access.png


I later wanted to go into "Session" and enable "Sign-In Frequency" and set it to the recommended 90 days. After I hit save I get "Validating Session" at the bottom. But it never actually saves at all.

I tried re-creating the policy from scratch including this setting and it will not save. I don't know why.

23 Replies
Hello, the Azure AD default configuration for user sign-in frequency is 90 days, which should explain what you're experiencing (can not save something that is already set).



So, when using MFA, how do I get it to add the prompt "Remember this device for X days" option? Because under "Remember multi-factor authentication on trusted device" setting it tells me to use Conditional Access:

NOTE: For the optimal user experience, we recommend using Conditional Access sign-in frequency to extend session lifetimes on trusted devices, locations, or low-risk sessions as an alternative to ‘Remember MFA on a trusted device’ settings. If using 'Remember MFA on a trusted device,' be sure to extend the duration to 90 or more days. Learn more about reauthentication prompts.


So, I should enable it in trusted device? Or require MFA with each login when outside my network?

BTW, I just tried setting it to 45 days and it still won't save.

Hi, well the 90 days was something that just popped to mind so had to put it out there. As why it is not saving your settings I think it's better if I just link this for guidance.

And for reference


Configure authentication session management - Azure Active Directory | Microsoft Docs

I read the two reference links before. From what your link suggests, they are advocating that the remember device is not to be used. But also suggests you can enable the session sign-in frequency along with MFA (mostly from the comments) but that isn't working for me. it won't enable it. But it sounds like unless i want to reduce it from 90 days, I don't need it.
Hello again, sounds right to me as well as it’s basically about adjusting the default rolling window (90). But I would open up a support ticket with Microsoft anyway to get an answer as to why you cannot save your policy with a custom number. Perhaps something to do with the recent incident.

I too am experiencing the same hung 'validating policy' in conditional access. Mine is not a policy already active, a brand new policy with no bearing or effect on any other features or policies already being manipulated by conditional access. 

Me too. I can't create a new CA policy (or edit an existing one) where I change the "sign-in frequency" option to On. I can edit a CA policy that has "sign in frequency" turned on but I can't change the values for that frequency. This is all irrespective of what value I use (e.g. 90 days, 1 hour, etc.).

It's been like this for a couple of days or more. I've opened a case with Microsoft.

Hi, thanks for adding to the conversation. Could be what I said in a reply above, that it's an effect of the recent Azure outage (multiple M365 services). Please update with a response from the official support.

In my discussion with the microsoft rep, he had me do some sort of log and send it to him. I did so and they will get back to me.

That's great. Thanks for the update.

@ChristianBergstrom  @Tomnibus_MedOne have you heard anything back? This seems to be a recent bug. We're about to open a sev1 ticket on this. 

FYI, it's fallout from the Azure AD outage on Monday March, 15.
Ah, as I said above then. Thanks.

Hi @itomni@snout @ChrisShawLHC and possibly @Brownin88,


While this is broken on the Azure side of things, there is a workaround with Graph.


1) Create the policy in Azure AD without setting Sign-In Frequency.

2) Head over to Graph and sign in with your Global Administrator account

3) Run the following query: GET

(you may need to Consent to a few things under Modify Permissions)

4) Find the Policy you just created in the Response Preview and copy the ID


5) Change the request to PATCH and add the ID to the end of the previous request:

PATCH<id> and Edit your Request body to the following:

    "sessionControls": {
        "signInFrequency": {
            "value": 90,
            "type": "days",
            "isEnabled": true



6) Run the query (you may have to consent to a couple of things again)

7) Done! You will get a 204 No Content success message and the policy has now been updated

I have not yet. I submitted several things he asked for and they are reviewing it. I hope to hear something this afternoon.
This looks great! For me, with my open ticket. I don't want to change anything lest they conclude the problem doesn't exist anymore. But I hope this helps someone else.
Thanks for this. It's faster than getting all the PowerShell modules installed and doing it that way.
Well, I don't know if Microsoft Fixed things on its own or not. The MS tech was having me try all these things and it kept failing. He then had me run IDFix to fix problems with amy local AD. "To make sure there are no duplicates preventing me from saving the CA policy." I wondered why that would be an issue.

I ran Idfix and didn't have any duplicates but I had a couple other issues that I fixed mostly display name problems. I did not run an AD Sync at all. I just went in and tried to edit and save and it did. So, I think MS fixed it on the back end without me doing anything.
1 best response

Accepted Solutions
best response confirmed by Tomnibus_MedOne (Brass Contributor)

@Tomnibus_MedOne Yes, it started working for me as well yesterday, with no intervention required.


In fact, I haven't even heard back from Microsoft Support yet, despite opening the case 6 days ago and sending a chasing email a day or two ago.

View solution in original post