How do I harden an on-premises Exchange server?

Sandeep Sidhu · 2026-09-16 · 10 min read

Exchange is the most attacked server in the building. It sits on the network edge, handles sensitive data, and has a long history of mass exploitation campaigns that scan the entire internet rather than targeting specific organisations. If you are running Exchange on metal or in a VM, you are not just managing mail; you are defending a high-value target that is constantly probed by automated tools looking for unpatched vulnerabilities.

Many on-premises deployments are not legacy curiosities. Small firms and enterprises keep Exchange on-premises for data residency, cost control, or because their applications only talk to a local MAPI or SMTP endpoint. Moving to Exchange Online is an option, but it is not always the right one right now. The immediate job is to harden the server you have so it does not become the next headline.

Is this version of Exchange server still supported?

The first hardening step is not a registry key or a firewall rule. It is finding out what version and what cumulative update the server is on. Exchange Server 2016 and Exchange Server 2019 reached end of support on 14 October 2025. After that date, they receive no security updates at all. An unpatched Exchange server on the internet is compromised eventually, not hypothetically. Exchange Server 2013 went out of support on 11 April 2023.

The supported on-premises version is Exchange Server Subscription Edition (Exchange Server SE), released in July 2025. It is licensed by subscription and is the continuation of the on-premises product rather than a rewrite. The in-place upgrade from a fully patched Exchange 2019 is the supported path. If the server is out of support, plan the upgrade before anything else on this list, because everything else assumes a server that still receives security updates.

To check the version, run the following command in the Exchange Management Shell:

Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion

The build number matters, not just the major version. Map it against Microsoft's published Exchange build numbers page. If the server is unsupported, no amount of configuration hardening keeps it safe. You must address the version first.

Why do Exchange servers get hit so often?

Exchange has a long history of mass exploitation. Campaigns scanned the whole internet; they did not pick targets. The servers that were taken were the ones behind on updates. In March 2021, ProxyLogon chained from CVE-2021-26855, a server-side request forgery giving pre-authentication access. It was used by HAFNIUM and then by everybody. In August 2021, ProxyShell chained CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207. In September 2022, ProxyNotShell exploited CVE-2022-41040 and CVE-2022-41082. In 2024, CVE-2024-21410 was an NTLM relay against Exchange, mitigated by Extended Protection.

In every one of those campaigns the fix or the mitigation existed before mass exploitation peaked. The servers that fell were the ones behind on updates. These are pre-authentication remote code execution bugs, meaning an attacker runs code on the server without ever logging in, which is why "nobody knows this server is here" has never been a defence.

What should I run before changing anything?

Run the Exchange Server Health Checker. Microsoft publishes this script in the CSS-Exchange repository at github.com/microsoft/CSS-Exchange. It checks build and update level, TLS configuration, Extended Protection state, antivirus exclusions, .NET version, the Emergency Mitigation service, and a long list of known misconfigurations. It writes an HTML report. This is the single highest-value command on this page. Run it, fix what it flags in red, run it again. Run it after every CU.

Keep the Emergency Mitigation service running. The Exchange Emergency Mitigation service (EEMS) was introduced in the September 2021 CUs. It reaches out to Microsoft, downloads mitigations for actively exploited issues, and applies them to the server automatically, ahead of a patch being available. It is not a substitute for patching; it is the thing that buys days. It needs outbound internet access to work. Check it is on:

Get-OrganizationConfig | Format-List MitigationsEnabled
Get-ExchangeServer <name> | Format-List MitigationsEnabled

Do not turn it off. Admins sometimes disable it during troubleshooting and forget to turn it back on.

Leave AMSI integration alone. Exchange integrates with the Antimalware Scan Interface to scan HTTP request bodies before they reach Exchange code. It has been on by default since Exchange 2016 CU21 and Exchange 2019 CU10. It is disabled with a setting override, and vendor troubleshooting guides occasionally suggest doing so. Check nothing has:

Get-SettingOverride

If an override disabling AMSI (the BypassBody filtering override) exists, remove it and restart IIS.

How do I stay able to take security updates?

