Still running on-prem Exchange in Australia after the 2026 ACSC alerts: patch or exit now?

01What changed, and why the decision is sharper now

The latest Australian signal is hard to ignore. The ACSC alert on Exchange says it has identified extensive targeting and confirmed compromises of Australian organisations with vulnerable Microsoft Exchange deployments. It also says a large number of Australian organisations were still unpatched, and warned that ransomware actors may exploit these weaknesses. That is a direct statement about live exploit pressure in Australia, not a theoretical risk note: Exchange server critical vulnerabilities.

That sits alongside newer ACSC guidance published on 31 October 2025, which tells organisations to keep Exchange fully updated, migrate to supported Exchange Server Subscription Edition, enable Microsoft's built-in protections, strengthen authentication and encryption, and restrict administrative access. The same guidance says some Exchange versions have reached end of life and that the recommended defences are critical: New guidance to strengthen Microsoft Exchange Server security, Microsoft Exchange Server security best practices.

The background threat trend is also moving the wrong way. In its 2025-26 Annual Cyber Threat Report, published 26 October 2026, the ACSC says it responded to more than 1,500 cyber security incidents in FY2025-26, up 20 percent on the previous year, and notified entities more than 4,400 times of potentially malicious cyber activity, up 80 percent on FY2024-25. The report also says attackers can use AI to identify vulnerabilities and launch attacks at greater scale. For an internet-facing service with a long exploitation history, that matters: Annual Cyber Threat Report 2025-26 executive summary.

At the same time, Microsoft's support clock has already run out on the common legacy versions. Microsoft says support for Exchange Server 2019 and 2016 ended on 14 October 2025. If you are still on either version, you are already outside mainstream support and should be planning to move to Exchange Server Subscription Edition or Microsoft 365: Exchange Server 2019 and 2016 End of Support Roadmap.

• ACSC has confirmed Australian compromises tied to vulnerable Exchange deployments.
• ACSC's broader 2025-26 report shows rising incident volume and notification activity.
• Exchange 2016 and 2019 support ended on 14 October 2025.
• Continuing on-prem now means either moving to Exchange Server SE with disciplined hardening, or leaving on-prem mail.

02The key fact many teams are still missing: patching legacy Exchange is not a long-term strategy

Microsoft's supportability matrix is explicit: Exchange Server 2016 and 2019 have reached end of support, and the supported on-prem line is now Exchange Server Subscription Edition. Microsoft also notes that Windows Server 2012 and 2012 R2 extended support ended on 10 October 2023, so some Exchange estates are actually carrying two layers of platform obsolescence at once: Exchange Server supportability matrix.

That means a lot of teams are not really choosing between patching and migrating. They are choosing between a short-term containment programme and a supported future state. If you are on Exchange 2016 or 2019, every month you remain there increases the chance that one urgent patch cycle, one delayed maintenance window, or one missed indicator of compromise becomes the event that forces an unplanned migration under incident conditions.

Microsoft is still releasing Exchange security updates in 2026, but the release notes make the split clear. The October 2026 Exchange security update applies to Exchange Server SE, with Exchange 2019 and 2016 covered only through ESU updates. The September 2026 update uses the same framing. That is not the posture of a vendor telling you legacy on-prem is a stable destination: Released: October 2026 Exchange Server Security Updates, Released: September 2026 Exchange Server Security Updates.

So if your internal conversation is still 'can we keep patching 2019 for another year', the honest answer is that you may be able to contain risk for a while, but you are no longer investing in a durable position. You are buying time. That can be a sensible move, but only if the organisation treats it exactly as that.

• If you are on 2016 or 2019, patching is a bridge, not a destination.
• If your Windows Server base is also out of support, the risk multiplies.
• Use ESU only as a time-boxed measure while you move to SE or Microsoft 365.

03When patch-and-stabilise is still defensible

There are still legitimate cases for staying on-prem for a period, but they are narrower than many teams admit. A short-horizon patch-and-stabilise plan is defensible if you have a supported target state, a funded migration path, and strong operational evidence that your team can run Exchange safely during the interim.

Good candidates usually have most of these characteristics already in place: current inventory of every Exchange server and dependency, recent cumulative and security update discipline, no unsupported Windows base under Exchange, restricted administrative access, MFA everywhere relevant, internet exposure minimised, mature monitoring, tested restore and recovery procedures, and a clear cutover path either to Exchange Server SE or to Exchange Online.

ACSC's hardening guidance supports that view. Its best-practice paper emphasises rapid patching, restricted admin access, least privilege, removal of unnecessary services and features, and strong logging, monitoring and auditing. It also states that Exchange environments are continuously targeted and should be considered under imminent threat: Microsoft Exchange Server security best practices.

In practice, patch-and-stabilise makes sense in three common situations. First, you need a controlled few months to complete a Microsoft 365 migration without taking avoidable user risk. Second, you have a hard dependency on on-prem Exchange for hybrid recipient management and are already upgrading to SE. Third, you sit in a regulatory or operational edge case where mail data placement, application integration, or latency-sensitive workflows make immediate full exit unrealistic. Even then, the burden of proof is on the team proposing to stay.

• Time-boxed bridge to Microsoft 365.
• Planned upgrade to Exchange Server SE in a hybrid model.
• Documented business constraint that blocks immediate exit.

04When the right answer is to accelerate exit now

