Microsoft Purview PowerShell Cmdlet Authentication Migration: April 30 Deadline for Financial Institutions

If your bank, credit union, or mortgage company runs scheduled PowerShell jobs that touch Microsoft Purview retention policies, compliance tags, or retention events, you have one day to migrate. Microsoft 365 Message Center notification MC1213770, originally posted January 6, 2026 and updated April 20, 2026, set the enforcement date for April 30, 2026. Starting that day, scripts that connect to Security and Compliance PowerShell using older versions of the ExchangeOnlineManagement module, or that omit a single new switch parameter, will fail when they call any of thirteen specifically named cmdlets. The portal still works. The PowerShell automation does not.

The change is small in mechanical terms. It is large in operational terms. Most financial institutions have layered records-retention obligations under SEC Rule 17a-4, FINRA Rule 4511, NCUA's records preservation regulation in 12 CFR Part 749, and OCC examination expectations for federal banks. Many of those institutions automate Purview retention policy creation, compliance tagging, and event-driven retention scheduling using the exact PowerShell cmdlets named in MC1213770. The automation runs unattended, often on a server nobody has touched in eighteen months, and it works until tomorrow.

This article walks through what is actually changing, why Microsoft is changing it, the one-line fix that solves it, the operational pitfalls most likely to bite a financial institution during a rushed migration, and the records-retention compliance lens that explains why the deadline matters more for banks, credit unions, and mortgage companies than for most other Microsoft 365 customers.

The April 30 PowerShell Cliff Most FI Compliance Teams Don't See Coming

The trap is set by how invisible the affected workflow is to executive leadership. The bank's CISO knows about the major Microsoft 365 changes that show up in Defender XDR alerts or in the Secure Score dashboard. The CFO sees the retention policy reports. The compliance officer reviews the eDiscovery case logs. None of those people typically sees the PowerShell scheduled job that runs on a domain-joined Windows server at 3:15 a.m. every Sunday and creates new retention compliance rules for the loan-origination archive based on the previous week's loan closures. The script has been running for two years. It has not failed once. It is also about to fail silently in less than 24 hours.

Microsoft has been moving away from legacy authentication patterns for several years. Remote PowerShell, the original protocol for connecting to Exchange Online and Security and Compliance PowerShell, was deprecated for Security and Compliance PowerShell in October 2023. The Exchange Online PowerShell V3 module replaced Remote PowerShell with REST API connectivity that supports modern authentication, multi-factor authentication, and certificate-based app-only authentication. Most financial institutions migrated their scripts to the V3 module during 2023 and 2024. The April 30, 2026 change is the next refinement in that modernization arc.

What MC1213770 changes is the audience claim on the OAuth access token issued during a Connect-IPPSSession session. Without the new -EnableSearchOnlySession switch, the token is scoped to the standard Security and Compliance endpoint. With the switch, the token is scoped to a narrower service audience that permits cross-service operations into Exchange Online, SharePoint Online, Microsoft Teams, and OneDrive. Retention policies that span multiple workloads need that broader audience because applying a single retention rule across an Exchange mailbox and a SharePoint site requires authentication that both services accept. The thirteen specifically named cmdlets are the ones that perform exactly those cross-service operations.

The reason this matters more for financial institutions than for most other Microsoft 365 customers is records retention. Banks, credit unions, and mortgage companies operate under retention rules that other industries do not face. SEC Rule 17a-4 requires broker-dealers to preserve specific books and records for three to six years, with some categories required for the life of the entity plus three years. FINRA Rule 4511 binds member firms to those same retention periods. NCUA's records preservation regulation in 12 CFR Part 749 requires federally insured credit unions to maintain a written records preservation program covering vital records and operational continuity. Manual policy enforcement at scale is impractical. Compliance teams script the work. They script it using exactly the cmdlets named in MC1213770. When the scripts fail tomorrow, the underlying policies still apply, but the institutions lose the automation that operationalizes them.

What Microsoft Changed: The 13 Cmdlets Affected and Why

MC1213770 lists the affected cmdlets explicitly. They fall into four functional groups: retention compliance policies, retention compliance rules, compliance tags (records management), and retention events with their associated event types. Each group corresponds to a different layer of how Microsoft Purview operationalizes records retention across the Microsoft 365 estate.

