Old Credential Parameter Gets the Bullet in June 2026

Much as I support the efforts to eradicate single-factor authentication from Microsoft 365, especially for administrative purposes, the February 12, 2026, announcement about the deprecation of the Credential parameter in Exchange Online PowerShell left me cold.

The logic underpinning the announcement is undeniable. Microsoft 365 is gradually turning the screw on administrators to force the adoption of multifactor authentication. The process started a few years ago and has gradually spread over the Microsoft 365, Azure, and Entra administrative interfaces.

Username and Password Credentials

The Credential parameter for the Connect-ExchangeOnline cmdlet accepts a PSCredential object containing the username and password for an account and uses the credentials (Figure 1) to connect to Exchange Online in an authentication flow called Resource Owner Password Credentials (ROPC). Even though ROPC is supported by OAuth, it doesn’t support multifactor authentication and is therefore just about as secure as watching someone manually enter a username and password to run an interactive Exchange Online PowerShell session.

In addition, the Microsoft Authentication Library (MSAL), the component used by applications to acquire access tokens from Entra ID has deprecated ROPC. MSAL is heavily used across Microsoft 365, so when an important component removes support for a capability, it’s time for software that depends on the capability to get rid of it too. And that’s what’s happening here.

I doubt that the change will make any difference to administrators who run interactive sessions with the Exchange Online management module. Their administrative accounts use multifactor authentication (or should) and I can’t see any administrator signing into Exchange Online PowerShell with a credentials object.

Background Jobs Might be Impacted

Where the change could impact operations is in background jobs based on the Exchange Online management module, especially jobs which run scripts written a few years ago and run by the Windows Task Scheduler. I’ve said for years that people should avoid using the Windows Task Scheduler to run jobs. Better and much more secure alternatives exist, like Azure Automation runbooks. Executing Exchange Online runbooks on a schedule managed by Azure Automation is more secure and reliable than any job managed by Task Scheduler.

Some companies continue to insist on banging the drum for the old approach by pumping out example scripts that use Task Scheduler. I suspect that they do this because Task Scheduler is easier for people to set up and configure. Azure Automation is more complex, but it’s like driving a car: two months after you start using Azure Automation to run Exchange Online scripts, you’ll wonder why you thought it so complicated when you started.

Cost is the other fear I hear about moving work to Azure Automation. It’s true that Azure Automation requires a paid Azure subscription with a valid credit card, but the free tier offers 500 minutes of job run time per month. You can run a lot of scripts in 500 minutes, and the cost thereafter is $0.002/minute.

Change and Opportunity

Change brings opportunity, or so it’s said. In this case, the change is the removal of an old parameter that’s well past its best-by date and the opportunity is to find and revamp scripts that use the soon-to-be-deprecated parameter. Move to a more secure form of authentication (the gold standard for unattended jobs is Azure Automation with managed identities) and take the chance to review the code to improve its performance and robustness.

The Changeover

Microsoft says that the change is effective in versions of the Exchange Online management PowerShell module released after June 2026. This does not mean that the Credential parameter will stop working on July 1, 2026. It does mean that if you update to a new version of the module after June 2026, you can expect to find the parameter is missing. It also means that at some time in the future Microsoft will remove the server-side code that processes the ROPC authentication flow for Exchange Online. At this point, the parameter will cease working even if you use an older version of the module where the parameter is still available.

With so much goodness flowing from the deprecation of an old and insecure component, why I am unhappy? The simple reason is that I’d prefer if the developers working on Microsoft 365 PowerShell modules dedicated their time to resolve the infuriating assembly clashes between Exchange Online, Teams, and the Microsoft Graph PowerShell SDK. I guess that goal doesn’t count as high as elimination of old components and the subsequent reduction of engineering costs. Oh well…