Exchange Online PowerShell 3.10.1 Deadline: Upgrade Before March 2027 Enforcement

Here is what changes, who is likely affected, how to check your machines, and one PowerShell 7 catch that can block the upgrade if you miss it.

What Microsoft announced​

The Exchange Manageability Team posted the notice on October 1, 2026, and it also appears in the Microsoft 365 Message Center as MC1483974. According to the Message Center entry, Microsoft introduced security enhancements to Exchange Online PowerShell authentication in ExchangeOnlineManagement module version 3.10.1. These enhancements strengthen the authentication flow and provide protection against emerging threats.

Microsoft describes two outcomes once enforcement begins:

• ExchangeOnlineManagement versions older than 3.10.1 may experience authentication failures in certain interactive authentication scenarios.
• ExchangeOnlineManagement version 3.10.1 and later will continue to function normally.

Microsoft also says the module update is all that's needed: Upgrading the ExchangeOnlineManagement module to versions 3.10.1 (or newer) is the only thing you need to do. No other changes are required.

The rollout is a window, not a single day​

The blog post gives one date. The Message Center version adds more detail: enforcement of strict logon requirements is scheduled to begin on March 31, 2027. The rollout is scheduled to begin in late March 2027 and be completed by late April 2027.

That matters for planning. Some community write-ups already treat late April as the deadline. For example, Michael Spice's blog says users need to update to version 3.10.1 or later by late April 2027. Don't plan around the end of the window. Enforcement starts March 31, and your tenant could be early in the rollout. The safe target is to be upgraded and tested before March 31.

Section summary: Enforcement starts March 31, 2027 and rolls out through late April. Version 3.10.1 or later is the minimum. Older builds are at risk only in certain interactive sign-in scenarios.

Who is actually at risk​

Microsoft's notice lists three conditions that together describe the affected group. You may be affected if you are:

1. Running ExchangeOnlineManagement versions earlier than 3.10.1.
2. Using PowerShell 7.
3. Using interactive authentication with Web Account Manager (WAM) disabled.

You are probably outside the initial impact if you use ExchangeOnlineManagement version 3.10.1 or later, Certificate-Based Authentication (CBA), WAM-based authentication, or Windows PowerShell 5.x.

Why "WAM disabled" is more common than you might think​

According to Microsoft Learn, WAM became the default authentication broker for user sign-in starting with module version 3.7.0. Version 3.7.2 added the -DisableWAM switch to Connect-ExchangeOnline because WAM caused problems in some real-world setups. Microsoft's troubleshooting article lists three of them:

• RunAs sessions. Running PowerShell under a different account from the signed-in Windows user breaks WAM, because WAM depends on the active user session.
• GDAP partner flows. With -DelegatedOrganization, WAM can produce tokens that lack required claims, which leads to role errors.
• Task Scheduler jobs set to "Run whether user is logged on or not". WAM needs an active user session, which these jobs don't have.

That same article says -DisableWAM should be used only as a temporary measure. Many shops added it to get past one of those errors and never removed it. Managed service providers working through GDAP and admins running PowerShell 7 under alternate credentials are the most likely to be in the affected group without knowing it.

Microsoft is clear that it isn't forcing anyone back onto WAM. Its FAQ says the change does not require customers to enable WAM. Updating the module is the fix.

What about automation?​

The FAQ says scripts using certificate-based authentication are not expected to be affected, because they don't use interactive sign-in. Even so, Microsoft recommends that all customers upgrade, whatever their scenario, to stay compatible with current and future authentication requirements. The 3.10.1 release notes give CBA users their own reason to upgrade. The PowerShell Gallery entry says the release fixed certificate-based authentication (CBA) flow bugs and few other minor performance issues.

Those public release notes don't mention the authentication security enhancements the Exchange team describes. Microsoft hasn't said which protocol, token, or error will change at enforcement. Treat this as a compatibility deadline, not a patched vulnerability. There's no CVE and no reported active exploit.

Section summary: The highest-risk group is PowerShell 7 users signing in interactively with -DisableWAM on a module older than 3.10.1. CBA, WAM, and Windows PowerShell 5.x users are expected to be fine at first, but Microsoft still recommends everyone upgrade.

The PowerShell 7 catch​

The announcement doesn't spell this out, so check it before you schedule the work. According to Microsoft Learn, module versions 3.10.0 and later require PowerShell 7.6.0 or later because they depend on .NET 10. The Gallery release notes for 3.10.0 say the same thing: the minimum required version of PowerShell 7 is now 7.6. Windows PowerShell 5.1 is not affected.

