Self-hosted Exchange in Australia: what controls should you add first after the latest ACSC guidance?

01Start with this priority order, not a long hardening backlog

The ACSC published new guidance on 31 October 2025, co-authored with international partners and led by the US National Security Agency, specifically to harden on-premises Microsoft Exchange. The ACSC also continues to keep Exchange-related alerts and advisories active, including alerts urging Australian organisations to urgently patch vulnerable Exchange deployments because extensive targeting and confirmed compromises have been seen in Australia. That is the right context for prioritisation: assume active threat, not a theoretical gap. New guidance to strengthen Microsoft Exchange Server security Exchange server critical vulnerabilities

For most teams, the first sequence should be: 1) verify support and patch state, 2) enable the controls that cut common web and relay attack paths, 3) reduce admin exposure, 4) establish health and security monitoring, 5) then tidy lower-value configuration debt. If you try to do everything evenly, you delay the controls that change attacker economics now.

If your estate includes other inherited infrastructure and you need to combine Exchange work with broader platform cleanup, it helps to treat this as a short, bounded hardening programme rather than open-ended operations. That is usually closer to a cybersecurity risk service engagement than a generic infrastructure refresh.

• Treat Exchange as an internet-exposed priority system.
• Do patch and support checks before configuration tuning.
• Implement controls that reduce exploitability before controls that mainly improve neatness.
• Separate immediate hardening from medium-term exit or migration decisions.

021. Verify support status and patch state before anything else

The ACSC guidance is explicit that Exchange versions that have become end of life carry heightened risk, and Microsoft’s Exchange security best practices pages are maintained as a living set of recommendations for Exchange Server 2016, 2019 and Subscription Edition. If you are unsure what is actually installed, run Microsoft’s official HealthChecker script before you start making changes. Microsoft’s CSS-Exchange HealthChecker is designed to detect common configuration issues and collect server information that speeds assessment. Microsoft Exchange Server Security Best Practices PDF Security best practices for Exchange Server HealthChecker - Microsoft - CSS-Exchange

Do not skip this because you already have WSUS or another patching process. Exchange often fails in the gaps between Windows patching, cumulative updates, security updates, certificate state and IIS settings. HealthChecker is useful because it gives you a single baseline for each server before and after remediation.

Your immediate questions are simple: is this build supported, are the latest security updates installed, are there obvious certificate or IIS issues, and are there any prerequisites that will break the harder controls later. If you cannot answer those four questions quickly, you do not yet have enough control of the platform to start arguing about secondary hardening items.

If you are deciding whether to keep self-hosted mail at all, these checks also give you the evidence base for that decision. A related read is self-hosted mail versus cloud mail platforms, and for inherited environments that need structured remediation you may also need legacy modernisation support.

• Run HealthChecker on every Exchange server.
• Record Exchange version, CU, SU and Windows Server build.
• List internet-facing namespaces, certificates and load balancer pathing.
• Identify any unsupported versions before configuration changes.

032. Enable Windows Extended Protection early, but validate your publishing path first

If there is one hardening control to move near the top of the list after patching, it is Extended Protection. Microsoft states that Windows Extended Protection mitigates authentication relay and man-in-the-middle attacks, and it is enabled by default for new installs of Exchange Server 2019 CU14 or later. On older supported versions, Microsoft provides the ExchangeExtendedProtectionManagement.ps1 script to help enable it. Exchange Server support for Windows Extended Protection

Why is this near the top? Because it directly addresses a class of abuse that matters on Exchange’s web-facing surfaces. It is also one of the controls ACSC-backed guidance aligns with, so it is not a vendor-specific preference dressed up as best practice. It is a meaningful reduction in exposure.

The catch is compatibility. Microsoft documents scenarios that can affect client connectivity, especially where SSL offloading, SSL bridging, reverse proxies or older client paths are involved. That means Extended Protection is not a blind toggle. Before rollout, confirm how traffic reaches Exchange, whether TLS is terminated on a device before Exchange, and whether any legacy clients or integrated applications still depend on behaviours that Extended Protection will tighten.

A sensible rollout pattern is one non-production server first, then one production server or site, then wider rollout after OWA, ECP, ActiveSync, Autodiscover and Outlook connectivity tests pass. If your team owns load balancers or reverse proxies separately from Exchange, make them part of the change from day one. This is exactly the kind of cross-team issue that turns a one-day security change into a two-week incident if you discover it late.

• Map TLS termination and proxy behaviour before enabling Extended Protection.
• Test OWA, ECP, ActiveSync, Outlook Anywhere or MAPI over HTTP, and Autodiscover.
• Check legacy devices and service accounts that may break under stricter authentication handling.
• Roll out in stages, not across all servers at once.

043. Make sure AMSI protection is actually active on Exchange

Microsoft’s AMSI integration for Exchange is one of the few controls that gives you immediate inspection value against suspicious content as requests are processed. Microsoft says AMSI-capable antimalware software on the Exchange server performs real-time scans, and that the November 2024 Security Update enhanced AMSI integration to include scanning of the HTTP message body. AMSI integration with Exchange Server

That makes AMSI a high-priority control after patching and Extended Protection. It helps because modern Exchange exploitation often involves abuse over HTTP paths, and Microsoft specifically expanded AMSI to see more of that traffic. If you already have endpoint protection on the server, do not assume this is covered. Validate that the product is AMSI-capable in this context and that Exchange AMSI integration is functioning as intended.

This is also where many teams lose time to assumption. They have antivirus, therefore they think Exchange is covered. They have a security update, therefore they think AMSI changes are live. Both may be wrong. Test the control path, confirm the antimalware integration, and record which team owns ongoing validation after each Exchange security update or AV platform change.