For many Australian organisations, the honest answer after the ACSC alerts is exit now, or at least start the exit programme immediately while hardening the current estate as a temporary control. That is especially true if any of the following are true: you still run Exchange 2016 or 2019 without a funded SE plan, your team struggles to patch fast, your mail platform is tightly coupled to ageing infrastructure, your monitoring is weak, or you cannot show a recent clean compromise assessment.

The strongest trigger is operational fragility. Exchange is not just another Windows workload. It is a high-value, externally interesting platform that often sits close to identity systems, archives, mobile access, SMTP relays and business-critical workflows. If the people who know it best have left, if maintenance windows are politically difficult, or if every patch cycle causes user disruption, the risk is already telling you what to do.

The second trigger is environmental sprawl. Many estates still carry old load balancer rules, forgotten relays, legacy namespaces, stale certificates, old Outlook Anywhere dependencies, or third-party tools with privileged access. In that situation, hardening work becomes archaeology. Migration is not automatically cheaper, but it can be safer because it gives you a structured way to retire attack surface rather than keep discovering it piecemeal.

The third trigger is governance reality. Boards and executives are far more likely to back a funded exit after a national warning and a rising incident trend than after a purely technical architecture debate. If you need political cover to retire on-prem mail, the current Australian threat context gives you a legitimate, evidence-based case for acceleration: Exchange server critical vulnerabilities, Annual Cyber Threat Report 2025-26 executive summary.

• Unsupported version with no near-term SE upgrade.
• Slow or inconsistent patching cadence.
• Weak logging, monitoring, backup validation or incident response maturity.
• Critical knowledge concentrated in one or two people.
• Large amount of inherited Exchange complexity or unknown dependencies.

05A practical decision checklist for the next 30 days

Do not start with ideology. Start with evidence. The fastest way to make the decision is to score your current position across support, exposure, operational readiness and migration feasibility.

• Are all Exchange servers on a supported version, or on a formally approved, time-boxed ESU path?
• Are the underlying Windows Server versions supported and fully patched?
• Can you deploy critical Exchange updates in days, not weeks?
• Have you completed a fresh review for web shells, indicators of compromise and suspicious admin activity?
• Is administrative access restricted, least-privilege based and protected by strong authentication?
• Have you reduced internet exposure and removed unnecessary services and legacy access paths?
• Do you have centralised logging and alerting that your team actually reviews?
• Have you tested mailbox recovery, server rebuild and certificate recovery in the last 12 months?
• Do you know every application, relay, archive, mobile service and workflow that depends on Exchange?
• Is there an approved plan, budget and owner for either Exchange SE upgrade or Microsoft 365 migration?

06What an accelerated exit actually involves

Leaders often delay exit because they imagine a single risky cutover. In practice, the safer path is staged. First, contain risk on the current estate: apply the latest security updates, validate exposure, review indicators of compromise, lock down admin access and reduce unnecessary internet-facing paths. Then move the decision into a migration track with named owners, dates and dependency work.

For many organisations the likely destination is Exchange Online, often with a small on-prem footprint retained temporarily if Microsoft Entra Connect and on-prem Active Directory remain the source of authority for recipients. Microsoft states that if you move mailboxes to Microsoft 365 and keep using Microsoft Entra Connect for user management, you must keep at least one Exchange server, and recommends upgrading that environment to Exchange Server SE: Exchange Server 2019 and 2016 End of Support Roadmap.

The engineering work is usually less about mailbox moves than about surrounding dependencies. Expect effort around identity hygiene, conditional access, relay redesign, application SMTP changes, archiving, journalling, shared mailbox permissions, mobile policies, DNS and certificate clean-up, and user communications. If your estate is heavily customised, this can look more like a legacy modernisation exercise than a messaging project, which is why teams often benefit from an explicit legacy modernisation approach and a clearer cloud infrastructure plan before they begin.

If you decide to retain a minimal on-prem component, treat it as a control plane, not as a mail platform. Shrink the estate, reduce roles, remove public exposure where possible, and make sure the remaining server is there because Microsoft's hybrid management model requires it, not because nobody got round to decommissioning the old environment.

• Contain first, migrate second.
• Assume dependencies will take more time than mailbox moves.
• Minimise the retained on-prem footprint if hybrid identity remains.

07Questions to ask your team or vendor before you commit to either path

Whether you keep on-prem briefly or exit quickly, the quality of the plan depends on the questions you ask. Ask for direct evidence, not reassurance.

For a patch-and-stabilise proposal, ask: what exact Exchange build and Windows Server version is each server on, what is the current patch lag, what public exposure exists today, what detections are in place for web shells or suspicious Exchange activity, when was the last successful full restore test, and what is the date by which this temporary position ends?

For an exit proposal, ask: which dependencies block migration, which workloads can move in wave one, what remains on-prem and why, how recipient management will work after mailbox migration, what user-impact windows exist, and what decommissioning tasks will remove residual attack surface?

If you use an external partner, ask who owns the security workstream during migration, how compromise assessment is handled before cutover, whether unsupported OS and Exchange components are in scope, and what proof they will provide that legacy connectors, relays and namespaces have been retired. This is where a focused cybersecurity risk service, supported by managed services capability or specialist mail infrastructure support, can be more useful than a generic migration project team.

If your current posture is weak, the best vendor is not the one promising the fastest mailbox move. It is the one that can reduce exposure immediately, surface hidden dependencies quickly, and give you a realistic sequence for leaving the risky parts of the estate behind.

• Ask for builds, dates, evidence and owners.
• Time-box any patch-only plan.
• Make dependency retirement part of scope, not an afterthought.