Blog Post

Exchange Team Blog

2 MIN READ

Deprecation of the -Credential Parameter in Exchange Online PowerShell

Platinum Contributor

Feb 12, 2026

As part of our continued commitment to strengthening security across Exchange Online, we want to inform our customers about an important change coming to the Exchange Online PowerShell module.

What’s changing and why

Microsoft is progressively moving all services toward more secure, modern authentication experiences. As part of this shift, multi-factor authentication (MFA) is being made a mandatory security requirement across Microsoft cloud services. Because the legacy Resource Owner Password Credentials (ROPC) authentication flow does not support MFA, it is on the path toward deprecation as Microsoft strengthens its security baselines. Additionally, the Microsoft Authentication Library (MSAL) that supports authentication across Microsoft services has deprecated ROPC starting with version 4.74.0.

The -Credential parameter in Exchange Online PowerShell relies on ROPC, and therefore cannot meet MFA or Conditional Access requirements. To align with MFA enforcement, modern authentication principles, and Microsoft’s broader security standards, support for the -Credential parameter will be removed from new Exchange Online PowerShell versions released after June 2026.

This change is applicable to both Connect-ExchangeOnline and Connect-IppsSession.

While our published timeline extends to June 2026, we strongly recommend that all customers transition away from the -Credential parameter as soon as possible and not wait until the deadline.

Alternatives for the -Credential parameter

Below is a list of supported alternatives for the -Credential parameter that you should adopt depending on their scenario:

Scenario / Use Case	Recommended Authentication Method	Description	Documentation
Admins connecting interactively	Interactive Sign‑In (Modern Auth + MFA)	Secure sign-in for human administrators; supports MFA and Conditional Access.	Connect to Exchange Online PowerShell \| Microsoft Learn
Automation running outside Azure	App‑Only Authentication	Certificate‑based or secret‑based app registration for non‑interactive automation.	App-only authentication in Exchange Online PowerShell and Security & Compliance PowerShell \| Microsoft Learn
Automation running in Azure services	Managed Identity Authentication	Ideal for Functions, Automation Accounts, and cloud-native tasks. Eliminates secrets entirely.	Use Azure managed identities to connect to Exchange Online PowerShell \| Microsoft Learn

Timeline

Current state: the -Credential parameter continues to function today and will continue to function in all modules released till end of June 2026.
Recommended action (effective immediately): you should begin migrating away from the -Credential parameter use while connecting to Exchange Online using the Connect-ExchangeOnline or Connect-IppsSession cmdlets
After June 2026: new versions of the Exchange Online PowerShell modules released post 2026 will no longer include support for the -Credential parameter.

If you encounter any gaps or unsupported scenarios with the alternative authentication flows, please share them in the Comments section so we can prioritize addressing them in future updates.

Major changes to this post:

2/17/2026: Added a note that this change applies to both Connect-ExchangeOnline and Connect-IppsSession.

Exchange Online Management Team

Updated Feb 17, 2026

Version 2.0

Platinum Contributor

Joined April 19, 2019

View Profile

Exchange Team Blog

You Had Me at EHLO.

11 Comments

JoostdeHeer
Copper Contributor
Mar 11, 2026
There are several cmdlets that are not compatible with CBA, see MC1131771 or the documentation link in the Automation running outside Azure section.
How do you run these cmdlets if credential-based authentication is deprecated?
I've tried moving our automated purge scripts to graph but never got the actual purge to work:
Creating the case works: case = graph.post('security/cases/ediscoveryCases', body=body)
Creating the search works: search = graph.post('security/cases/ediscoveryCases/{}/searches'.format(case['id']), body=body)
Starting the search works: startsearch = graph.post("security/cases/ediscoveryCases/{}/searches/{}/estimateStatistics".format(
case['id'], search['id']), body=None)
Downloading the search results works with an access token scoped to b26e684c-5068-4120-a679-64a5d2c909d9/.default
Starting the purge works: startpurge = graph.post('security/cases/ediscoveryCases/{}/searches/{}/purgeData'.format(case['id'], search['id']), body=body)
But the end result of that purge is that nothing is deleted. The app registration has all the rights that are needed, as far as I can see (Purview role with 'Search and purge').
Vivek
Microsoft
Mar 10, 2026
Sanjeevantero , Thanks for pointing this out. We’ll look into this internally and get back to you. In the meantime, could you help clarify a couple of things:

Does the cmdlet work when using user-based authentication currently?

Do you have an approximate timeline for when this cmdlet stopped working with the app-only authentication flow?
- Sanjeevantero
  Copper Contributor
  Mar 10, 2026
  Vivek , Yes the cmdlet works in user-based authentication. this has impacted our running flow that exports activity data and ingests it to sentinel for monitoring purpose.
  
  It stopped working on 26th Feb 2026.
  - Vivek
    Microsoft
    Mar 10, 2026
    Thanks for the confirmation. I will check internally and get back here.
RonRon
Copper Contributor
Mar 06, 2026
I just read it here in the tech community, why didn't I read about this in the O365 Admin Center messages?
This is a huge impact for us, we have to change a lot of automation scripts that depend on the -Credential parameter.
It's a coincidence that I read this article, and the deadline is already in June? How can we request a delay of this date?
And I would suggest you post this in the Message Center of the admin center, most likely a lot of other companies that rely on PowerShell scripting are facing a huge problem with this deadline.

And will this also be the case for connecting to Azure/EntraID, Teams etc. (Ie PowerShell scripting)
- Nino_Bilic
  Microsoft
  Mar 06, 2026
  Indeed, MC post is coming.
VasilMichev
MVP
Feb 12, 2026
So, just to clarify, is this a client-side change then? Will older versions of the module still work with -Credentials, or are you going to block ROPC service-side at some point?

WRT to supported scenarios, there are few cmdlets that do not work with application context/MSI. What will be the alternative to manage those?

Also, what about the SCC cmdlets/connectivity method?
- Nino_Bilic
  Microsoft
  Feb 12, 2026
  I'll answer the first part of your question, Vasil (other parts someone else will). The changes made here are both client and service side:
  
  Yes, PowerShell modules starting with the version specified will not have that parameter, and you could after that day still use the older PS version with the Credential parameter. So yes, this is a client-side change.
  
  Also yes, there will be a service side change which will eventually break this no matter which client (PS version) you use on client side. And that change is the overall deprecation of ROPC flow. Once that goes, it's gone. Once that service change is made, no matter which version you have client side, the parameter will not work.
  - Vivek
    Microsoft
    Feb 15, 2026
    Hi Vasil, For the first part of the question, as mentioned by Nino, to start with it will be client-side change post June 2026. And eventually in the long term, the changes would be made server side that would break all the older versions as well. The timelines for this are not yet decided.
    
    The deprecation would impact both Connect-ExchangeOnline as well as Connect-IppsSession. The SCC cmdlets that do not work in App only modes, will not be supported as these cmdlets are not intended to be used in automation scripts. In case you believe these are required for your specific scenarios, we can discuss to get your requirements.