Monthly Archives: June 2022

Microsoft increases email security market share 18%

Back in 2019, I wrote a blog post (here) explaining how to identify the primary DNS MX records used by the Fortune 500 and then use that to identify email security vendor market share. Then in 2020, I wrote a post that Microsoft had dipped 12% while others gained.

So when I ran the analysis again today, I was surprised to see that Microsoft had gained 14 new clients since the last time I had run the report two years ago. During that same time ProofPoint and Cisco also gained while Symantec and others lost market share amongst the Fortune 500.


I am asked all the time by customers “Is Microsoft “good enough?” Yes, but you don’t have to take my word for it. Microsoft just received the “AAA Protection Award” from SE labs—a testing lab focused on assessing the efficacy of security solutions. They evaluated email security vendors against a range of real-world email attack scenarios. They found 97 percent of emails that contained threats were blocked. That’s pretty good! Read more about Microsoft’s results here.

At the 2019 Microsoft Ignite Conference, there was a presentation (available on YouTube here) given where Microsoft made a pretty compelling case: since they sit behind other email security vendors (when mailboxes are hosted in Exchange Online) they can see when they could have blocked threats that others missed. In the graphic below, they claim to catch 400% more things than competitors!

MSFT misses 0.002% whereas competitors are missing 0.01% and 0.012% (that is a difference of 400%). To be sure, the competitors will make similar claims since Microsoft is unaware of their unique catch rates.

Industry analysts such as Forrester have named Microsoft a leader in email security (read the announcement here)


10 Reasons why I recommend Microsoft for Email Security

There are ten reasons why I recommend Microsoft email security to my clients:

  1. Automatic signal sharing with Microsoft Defender for Endpoint
  2. Protect malicious links in SharePoint, OneDrive, Teams, Office on the Web, and Microsoft 365 Apps for Enterprise
  3. Safe Documents
  4. Lateral Phishing Protection
  5. Native Link Rendering
  6. Anti-Phishing (prevent Business Email Compromise)
  7. Automatic Investigation and Response
  8. Threat Explorer
  9. Threat Hunting & XDR Integration
  10. Performance

Automatic signal sharing with Microsoft Defender for Endpoint

Whereas most other email security vendors create a silo of malicious file hashes when threats are detonated, Microsoft is able to share this information with Defender for Endpoint within milliseconds because they share a common back-end “the Intelligent Security Graph (PPT Download link).”


Protect malicious links in SharePoint, OneDrive, Teams, Office on the Web, and Microsoft 365 Apps for Enterprise

Whereas other email security products are typically limited to scanning only external emails, Microsoft is able to scan hyperlinks and attachments throughout the productivity applications. This is important because hackers often like to hide their malware in trusted locations such as OneDrive or SharePoint because most organizations cannot afford to block these root URLs since they are also used for business productivity.

Safe Documents

Safe Documents uses the cloud backend of Microsoft Defender for Endpoint (MDE) to scan documents opened in Microsoft Office. Users do not need to have MDE installed for this to work.

License Requirements: M365 E5 Security or full M365 E5. It is not included in the EOP or MDO license plans, you need the E5 Security step-up license (added to M365 E3) or the full M365 E5 suite.

Enable with PowerShell here:
Set-AtpPolicyForO365 -EnableSafeDocs $true –AllowSafeDocsOpen –$false

Learn more about Safe Documents in the Microsoft Documentation (here).

Lateral Phishing Protection

When mailboxes are hosted in Exchange Online, Microsoft is able scan internal emails, whereas other security vendors are usually limited to only when emails are external. Microsoft uses its advantage of hosting the email platform to perform this internal email scanning. This is valuable because if a hacker compromises an account, they will often use that to attack other internal accounts since it will look more trust worthy.

Learn how to configure safe link policies in the Microsoft Documentation (here)

Native Link Rendering

When email security vendors re-write the URL back to their service, they do so because they want to examine the hyperlink at the time of click for threats. Since Microsoft ‘owns’ the Outlook clients (mobile, web, desktop) then they can render the original URL when the user hovers over the link. This is helpful so that the user can use their security awareness training to better judge if the link appears suspicious. Other vendors cannot achieve this since they do not own the most popular email client used in the enterprise.

Read about the announcement of Native Link Rendering back in 2018 (here)

Anti-Impersonation in Anti-Phishing Policy to prevent Business Email Compromise


You can configure anti-impersonation for up to 350 users in a single policy (multiple policies are permitted). The idea is to protect your top executives from having their Display Name impersonated, or domain names that look similar to the domains you own. 

Learn more about how to enable Anti-Phishing in the Microsoft Documentation (here)

Automatic Investigation and Response

After a potentially malicious URL click is detected in email, or is manually reported by a User or Admin, or a SOC analyst who integrates AIR with their SIEM uses the Office 365 Management Activity API, then an automated playbook is launched to perform a deep investigation of these 13 steps:

1.Analyze user activity anomalies in Microsoft Cloud App Security, and check the attachment against Defender for Endpoint

2.On-demand check of domain reputation from Microsoft’s ISG and external threat intelligence sources

3.Detect anomalies based on historical mail flow sending patterns for users in your organization

4.Extract indicators from header, body and content of the email for investigation

5.Investigate mail delegation access for user mailboxes related to this investigation

6.Investigate any violations detected by Office 365 Data Loss Prevention (DLP)

7.Detect intra-org and outbound malware or phish originating from users in your organization

8.Investigate any mail forwarding rules for user mailboxes related to this investigation

9.Email cluster analysis based on (1) header, (2) body, (3) content and (4) URLs

10.On-demand check on URL reputation from Microsoft’s ISG and external threat intelligence sources

11.On-demand check of IP reputation from Microsoft’s ISG and external threat intelligence sources

