Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Introducing security defaults
Published Jan 09 2020 09:00 AM 239K Views
Microsoft

Hey folks,

 

In 2012, we started the Identity security and protection team for our consumer accounts (Microsoft accounts used for signing in to OneDrive, Skype, Xbox and such). We started out by doing two things – putting metrics in place for everything (so we could be confident we’d know what works) and establishing a security minimum standard for our consumer accounts. This includes measures like registering a second factor, challenging accounts when we see risk on the login, and forcing folks to change their passwords when we found them in the hands of criminals. The results have been very good; while there was some angst involved in requiring multi-factor authentication (MFA) registration to play Xbox or on that Hotmail account that’s “worked fine for 16 years!”, the net impact was massively positive – e.g., measuring from 2014 to 2019:

  • Unaided password recovery jumped from less than 20% to more than 90%
  • Account retention increased by more than 10%
  • Our ability to challenge users when we see risk led to a 6x decrease in compromise rate. This means that even as we’ve had a substantial increase in users, we have fewer compromised Microsoft accounts than ever before.

In 2014, we started making these technologies available to our Azure Active Directory (AD) organizational customers, and we’ve learned that they’re very effective – for example, our telemetry tells us that more than 99.9% of organization account compromise could be stopped by simply using MFA, and that disabling legacy authentication correlates to a 67% reduction in compromise risk (and completely stops password spray attacks, 100% of which come in via legacy authentication).

 

Unfortunately, we’ve been less successful than we’d like at raising awareness and getting folks to adopt the technologies. While the tools are in place for customers to stop these attacks, adoption is significantly low. Despite marketing, tweeting, and shouting from the rooftops, the most optimistic measurement of MFA usage shows that only about 9% of organizational users ever see an MFA claim.

 

If you’re reading this blog, you’re probably a security or identity enthusiast. You’re aware of the importance of securing identities and taking advantage of key capabilities in the platform. But for most people, especially individual developers, small businesses, or folks just experimenting with our Azure, Office, or Dynamics services, security isn’t the first thing on their minds. The goal is just to find the shortest path to setting up email and document sharing, or building that first Azure application – they won’t configure security settings until they’ve been hacked.

 

With millions of organizational accounts vulnerable to preventable compromise each year, we felt we needed to take a different tack – to protect organizational accounts just like we do the consumer accounts. We experimented with a few different approaches (including “Baseline protection”), listened to partners and customers, and learned a ton along the way. The result of all this learning is Security Defaults.

Security defaults provide secure default settings that we manage on behalf of organizations to keep customers safe until they are ready to manage their own identity security story. For customers like this, we’ll manage their security settings like we do for our Xbox, OneDrive, Skype and Outlook users.

For starters, we’re doing the following:

 

  1. Requiring all users and admins to register for MFA.
  2. Challenging users with MFA - mostly when they show up on a new device or app, but more often for critical roles and tasks.
  3. Disabling authentication from legacy authentication clients, which can’t do MFA.

 

We will judiciously expand these security defaults to maximize protection for our users, but as MFA prevents >99.9% of account compromise, that’s where we’re starting. We are applying security defaults for all license levels, even trial tenants, ensuring every account can be protected by MFA.

 

None of this replaces the rich security capabilities in Azure Active Directory. If you are a person who uses Conditional Access to manage your break glass accounts with terms of use controls, chooses MFA based on device compliance, or integrates Identity protection reports into your SIEM, you’re far more sophisticated than our target user for Security Defaults. If you’re thinking of break glass accounts or exception scenarios, Security Defaults isn’t for you – you want Azure AD Conditional Access.

 

Since introducing the feature, we’ve enabled Security Defaults for more than 60k newly created tenants. More than 5k other tenants have opted into Security Defaults. All of these organizations have significantly reduced their compromise rates; only a few hundred have opted out, mostly to use Conditional Access. We’ll take the learnings from these tenants and continuously tune as we eventually roll this out to all new tenants, then to tenants who have never looked at security settings. We will expand first to apply security defaults to all new tenants as well as applying it retroactively to existing tenants who have not taken any security measures for themselves. We’re experimenting, listening and adapting as we go.

 

If you have an existing tenant where you’d like to enable security defaults, or are ready to turn it off and move up to using Conditional Access to manage your access policies, you’ll find the settings in your Azure AD tenant configuration in Azure Active Directory, Manage, Properties – look for “Manage Security Defaults” at the bottom of the page:

 

 