The first group, retention compliance policies, defines which Microsoft 365 locations are subject to which retention rules. A retention compliance policy can target Exchange mailboxes, SharePoint sites, Microsoft Teams channel messages, OneDrive accounts, Microsoft 365 Groups, or Yammer messages, with an inclusion list and an exclusion list at each location type. The cmdlets in this group create, update, and remove those policies.

The second group, retention compliance rules, defines the actual retention behavior associated with a policy: how long content is retained, what happens at the end of the retention period, and any conditions that trigger the rule. A single policy can have multiple rules that apply to different content types or different conditions.

The third group, compliance tags, defines records management classifications that users or automated processes apply to individual items. A compliance tag is what enables the records management capability in Purview, allowing items to be classified as records that require formal disposition review before deletion. Banks use compliance tags heavily for items subject to BSA five-year retention, OFAC sanctions records, and SEC books and records.

The fourth group, retention events and event types, defines event-driven retention. Instead of starting retention at the moment content is created, event-driven retention starts the clock when something happens in the business: a loan closes, an employee leaves, a customer relationship ends, a deposit account closes. Compliance teams configure event types, then create events that reference those types, and Purview applies the appropriate retention behavior across all locations covered by the relevant policies.

All thirteen cmdlets share a common architectural property: they coordinate across multiple Microsoft 365 services to apply retention behavior. When a script invokes New-RetentionCompliancePolicy with parameters specifying both Exchange mailboxes and SharePoint sites, the Purview backend calls into both services to register the policy and apply enforcement. That cross-service coordination is what the new -EnableSearchOnlySession parameter authenticates. The audience claim in the access token tells Exchange Online and SharePoint Online that this PowerShell session is authorized to ask both services to enforce the same retention rule. Without that audience scope, the cross-service request is rejected as out of scope, and the cmdlet fails.

The EnableSearchOnlySession switch specifies whether to enable certain eDiscovery and related cmdlets that connect to other Microsoft 365 services. Microsoft Learn, Connect-IPPSSession reference, parameter documentation as of April 2026.

It is worth pausing on what is not changing. Cmdlets that operate entirely within Security and Compliance, such as Get-RetentionCompliancePolicy for read-only inventory, are not on the list. Sensitivity label cmdlets like Get-Label, New-Label, and New-LabelPolicy are not on the list. Data Loss Prevention policy cmdlets are not on the list. The change is targeted at the thirteen cmdlets that perform cross-service write operations against retention infrastructure. Read-only operations and within-service operations continue to work without the new parameter.

The thirteen affected cmdlets organized into four functional groups. All thirteen share one property: they perform cross-service write operations that require the broader OAuth audience scope unlocked by -EnableSearchOnlySession.

The One-Line Fix: -EnableSearchOnlySession on ExchangeOnlineManagement v3.9.0

The mechanical remediation has two parts. First, ensure the ExchangeOnlineManagement PowerShell module on the script-execution host is at version 3.9.0 or later, because the -EnableSearchOnlySession switch was introduced in that release. Second, add the switch to every Connect-IPPSSession invocation that runs scripts against the affected cmdlets. Both parts must be done; updating the module without adding the switch fails the same way as adding the switch on a module too old to recognize it.

The verification command for the module version is short. From an elevated PowerShell prompt on the script-execution host, run Get-Module ExchangeOnlineManagement -ListAvailable | Select-Object Version. If the highest version returned is below 3.9.0, run Update-Module ExchangeOnlineManagement -Force followed by a new PowerShell session. The new session will load the updated module. Modules updated mid-session do not always replace the loaded version; restarting the session is the safer pattern.

For interactive sign-in by a human compliance officer, the connection command becomes Connect-IPPSSession -UserPrincipalName admin@bank.com -EnableSearchOnlySession. The session opens a modern authentication dialog that supports multi-factor authentication and Conditional Access policies, then issues an access token with the broader audience. From that point, all retention and compliance-tag cmdlets execute against the token. The session behaves identically to a pre-April-30 session for any cmdlet that was not on the affected list.

