Users Aren’t Getting MFA Prompts Every Day

I often get asked by customers about the frequency of MFA for Office 365 / Azure AD. There is an assumption that when we enabled MFA, users should get prompted when they log in every morning. By default that isn’t the case – and has never really been the case. It also really shouldn’t be the case in most scenarios.

Microsoft documentation on MFA frequency is extremely detailed but honestly not as clear as it could be. In this post I will try to simplify the many factors that influence MFA timing and provide some guidance so that we can (somewhat) predict when and how often our users will be prompted.

Understanding the Role of Reauthenticating with MFA

It’s important when looking at MFA frequency to clearly understand the goal. The most common prompt users receive in a lot of organizations is on their primary device that is already in use. By default, the frequency of these prompts is:

  • Office apps – a rolling window of up to 90 days (inactivity), this is renewed at each authentication until revoked
  • Web Browsers – at each sign-in in a fresh browser session

This means that users by default, on a non-Azure AD joined device, users won’t be prompted daily (or even monthly) to use their office apps. This is by design. There is little value in prompting users every day to answer MFA on the same devices. This can lead to MFA fatigue, where users automatically approve MFA prompts without thinking about where the prompt came from. The real benefit of MFA is protecting against leaked credentials and/or brute force attacks. These connections will not be coming from the users own device so prompting devices at first connection, rather than constantly makes a lot more sense.

Factors that Influence the Defaults

The following factors can influence the times outlined above:

  • Using an Azure AD Joined Device
  • Configuring the “Remain Signed-in” Option
  • Configuring the “Remember MFA for X Days” Option
  • Configuring Conditional Access “Sign-in Frequency”
  • Configuring Conditional Access “Persistent Browser Session”

Let’s break down what each of these settings is and how they influence MFA prompts.

Using an Azure AD Joined Device

When we use an Azure AD Joined or a Hybrid Azure AD Joined Device, we log on to Windows and receive a Primary Refresh Token (PRT). This PRT enables us to use SSO with Azure AD an use the known device as the strong authentication method. In this scenario, we are not prompted for MFA as we have already satisfied the requirement by using a known device.

If we want users on Azure AD Joined Devices to be prompted when accessing Office 365 then we can use Conditional Access “Sign-in Frequency” which we will look at later in this post.

Configuring the “Remain Signed-in” Option

The option to “Remain Signed-in” can be enabled / disabled from the Azure AD Portal, located under “Company Branding” by selecting the Company Branding Policy.

When enabled, this option enables the Persistent cookie functionality which influences the behaviour of Browser Sessions. When a user signs-in, they will see the below message:

Screenshot of example prompt to remain signed in

Clicking “Yes” on this message will issue a persistent cookie, meaning that the web browser sessions will retain authentication cookies even after closing and reopening. This means that the lifetime of MFA before users getting prompted for browsers is brought in line with Office Apps.

Configuring the “Remember MFA for X Days” Option

This option is configured from the Azure MFA Service Settings Page and when enabled can be configured for between 1 and 365 days.

Enabling this feature will give users the option “Don’t ask again for X days” when authenticating with MFA. With the ‘X‘ being the number of days specified in the setting.

Screenshot of example prompt to approve a sign-in request

When users tick this box they are given a persistent cookie just like the previous setting however the amount of days we specify is the amount of time before they will be prompted again. This means that setting this to lower that 90 days will prompt users more often for Office clients but less often for Web Browsers.

Configuring Conditional Access “Sign-in Frequency”

The Conditional Access Session Policy for Sign-in Frequency allows us to specify how often a user is asked to sign-in. While this time aligns with MFA, it can be misleading as a user can authenticate multiple times without MFA and refresh their Sign-in Frequency timer when they are using an Azure AD Joined Device.

This setting works best as an example, the below examples from the Microsoft Documentation really help to clear this up:

If you have Azure AD joined, hybrid Azure AD joined, or Azure AD registered devices, when a user unlocks their device or signs in interactively, this event will satisfy the sign-in frequency policy as well. In the following two examples user sign-in frequency is set to 1 hour:

Example 1:

At 00:00, a user signs in to their Windows 10 Azure AD joined device and starts work on a document stored on SharePoint Online.
The user continues working on the same document on their device for an hour.
At 01:00, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator.

Example 2:

At 00:00, a user signs in to their Windows 10 Azure AD joined device and starts work on a document stored on SharePoint Online.
At 00:30, the user gets up and takes a break locking their device.
At 00:45, the user returns from their break and unlocks the device.
At 01:45, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator since the last sign-in happened at 00:45.

So from these examples we can see that when we are using Azure AD joined, hybrid Azure AD joined and Azure AD registered devices, users signing in to the machines or interactive sign-in will refresh the sign-in frequency. It’s important to keep this in mind when configuring Sign-in Frequency for these devices.

Configuring Conditional Access “Persistent Browser Session”

The Conditional Access Session Policy for Persistent Browser Sessions allows us to enable the functionality of the “Remain Signed-in” setting above for users automatically, bringing in line both Browser and App sign-in frequency.

How It All Comes Together

Bringing all of this information together, we can see how depending on the settings detailed above, our users will get MFA prompts at different intervals depending on the settings above, the machine state and the recent activity.

Some high level points to keep in mind from everything here:

  • Persistent Browser Sessions effect Web Browsers and allow authentication cookies to persist even after closing the browser
  • The default MFA interval is 90 days however this interval is refreshed at each authentication so it’s best to read this as 90 days of inactivity
  • With the “Remember MFA” or “Sign-in Frequency” settings, this can be reduced
  • It’s recommended (if licensed with AAD Premium) that you use the Conditional Access Session Controls rather than the other MFA settings
  • Users on unfamiliar devices will always be prompted for MFA at first logon
  • Azure AD Joined devices will authenticate with the PRT and not receive MFA by default

Keep in mind how often you should prompt your users, especially when they are on the same corporate device and have potentially entered an encryption pin and used biometrics to authenticate in the case of Windows Hello for Business.

For more details on configuring these settings check out the official Microsoft Docs here.

9 thoughts on “Users Aren’t Getting MFA Prompts Every Day

  1. Pingback: Azure AD Conditional Access Continuous Access Evaluation Becoming Default – Sean McAvinue

  2. jay

    thanks for the blog. if a browser app is configured with conditional access to grant access using mfa and to sign in every 1 hour frequency, the user ticks ‘don’t ask again for x days’ for mfa, 1 hour later, will the user can to re-sign in again with mfa?


    1. Sean McAvinue

      Hi Jay,
      Yes a sign-in frequency policy targeted to browser would require the user to reauth completely after the specified time, in this case, 1 hour


  3. Hello, thanks for the great article.
    I setup authentication for our company VPN client, so users are synchronized to AAD. I would like to create Conditional Access Policy, where users will be prompted for MFA. I want to prompt them every time they sing-in. Another condition would be, that device must be Hybrid Azure AD join, Is it possible to push MFA every time they use VPN?
    Thanks for advice


    1. Hi Hanakjrs,
      For MFA authentication for VPN – depending on the vendor, You will most likely require an NPS infrastructure with Azure MFA configured there. What is the VPN software you are using?


      1. We are using FortiGate SSL VPN, which We configured in Azure Enterprise Application, We selected synced group from Active Directory and gave them access to our VPN. I made Conditional Access Pocily, where I selected this Group and FortiGate SSL VPN. We require MFA auth for Sign-in. However when I check Sign-in logs in Azure for this App I see MFA requirement Previously satisfied. But We would like to force MFA for every Sign-in.


    2. Jared

      Same issue. I’m migrating from Okta for Global Protect VPN and in Okta they have the ability to set a policy such that it prompts for MFA at every login. When I switched to Azure SSO there isn’t a setting like that, still trying to figure out I can prompt for MFA every login. The azure logs just show it letting it through. Fine if it wants to save creds but should have an option to prompt for MFA everytime you sign into the app if you want. If you know of any tweaks, let me know as well!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s