Security defaults.PNG

 

Click there and you’ll see the blade that allows you to enable security defaults. But again, security and identity enthusiast – you probably want the advanced controls that Azure Active Directory Conditional Access gives you. 

 

Security defaults2.PNG

 

You can’t enable Security Defaults if you’re already using conditional access policies or other settings which conflict. If you do, you’ll see this warning:

 

Security defaults 3.PNG

 

Some of you may have tried out baseline protection policies – security defaults replaces all those settings, and we will stop enforcing them on Feb 29th. If you’re reading this, you probably want the granular control Conditional Access gives you, so in place of baseline, set up the equivalent Conditional Access policies as outlined here.

 

The Identity Security team is super-focused on preventing account compromise, and ensuring there is no barrier to secure, multi-factor authentication using secure protocols is a critical step forward. As always, we’d love your feedback. Reach out to me at @alex_t_weinert on twitter!

 

Stay safe out there,

Alex

 

 

71 Comments

@Alex Weinert I have always wondered what the settings look like for the Baseline conditional access polices - such as the Block legacy auth, so that I could replicate in a custom CA policy with exceptions for other customers with AAD P1. Does the article at https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-acces... replicate the baseline policies exactly or are there things you are doing in the baseline policies that differ?

 

If I understand correctly, there are 2 types of customers > Those that manage their own security and have sophisticated CA policies in place, and those that don't know or care to do so. Will the end goal be to have Security Defaults enabled by default (this would explain the over simplified UI experience) for new tenants or customers without AAD P1 in the future?

 

I love the direction of travel btw.

Steel Contributor

@Matthew Levy Love this! We have hundreds of old customers with no Conditional Access policies created nor enabled Baseline Policies. I understand you are slowly rolling out Security Defaults to existing tenants. How do you inform the customers you will enforce Security Defaults? Message Center? Email to admins? Message in portal.azure.com?

 

Just figuring out how to prepare for unplanned move to Security Defaults.

Iron Contributor
"We’ll take the learnings from these tenants and continuously tune as we eventually roll this out to all new tenants, then to tenants who have never looked at security settings. We will expand first to apply security defaults to all new tenants as well as applying it retroactively to existing tenants who have not taken any security measures for themselves." * Will you enable for tenants that have looked at Conditional Access but not enabled or created any rules? I find the way you put this automated process of enabling Security Defaults on existing tenants confusing. * Will said tenant get any alert/ notification ahead of time, or will you just go all in and break integrations, break glass accounts etc. in the process? I like Security Defaults, don't get me wrong. I'm just afraid that we'll get a lot of frustrated and confused CSP customers in near future.
Copper Contributor
Microsoft has done a great job by releasing security defaults, however it's lacking the ability to exclude a single emergency access account. As per https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-emergency-acces... one of Microsoft's best practices for Azure Active Directory (Azure AD) is to have a cloud-only emergency access account which is excluded from MFA. This is similar to the built-in Administrator account in traditional Active Directory, without the ability to exclude a single account most organizations without AAD P1 licensing will simply leave security defaults turned off. If we want fine grained exclusions or multiple emergency access accounts it would then make sense to purchase AAD1 P1 licenses and configure Conditional Access. I've created a feedback suggestion here - https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/39425896-exclude-emergen...
Copper Contributor

Hello everyone,

 

I spent the last month looking at the security options offered by Azure and I must say that Microsoft did a great job! 

 

3 days ago we enabled the security defaults same as explained by @Alex Weinert. Since then we have one issue with Dynamics 365 Business Central that is now blocked by these settings.

 

Here is the error message we can see on the sign-in log (account used by Business Central to send emails):

Status: Failure
Sign-in error code: 53003
Failure reason: Access has been blocked due to conditional access policies.
Application: Office 365 Exchange Online
Location: Toronto, Ontario, CA
IP address: 52.138.16.175
Authentication method: CloudOnlyPassword
 
Requirement: Primary Authentication
Policy Name: Security defaults
Grant Controls: block
 
How can we prevent this kind of false positives? 
As I added the IP range of the Microsoft data center used by business central as a trusted Named location but it still doesn't work.
 
Thank you for your help.
Copper Contributor

Thanks for the info Alex.