Exchange ships Cumulative Updates (CUs) and, between them, Security Updates (SUs). Security updates only apply to the most recent CU or two. A server that has fallen several CUs behind cannot take the current security update at all, which is how servers end up years exposed. The practical rule is to stay on a CU that is still receiving SUs, and apply SUs promptly. Exchange SUs are routinely for pre-authentication remote code execution, which is the worst class of bug there is.

Run the Exchange setup and updates from an elevated command prompt. Put the server into maintenance mode first on a DAG member. If you are running an unsupported version, you cannot take the current security update. You must upgrade to a supported version first. This is why finding the version is the first step. If the server is on Exchange Server SE, follow the subscription update cadence. If it is on an older version, plan the upgrade path immediately.

Which built-in protections must stay switched on?

Extended Protection binds the TLS channel to the authentication, stopping an NTLM relay attack against Exchange. Microsoft ships a script, ExchangeExtendedProtectionManagement.ps1, in the CSS-Exchange repository to enable it across the organisation. Enable it. Health Checker reports whether it is on. Check first that any SSL-offloading device in front of Exchange is accounted for, because Extended Protection and TLS termination at a load balancer interact.

Do not run an open relay. An anonymous relay connector scoped too widely turns the server into spam infrastructure and gets the domain and the public address blocklisted. Check your connectors:

Get-ReceiveConnector | Format-List Name, Bindings, RemoteIPRanges, PermissionGroups, AuthMechanism

Look for connectors with AnonymousUsers in PermissionGroups and a wide RemoteIPRanges. An internal relay connector for printers and applications should list the specific addresses of those printers and applications, never a whole subnet and never 0.0.0.0-255.255.255.255. Test from outside with an external relay test, and check the public address against the common blocklists.

What should not be reachable from the internet?

Do not publish ECP to the internet. OWA at /owa generally needs to be reachable for remote users. The Exchange Control Panel at /ecp is the administrative interface, and it has been part of multiple exploit chains. There is no good reason for it to answer requests from arbitrary internet addresses. Restrict /ecp at the reverse proxy or firewall so it is reachable only from the internal network or a management address range. If there is no reverse proxy, use IIS IP address and domain restrictions on the ECP virtual directory.

The same reasoning applies to /powershell and /mapi where the business does not need them externally. Publish what is required, not what is installed by default. Turn off the protocols nobody uses. Every enabled protocol is attack surface and, more importantly, a path that may accept a password without a second factor. POP3 and IMAP4 services are set to Manual and stopped on a default install. Confirm they are, and leave them that way unless an application genuinely needs them. Per-mailbox protocol access: Get-CASMailbox shows which of OWA, ActiveSync, MAPI, POP and IMAP each mailbox may use. Set-CASMailbox turns off what a given mailbox does not need.

How do I stop password-only sign-ins?

Block legacy authentication. Basic authentication sends the password on every request and cannot present a second factor, so any protocol that allows it is a credential-stuffing target that bypasses MFA entirely. On-premises Exchange supports authentication policies to block it:

New-AuthenticationPolicy -Name "Block Basic Auth"
Set-User -Identity <user> -AuthenticationPolicy "Block Basic Auth"
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Basic Auth"

A new authentication policy blocks basic authentication for all protocols by default. Parameters exist to re-allow individual protocols where an application still needs one. Roll it out to a pilot group before the organisation default, because the thing that breaks is always an unattended application account nobody documented. Exchange Online retired basic authentication for most protocols in October 2022. On-premises Exchange did not; you have to do it yourself.

Multi-factor authentication on OWA is not supported natively. Getting a second factor in front of it means putting something in front of OWA: a reverse proxy or web application firewall that does MFA, AD FS, or Microsoft Entra application proxy. There is no checkbox for this one. It is a piece of infrastructure work, and it is worth planning for rather than discovering halfway through an audit.

How do I fix TLS without breaking Outlook?

Disable SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 and enable TLS 1.2. This is done with SCHANNEL registry keys under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols, and it must be matched by .NET Framework settings so that Exchange's own code uses the strong protocol:

HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319