The affected group is defined by PowerShell 7. So the admins who most need 3.10.1 are the ones who may first have to upgrade PowerShell itself. If your jump boxes, build agents, or containers are pinned to PowerShell 7.4 LTS, updating the module alone won't be enough.

Hosted runtimes add another complication. Andres Bohren of the Icewolf blog tested 3.10.0 in an Azure Automation PowerShell 7.4 runtime environment and found that updating the module from the Gallery through the normal route seems that does not work anymore. He used a REST API workaround instead. If you run Exchange runbooks in Azure Automation, check which runtime version you're on before assuming the upgrade will be routine. Microsoft Learn's platform notes also list some older platform entries where the newest supported module is 3.9.2, because PowerShell there tops out at 7.4.x. Those machines will need a newer OS or PowerShell build, not just a module update.

How to check and upgrade, step by step​

1. Find every installed copy. Microsoft's notice gives this command:

Get-Module ExchangeOnlineManagement -ListAvailable

-ListAvailable lists every version installed on the machine, not only the one loaded in your current session. Expect to see several versions side by side on admin workstations. Run the check on every machine where Exchange scripts actually run: jump servers, scheduled-task hosts, CI agents, and Automation accounts. A clean result on your laptop tells you nothing about the server that runs the 3 a.m. mailbox report.

2. Find out how it was installed. According to Microsoft Learn, this command shows the installed location:

Get-InstalledModule ExchangeOnlineManagement | Format-List Name,Version,InstalledLocation

A path under %ProgramFiles%\WindowsPowerShell\Modules\ means an all-users install.

3. Confirm your PowerShell 7 version if you're upgrading on PowerShell 7. Check $PSVersionTable.PSVersion and move to 7.6 or later first if needed.

4. Update using the same scope as the existing install.

Update-Module -Name ExchangeOnlineManagement

According to Microsoft Learn, updating an all-users install requires an elevated session, while a current-user install doesn't. If you use the newer PSResourceGet tooling, the Gallery also lists Install-PSResource -Name ExchangeOnlineManagement. To pin a version explicitly, Install-Module and Update-Module accept -RequiredVersion.

5. Check the result. Run Get-Module ExchangeOnlineManagement -ListAvailable again. You should see 3.10.1 or later. The Gallery currently lists Version: 3.10.1 (current version), published July 24, 2026. Remember that 3.10.1 is the minimum, so take whatever newer GA release is available when you do the work.

6. Check for pinned versions. This one is general PowerShell practice rather than part of Microsoft's notice. Look through scripts for #Requires -Modules statements or Import-Module -RequiredVersion calls that lock an older build. By default PowerShell imports the newest installed version, but a pin overrides that, and your upgrade will quietly have no effect on that script.

7. Optionally remove old versions. Michael Spice suggests Uninstall-Module with -RequiredVersion for each stale build. That leaves less room for a pinned script to load an old version by accident.

8. Test the real workflow. Microsoft Learn's quick connection test is to connect and run something harmless like Get-AcceptedDomain. The Message Center guidance also recommends you validate related scripts before enforcement. Test the exact sign-in path your scripts use, including GDAP, -DisableWAM, or device-code sign-in. A successful run of a different sign-in path doesn't prove much.

Section summary: List every copy, match the install scope, upgrade PowerShell 7 first where needed, check for pinned versions, and test the actual connection paths before March 31.

Analysis: a reasonable deadline with one thing missing​

Microsoft is handling this sensibly. Admins get roughly six months of notice, the fix is a single module update, and the affected group is described precisely instead of a vague "update or else." Compared with the long and messy retirements of Basic authentication and Remote PowerShell, this is about as gentle as Microsoft's identity changes get.

The criticism is about transparency. "Strengthens the authentication flow" and "emerging threats" don't tell security teams much. Without a named mechanism, admins can't easily judge their exposure beyond Microsoft's checklist, and they won't know what a failure looks like when it happens. The precise impact list is also a double-edged sword. Some readers will reason that they use WAM, so they can skip it. But Microsoft says older builds "may not support future authentication requirements," which suggests the current list is only the first round of enforcement.

The practical advice is to put this on the change calendar for the fourth quarter. Do it before the holiday freeze, before PowerShell 7.6 upgrades get stuck in someone's backlog, and well before late March.

If you're tracking related Exchange Online changes, this deadline overlaps with the ongoing EWS deprecation and the EWSAllowedAppIDs allow-list guidance. Admins handling both should audit their Exchange automation once and fix everything in a single pass.