How would you manage this setting using PowerShell?

 

-Tom

Copper Contributor

I implemented Security Defaults for one of my tenants, and configured MFA for an end user account.  I then tested logging into office.com from several different computers, in geographically different locations and found that it does not always prompt for secondary authentication. For example, i logged into my customer's office.com account from my home pc and it did not prompt. We are in the same physical town, a few miles away from each other. I then tried the same thing from a computer about 10 miles away in a different town and it did not prompt for mfa. I then attempted to login from a computer in a different state and it DID prompt for mfa. When i inspect the azure login logs, every login says it is using the "Security Defaults" policy, but it is NOT prompting for 2fa authentication in many circumstances. Is there a document available that explains, in detail, under what circumstances Security Defaults will prompt the end user for MFA authentication?

Copper Contributor

This is a great idea but I only stumbled across this setting when browsing around the Azure Portal. It really should be a banner at the top of the Security blade.

Brass Contributor
Thank you , Great Article Enabling Security Defaults equivalent to Enable all Default CA Policies .
Copper Contributor

Hi.

Is there a way to Enable Security defaults just for a few ‘test’ users instead of enabling for the entire tenant? -  

We would like to prepare/test (see the entire process, see the prompt to register for multi-factor authentication, etc.) internally (IT department) before we turn it on for all end-users.

 

This way we can communicate in advance what they can expect.

 

Thanks.

Steel Contributor

.

Copper Contributor

Hi, 

 

When you're saying -- "Some of you may have tried out baseline protection policies – security defaults replaces all those settings, and we will stop enforcing them on Feb 29th." 

 

Were you referring that with effective Feb 29th, "baseline policies" will be replaced by "security default" and these settings WILL BE ENFORCED for all applicable tenants ? 

 

If that's the case, does this apply to all kinds of Office 365 licensed organizations, or only those service providers managing Office 365 tenants participated in CSP ? 

 

Thanks,

 

Eric

Copper Contributor

Our organization has same questions. Do we have the ability to control when this setting will be enforced? 

Copper Contributor

How to make exceptions to the security default? Is this still possible? If not then;

I'm all for increasing security, however for now 95% of organizations cannot enable the security defaults as it will break many mail enabled applications. We will still use conditional access policies, because with security defaults we cannot make exceptions.

 

The microsoft documentation is unclear about this.

Copper Contributor

I agree with @Luitzen_Boot  post.

This is the same issue I posted a message about almost a month ago here in this thread.

Can anyone from Microsoft step in and let us know what can be done?

Steel Contributor

I'm not from Microsoft but my thinking is that if you enable Security Defaults you accept these defaults. Most of my customers will not be able to accept these since almost everyone need some kind of exception, mainly:

- users that can't run the Authenticator app but need text message instead

- Some few accounts which can't have MFA at all

- Some few accounts still using legacy authentication

 

In that case, Microsoft seem to point us to not using Security Defaults but create our own Conditional Access instead.

 

But to be honest, I think Microsoft themselves are slowly rolling this out and learning and listening. I've reached out to Alex on Twitter and hope he can join the conversation here.

Copper Contributor

@Jonas Backsounds reasonable, however MS requires it's partners to be compliant. If we do not enable security defaults we're not compliant. So we can choose non compliant or break e-mail enabled third party applications. It seems this has not been thought through carefully.

Copper Contributor

Are the security defaults going to force MFA for Outlook/email when implemented or is this just for Azure AD at this time?

 

While I agree MFA needs to be implemented for all customers/clients. We need time for a full Office 365 MFA rollout.

Copper Contributor

We recently applied the change on our domain, and it has broken the connection to Outlook. Our users can still access outlook using the browser, but trying to get the outlook client isn't working.

 

A couple things I've already attempted.

 

1. Reset PW

2. Clear out app pw's 

3. Clear out windows credential manager

4. create new App PW

5. Create new Outlook profile

6. Reboot

7. Install

 

Nothing that I have done has resolved the issue. What should i be trying next? 

Steel Contributor

I think Microsoft should be prohibited from calling anything that didn't make it out of Preview status, and only existed for a short time - "Legacy".  In the AAD Portal, if you select a Baseline policy it says:

 

