Microsoft has given Exchange Online administrators some welcome breathing room by delaying the retirement of a widely used PowerShell authentication method. The company now plans to begin removing support for the -Credential parameter from Exchange Online PowerShell module releases starting in December 2026.
The parameter had previously been scheduled for removal in July 2026. The revised timetable allows IT departments several extra months to identify affected scripts, replace older authentication methods and test updated automation before the change is enforced. Microsoft said the delay followed customer feedback, but it continues to recommend that organisations begin migrating immediately rather than wait for the new deadline.
What Microsoft Has Changed
The planned change affects the -Credential parameter used with two important PowerShell commands:
Connect-ExchangeOnlineConnect-IppsSession
These commands allow administrators to connect to Exchange Online and Security and Compliance PowerShell. In older scripts, the -Credential parameter may be used to supply a username and password stored in a PowerShell credential object.
Microsoft originally planned to remove the parameter in July 2026. It has now postponed that step until Exchange Online PowerShell module versions are released from the beginning of December 2026. Scripts that continue to use the parameter may fail after an administrator installs one of those newer module versions.
Why the Credential Parameter Is Being Retired
Microsoft is gradually moving customers away from authentication methods that depend on stored usernames and passwords.
Password-based automation can create security risks, especially when credentials are
- Hard-coded inside scripts
- Stored in unsecured configuration files
- Shared between administrators
- Used by unattended scheduled tasks
- Not protected by multifactor authentication
- Left unchanged for long periods
Modern authentication methods provide stronger controls and reduce the need to store reusable passwords. Microsoft has already disabled Basic authentication across Exchange Online tenants for many traditional connection methods as part of its broader security strategy.
The retirement of [name] -Credential is part of this ongoing effort. Instead of passing a username and password to a script, organisations are encouraged to use authentication methods designed for interactive users, applications and automated workloads.
Why Exchange Online Administrators Needed More Time
Although the security reasons are clear, replacing the parameter is not always a quick job.
Many organisations have built up years of automation around Exchange Online PowerShell. These scripts may handle essential tasks, such as:
- Creating and updating mailboxes
- Managing distribution groups
- Producing compliance reports
- Reviewing mailbox permissions
- Applying retention settings
- Managing mail-flow rules
- Updating user attributes
- Running scheduled security checks
Finding every script that it contains -Credential can be difficult, particularly in large organisations with multiple IT teams, service accounts and third-party support providers.
Once an affected script is found, administrators must choose an alternative authentication method, rewrite the connection process and test the entire workflow. Even a small authentication change can interrupt a business-critical task if the replacement is not properly configured.
The delay therefore provides administrators more time to carry out a controlled migration rather than rushing changes into production. The Register reported that scripts relying on the parameter could break and take down established automation workflows once support is removed.
When Will Existing Scripts Stop Working?
The timeline has two important stages.
First, the -Credential parameter will be removed from Exchange Online PowerShell module versions released beginning in December 2026. An affected script could therefore stop working when the organisation updates to a new version of the module.
Second, Microsoft plans to retire the underlying authentication flow on the server side at a later date. Once that happens, keeping an older PowerShell module will no longer provide a lasting workaround. Microsoft has warned that the parameter will eventually stop functioning even in older module versions.
This means administrators should not treat the delay as a permanent escape route. Avoiding module updates may temporarily reduce disruption, but it can also prevent organisations from receiving security improvements, bug fixes and new features.
What Administrators Should Do Now
The additional time should be used to create a structured migration plan.
Start by searching script repositories, scheduled-task servers, Azure Automation accounts and administrative workstations for references to:
-CredentialAdministrators should also review scripts using:
Connect-ExchangeOnline
Connect-IppsSessionFinding those commands does not automatically mean that a script is affected, but it identifies likely candidates for further inspection.
Next, classify each script according to how it runs. An interactive script used by an administrator may require a different replacement from an unattended task that runs overnight.
Organisations should then:
- Identify the script owner and business purpose.
- Record where and how often the script runs.
- Select a supported authentication method.
- Test the replacement in a non-production environment.
- Confirm that the account or application has only the permissions it needs.
- Monitor the updated script for errors.
- Remove stored passwords and unused service accounts.
Microsoft recommends moving away from the parameter as soon as possible, despite extending the published timetable to December 2026.
Possible Modern Authentication Alternatives
The correct replacement depends on the type of workload.
For interactive administration, administrators can use modern sign-in methods that support Microsoft Entra ID and multifactor authentication.
For unattended automation, organisations may consider app-only authentication using an application identity and a certificate. Managed identities may also be suitable for supported automation hosted in Azure.
Other supported connection approaches may include access-token-based authentication in specific scenarios. The final choice should be based on Microsoft’s current documentation, the environment in which the script runs and the permissions required.
The main objective is to remove dependence on stored user passwords while preserving reliable automation.
- Legacy username-and-password authentication
- Interactive modern authentication
- Certificate-based app authentication
- Managed identity
Security Benefits of Migrating Early
Replacing the legacy parameter can deliver benefits beyond avoiding script failures.
Modern authentication can help organisations:
- Reduce password exposure
- Apply stronger identity controls
- Limit application permissions
- Improve auditability
- Remove unnecessary service accounts
- Support multifactor authentication
- Reduce the impact of stolen credentials
Migration also gives administrators the opportunity to review old scripts that may have excessive permissions or that may no longer be required.
A script written several years ago might connect using a highly privileged administrator account even though it performs only a limited reporting task. Rebuilding the authentication process is a valuable opportunity to apply least-privilege access and improve the organisation’s security posture.
Why Waiting Until December Is Risky
It is tempting to leave existing automation unchanged until the final weeks before the deadline. That approach carries several risks.
Large environments may contain more affected scripts than expected. Some may be owned by former employees, hidden inside scheduled tasks or provided by outside suppliers. Testing may also expose application-permission issues, certificate-management problems or dependencies on older modules.
A rushed migration increases the likelihood of the following:
- Broken administrative jobs
- Delayed mailbox provisioning
- Missing compliance reports
- Failed security checks
- Emergency use of insecure workarounds
Starting early allows teams time to prioritise important workflows and resolve problems without adding unnecessary operational pressure.
What the Delay Means for Businesses
For businesses, the announcement reduces the immediate risk of disruption but does not remove the need for action.
Small organisations may have only a few scripts to review. Larger enterprises, managed service providers and public-sector bodies may have hundreds of automated Exchange Online processes operating across different departments.
IT leaders should treat the extension as a planning window. They should ensure that administrators have sufficient time, documentation and testing resources to complete the migration safely.
The change may also affect software vendors whose products connect to Exchange Online PowerShell using older authentication methods. Organisations should contact their suppliers to confirm that supported updates will be available before Microsoft retires the parameter.
Frequently Asked Questions
What is Microsoft removing from Exchange Online PowerShell?
Microsoft is retiring the -Credential parameter from the Connect-ExchangeOnline and Connect-IppsSession commands.
When will the change begin?
The removal is now expected to begin with Exchange Online PowerShell module releases starting in December 2026.
Will older module versions continue working?
They may continue working temporarily, but Microsoft plans to retire the underlying server-side authentication flow later. At that point, the parameter will stop functioning even with older modules.
Which scripts are affected?
Scripts and automation workflows that are used -Credentialto connect to Exchange Online or Security and Compliance PowerShell will be affected.
Should administrators wait until December?
No. Microsoft recommends transitioning as soon as possible so organisations have enough time to identify update and test affected automation.
Conclusion
Microsoft’s decision gives Exchange Online administrators valuable additional time, but the direction remains unchanged. Password-based PowerShell connections using the -Credential parameter are being phased out, and affected scripts will eventually need to adopt modern authentication.
Administrators should use the extension to locate legacy automation, choose secure alternatives and test every important workflow well before December 2026. The delay is breathing room—not a cancellation—and organisations that begin the work early will be far less likely to face broken scripts or emergency fixes when the retirement takes effect.
