“Complexity is the worst enemy of security, and our systems are getting more complex all the time.” – Bruce Schneier (@schneierblog)

Microsoft recently launched “Authentication Methods Policy Convergence” (Public Preview). This is so very exciting because it exponentially reduces the complexity of multifactor authentication. I was part of the private preview program, and I’m very happy to see this feature going public.

In my book, “Securing Microsoft 365 (2nd Edition) (2022)” I write about the imperative of Zero Trust and how to configure multiple factors of authentication to prevent unauthorized access to Microsoft 365. Three years ago, I wrote about the most common MFA myths and misconfigurations that I have seen in customer environments.

As of the fall of 2022, only 25% of all authentications are protected by MFA in Microsoft Entra (Azure Active Directory). So this new simplified experience of configuring MFA is such an incredibly welcome improvement. I believe we will see a significant improvement in MFA adoption over the next two years. The reason it will take some time is because the policy convergence is not yet a forced experience, meaning we will still see customers configuring MFA in multiple portals until they learn about policy convergence. And that is why I am writing this blog article, to get the word out! In January 2024, the legacy multifactor authentication methods portal and SSPR authentication methods will be deprecated. Until then, it is very important to note that the new Authentication methods are evaluated in addition to the legacy MFA and SSPR policies.

One of the biggest improvements that I like about policy convergence is that not only do we get a single place to configure MFA authentication methods, but we also get the ability to target individuals and groups. Previously, if you wanted some users to have the ability to use SMS/TEXT or Voice then you had to enable it for the entire tenant. With policy convergence, we now have the ability to be more selective!

You can migrate your existing policies to the new blade at your own pace. Make sure to follow the latest Microsoft Documentation: “Migrate MFA and SSPR policy settings to the Authentication methods policy for Azure AD” and “ Manage authentication methods for Azure AD”

Support for Hardware OATH tokens and Security Questions is coming soon. If you’re using hardware OATH tokens or Security Questions (for SSPR), do not proceed further.

After you capture available authentication methods from the policies you’re currently using, you can start the migration.Open the Authentication methods policy, click Manage migration, and click Migration in progress. You’ll want to set this option before you make any changes as it will apply your new policy to both sign-in and password reset scenarios.

Screenshot of Migration in progress.

Then, update the new auth methods to match the methods you are currently using, or take this as an opportunity to eliminate the less secure methods. If you do that, just be aware that the user will be forced to register for the more secure methods at their next sign-in (so it would be wise to inform your helpdesk and send an email to your users about what they are going to expect!).

After you update the Authentication methods policy, go through the legacy MFA and SSPR policies and remove each authentication method one-by-one. Test and validate the changes for each method. Then go back to the migration process and mark the migration as complete.

Screenshot of Migration complete.

Be aware that it can take up to 15 minutes before changes are reflected.

After reviewing Jan Bakker’s (@janbakker_) blog post on this same subject, I realized that I could not improve upon it any further, so I just want to direct my readers there because he did such a good job on describing the experience in such great detail: https://janbakker.tech/goodbye-legacy-sspr-and-mfa-settings-hello-authentication-methods-policies/

For example, Jan points out “Ensure you have also enabled the combined registration portal for SSPR and MFA before using the new policies. Microsoft should have already enabled this feature, starting Sept. 30th, 2022, but I still see tenants where this is disabled.” I too have seen customers with that disabled, so here is the setting that Jan shared on his post:

The Cybersecurity and Infrastructure Agency (CISA) in the United States of America is responsible for providing guidance to all United States government agencies and critical infrastructure.

On October 17th 2022 an initial draft (version 0.1) was released (here) for the minimum security configuration that “SHALL” or “SHOULD” be applied to Microsoft 365 Defender.

The draft guideline states:

“Generally, use of Microsoft Defender is not required by the baselines of core Microsoft 365 products (Exchange Online, Teams, etc.); however, some of the controls in the core baselines require the use of a dedicated security tool, such as Defender. This baseline should not be considered a requirement to use Defender, but instead used as guidance for how these requirements could be met using Defender, should an agency elect to use Defender as their tool of choice. In addition to these controls, agencies should consider using a Cloud Access Security Broker to secure their environments as they adopt zero trust principles”

So in other words, if you are going to use Defender to secure Microsoft 365, then CISA has provided guidance on minimum security.