"Baseline Protection policies are a legacy experience which is being deprecated. All Baseline Protection policies will be removed on February 29th, 2020. If you're looking to enable a security policy for your organization, we recommend enabling Security defaults or configuring Conditional Access policies."

 

Just my two cents.  Something like "Bad idea" or "boycotted feature" would be better.

Copper Contributor

We currently have all Baseline policies enabled, as well as use a number of our own Conditional Access Policies that further secure access to various services.

 

In order to achieve the same functionality going forward, it looks like we would have to purchase AAD P2 licenses to re-create what the baseline End-User Policy achieved. The risk-based CA condition is not available with the AAD P1 licenses that we already have.

 

Can you please confirm that my understanding is correct? It would be better if we could use custom CA policies in conjunction with the Security Defaults as we have been able to with the End User Policies...

Microsoft

Lots of questions here, going to try to catch them all up at once.

@Matthew Levy, the article is intended to exactly replicate the policies. As to your second point, there are a spectrum of customers at all license levels. We want to make sure everyone starts with safe defaults (MFA always). Come customers may choose to change those defaults, and many organizations will choose to turn off security defaults and take the reins themselves with Conditional Access. Glad you like the direction!

@Jonas Back we are spec’ing the comms plan and rollout plan now – we’ll broadcast here before we start engagement.

@Olav Rønnestad Birkeland see prior response on comms. The cases you are describing wouldn’t happen per plan – if a tenant has *any* conditional access policies, creds policies, or other overlapping setitngs, we wouldn’t apply security defaults.

@jakemarston I think we have threaded on Twitter on this – break glass is about continuity. The phone app in passwordless mode doesn’t use the MFA infrastructure, nor does FIDO. Regardless, security defaults is really about ensuring that *before* tenants are thinking about break glass or other more complex policies, they are safe.

@RBdeltA I think you are hitting an endpoint that can’t do MFA, thus getting blocked. We should have no need to hit such endpoints in our first party apps. Will dig in and get back to you if we have questions.

@TomPhillips we will add the setting to graph for powershell management

@Kent Gerhart at this time, we are prompting when our ML system determines that the risk justifies the challenge. The rules factor in many aspects of the login, including behavioral familiarity, threat intelligence, and many many other factors.

@Gavin Meerwald it isn’t appropriate for all tenants. Most large tenants or security enthusiast smaller tenants shouldn’t use it, but set up Conditional Access instead.

@Lassaad glad you enjoyed it.

@CarlosKYO no, you are looking at Conditional Access. See the link in the blog for how to set these policies up.

@ericng99 this is universal, we are removing the baseline policies for all tenants.

@brandon nesbitt no, if you want that control use Conditional Access.

@Luitzen_Boot no, if you want exceptions use Conditional Access. Security defaults is a “starter” setting for orgs aren’t yet dialing in their own security settings.

@RBdeltA if you want per-app exceptions, per user exceptions, etc. that’s Conditional Access.

@Jonas Back  yep I am here. Security defaults is not a replacement for Conditional Access. Yes, we expect that as orgs become more sophisticated in their rollouts they will transition from Security Defaults to Conditional Access, and we don’t think anyone using Conditional Access should go from that to Security Defaults.

@Luitzen_Boot that’s not accurate – partners must protect their users and all delegated admin access with MFA. Security defaults is *not* the only way to do that – use Conditional Access. We do not recommend of old clients that can’t handle MFA claims.

@Jimburris006 for all connected apps.

@Gus_Tejada please dm me at @Alex_t_weinert on twitter and let me know the specifics of the app you are using?

@Jeremy Bradshaw fair feedback. Will definitely take it to heart.

@ablanken yes, that is correct, if you want risk-based MFA you need P2/E5.

 

 

Copper Contributor

We recently applied the change on our domain, and it has broken the connection to Outlook. Our users can still access outlook using the browser, but trying to get the outlook client isn't working.

 

A couple things I've already attempted.

 

1. Reset PW

2. Clear out app pw's 

3. Clear out windows credential manager

4. create new App PW

5. Create new Outlook profile

6. Reboot

7. Install

 

Nothing that I have done has resolved the issue. What should i be trying next? 

 

I'm replying back to my own thread made back on 2-10-2020. I was able to resolve the issue by enabling Modern Authentication using powershell. Here is a good link I found in case someone has the same issue my company had.

 

https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-mo...

 

 

 

 

Copper Contributor

