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:

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.

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.
Pingback: Azure AD Conditional Access Continuous Access Evaluation Becoming Default – Sean McAvinue
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?
LikeLike
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
LikeLike
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
Jerry
LikeLike
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?
LikeLike
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.
LikeLike
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!
LikeLike
I haven’t tested but I wonder if session persistence would help here if it was targeted to the VPN?
LikeLike
Probably not if you are signed in via seamless SSO and have other apps running, the device would have an authenticated token but worth testing
LikeLike