For unattended scripts running in Azure Automation, Azure Functions, or Azure Logic Apps, the recommended pattern is managed identity authentication. The runbook or function code calls Connect-IPPSSession -ManagedIdentity -Organization bank.onmicrosoft.com -EnableSearchOnlySession. The platform issues the access token to the Azure-managed identity assigned to the runbook. The script executes without storing any credentials, certificates, or secrets in script files or configuration variables. This pattern is the most secure available option for long-running compliance automation.

Certificate-based authentication, which financial institutions have used for unattended scripts on on-premises servers since the deprecation of Remote PowerShell, has a complication. The thirteen affected cmdlets are not currently compatible with certificate-based authentication when used with the -EnableSearchOnlySession switch. Per Microsoft Learn documentation, the parameter set requires interactive or managed-identity authentication for the affected cmdlets. Scripts that previously used Connect-IPPSSession -CertificateThumbprint <thumbprint> -AppId <guid> -Organization bank.onmicrosoft.com for the affected cmdlets will need to migrate to a different authentication method. The most practical path for financial institutions running these scripts on on-premises servers is to migrate the workload to Azure Automation with a system-assigned managed identity, which eliminates the certificate management overhead and aligns with Microsoft's preferred long-term automation pattern.

The sequence above is intentionally compressed. Inventory in the morning. Module update and parameter addition by mid-afternoon. Test runs and monitoring instrumentation by end of day. For an institution with ten or fewer compliance scripts, the entire migration fits inside a normal change window, with most of the time spent on the inventory and the testing rather than the code edits. For institutions with extensive compliance automation distributed across multiple servers, the inventory step is the longest phase, and starting it before the deadline is the only practical path. Either way, the operational shape is the same: find every affected script, update every host, add the parameter, prove it runs, add the monitoring that catches the next change before it becomes a deadline scramble.

Five Migration Pitfalls That Will Break FI Compliance Automation

Across financial-institution Microsoft 365 estates, five operational pitfalls account for most of the silent failures that show up after authentication changes like this one. Each has a specific remediation. Identifying them in advance turns a one-day deadline scramble into a planned change.

• Module updated on the wrong machine. Compliance scripts often run on a domain-joined Windows server that has not been logged into in months. The administrator updates the ExchangeOnlineManagement module on a workstation, edits the script, and tests it interactively. The test passes. The scheduled job continues to fail because the production server still has the old module loaded under the service account. The remedy is to update the module on every host that executes the script, not only on the developer's workstation. Use Get-Module ExchangeOnlineManagement -ListAvailable on the production host to confirm.
• Certificate-based scripts hitting an incompatibility wall. The affected cmdlets currently do not support certificate-based authentication when combined with -EnableSearchOnlySession. Scripts that previously ran unattended on on-premises servers using -CertificateThumbprint and -AppId cannot simply add the new switch. They must migrate to managed identity authentication in Azure Automation, or be rebuilt as interactive workflows behind a managed PowerShell desktop with a service identity. The remedy is to plan the migration to managed identity now, not after the deadline. Hybrid identity environments may need additional Azure Arc configuration to use managed identity for on-premises workloads.
• One Connect-IPPSSession call serves multiple cmdlet types. A common pattern is a long-running script that connects once and then executes both affected cmdlets and unaffected cmdlets in the same session. The simplest remedy is to add -EnableSearchOnlySession to the single connection call. The switch does not break unaffected cmdlets; it only adds the broader audience scope. Including it unconditionally on every Connect-IPPSSession invocation is the safest pattern, eliminates the need to reason about which cmdlets need it, and is forward-compatible with potential future audience refinements.
• PowerShell module version cached in scheduled-task agent. Scheduled-task hosts that run PowerShell jobs in long-lived agent processes (some monitoring systems, automation runners, and configuration-management agents) cache loaded PowerShell modules in the agent process. Updating the module on disk does not always force the agent to reload. The remedy is to restart the scheduling agent service after a module update, or restart the host. Confirming the version through the same execution path the scheduled job uses is the verification step that prevents this from being a silent failure.
• Logging and monitoring not in place. Most financial institutions discover the failure when a downstream artifact does not exist, not when the script reports an error. The retention policy that should have been created last Sunday is not in Purview, the compliance tag that should have been applied is missing, or an examiner asks for a report that never ran. The remedy is to add explicit success/failure logging to the script, route the logs to a central system, and add an alert on script exit codes and on the existence of expected outputs. Once in place, this monitoring catches not only this enforcement change but every future change that affects script behavior.