If you need a broader operating model for recurring security validation on infrastructure you are keeping on-prem for now, this is where a structured managed services approach or cloud and infrastructure support model can help, but only if it includes explicit control checks rather than generic server support.

• Confirm the Exchange build includes the relevant AMSI capabilities.
• Verify your antimalware platform is AMSI-capable on the Exchange host.
• Test and document the validation method.
• Recheck after every significant Exchange or antimalware update.

054. Check Exchange Emergency Mitigation service, but do not treat it as patch replacement

Microsoft’s Exchange Emergency Mitigation service is installed automatically with September 2021 CU or later on Exchange 2016 and 2019 Mailbox servers, unless you disable it. Microsoft says it uses the Office Config Service to download and apply temporary mitigations for potential threats against your servers. Exchange Emergency Mitigation Service

This should be implemented or validated early because it improves your position during the gap between a threat emerging and you completing a full SU or CU rollout. It is especially useful for smaller teams that cannot patch every urgent Exchange issue within hours. But it is not a substitute for patching. Think of it as a buffer, not a strategy.

The immediate task is to confirm the service is present where expected, has outbound connectivity to the required cloud endpoint, and that your team knows how to review applied or blocked mitigations. Microsoft also documents connectivity testing for the service. If your outbound filtering blocks it, you may think you have the protection while receiving none of the mitigations.

This is a good place to add one governance step: nominate a named owner for emergency mitigations and one backup owner. In many Exchange incidents, the issue is not lack of tooling but unclear ownership during the first few hours.

• Verify whether EM service is installed on each Mailbox server.
• Test connectivity to the mitigation cloud endpoint.
• Review logs or commands for applied and blocked mitigations.
• Keep patching as the primary remediation path.

065. Reduce admin privilege and PowerShell exposure before the next incident

ACSC’s system hardening principles emphasise access control alongside patching, secure configuration and monitoring. On Exchange, that translates into a simple question: how many people can run powerful admin actions from where, using what credentials. System hardening

Microsoft recommends defence-in-depth around Exchange administration too, including certificate-based signing of PowerShell serialisation payloads for Exchange Management Shell sessions. Microsoft describes this as a feature to help prevent malicious manipulation of serialised data exchanged via EMS sessions. Exchange Server certificate signing of PowerShell serialization payloads

For practical prioritisation, first remove broad standing admin where you can, then introduce delegated administration for repeatable support tasks. PowerShell Just Enough Administration, JEA, is useful here because Microsoft documents it as a way to restrict remoting sessions to specific cmdlets, parameters and values. Overview of Just Enough Administration

You do not need to redesign all Exchange admin this month. Start with the highest-frequency, lowest-risk support tasks, such as service status checks, queue inspection, health reporting and approved restarts. Build a limited JEA endpoint for those, leave break-glass full admin tightly controlled, and log who can still access the wider Exchange Management Shell. The aim is to cut routine over-privilege, not to create a perfect zero-trust administration model in one sprint.

• Review members of Exchange and local admin groups.
• Separate break-glass admin from everyday support operations.
• Use JEA for repeatable support and operational tasks where possible.
• Enable Exchange PowerShell signing controls where supported and tested.

076. Put recurring health and drift checks in place so the hardening sticks

Hardening is not complete when the change window closes. Exchange has built-in health reporting through cmdlets such as Get-ServerHealth and Get-HealthReport, and Microsoft documents managed availability health sets for ongoing monitoring. Get-ServerHealth Get-HealthReport Manage health sets and server health

The practical goal is not just uptime. It is drift detection. You want to know if Extended Protection was rolled back on a virtual directory, if a certificate renewal changed bindings, if a service stopped, if a mitigation failed to apply, or if a patch window left one server behind the rest of the DAG.

A sensible minimum is a scheduled HealthChecker run, periodic built-in health reports, and a reviewed monthly checklist covering Exchange version state, certificate expiry, EM service status, AMSI validation state, and privileged group membership. Microsoft’s CSS-Exchange project also documents ways to schedule HealthChecker runs, which is useful if you want a repeatable baseline without depending on memory. HCScheduledTask - Microsoft - CSS-Exchange

If your team is trying to keep self-hosted Exchange stable while deciding whether to stay, modernise or move, use these checks to create an evidence-based decision point in 30 days. If you still cannot produce a clean bill of health and documented control ownership by then, the platform is telling you something.

• Schedule HealthChecker regularly.
• Review built-in health reports at least monthly, more often after changes.
• Track configuration drift on certificates, IIS virtual directories and mitigation status.
• Assign named owners for each control, not just the server.

08A 30-day implementation plan for teams not exiting Exchange this quarter

Week 1: run HealthChecker, confirm supported versions, patch to current supported levels, document internet-facing paths, certificates and dependencies. Week 2: pilot and roll out Extended Protection with application and client testing. Week 3: verify AMSI integration and antimalware compatibility, then validate Exchange Emergency Mitigation service connectivity and review process. Week 4: tighten administration, implement at least one delegated support path, and schedule recurring health checks with named owners.

That plan is deliberately narrow. It does not try to solve every mail architecture question. It gets you from broad guidance to the first controls that materially reduce exposure now. If you need help running that sequence, SyncTrix can support the work as a focused engineering effort through its cybersecurity risk service.

• Keep changes sequenced and testable.
• Prefer controls with immediate exposure reduction.
• Document ownership as you implement each control.
• Use the first month to decide whether hardening is sustainable or only buying time.