12.Email cluster analysis based on outbound mail flow volume patterns

13.On-demand detonation triggered with Defender for Office 365 for emails, attachments and URLs

Then an Administrator is presented with an option to soft delete the emails:


Learn more (here).

Threat Explorer

Assuming you have permissions and licensing, you can navigate to Threat Explorer directly here:

Threat Explorer is very powerful. You can:

  • See malware detected by Microsoft 365 security features
  • View phishing URL and click verdict data
  • Start an automated investigation and response process from a view in Explorer
  • Investigate malicious email, and more

Learn more about Threat Explorer (here).

Also the “Email Entity Page” is also helpful in investigations. Check it out (here). The Microsoft documentation is very good (much better than competitor products).

Threat Hunting & XDR Integration

If you know Kusto Query Language (KQL) then you can construct queries across inboxes, devices, identities, etc. You can also integrate with a SIEM such as Sentinel for true XDR. Sample queries:

  • Finds PowerShell activities that occurred right after an email was received from a malicious sender
  • Find the first appearance of files sent by a malicious sender among all devices or inboxes
  • Find emails containing open redirect URLs, for example:


| where Url matches regex @”s?\:\/\/(?:www\.)?t\.(?:[\w\-\.]+\/+)+(?:r|redirect)\/?\?”

  • Logons to a device after a malicious email was received, for example:


| where Timestamp > ago(7d)

| where ThreatTypes has_cs “Malware”

| project EmailReceivedTime = Timestamp, Subject, SenderFromAddress, AccountName = tostring(split(RecipientEmailAddress, “@”)[0])

| join (


| where Timestamp > ago(7d)

| project LogonTime = Timestamp, AccountName, DeviceName

) on AccountName

| where (LogonTime – EmailReceivedTime) between (0min .. 30min)

Learn more about advanced hunting (here)


The speed at which Microsoft can detonate attachments is impressive.

Most emails are detonated for threats within 5 to 12 seconds.


Can you imagine what it would take for you to build enough virtual machine capacity in your on-premises network to open every single email attachment received in a separate virtual machine to analyze behavior?

Here is a report you can use to analyze the latency introduced by Microsoft’s email security:

Try it out

If you are using a 3rd party email security solution, you can begin to evaluate Microsoft Defender for Office now. You will need an E5 Trial subscription and you need to be a member of the Security Administrator and Exchange Administrator roles to set up the evaluation.
Learn more here:

Make the switch!

Already convinced? You can plan to make the switch from a 3rd party email security vendor to Microsoft by following the excellent documentation (here) or contacting a Microsoft Partner (such as Patriot! (My company!) – contact us at [email protected] for a quote!).

Azure AD Combined Registration (SSPR + MFA) is rolling out by October 2022

I’m starting to get questions from my customers about what to expect when the Azure AD “Combined Registration” feature is enabled beginning October 2022 and completing January 2023. On March 29th 2022 Microsoft published MC348869 in Message Center.

A bit of background: In April 2020, the combined security information registration experience for registering both multi-factor authentication (MFA) and self-service password reset (SSPR) was made available as an Opt-in feature but otherwise disabled by default.

We quickly encouraged everyone to enable it, for two primary reasons:

1. It simplifies the user experience so they register once instead of twice (when both MFA and SSPR are both used)

2. FIDO2 Security Key registration requires that the combined registration feature is first enabled. this is required if you want to go passwordless, as FIDO2 has use cases that augment WH4B and Authenticator app such as shared workstations or when employees don’t want to use their personal phones for authentication. It also adds URL binding so that users don’t get phished. But this isn’t a blog about FIDO2, I just can’t help use every opportunity to evangelize it – go use it now!

As you can see, even if you don’t use SSPR, it’s still valuable to enable the FIDO2 passwordless experience.

So does this change impact me?

Did you create your tenant after August 15th 2020? Then no, this change won’t impact you because any tenant created after that date already has Combined Registration enabled.

You can go check out to see if you have it enabled by following these instructions:

1. Sign into the Azure portal ( with a privileged role such as “user administrator” or “global administrator.”
2. Go to Azure Active Directory > User settings > Manage user feature settings.
3. Under “Users can use the combined security information registration experience” – record the setting.

If it is not enabled for all users, then you can select an option to enable it for a pilot group so that you can record the new user experience , and then decide if you want to update your onboarding documentation.
Microsoft provides screen shots of the new experience here:

Will there be any user impact?

Another customer recently asked me: “I use ADFS, and I do not have SSPR enabled, will this change impact me?”

Potentially yes. If your tenant currently does not have combined registration enabled, and you do not have SSPR registration currently required, then it is possible that if your SSPR authentication factors are not aligned to your MFA factors then I could imagine a scenario where users would be required to register for the SSPR factors when this change rolls out in October.

So my advice for everyone is to go into your SSPR authentication factors and try to align those with your MFA factors.

What makes this a confusing time (June 2022) is that there are three separate areas to configure factors.

1. Legacy MFA portal


2. SSPR Portal
Authentication methods selection in the Azure portal

3. Azure AD Portal – Authentication Methods


Eventually I expect these portals to be consolidated into the 3rd portal. Until then, sometimes users are not aware of all these locations to configure the authentication experience.

And recently, one of my customers was confused by the 3rd portal, thinking that “text message” had to do with using SMS as 2FA


No – remember this list of options are for passwordless authentication methods. So this text message option is for using your phone number instead of username, then you type in the code on your phone instead of a password (useful for retail environments where there is high employee turnover). Learn more about SMS-based authentication as an alternative to usernames/passwords in the Microsoft documentation here. Just because it is there, does *not* mean you should turn it on! Remember, SMS based authentication is weak! See Alex Weinert’s article “It’s Time to Hang Up on Phone Transports for Authentication.