... Enforcement starting March 31, 2027!
On September 30, 2026, Microsoft issued an action-required notification for Exchange Online PowerShell with MC1483974. The key point: Starting March 31, 2027, Microsoft will enforce stricter authentication rules for connections using the ExchangeOnlineManagement module.
Anyone still running a version prior to 3.10.1 by then risks authentication failures. This affects interactive logins at the admin workstation as well as automations, runbooks, and scheduled tasks that authenticate to Exchange Online via script.
The security enhancements are built into the module itself. Microsoft introduced them with version 3.10.1, which has been available in the PowerShell Gallery since July 24, 2026. Those already on version 3.10.1 or later need not do anything except keep the module up to date. Everyone else now has just under six months before enforcement takes effect.
Why This Isn’t Just a Version Update
According to Microsoft, scenarios involving PowerShell 7 where the Web Account Manager (WAM) is disabled are particularly vulnerable. In such cases, older module versions may fail during interactive logon after the deadline. This specifically affects automation hosts that often run untouched for years, where no one remembers which module version is installed.
A second point turns the update into a planning task rather than a one-liner: Module 3.10.0 and newer require PowerShell 7.6.0 or higher due to .NET 10 dependencies. If you update the module on a host with an older PowerShell 7 version, you may first need to upgrade the PowerShell runtime.
While the module continues to run on Windows PowerShell 5.1, this combination should be on your checklist because the REST-based V3 cmdlets are the future anyway and no longer require WinRM Basic Auth.
What to Do Now
First, take inventory. Identify every host using the module: admin workstations, jump servers, automation servers, Azure Automation runbooks, and anything with scheduled Exchange scripts. Check the installed version per host with a command:
Get-Module ExchangeOnlineManagement -ListAvailableIf the version is below 3.10.1, you update within the same scope where it was originally installed and restart PowerShell afterward so that the new version is loaded:
Update-Module -Name ExchangeOnlineManagement -Scope CurrentUserAfterwards, you test the affected scripts against the new version before the cut-off date, not after. Also check the PowerShell version on the automation hosts to avoid being caught off guard by the 7.6 requirement during the migration.
Conclusion
MC1483974 is one of those messages that quietly sits in the Message Center and only becomes loud in March 2027 when a signature automation or mailbox reporting suddenly refuses to authenticate. The effort is minimal, but the timing makes all the difference.
A module update followed by script testing during a scheduled maintenance window can be planned. A sequential authentication failure across production automations, on the other hand, may catch you off guard on any given day after the deadline. If you know your Exchange Online automation landscape, you'll likely have it resolved within an hour. For everyone else, this announcement is the perfect reason to finally take inventory of it.
Sei der Erste und starte die Diskussion mit einem hilfreichen Beitrag.
Leave a comment
Dein Beitrag wird vor der Veröffentlichung kurz geprüft — fachlich, respektvoll und auf den Punkt ist hier genau richtig.