In this Help Net Security interview, Scott Schnoll, Microsoft MVP for Exchange, breaks down the Shared Responsibility Model, where Microsoft secures the cloud while organizations must protect their own data, identities, and configurations.
The discussion covers default settings worth changing tomorrow, including legacy protocols like SMTP AUTH that survive due to printer, scanner, and ERP dependencies. Schnoll highlights overlooked controls such as Conditional Access, PIM, and continuous monitoring, plus blind spots in audit logs around POP, IMAP, and client-side mailbox rules. He also weighs when third-party email gateways add value versus when they create duplicate spend for mid-sized teams.
When you walk into an organization for the first time and they tell you Exchange Online is “secure because it’s Microsoft’s problem now,” where does that conversation usually go in the next ten minutes?
This is a great first question because I’m having that conversation with a customer right now. I start by explaining what’s called the Shared Responsibility Model in Microsoft’s cloud. I always make sure that customers understand that attackers don’t attack Exchange Online per se; rather, they attack an Exchange Online tenant; they attack your identity, your configuration, and (for a lot of customers), your lack of monitoring, and your lack of user education.
As its name implies, in the Shared Responsibility Model, Microsoft and the organization each have responsibility for different aspects of the deployment. While Microsoft has a number of security and compliance controls, there are just as many that are made available to tenant admins for properly securing the tenant.
Of course in the cloud, Microsoft is providing datacenters, networking, servers, compute resources, identity and infrastructure, and some applications. Microsoft also provides a number of controls for the environment, such as physical and logical access controls, networking controls, monitoring, and more.
But for all Microsoft cloud deployments, the organization owns their data and identities. Thus, the organization is responsible for protecting the security of their data and identities, along with the cloud components they control through available configuration settings. So while Microsoft provides a variety security controls for Exchange Online, it remains the organization’s responsibility to manage access and to secure and protect their data, accounts, and endpoints.
Microsoft secures the cloud, and to help customers secure their Exchange Online tenant, Microsoft provides a number of controls for change management, anti-malware, antispam and protection against other malicious software, baseline threat protection, patch management, and data replication and redundancy, among other things.
Microsoft also provides admins with controls and tools for managing identity and access, certificates, email authentication, eDiscovery and search, and many security and compliance tools. And those provided controls don’t configure themselves. Instead, the organization configures them based on their business needs and risk tolerance. In fact, as I am going through this with a customer now, I can tell that there are more than 300 technical, operational, and documentation controls that can be implemented by customers based on their business needs. These controls span cloud settings, directory access, security, compliance, endpoint management, risk assessment, and more.
So, you’ve just moved your family and all your belongings to a new, rented house. The landlord provides you with doors, windows, a roof, etc. The landlord is interested in protecting the house, but responsibility for protecting the people, and property in the house is up to you. It’s your responsibility to harden the environment to meet your needs. You might decide you want better locks, cameras, an alarm system, etc. These are all things that you can do to improve security, and these things are not provided by the landlord, thereby making them your responsibility.
It’s the same principle in the cloud. It’s your data and your users. It’s up to you to protect them.
What’s the configuration default in Exchange Online that you wish Microsoft would change tomorrow, and why has it survived this long?
Oh, if only it were that easy. There’s a few things I’d like to see changed (or gone), including support for legacy protocols and authentication. For example, taking something like authenticated SMTP submissions aka SMTP AUTH. It’s used by POP3 and IMAP4 clients to submit messages, and by applications, servers, and devices that don’t use modern authentication methods.
The RFC that defines SMTP auth was created more than a decade ago, and today, all modern email clients that connect to Exchange Online (e.g., Outlook, Outlook Mobile, OWA, etc.) don’t use SMTP AUTH. For this reason, Microsoft strongly recommends disabling SMTP AUTH (either tenant-wide, or with some exceptions when needed).
Unfortunately, what keeps SMTP AUTH around is the lack of support for it by devices and applications used by customers. This includes things like printers and scanners, HVAC systems, ERP systems, legacy applications, and so forth. As long as customers continue to use clients that don’t support modern authentication (e.g., OAuth), it makes it a challenge for Microsoft to turn it off completely.
We all agree that disrupting messaging services is a non-starter (not to mention politically dangerous). In fact, for some customers, breaking mail flow is worse than leaving some legacy protocol enabled. The fact is that security best practices have moved and are moving faster than Microsoft’s willingness to break mail flows (or other things). So, it can take years to remove insecure legacy protocols from Exchange Online. And as we’ve seen in this case (and with other significant cloud deprecations), even when Microsoft sets a deadline that deadline is often extended based on telemetry they have that shows legacy authentication still in use, and of course, based on escalations from customers who ask for more time.
Walk me through the controls you consider non-negotiable that most mid-sized organizations still get wrong. Where is the gap between Microsoft’s documentation and what teams operationalize?
This is an interesting question but I’m not sure it applies just to mid-sized organizations. There are organizations of all sizes who overlook things, or things just fall through the cracks. Microsoft’s documentation is not perfect, but it is fairly comprehensive and I can’t think of any security or other controls that are not well documented (although even in those cases, some additional polishing could help).
Since there are literally hundreds of controls for customers to manage, it’s easy to miss or misconfigure a control, and it’s easy to assume that implementing a control provides more protection than it actually does. For example, I’ve had customers who have enabled MFA thinking that alone solves the authentication gaps. These same customers have left POP, IMAP, and legacy authentication enabled, basically rendering the protections provided by MFA useless. I’ve also had customers create really solid policies, but then they open gaps by allowing for “temporary exceptions” that often become permanent.
For me, identity and access controls like Conditional Access, PIM, JIT elevation, and multi-admin approval are non-negotiable. So are controls that provide auditing, encryption, external forwarding, and data protections. The Security Defaults in Microsoft 365 are good, but only as a starting point. There are many more controls that need to be implemented and monitored to properly protect a tenant. And once the controls have been properly configured and implemented, then continuous monitoring needs to take place. The lack of continuous monitoring is often an organization’s biggest operational failure and something that unfortunately, a lot of organizations lack. An organization can implement all available controls, but without regular reviews of identity, permissions, control effectiveness, and system activity, the controls themselves are not enough.
When an account is compromised, what artifacts do incident responders consistently miss in Exchange logs? Where are the blind spots in the unified audit log that you would warn people about?
I’ll say from the start that I’m a little reluctant to answer this because I don’t want to expose any auditing gaps that can be exploited by anyone. The reality is that mailbox audit logs may show that mailbox items were accessed, but they cannot always reliably prove exactly which messages were read or whether data was exfiltrated.
For sure there are nuances to using the information in the audit logs. Incident responders often miss client-side mailbox access artifacts, delegated access activity, and non-Exchange workloads that attackers abuse but do not fully appear in the audit log. To use your language, the audit log also has “blind spots” around IMAP/POP access, token replay, legacy protocol abuse, and gaps in mailbox rule creation visibility, all of which can allow an attacker to go completely unnoticed even when auditing is enabled.
One of the tactics used by attackers is creating client-side mailbox rules that silently forward emails to external addresses or auto-delete specific messages. Creation and usage of these rules may not be fully captured in the audit logs. Similarly, accessing a mailbox using a legacy protocol like POP and IMAP generates minimal or sometimes no auditing events. You’ll see authentication activity captured in the sign-in logs, but after that mailbox access, message and folder binding, and other activity simply won’t appear in the logs (in this case because the session is treated as a protocol synchronization instead of an interactive mailbox action). POP itself specifically bypasses item level security, and its especially problematic given that it can trigger both download and deletion of messages in a mailbox.
Several years ago, Microsoft did add auditing for MailItemsAccessed, which details what messages and folders were accessed and whether synchronization occurred but it doesn’t capture this data from legacy clients (POP, IMAP, and even older version of Outlook). So, if legacy clients are used as part of an attack, from a forensic standpoint you’ll likely be able to tell that the mailbox was accessed, but you won’t always be able to tell exactly what the attacker read.
To account for these gaps, responders typically have to look at multiple sources of data, including Entra ID sign-in logs, message trace, Defender for Cloud Apps, Conditional Access logs, mailbox audit data, and endpoint telemetry from managed devices because Exchange Online auditing might not tell the complete story.
What’s your view on the value of third-party email security gateways sitting in front of or alongside Exchange Online? Where does the math work, and where is it duplicate spend?
This is one of those questions where it’s difficult to provide a specific answer around costs and duplicate spending. The short answer is that third‑party email security gateways can add value for very specific needs, such as when an organization needs legacy routing, specialized compliance tools, or advanced threat‑layer diversity. But for many Exchange Online customers, using them does create duplicate spend, and it can also reduce detection accuracy, not to mention introduce operational complexity.
For most customers, the math works only when they have requirements that Microsoft’s native stack cannot meet. For example, if a customer needs to use specialized routing or encryption, or Centralized Mail Transport (or even legacy hybrid mail flow) then using a third-party gateway could be their best solution. But, if the organization needs only spam or message hygiene capabilities, or wants to detect things like business email compromise, internal threats, and OAuth abuse, then using the native capabilities in Exchange Online is better than relying on a third-party gateway.
Scott Schnoll is a speaker at Span Cyber Security Arena 2026 taking place in May. Help Net Security will be on-site, get in touch to book a meeting.
