The cutoff for using stored credentials in Exchange Online automation is moving from July 2026 to December 2026, Microsoft confirmed in an updated Message Center advisory on July 16. The change affects the -Credential parameter in the Exchange Online PowerShell module—a workhorse of unattended scripts that connect to Exchange Online and Security & Compliance PowerShell sessions. The extra time is a direct response to IT administrators who warned the original July deadline was too aggressive for organizations with large script estates.

But this is not a reversal. The retirement is a two-phase move: first, client-side module builds released after December 2026 will no longer expose -Credential; second, at an unannounced later date, the Exchange Online service itself will reject the legacy authentication method regardless of the module version. That means the six-month extension is less a safe harbor than a final migration window for teams that weren't ready.

What’s Actually Changing

The -Credential parameter lets a script pass a username and password directly to Connect-ExchangeOnline or Connect-IppsSession—the cmdlets for managing Exchange Online and Security & Compliance PowerShell, respectively. It relies on the Resource Owner Password Credentials (ROPC) flow, which the Microsoft Authentication Library (MSAL) deprecated in version 4.74.0 because it can’t satisfy multifactor authentication or Conditional Access policies that demand modern token-based sign-in.

Microsoft first announced the parameter’s removal on February 12, 2026, with an initial deadline of July 2026 for all newly released module versions to drop support. That timeline has now been pushed to December 2026, as reported by Neowin and confirmed in Microsoft 365 Message Center advisory MC1248389. The delay applies only to the client-side part: modules released before the cut-off can still use -Credential, even after newer builds remove it.

A server-side retirement will follow later, Microsoft says. Once that takes effect, the Exchange Online service will block the legacy sign‑in path entirely. At that point, pinning an old module version will no longer keep scripts running, and any automation still relying on a password will simply fail to connect.

Which Scripts Are at Risk

Any unattended script that uses -Credential $Credential to connect to Exchange Online or the Security & Compliance Center is in scope. That includes:

  • Exchange mailbox provisioning and transport‑management routines
  • Compliance reporting and retention‑policy automation
  • eDiscovery‑related workflows
  • Help‑desk ticket integrations that pull mailbox data
  • Monitoring jobs that query Exchange health
  • Reports generated via scheduled tasks or CI/CD pipelines

This isn’t just about obvious .ps1 files. Credential objects often get passed through functions buried in home‑grown tooling, vendor extensions, or line‑of‑business orchestrators. A simple text search for -Credential may not catch them all, but it’s the place to start.

Why Passwords Are Being Booted

The move is part of a broader, years‑long push to kill basic authentication in Exchange Online. Basic auth—sending a username and password with every request—was disabled for most protocols by early 2023, as detailed on Microsoft Learn. PowerShell’s ROPC flow is an extension of that same approach, and it carries the same risks: credentials can be stolen, reused, or extracted from script stores. Hard‑coded passwords violate Zero Trust principles and undercut security controls like MFA and Conditional Access.

While ROPC has been a convenient crutch for automation, it’s also a liability. A service principal with a certificate or a managed identity can be scoped, audited, and rotated independently of any human account. That’s the destination Microsoft is steering toward.

A Reprieve, Not a Pardon

The six‑month delay is valuable, but only if used to finish a migration, not to start one. Admins who treat December as a soft deadline risk being caught when the server‑side axe falls.

Here’s what the new timeline means in concrete terms:

  • Until December 2026: You can continue using -Credential in current module versions. You should be completing your transition to app‑only authentication during this window.
  • After December 2026: Any newly released ExchangeOnlineManagement module will not include -Credential. If your automation automatically pulls the latest module, scripts will break at the connection step. You’ll need to either pin an older module version (temporarily) or have already switched to certificates or managed identities.
  • When serverside enforcement arrives (date TBD): Even pinned old modules will stop working. This is the real finish line, but Microsoft hasn’t announced it yet. Guessing when it might occur is risky.

The Replacement: App‑Only Authentication and Managed Identities

For interactive administrators, switching to modern sign‑in with MFA is straightforward. The real heavy lifting is for headless scripts—those running as Task Scheduler jobs, Windows services, on‑premises management servers, in Azure Automation, or inside CI/CD runners.

Microsoft’s recommended replacements are:

  • App‑only authentication using an Entra ID application and a certificate: This works for automation outside Azure. You register an app in Entra, assign Exchange permissions, upload a certificate, and make the private key available to the script’s execution context. The script then connects with Connect-ExchangeOnline -AppId <id> -CertificateThumbprint <thumb> -Organization <tenant> instead of -Credential.
  • Managed identities: For workloads inside Azure (e.g., Azure Automation runbooks, Azure Functions), managed identities eliminate key management entirely. The Azure fabric handles authentication, and the script just calls Connect-ExchangeOnline -ManagedIdentity -Organization <tenant>.