Set SystemDefaultTlsVersions and SchUseStrongCrypto to 1 (DWORD). Apply the SCHANNEL and .NET changes on all servers at the same time. Disabling TLS 1.0 in SCHANNEL while .NET still requests it breaks Exchange in ways that are hard to diagnose. Health Checker reports the TLS picture across servers, and a mixed DAG where servers disagree about TLS causes an outage.

Follow Microsoft's Exchange TLS configuration guide rather than a generic Windows hardening script, because generic scripts break Exchange. Verify from the outside. Microsoft's Remote Connectivity Analyzer at testconnectivity.microsoft.com tests Autodiscover, ActiveSync, OWA and inbound SMTP from outside the network. Run it after any change to the published surface, because the point of restricting /ecp is lost if the reverse proxy rule was never actually saved.

What gets forgotten on every Exchange server?

Exchange holds extensive rights in Active Directory, which has made it a privilege escalation path more than once. Do not administer Exchange with Domain Admin accounts, and do not use one account for daily mail and administration. Use separate, named admin accounts for administration only. Use Exchange's Role Based Access Control rather than handing out Organization Management. Get-ManagementRoleAssignment shows who holds what. Help desk staff need the Help Desk role, not full organisation rights. Review membership of Organization Management periodically. It accretes.

Exchange needs specific antivirus exclusions to run reliably, and Microsoft publishes the list. Two failure modes here: too few exclusions causes database corruption and performance problems, and too many, such as excluding entire drives or the whole Exchange install path including the temporary ASP.NET compilation directories, is what let web shells sit undetected on compromised servers. Use Microsoft's published list exactly. Health Checker checks the exclusions for you.

An expired certificate takes down Outlook, ActiveSync and mail flow together.

Get-ExchangeCertificate | Format-List Thumbprint, Services, NotAfter, Subject

Put the expiry date in the monitoring system rather than in somebody's memory. Also check the self-signed certificate that Exchange installs is not the one bound to IIS. Backups and recovery must be Exchange-aware, tested by actually restoring, and kept somewhere the server's own administrator account cannot reach. Ransomware operators delete backups first, and an Exchange server is a domain-joined machine with a known role, so it is found early.

Moorfox monitors the Windows server Exchange runs on rather than Exchange itself, which covers the part of this list that decays quietly. Patch compliance is the heaviest single factor in the per-device security score, so a server drifting behind on updates surfaces in the fleet view rather than in an incident, and scheduled patching applies the operating system updates on a window that suits a mail server. PowerShell automations run against the server on a schedule, which is one way to keep the checks above, certificate expiry or an unexpected setting override, from depending on somebody remembering to look.

Frequently asked questions

Is Exchange 2019 still supported?

No. Exchange 2016 and Exchange 2019 reached end of support on 14 October 2025 and receive no security updates. The supported on-premises version is Exchange Server Subscription Edition, released in July 2025. The in-place upgrade from a fully patched Exchange 2019 is the supported route.

Can I put MFA in front of Outlook Web App on-premises?

Not natively, as OWA has no built-in MFA. Getting a second factor in front of it requires a reverse proxy, web application firewall, AD FS, or Microsoft Entra application proxy. This is real work and does not have a simple checkbox.

Should OWA be published to the internet at all?

OWA usually has to be published for remote users. The Exchange Control Panel at /ecp does not, and it has featured in several exploit chains, so restrict it to internal or management addresses. Publish what is required, not what is installed by default.

Why can I not install the latest security update?

Exchange security updates only apply to the most recent cumulative update or two. A server several CUs behind must take a CU first, which is why falling behind on CUs leaves servers exposed for years. You must address the version and update level before applying SUs.

Does the Emergency Mitigation service replace patching?

No. It applies interim mitigations for actively exploited issues before a patch exists, which buys time. It needs outbound internet access and should be left enabled. It is not a substitute for patching.

Are antivirus exclusions on Exchange a security risk?

Over-broad exclusions are. Excluding whole drives or the entire Exchange path is how web shells went unnoticed on compromised servers. Use Microsoft's published exclusion list exactly, no wider.