After reviewing the recommendations, my first suggestion to CISA is to update the title of this document to reference the specific product name that they are issuing guidance for. For example, the cover page states “Microsoft 365 Defender” which refers to a suite of many products, whereas the baseline recommendations included in the document seem to only reference one single Microsoft product: Microsoft Defender for Office.

In other words, if CISA intends to issue security baseline recommendations for the entire suite of M365 Defender, then this initial baseline is lacking recommendations for Defender for Endpoint, Defender for Identity, and Defender for Cloud Apps.

Let’s review each of their recommendations for a MDO security baseline.

Baseline 2.1 “Preset Security Profiles SHOULD NOT Be Used”

The very first recommendation is that you “SHOULD NOT” use the preset email security profiles in Microsoft Defender for Office (MDO) (Standard or Strict) which means you must instead customize each EOP + MDO setting.

CISA states “the preset security profiles are inflexible.“

Fortunately, they did not use the “SHALL” language because many organizations would benefit from the Standard and Strict preset profiles. These profiles will be adjusted over time by Microsoft to respond to threats on behalf of organizations.

For organizations that lack experience administering Office 365 then the preset policies will be less risky than untrained administrators attempting to customize each and every setting, because complexity is the enemy of security. The preset policies are very good in my opinion and they can greatly simplify the administration of email security policies if an organization decides to use Defender for Office.

So I recommend that CISA change this to the opposite, so that Preset Profiles SHOULD Be Used. Otherwise, CISA is going to have to come up with guidance on dozens of individual settings, and their guidance will quickly become obsolete as Microsoft continuously innovates and develops new features and old settings are deprecated.

Another reason that CISA should recommend to use the Preset Profiles is because the US Federal Government should have a clear standard that all email security settings are based on. If they are going to say “don’t use the preset configuration” then they need to exhaustively list a recommended configuration for each setting that has security implications.

If CISA does not agree with the recommendations in the Strict or Standard policies, they should at least state which specific recommendations they disagree with.

Baseline 2.2 Data Loss Prevention

This recommendation is more strongly worded, that DLP “SHALL” be enabled. In other words, you don’t have a choice, get ‘er done!

However, it does not specify which confidence level should be used to block PII (Credit Card, TIN or SSN). For example, a high confidence block of SSN requires a strongly formatted SSN (xxx-xx-xxxx) and a keyword like “SSN” within 300 characters of proximity, whereas a low confidence block of SSN is an unformatted string of numbers like xxxxxxxxx (resulting in higher false positives, but provides a lower risk of data leakage). Presumably this nuance is left to the individual agency to decide but that should be made more clear in this document.

Two of the bulleted requirements require Endpoint DLP to be configured:

“A list of apps that are not allowed to access files protected by DLP policy SHOULD be defined”
“A list of browsers that are not allowed to access files protected by DLP policy SHOULD be defined.”

I recommend that the document call out that these two bulleted items require the Endpoint DLP product because it has the higher M365 E5 or G5 license. Endpoint DLP is considered a ‘Suite Feature’ included when the M365 E5 package is owned. As far as I know it is not possible to license Endpoint DLP separately.

The section 2.2.4 Implementation neglects a very important step of onboarding computers into Endpoint DLP. This should be added in order for the two bulleted items above to work properly.

Section 2.3 Common Attachment Filter Policy incorrectly states that a MDO Plan 1 or Plan 2 license is required. That is not correct, the common attachment filter is freely included in all EOP license plans (any license plan bundled with Exchange Online). Basically, just mirror the language used in section 2.6.3

Section 2.4 – the Zero Hour Auto Purge for malware should be changed so that it reflects the stronger “SHALL” language because when a file signature matches Malware, it is bad and in my experience Microsoft has a very low false positive rate for malware. Also later in section 2.6.1 the ZAP feature is listed as having the SHALL language, so section 2.4 should be updated to match the 2.6.1 policy recommendation for consistency.
Also, it incorrectly states that a MDO Plan 1 or Plan 2 license is required. That is not correct, the ZAP feature is freely included in all EOP license plans (any license plan bundled with Exchange Online). Basically, just mirror the language used in section 2.6.3

Section 2.7 – I recommend Safe Link policies use the stronger “SHALL” language rather than the current “SHOULD” language, effectively for the same reason why Safe Attachments in Section 2.8 have the “SHALL” language.