Neither is a drop‑in replacement. App‑only auth requires:

  • Creating and approving an Entra application (often a hurdle in locked‑down corporate directories)
  • Granting the exact Exchange Online permissions needed—not over‑provisioning
  • Generating and securely storing a certificate, then deploying its public half to the app registration
  • Ensuring the automation host can access the private key (e.g., LocalMachine\\My store for a Task Scheduler job running as SYSTEM)
  • Setting up certificate renewal before it expires, or the script fails silently

Managed identities avoid key distribution, but only for workloads that can run in supported Azure services. An on‑premises server or a third‑party RMM platform cannot use a managed identity; it must use an app registration with a certificate.

There are also functional gaps to check. When the original February announcement was made, some admins reported that not all cmdlets worked under certificate‑based authentication. Microsoft invited customers to report unsupported scenarios, but you shouldn’t assume every command you use has an app‑only equivalent. Test thoroughly against your actual scripts and tenant configuration.

Immediate Steps for IT Teams

The extra six months should fund a full audit and transition. Here’s a practical checklist:

  1. Inventory every script and automation that touches Exchange Online PowerShell. Search for Connect-ExchangeOnline, Connect-IppsSession, and -Credential across script repositories, scheduled task actions, CI/CD pipeline definitions, monitoring tools, and help‑desk integrations. Don’t forget stored PSCredential objects that might be passed indirectly.
  2. Record the ExchangeOnlineManagement module version on each automation host. Determine whether you install a fixed version, always grab the latest from the PowerShell Gallery, or use a shared module path. This tells you which hosts will break automatically after December 2026.
  3. Classify each script as interactive or unattended. Interactive sessions are easy to fix with modern authentication; unattended ones need one of the app‑only paths.
  4. For unattended scripts, choose a target authentication method. On‑premises → app‑only with certificate. Azure‑hosted → managed identity where possible, otherwise app‑only with a certificate stored in Azure Key Vault.
  5. Test the replacement connection method against every cmdlet and scenario the script uses. Don’t just test that Connect-ExchangeOnline works; verify that subsequent commands like Get-Mailbox, Set-CalendarProcessing, New-ComplianceSearch, etc., run correctly without falling back to legacy permissions.
  6. Build certificate lifecycle management into your operations runbook. Certificates expire. You need a process to rotate them before they do, and to update the private‑key store on every host that needs it. This is often the hardest operational piece, especially in distributed or air‑gapped environments.
  7. Plan for the server‑side cutoff. Once Microsoft announces that date, any remaining -Credential scripts will stop working, regardless of module version. Use this window to eliminate reliance on the parameter entirely, not just to pin an old module.

How We Got Here

The deprecation of -Credential is the latest chapter in Exchange Online’s long goodbye to basic authentication. Microsoft began disabling basic auth for tenants with no usage in 2021, and by early 2023 it was turned off everywhere. The move was accompanied by guidance to adopt modern authentication (OAuth 2.0) for all protocols, including PowerShell.

The Exchange Online PowerShell module has supported modern authentication since its inception, but its earlier versions also offered -Credential as a convenience. When MSAL deprecated ROPC in version 4.74.0, the clock started ticking. Microsoft’s February 2026 announcement set a client‑side deadline of July 2026, but feedback from the community—complaints about insufficient time, incomplete cmdlet support, and the operational nightmare of rearchitecting thousands of scripts—prompted the extension to December.

That feedback loop is why the delay exists. The admin pushback was significant enough that Microsoft adjusted the schedule, but the company hasn’t budged on the end goal: ROPC and password‑based PowerShell auth must go.

Outlook: Watch for the Server‑Side Date

December 2026 is not the finish line; it’s the start of the waiting game for the server‑side removal. Microsoft has not said when that will happen, only that it will follow the client‑side change. When the announcement comes, organizations that still have scripts dangling on -Credential will have no fallback.

The sensible play: Treat the December date as your own hard deadline for having all automation migrated. By then, every unattended script should be running with a certificate or a managed identity, and every interactive admin should be using modern authentication. The sooner you start, the less painful the transition will be—especially as you’ll need time to debug edge cases, educate your team, and establish the certificate‑management discipline that app‑only auth demands.