@Gus_Tejada That is exactly what I sent you in a private message shortly after you made that post.

 

@Alex Weinert in pretty sure the original post has been modified after my reply.

Iron Contributor

@Alex Weinert  Thanks for the very detailed explanation and individually answering posts by admins. Glad to hear the Security Defaults will not enable if Tenant already has Conditional Access policies applied. I will be verifying that is the case very soon. 

Copper Contributor

@Luitzen_Boot you did, and I much appreciate it!

@Alex Weinert 

I am curious about the details around what will happen on February 29th 2020 with regards to existing configured Baseline policies and Security Defaults.

 

I’m wondering about the Baseline policies that are already configured for tenants, in some cases only 1 or 2 of the 4 are configured (end user protection for e.g.), so will they be off by default and disappear on 29 Feb? Will Security Defaults be off by default, therefore leaving a tenant which was previously protected in a worse state than before. If Security defaults will be ON by default, what will happen with legacy auth exceptions etc?

 

Anyone else have other concerns?

Copper Contributor
@Alex Weinert Having an Emergency Access or Break Glass Account is not complex and is thoroughly recommended by Microsoft https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-emergency-acces.... It's unbelievable that this account isn't created automatically and excluded from security defaults, like AWS has accomplished by making the first account the root account. I understand that if we want fine grained exclusions conditional access is required, but for small customers/environments that only have a few administrators having a EA/Break Glass account is absolutely crucial. Since Microsoft is turning on Security Defaults for new tenants you are going against your own best practices and making Security Defaults impractical. I seriously hope that Microsoft reconsiders having a "single" exclusion for Security Defaults.
Copper Contributor

@Alex Weinert 

Interesting, activating Security Defaults means we can't use any other Conditional Access policies. For instance, device compliance policies to ensure all devices with company data are encrypted. So, to maintain proper security we're forced to use Conditional Access, but using our own Conditional Access instead of Security Defaults. Are we forced to license all guest users with AAD Premium in our tenant?

Iron Contributor

@cloud_compadre

B2B guest users must be licensed 1 (license) to 5 (guest users), or greater license to guest users ratio (X>=1:5).

https://docs.microsoft.com/en-us/azure/active-directory/b2b/licensing-guidance

Steel Contributor

That B2B licensing stuff that runs on the honor system, and we all know that means customers will get weird deals thrown at them later on to avoid backdated bills - is just as stupid as it gets.  This kind of billing mindset is, stupid.  I can't think of a better word for it.  Maybe I'm stupid too.

Copper Contributor
How is this related to the end of support for Basic Authentication for the mail protocols announced for the 13th of Ocober? (https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-...) Will applications using Basic Authentication for IMAP and POP to EWS stop working the end of February when legacy authentication will be blocked by default? Or am I mixing up things now?
Copper Contributor
Copper Contributor

Thanks for the response Alex. Will you be posting the PowerShell cmdlet that will be used to manage this setting? 

Copper Contributor

I was hoping to find a PowerShell cmdlet to display this setting too but so far I have not been able to find anything. 

Would it be available through Graph for example ? If so, what endpoint?

I feel the customers for Microsoft who administers more than one customer in their CSP tenants, are forgotten when it comes to functionality like this, its easy to administer if you have just your one tenant to work with... Having an overall control of all customers this setting should be visible through either Graph or a cmdlet.

Copper Contributor

Hi Alex or anybody who can help me,

We have  Azure AD (no Premium license) with 600 users of O365. We have "Modern Authentication"  already enabled. We want to enable MFA for set of users who considered to be high risk. I am hesitant to enable "Security Default" as there is no way to exclude users/group. Is it advisable to enable MFA individually at each users level? Will it affect anyway later enabling Security default or any other security measures?

 

Thanks

Charles

 

Copper Contributor

@charlesntoroaluminum 

These are your options:

"You can use security defaults to enable multi-factor authentication for all users, every time an authentication request is made. You don't have granular control of enabled users or scenarios, but it does provide that additional security step.
Even when security defaults aren't used to enable multi-factor authentication for everyone, users assigned the Azure AD Global Administrator role can be configured to use multi-factor authentication. This feature of the free tier makes sure the critical administrator accounts are protected by multi-factor authentication."


Source: https://docs.microsoft.com/nl-nl/azure/active-directory/authentication/concept-mfa-licensing


