In this article, I present a summary of the security best practices for Microsoft Exchange Server, directly inspired by the recommendations published by the NSA and CISA.
These guidelines aim to strengthen the resilience of Exchange environments hosted in data centers — whether on-premises or hybrid — against current threats, including email account compromises and the exploitation of known vulnerabilities.
The goal of this document is to provide a clear and practical reference for system administrators, CERT/SOC teams, and security managers who wish to secure their Exchange servers over the long term.
Executive Summary
On-premises Microsoft Exchange servers are high-value targets for cyber threats, and must be secured using industry best practices. A joint report published in October 2025 by the NSA, CISA, Australia’s ASD/ACSC, and the Canadian Cyber Centre outlines key recommendations for hardening on-premises Exchange environments. In summary, organizations should:
- Keep Exchange servers updated: Apply security patches and Cumulative Updates promptly, as attackers often exploit newly disclosed Exchange vulnerabilities within days.
- Migrate out-of-support versions: Replace or upgrade any end-of-life Exchange servers with Exchange Server Subscription Edition or another supported email platform to mitigate the risks posed by unpatched legacy systems.
- Enable the Emergency Mitigation service: Ensure the Exchange Emergency Mitigation (EM) service is running so that Microsoft’s temporary mitigations for critical vulnerabilities can be auto-applied in between patch releases.
- Apply security baselines: Use standardized secure configuration baselines (e.g., DISA STIGs, CIS Benchmarks) for Exchange, the Windows OS, and Office clients to enforce a hardened and consistent configuration.
- Leverage built-in protections: Enable native security features (Microsoft Defender Antivirus/AMSI, Attack Surface Reduction rules, AppLocker or Windows Defender Application Control, EDR) to establish defense in depth on the Exchange server
- Implement email authentication standards: Configure SPF and DMARC DNS records and deploy DKIM signing to prevent email spoofing and impersonation on domains used by Exchange.
- Restrict administrative access: Limit access to the Exchange Admin Center (EAC) and remote PowerShell to dedicated admin workstations only, using Exchange Client Access Rules and firewall rules.
- Harden authentication and encryption: Enforce secure protocols (TLS 1. 2 or higher), enable Extended Protection to defeat authentication relay attacks, prefer Kerberos over NTLM, and configure Modern Authentication (OAuth 2.0 with MFA) while disabling Basic Auth.
- Secure the PowerShell environment: Enable certificate-based signing for remote PowerShell (introduced in Nov 2023) to ensure management commands are authentic , and disable remote PowerShell for non-admin users to reduce attack surface.
- Protect web access: Enforce HTTPS for Outlook on the Web via HSTS (HTTP Strict Transport Security) and configure a separate OWA download domain for attachments to prevent web-based attacks like CSRF.
- Adopt least-privilege administration: Use role-based access control (RBAC) with split permissions so that no single Exchange admin account can compromise Active Directory administrative roles should be separated and minimized
Enable sender forgery detection: Keep Exchange’s new “P2 From” anti-spoofing mechanism enabled (introduced in Nov 2024) to automatically flag emails with forged sender identities.
Introduction
Persistent threats and recent exploits targeting on-premises Microsoft Exchange Server have prompted government agencies to issue strengthened security guidance. In October 2025, the U.S. National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), Australia’s Australian Cyber Security Centre (ASD’s ACSC), and the Canadian Centre for Cyber Security jointly released a Microsoft Exchange Server Security Best Practices report. This official guidance provides administrators with recommended measures to harden on-prem Exchange servers against sophisticated threats.
The recommendations span several core areas: maintaining a prevention-first posture (through timely patching and attack surface reduction), enforcing secure configurations (baseline settings), strengthening authentication and encryption of Exchange services, tightly restricting administrative access and privileges, and improving email trust and safety (through anti-spoofing and authentication standards). By implementing the following best practices, organizations can significantly improve the security of their on-premises Exchange servers and better defend their critical email communications from compromise.
Maintain Regular Updates and Patching
Keeping Exchange servers fully up-to-date with the latest software version and security patches is the single most effective defense against exploitation. Microsoft typically releases two Exchange Cumulative Updates (CUs) per year, along with monthly security and hotfix updates. Administrators should plan for and apply these updates as soon as practicable, because malicious actors can develop exploits for disclosed Exchange flaws within just days of a patch release. Delaying or skipping patches leaves known vulnerabilities open, compounding risk over time and potentially putting the entire network in jeopardy.
Microsoft provides tools such as the Exchange Update Wizard, the Exchange Health Checker script, and SetupAssist to help verify that servers are current and ready for new updates.
It’s also important to monitor Microsoft’s official channels for Exchange updates and emergency mitigations: announcements are posted on the Exchange Team blog and on the Exchange Server documentation site whenever a new patch or interim mitigation is available. By staying vigilant and promptly updating Exchange, administrators can greatly reduce the window of exposure for any given vulnerability.
Don’t Think ! Patch Now !
Migrate End-of-Life Exchange Servers
As of October 14, 2025, earlier on-premises Exchange versions have reached end-of-life (EOL) status, and Exchange Server Subscription Edition (SE) is now the only supported on-prem version. Running an unsupported Exchange server means no further security fixes for that system, which leaves it increasingly vulnerable to attack. Organizations should migrate EOL Exchange servers to Exchange SE or another supported email solution as soon as possible to avoid the elevated risks associated with unpatched software.
If an EOL Exchange server must remain in operation temporarily (e.g. due to ongoing migration), its attack surface must be minimized.
It should never be internet-facing: place the server in a restricted network segment, remove or disable any external publishing, and limit its use to internal email functionality only.
If external mail flow is still required during this transition, route those messages through a secure email gateway or relay service instead of allowing direct internet traffic to the legacy Exchange server.
By isolating the outdated server in this manner, you significantly reduce the chances of it being targeted from the internet. (For context, U.S. federal civilian agencies were directed under CISA’s Emergency Directive 25-02 to disconnect all EOL Exchange servers, underscoring how critical it is to remove or neutralize unsupported instances.)
Ensure the Emergency Mitigation Service is Enabled
Microsoft’s Exchange Emergency Mitigation (EM) service provides an automated defense mechanism to apply temporary mitigations for Exchange vulnerabilities in between official patches. This service is automatically installed on Exchange Mailbox servers (since the September 2021 updates) and works by contacting Microsoft’s cloud-based Office Config Service (OCS) to fetch the latest mitigation scripts or rules.
When Microsoft releases an interim fix (for example, to address an actively exploited 0-day), the EM service will automatically apply those mitigations. These can include adding or updating IIS URL Rewrite rules to block malicious request patterns, or disabling vulnerable Exchange services or app pools until a patch is installed. The EM service logs its actions in the Windows Event Log and in a dedicated Exchange logging directory for administrator awareness.
It is critical that the EM service remain enabled and running on all Exchange servers to benefit from this rapid response capability. In the event of a new exploit, Microsoft-approved mitigations can be deployed within hours to reduce harm, without any administrator intervention.
Note: The EM service is not a substitute for applying Exchange security updates; it is a stopgap that provides the “fastest and easiest way to mitigate the highest risks to internet-connected, on-premises Exchange servers before updating”. Administrators should still apply the permanent fixes as soon as they are available, but the EM service offers invaluable protection in the interim.
Apply Security Configuration Baselines
Implementing standard security baselines for Exchange servers, their operating systems, and associated software helps maintain a consistent and hardened security posture. A security baseline is essentially a set of recommended configuration settings (registry keys, policies, file permissions, etc…) designed to minimize vulnerabilities. Adopting baselines makes it easier for administrators to identify systems that deviate from secure settings and to remediate misconfigurations before they are exploited.
Several authoritative sources publish baseline guides for Exchange and Windows.
For example:
| Provider | Security Baseline Guide |
|--------------------------|----------------------------------------------------------|
| DISA (U.S. DoD) | Exchange Server Security Technical Implementation Guide (STIG) |
| DISA | Microsoft Office System 2016 STIG |
| DISA | Microsoft Office 365 ProPlus STIG |
| CIS (Center for Internet Security) | Exchange Server CIS Benchmark |
| CIS | Microsoft Office CIS Benchmark |
| Microsoft | Security baseline for Microsoft 365 Apps for Enterprise (Office) |
By applying such baselines (and keeping them updated as guidelines evolve), organizations benefit from vetted best practices that harden Exchange and its environment. Baselines enforce least-privilege configurations, disable legacy or insecure settings, and ensure important security controls are enabled. Maintaining a baseline also means any configuration drift or unauthorized change on a server can be quickly spotted and corrected, thereby reducing the window of opportunity for attackers.
Enable Built-In Security Protections
A layered approach is vital to secure an Exchange server. Administrators should enable the built-in security features available on the server and OS, especially if equivalent third-party solutions (antivirus, EDR, etc…) are not in place. Key protections include:
- Anti-Malware (Microsoft Defender Antivirus): Ensure real-time antivirus is running on the Exchange server. Microsoft Defender (the built-in Windows AV) is supported with Exchange, and administrators should configure the recommended AV exclusions (for Exchange processes, directories, and file types) to avoid performance issues. An up-to-date antivirus will detect known malware and some exploit tools that could target the server.
- AMSI Integration: Exchange Server integrates with the Antimalware Scan Interface (AMSI) on Windows, allowing the antivirus engine to scan content within Exchange HTTP requests. This means that malware transmitted via OWA (e.g. as an email attachment upload) can be scanned and blocked by Defender or a third-party AV that supports AMSI, providing an extra layer of inspection at the application level.
- Attack Surface Reduction (ASR) Rules: Microsoft Defender’s ASR rules can proactively block common attack vectors. One crucial rule to enable on Exchange servers is “Block webshell creation for servers”, which prevents web shell malware from being created on the server. Web shells have been a frequent component of Exchange attacks, allowing persistent backdoor access enabling this ASR rule can stop web shell deployment even if an attacker manages to drop malicious files.
- Application Whitelisting (AppLocker/WDAC): Use Windows AppLocker or Windows Defender Application Control to restrict which executables and scripts can run on the Exchange server. By default-denying anything not explicitly allowed, you greatly reduce the risk of malicious or unauthorized tools running on the server. This control can prevent an attacker from executing arbitrary payloads or living-off-the-land binaries on Exchange.
- Endpoint Detection & Response (EDR): Deploy an EDR solution on the Exchange server to gain advanced threat detection and visibility into suspicious behavior. EDR tools can detect techniques that antivirus might miss (like credential dumping, unusual PowerShell usage, lateral movement attempts) and provide alerts. They also facilitate incident response by recording detailed telemetry that can be analyzed if a breach is suspected.
- Exchange Anti-Spam/Anti-Malware Features: Enable and tune Exchange’s built-in anti-spam and anti-malware agents to help filter out malicious emails at the server level. While many organizations use cloud email filters or gateways, those with on-premises mail flow should not ignore Exchange’s native content filtering capabilities as a first line of defense against phishing and viruses.
Together, these protections fortify the server’s defenses. It is worth noting, however, that on-prem Exchange lacks native support for certain email security protocols – specifically, DMARC, DKIM, and SPF. Those standards are essential for preventing email domain spoofing and require additional configuration or tools, as discussed next.
Implement SPF, DKIM, and DMARC for Email Authentication
To guard against email spoofing and domain impersonation, organizations must implement SPF, DKIM, and DMARC in their Exchange environment. These email authentication standards work together to verify sender legitimacy and email integrity. Since on-prem Exchange Server does not natively provide full support for them , administrators should deploy them through DNS configurations and auxiliary tools or services:
- SPF (Sender Policy Framework): Publish SPF records in DNS for each email-sending domain. An SPF record designates which mail servers are authorized to send email for your domain. Receiving servers check SPF to detect forgeries – if an email claims to be from your domain but comes from an IP address not in your SPF record, it will fail SPF validation. Ensure all of your legitimate outbound mail sources (Exchange servers, any mail relay, cloud services, etc… ) are listed in your SPF record, and configure your mail systems to perform SPF checking on incoming mail.
- DKIM (DomainKeys Identified Mail): Implement DKIM signing on outbound email. DKIM uses a public/private key pair per domain to add a cryptographic signature to email headers. Exchange on-premises does not have built-in DKIM signing, so this typically requires either a third-party DKIM agent installed on Exchange or routing outbound mail through an email gateway that can sign messages with your domain’s DKIM key. Once in place, external recipients can verify that emails from your domain were indeed signed by your server and not altered in transit.
- DMARC (Domain-based Message Authentication, Reporting & Conformance): Publish a DMARC policy in DNS for your domain. DMARC builds on SPF and DKIM results to tell receiving servers what to do if an email fails authentication (e.g., reject or quarantine it) and provides a feedback mechanism. For example, a DMARC record might specify that if an incoming message purports to be from your domain but fails SPF/DKIM checks, it should be rejected. DMARC also lets you receive aggregate reports from mail providers about messages using your domain, which can reveal impersonation attempts. Configure your DMARC policy to at least “monitor” (p=none) and then enforce (p=quarantine or p=reject) once you’re confident legitimate mail is properly authenticated.
In practice, to use these standards with Exchange on-premises, you may need a combination of steps and tools. DNS configuration is required for SPF and DMARC (and publishing DKIM public keys). For DKIM, you might deploy a plugin or script on Exchange to add DKIM signatures, or use an external mail relay service that automatically signs outgoing mail. Similarly, for inbound mail, an external gateway service can perform SPF/DKIM/DMARC checks before passing messages to Exchange.
By implementing SPF, DKIM, and DMARC, you greatly improve the trustworthiness of your organization’s emails, making it far harder for attackers to successfully send phishing emails that appear to come from your domains.
Secure Exchange Administration
Compromised administrative access to Exchange can lead to full domain or enterprise compromise. It’s therefore critical to secure Exchange’s administrative interfaces and privileges. Two important measures are: restricting network access to management endpoints, and enforcing strict administrative role separation using RBAC.
Restrict Administrative Access (EAC and PowerShell)
Only designated admin workstations should be permitted to reach Exchange’s management interfaces – the Exchange Admin Center (EAC) web UI and remote PowerShell (WinRM) endpoint. Because EAC runs as part of the Exchange web services, you can configure Client Access Rules in Exchange to block EAC access for all IPs except those of your admin machines.
This prevents anyone outside the allowed IP range from even reaching the EAC logon page. Additionally, set up Windows Firewall rules on the Exchange server (or upstream firewall ACLs) to restrict remote PowerShell (HTTPS/WSMan) access so that only your admin subnet or specific IPs can connect to PowerShell on Exchange.
By implementing these network-layer restrictions, even if an attacker is on your internal network, they cannot easily use the Exchange admin endpoints. Regular users and systems have no business reaching EAC or remote PowerShell – limiting access significantly reduces the chance of abuse.
Enforce RBAC and Split Permissions
Exchange Server’s Role-Based Access Control (RBAC) model allows granular delegation of admin tasks. Organizations should use RBAC to adhere to the principle of least privilege: grant administrators only the rights they need, and no more. In particular, implement Exchange’s split permission model to separate Exchange administration from broader Active Directory administration. In a split-permissions setup, Exchange admin accounts cannot create or modify AD objects (users, groups, etc…), and domain admins cannot directly make changes in Exchange configuration. This prevents a scenario that was common in the past – where Exchange admins were also domain admins, so compromising Exchange effectively meant compromising the entire AD domain.
With RBAC split permissions, even if an Exchange organization admin account is hijacked, it should not have the permissions to alter AD users or elevate privileges outside Exchange. Take advantage of built-in RBAC roles, and remove any inappropriate membership (for example, ensure Exchange admins are not members of Domain Admins, and vice versa). Proper RBAC configuration contains the blast radius of an Exchange breach and is a cornerstone of Exchange security best practices.
Strengthen Authentication Mechanisms
Strong authentication underpins Exchange security. Administrators should harden both the server’s internal authentication protocols and the client authentication methods. This involves enabling Extended Protection (to defend Windows authentication against relays) and adopting Modern Authentication with OAuth tokens and MFA for user access.
Enable Extended Protection and Phase Out NTLM
Microsoft’s Extended Protection for Authentication is a feature that helps thwart man-in-the-middle and credential relay attacks by binding the authentication process to the TLS session over which it occurs When Extended Protection (EP) is enabled, if an attacker manages to steal a user’s NTLM authentication hash or token from one session, they cannot successfully reuse it on another connection because the TLS channel bindings won’t match and the server will reject it. Enabling EP on all Exchange servers is strongly recommended to add this layer of defense.
For EP to work properly, your environment must be configured to use only secure protocols: ensure that TLS 1.2+ is enforced (disable older SSL/TLS versions), and that outdated NTLM versions are disabled – only NTLMv2 should be allowed, if NTLM is needed at all. (By default, modern Windows systems already disable SMBv1 and NTLMv1, which are known insecure protocols.) Extended Protection is on by default for new installations of Exchange 2019 CU14 and later, and in Exchange SE. In existing deployments, use the Exchange Health Checker to verify prerequisites (like uniform TLS settings on all servers) and then manually enable Extended Protection for your Exchange virtual directories.
At the same time, organizations should begin moving away from NTLM authentication entirely. NTLM has been a staple of Windows authentication for decades, but it is more vulnerable to certain attacks compared to Kerberos or OAuth. You should audit NTLM usage in your domain (via Active Directory audit logs) to discover which applications or clients are still using NTLM.
Common culprits might include older Outlook clients, legacy applications or services that connect to Exchange. Plan to update or reconfigure these to use modern authentication protocols – for example, ensure all Outlook clients use MAPI over HTTP (which can leverage Kerberos or OAuth) rather than RPC over HTTP (which used NTLM).
Microsoft has been reducing NTLM dependencies in recent platforms (Windows 11 made strides in this area), and importantly, Exchange SE’s roadmap indicates that Kerberos will replace NTLM for server-to-server authentication starting with the first CU for Exchange SE.
The end goal should be to reach a state where NTLM can be completely disabled in your environment, closing off a common avenue of attack.
Enable Modern Authentication (OAuth 2.0) and MFA
All Exchange organizations should disable Basic Authentication for client access protocols and require Modern Authentication with OAuth 2.0 tokens. Modern Authentication allows Exchange to integrate with an identity provider (on-prem ADFS or Azure AD in the cloud) to issue OAuth access tokens that govern mailbox access. This enables you to enforce multi-factor authentication (MFA) for email access, greatly improving account security. Exchange Server 2019 CU13 and later support Modern Auth for on-prem mailboxes, and hybrid setups can use Hybrid Modern Authentication so that on-prem Exchange accepts Azure AD tokens for mailbox access.
Once Modern Auth is enabled and verified, you should turn off any remaining Basic Auth on the Exchange server (for Outlook, EWS, EAS, POP, IMAP, SMTP Auth, etc…). Basic Auth sends a username and password (often unencrypted or easily intercepted), making it highly prone to credential theft and reuse. With Modern Auth, by contrast, a client must obtain a limited-life token after successfully authenticating (often with MFA) to the IdP, and Exchange will trust that token to grant mailbox access. This means an attacker can no longer just steal credentials via phishing and log in – without the token (and second factor), they’re stopped.
Modern Auth thus dramatically reduces the risk of account compromise and is a fundamental part of a Zero Trust strategy, wherein no access is granted until the user’s identity is strongly validated. Exchange administrators should ensure all client applications are updated to support Modern Auth (for instance, older Office versions may need an update or registry tweak to use OAuth), then enforce the switch and monitor for any clients still trying to use basic auth, which can indicate misconfigurations or malicious attempts.
Secure PowerShell Management
Exchange is heavily managed through PowerShell Remoting, which introduces a potential attack surface if not secured. In a remote PowerShell session (used by the Exchange Management Shell and remote admin tools), Exchange and the client exchange serialized. NET objects representing command data. Attackers have found ways to exploit this process in the past by injecting malicious data into the serialization stream. To mitigate such threats, Exchange now supports certificate-based signing of PowerShell serialization data. As of the November 2023 security update, this signing is enabled by default on supported Exchange servers.
With this feature, any data exchanged in a remote PowerShell session is digitally signed using the Exchange server’s authentication certificate. The receiving end will verify the signature and reject the data if it’s been tampered with. This prevents an attacker on the network or on the server from altering cmdlet arguments or injecting commands without detection.
Administrators should ensure that all Exchange servers have this protection turned on and that they share a common, valid Exchange Auth Certificate used for signing/verifying PowerShell data (Exchange setup usually handles this, but it’s worth confirming in environments with multiple servers).
Additionally, consider disabling remote PowerShell access for non-admin users who don’t need it. By default, any authenticated user could open a remote PowerShell session to Exchange (for instance, to manage certain personal settings). If a regular user account is compromised, an attacker could abuse this to run Exchange cmdlets (within that user’s RBAC permissions) and if you have no need for users to run remote PowerShell on Exchange, use the Set-User or Set-CASMailbox settings to turn off RemotePowerShell for those accounts.
This way, only administrators can open such sessions. Reducing the exposure of PowerShell endpoints and ensuring all PowerShell data is signed and verified will harden the Exchange management plane against abuse.
Secure Web Access (OWA/EAC)
The Outlook on the Web (OWA) interface (and by extension the EAC, since it runs under OWA) should be secured to prevent session hijacking and injection attacks. First, enforce HTTP Strict Transport Security (HSTS) for your Exchange web services. HSTS ensures that browsers always use HTTPS when connecting to OWA/EAC. When a browser first accesses the site over HTTPS, Exchange will include a Strict-Transport-Security header specifying a time period (e.g.,6 months) during which the browser should never downgrade to HTTP.
From then on, even if a user or an attacker tries to load an http:// link for OWA, the browser will automatically convert it to https://, preventing any attempt to establish an unencrypted session. This mitigates man-in-the-middle and sniffing risks by eliminating plaintext OWA traffic. Be sure to configure HSTS with an adequate max-age and include subdomains as needed, following Microsoft’s guidelines, so that all relevant web endpoints (OWA, ECP/EAC) are covered.
In addition, all SMTP connections to and from your Exchange server should be encrypted (with TLS) and, where possible, authenticated (to prevent spoofing). Exchange supports Opportunistic TLS by default for SMTP, but you can configure send/receive connectors to require TLS for certain partners or to not fall back to cleartext. However, Exchange on-premises doesn’t natively enforce advanced standards like DANE (which uses DNSSEC for SMTP server certificate binding) or MTA-STS (which uses a policy file and certificate validation to require TLS) for external email If your organization requires stronger guarantees for SMTP transport security, consider deploying these standards externally: for instance, publish DNS TLSA records for your SMTP servers (for DANE), and/or use a third-party email gateway that honors MTA-STS policies. These additions will help ensure that your emails to other domains (and their emails to you) cannot be intercepted or downgraded by attackers in transit.
Another recommendation is to configure a separate download domain for OWA to mitigate certain web-based attacks. Known as the OWA Download Domain feature, this involves setting up a dedicated hostname (e.g., owa-download.company.com) from which attachments and files will be served, instead of using the main OWA domain.The benefit is that when a user clicks an attachment in OWA, it opens a new session on that separate domain – meaning the browser will not send the OWA authentication cookie along with the request. This segmentation prevents a malicious website from initiating a cross-site request that could steal or misuse the user’s OWA session cookie via a fake attachment download. In essence, the download domain is isolated from the OWA session, cutting off a potential CSRF attack vector. If feasible, implement an OWA download domain as per Microsoft’s guidance to add this extra layer of protection for web clients.
Detect Forged Sender (P2 From) Attacks
Email spoofing doesn’t only involve domain impersonation (addressed by SPF/DKIM/DMARC); attackers may also forge the “From” header displayed to users (the P2 header), making an email appear to come from a trusted sender even if the actual sender (P1 envelope) is different. Exchange Server has a built-in capability to detect such forged sender headers which was introduced in the November 2024 updates. When this feature is enabled (it is on by default in current versions), Exchange will inspect incoming emails for patterns that indicate the visible From header might be spoofed. If a message triggers this detection, Exchange will add a special header (X-MS-Exchange-P2FromRegexMatch) to the email and can also insert a warning into the email body to alert the recipient that the sender may have been forged.
Administrators should ensure this anti-spoofing feature remains enabled. It’s an additional safety net that complements DMARC by catching mismatches that DMARC might not, especially in internal or cross-domain scenarios. Furthermore, organizations can create Transport Rules to act on messages flagged by this mechanism. For instance, you might prepend a subject tag like “[Suspicious Email]” or redirect such emails to a quarantine mailbox for review. Tuning these actions to your business needs can automate the handling of potential phishing emails. In summary, this “P2 From” detection helps counter phishing and CEO fraud attempts by automatically identifying when an email’s displayed sender is likely falsified, enabling your users or email systems to treat it with caution.
Conclusion
These Exchange Server security best practices align with the fundamentals of a Zero Trust security model. Zero Trust operates under the assumption that threats can exist anywhere inside or outside the network and this every component must be hardened and continuously verified.
The measures described above focus on strengthening authentication and access controls, ensuring strong encryption of data in transit, and minimizing the attack surface of the Exchange application. By implementing them, organizations dramatically improve the security of their Exchange servers, which are often a core hub for business communication, thereby protecting the integrity and confidentiality of the information those servers handle.
It’s important to understand that no single mitigation is a silver bullet; rather, it’s the combination of these defenses that provides robust protection. An organization that keeps Exchange patched, segments and limits administrative access, enforces modern authentication with MFA, scans for malware, and so on, is far less likely to fall victim to the common vectors by which Exchange servers are compromised.
Administrators should also maintain a posture of continuous monitoring and improvement: watch for signs of intrusion (logs, alerts), regularly review and update configurations, and stay informed about new threats and guidance.
By following the official best practices outlined in the 2025 joint agency report – and treating Exchange as a critical asset that requires diligent security upkeep – organizations can significantly reduce their cyber risk and ensure their on-premises Exchange servers remain a reliable and secure component of their IT infrastructure.
Enjoy and stay safe !
References:
- NSA; CISA; Australian Cyber Security Centre; Canadian Centre for Cyber Security (2025). Microsoft Exchange Server Security Best Practices. Joint Cybersecurity Information Sheet, October 2025.
- https://www.cisa.gov/resources-tools/resources/microsoft-exchange-server-security-best-practices
- https://thehackernews.com/2025/10/cisa-and-nsa-issue-urgent-guidance-to.html