The Records-Retention Compliance Lens: SEC, FINRA, NCUA, OCC

The reason a one-day cmdlet authentication change is a compliance event for banks, credit unions, and mortgage companies and a routine IT change for everyone else is records retention. Most industries have records-retention obligations measured in years. Financial institutions have records-retention obligations measured in decades, in non-rewriteable formats, with documentation requirements that examiners audit on a recurring schedule.

The compliance dimension turns this from "update a module and add a parameter" into "document the change, validate it, retest it, and demonstrate to your examiner that the underlying retention controls remained in continuous force across the transition." That documentation is part of the configuration management and change control evidence FFIEC examiners look for. Institutions that can produce a clean record showing the inventory, the migration, the test results, and the post-deployment monitoring satisfy the expectation. Institutions that handled it ad hoc, with no record beyond a Sunday-night chat message saying "I updated the script," typically end up redoing the work under examination pressure six months later.

What "Modern Authentication" Means for FI Purview Operations

Step back from the specific enforcement deadline and the trajectory becomes clear. Microsoft has been retiring legacy authentication patterns one workload at a time. Basic authentication for Exchange Online retired in 2022. Remote PowerShell for Exchange retired by the end of 2023. Remote PowerShell for Security and Compliance retired in 2023. The -Credential parameter on Connect-IPPSSession is on Microsoft's published deprecation roadmap with a target of June 2026, less than two months after the April 30 cmdlet enforcement. The direction is uniform: passwords stored in scripts, basic authentication endpoints, and any pattern that does not support multi-factor authentication or Conditional Access is being systematically removed.

For financial institutions, the implication is that compliance automation needs a target architecture, not a sequence of patch fixes. The target architecture for unattended Purview operations is managed identity in Azure Automation, with role-based access control (RBAC) granting the least privilege required for the specific cmdlets the runbook executes. Managed identity eliminates the certificate management problem, eliminates the password storage problem, and provides clean audit trails through Azure Activity Log. Institutions that have not started the migration to managed identity should not wait for the next enforcement deadline; the migration takes longer than a single change window because RBAC modeling and runbook testing both require careful work.

For interactive Purview operations, the target pattern is sign-in with the user account that has the appropriate Microsoft Purview RBAC roles, multi-factor authentication enforced through Conditional Access, and Web Account Manager handling the credential broker on Windows. This is the pattern Microsoft has been recommending since the V3 module shipped in 2022. Compliance officers running ad-hoc PowerShell sessions to query retention policies or apply compliance tags should be using Connect-IPPSSession -UserPrincipalName officer@bank.com -EnableSearchOnlySession after April 30. The interactive prompt handles MFA naturally; the user account scope provides accountability through Microsoft 365 audit logs.

The broader lesson for financial-institution IT teams is that Microsoft 365 platform changes affecting compliance automation deserve the same change-management treatment as production application releases. The MC1213770 enforcement is not the last one. The June 2026 deprecation of -Credential is already announced. Future changes to Microsoft Purview, Microsoft Defender, Entra ID, and Exchange Online will continue to arrive on roadmaps. Institutions that subscribe to Microsoft 365 Message Center notifications for the relevant categories, document the changes against their compliance automation inventory, and execute planned migrations on a normal change-window cadence avoid most of the pain. Institutions that wait for the deadline and respond reactively eat the deadline pressure every time.

The work for this specific deadline is small. Update the module. Add the parameter. Test the affected scripts. Document the change. Move on to planning the managed identity migration that will simplify the next two enforcement deadlines. For institutions that automate beyond just retention, our Copilot governance dashboard walkthrough covers the broader Purview operational posture, and the email-authentication enforcement roadmap covers the parallel infrastructure-hardening work that complements compliance automation. The institutions that handle this well treat platform-change enforcement as a normal IT operations cadence, not an emergency.

Frequently Asked Questions

The three-step migration sequence. Inventory drives the work; module update plus parameter addition is the mechanical fix; monitoring closes the loop so the next platform change is caught before it becomes a deadline scramble.