So to answer your question, you can't enable MFA individually with a free license to a specific set of users (except for global administrators).

Copper Contributor
@Jan van VeldhuizenIt's not related. You're confusing basic authentication with legacy authentication. Security defaults block legacy authentication.
Steel Contributor

@Luitzen_Boot , is there any other authentication type than basic, which "legacy" is meant to be covering?  I don't think so, not in Azure AD.  There's just basic and then Modern (inferring all that modern entails).

Copper Contributor

@Jeremy Bradshaw 

Fair enough. Basic authentication falls under the broader category legacy authentication. There's a list here:

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-acces...

Copper Contributor

@Luitzen_Boot  Thanks for your response. But I cannot enable Security default as there are legacy apps like Outlook 2010 and 2013 are still in use for few users.  I don't see a place to enable MFA only for Admins as Baseline Policies are no longer available. 

Why do you say"you can't enable MFA individually with a free license to a specific set of users" ? I can go in to individual users settings and enable MFA. I already did it for few users. I am not sure whether I am using free licenses. I have 80 licenses of Office 365 Business Premium, and 350 Exchange Online (Plan 1) which I know does not include Azure AD Premium Licenses.

Copper Contributor

@charlesntoroaluminum 

I meant to say you can't control access (in your case exclude certain users for use of legacy apps) with a free license, instead you need a premium license to do that (E3,E5, AAD premium P1, AAD premium P2 etc. contact your account manager/reseller).

 

What you want is to exclude certain users by using conditional access policies. With security defaults you have no way of making exclusions.

Copper Contributor

@Luitzen_Boot 

Thanks for your reply, I understand I need Azure Premium level licenses to granular managed of MFA. But my original question  is "will it create problems if I enable MFA at individual users level" which I was able to do ?

Copper Contributor

@charlesntoroaluminumYes it will create problems. Enabling security defaults will block legacy authentication.

Copper Contributor

@Luitzen_Boot  Which will create problem? enabling MFA per user or enabling Security defaults?

 

Copper Contributor

@Tom Phillips @Alex Weinert 

It appears there is a Graph API beta for at least checking the status.  I found this last night.  Haven't had a chance to try it yet.

https://docs.microsoft.com/en-us/graph/api/resources/identitysecuritydefaultsenforcementpolicy?view=...

 

Matthew

Copper Contributor

I would like to support @charlesntoroaluminum's question - Do we eligible to configure and use the per-user MFA without enabling Security defaults and having P1/P2 licenses per each MFA-enabled user? Currently, we can do it and it works. But if it meets Microsoft licensing requirements? Thank you!

Copper Contributor

I have enabled Security Defaults for a tenant. Security info is managed via Combined Security Information Registration. My understanding is that MFA will be enforced for all user identities (except AD Connect user) simply by enabling Security Defaults. However users are still able to login to login.microsoftonline.com without completing an MFA challenge (the user has at this point completed their security info registration). Microsoft Support have advised that to enable MFA for each user identity after enabling Security Defaults, MFA must be enabled on the user account in the Microsoft 365 admin center under Users --> Active users --> Multi-factor authentication. Is this behavior by design?

Steel Contributor

@malcolmd_cnx is there any chance that you're just not seeing MFA prompts on *every* sign-in because of how refresh tokens work?  If you want MFA every single time, I believe the options are:

 

- If Conditional Access policies are available to you: use "Session" settings (i.e. 'Sign-in frequency' and 'Persistent browser session').

- Otherwise, use per-user MFA settings and MFA service settings' "Remember multifactor authentication" setting (configurable in # of days).

 

Hope I'm understanding your concern correctly.

Copper Contributor

@Jeremy Bradshaw. I don't believe this is related to refresh token behavior because in my testing I had the credentials for a user whom had completed Security Info Registration after I had enabled Security Defaults. And I used those credentials to access login.microsoftonline.com without an MFA challenge from a computer which had never authenticated the user in the past and was in a different network and behind a different firewall\public IP. However when I attempted to sign into mysignins.microsoft.com using the same session, an MFA challenge was initiated. Assuming this is a bug? Conditional access is not an option and per-user MFA via O365 is an option but the point is that I didn't think per-user MFA was required with Security Defaults enabled. Thanks.

Version history
Last update:
‎Nov 09 2023 11:09 AM
Updated by: