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

Fewer login prompts: The new “Keep me signed in” experience for Azure AD is in preview

Community Manager

A common request we get from our customers is to reduce the number of times users are prompted to sign into Azure AD. One way to reduce the frequency of prompts is to check the “Keep me signed in” checkbox on the sign-in flow, but our telemetry shows that usage of that checkbox is very low. But we know from talking to customers, that cutting down on the number of sign-in prompts is REALLY important. Nobody wants to have to sign-in to an app multiple times!


So today I’m happy to share that we’re improving how “Keep me signed in” option is shown to users. We’re also adding intelligence to ensure users are prompted to remain signed in only when it’s safe to do so.




Read about it in the Enterprise Mobility & Security blog.

30 Replies

and you thought replacing a simple checkbox with an extra annoying pop up dialog box is good because of what again?! people want to move away from sign in page as quickly as possible, even having separate dialogs for username and password was something "interesting". now you added the 3rd one?!

Our data shows that having a bit of friction up front ultimately improves the long-term user experience as it reduces subsequent sign-in prompts.


actually we would like to enable this setting for all users as it improves the user experience and allows us to get rid of the additional pop-up. In a recent case we found that this setting can not be controlled by GPO etc. Are you planning to add this option ? 

Unfortunately no. We believe that users need to make the decision, based on where they're signing in from, about whether they want their authentication to persist. As such, we don't have a way for tenants to turn on persistent auth without user interaction.


Something that is not clear to me is how this interacts with ADFS?


Does it makes a difference if you tick the checkbox before one is redirected to the internal ADFS log in page upon entering his UPN.


I don't know if your telemetry also shows how many users quickly thicking the box after entering their UPN and the browser is already starting to redirect to the internal ADFS log in page.

Hi Bart,

unfortunately the image used on the initial post in this thread shows the *old* experience. The change we're making only applies to the *new* sign-in experience. You can click the link to the blog post which will show you the exact change.

With this change, we're removing the checkbox in favor of a screen that appears after credential collection. In ADFS scenarios, the new screen will appear after successful authentication in ADFS. As such, the user doesn't have to worry about checking a checkbox before entering their UPN (and getting redirected).
Can I enable/disable this preview from OWA? I believe that I did not allow it first time I was presented with the option - and have not been prompted again.
BTW... Users have been complaining about the "Keep me signed In" checkbox in OWA for as long as I can remember. My results have always been erratic for the "Keep me signed In" checkbox. It's been especially annoying to be logged out without the option to save current work. Just a pop-up notice of the log out AND then find that no draft was saved for the email response I'd been editing.
We haven't rolled out the new "Keep me signed in" prompt to production yet, so I'm not sure what you're seeing. However, you should be able to clear any state you've gotten yourself into by clearing browser cookies.

With regards to your feedback about providing notice of log out in OWA, I'll forward this to the relevant team in Outlook.

Thanks for yor reply..

OK, I was able to get the new log on option back for OWA.

Unfortunately it doesn;t seem to be working any differently that the old version.

I was logged off from OWA again today.


FYI I work remotely for several sites

So I don't use the full Outlook client, but instead keep in touch thru multiple OWA sessions in IE.

What I've noticed...

I ONLY have problems with sites who are running Office 365.

- Never have issues staying logged on with sites that maintain Exchange/SMTP on site.

- So I am guessing the root cause for not being able to stay logged on?

i.e. is out of local admins control,  issues are "baked into" Office 365 or the admins at MS have disallowed staying logged on?


Easy for me to be suspicious when 3rd party administation could be involved.

One of the reasons why Office 365 still hasn't won me over.



Hi there Bruce - My name is David Los, I work on the Outlook on the Web team.  For Office 365 Tenants, there is a default activity timeout of 6 hours, that is set for all tenants ( And admin can configure that or disable the Activity timeout if they desire.  If a user selects KMSI, they should not be hitting the activity timeout.  


If you are experiencing something different, I recommend reporting the feedback from within OWA.  Click the question mark at the top/and select feedback. 

Thanks for the feedback


David Los

Is there a way to force my tenant to the new login experience? If not what is the current timeframe for when this will be rolled out?




I "regularly" log on as a different user on this machine for testing purposes. As per this blogpost this appears to have disabled the "Stay signed in?" prompt for my user.

Is there any way to stop Microsoft from thinking that this is a shared device? Having to log on -every- time is pretty frustrating. Especially as I have MFA enabled.

Unfortunately, there isn't a way to disable the shared device logic right now. The workaround is to use different browsers.

Kelvin, could you share any additional information about the shared device logic? I receive the additional keep me signed in prompt when using google chrome but it will not appear for me in IE, nor for any of my colleagues in the office.

Is there any particular setting that it could be picking up from IE?



Hi Jason,

Do you have any sort of SSO set up on your Windows machine? Eg. Browser SSO (where the account that is connected to Windows SSOs in the browser), or Seamless/Desktop SSO? If so, we won't show the prompt since SSO is happening.

Hi Kelvin,


We are experiencing an issue with the KMSI feature for IE11 only. We currently use ADFS 3.0 with Single Sign on. When users connect to services such as the office portal or SharePoint they are prompted to select there account, after which the service signs in. The issue is that the KMSI prompt is not presented to the users in the new experience. Within the old experience users were able to check the box to remain signed in.


What's strange is that from testing in other browsers such as Edge or Chrome we receive different results. In Edge users are redirected to the old sign-in experience where they can check the box. For Chrome, they again are taken to the old experience sign-in screen, but after entering there credentials they are redirected to the new KMSI prompt which can be selected and keeps the user signed in. 


From our on-prem ADFS server we have enabled the KMSI feature, this has also been configured from the Azure Tenant level within the company branding section.


Any help would be greatly appreciated.




Hi Kelvin


We have ADFS and Single Sign On working through IE with the "Automatically logon only in Intranet zone" set.  


Our users don't get the final option for Keep me signed in, which would be ok if only the first Pick an account window also did not show.  This seems like a pointless prompt because if I select Use another account and then enter it will still sign in with the currently logged on user. So if this is the behaviour, why do we have the option to pick an account for SSO enabled browsers when it just appears to ignore it?


A better user experience for SSO-enabled browsers would be to not show the first prompt, and just log the user straight in.  Alternatively - although less preferred - is to give them the prompt to allow them to stay logged in.  Having the first prompt really defeats the purpose of SSO.


Let me dig into this a bit more and get back to you.
You should no longer be seeing the old sign-in experience, so what you're seeing in Edge and Chrome is weird. What's the URL for when you see the old sign in experience in Chrome/Edge?