Audience: SharePoint admins, M365 admins, and anyone running automations that access SharePoint Online/OneDrive. This post explains what’s changing, how to detect legacy sign-ins, and the practical steps to move to modern authentication (OAuth) before the cutoff dates. 

Microsoft is turning off a legacy SharePoint sign-in method called IDCRL (Identity Client Run Time Library). If you only access SharePoint and OneDrive through the browser or Microsoft 365 apps, you’re probably fine—but if you run scripts, Power BI refreshes, Power Automate flows, or third-party tools that store a username/password, you’ll want to update those connections to Modern Authentication (OAuth/OpenID Connect) now to avoid outages. 

TL:DR (What you need to know) 

• Who’s most affected: Any non-interactive connection that stores a SharePoint username/password (scripts, scheduled jobs, Power BI refreshes, Power Automate flows, and third-party tools). 

• What’s changing: Microsoft is retiring legacy SharePoint authentication (IDCRL) for SharePoint Online and OneDrive for Business. 

• What to do: Move those connections to modern authentication (OAuth/OpenID Connect) using supported connectors, modules, or app registrations. 

• Key dates: Mid-February 2026 (legacy logins blocked by default), April 30, 2026 (last day an admin extension can keep legacy auth temporarily allowed), and May 1, 2026 (IDCRL fully retired and cannot be re-enabled). 

Quick checklist 

• Inventory: list SharePoint connections you own (scripts, Power BI, Power Automate, third-party tools). 

• Spot legacy auth: saved passwords, “Basic” auth, or PowerShell -Credential/SharePointOnlineCredentials. 

• Migrate: switch to Modern Authentication (OAuth) using supported connectors/modules. 

• Test: run the script/refresh/flow end-to-end and confirm it still works. 

• Finish early: complete updates ahead of mid-February 2026, and no later than May 1, 2026. 

What Is IDCRL and Why Is It Going Away? 

IDCRL (Identity Client Run Time Library) is an older SharePoint sign-in approach used by some legacy apps and scripts. In plain terms, it’s the “just pass a username and password” style of authentication. While most interactive sign-ins moved to modern authentication years ago, some behind-the-scenes tools still use IDCRL—often without the person who set them up realizing it. 

Why is Microsoft retiring it? Because password-based legacy flows are harder to protect and don’t align well with today’s security controls. Modern Authentication uses OpenID Connect and OAuth 2.0 with short-lived tokens (not stored passwords) and works cleanly with protections like MFA and Conditional Access. This is part of Microsoft’s broader “secure by default” direction—and it reduces risk for both individual accounts and the organization. 

From Microsoft’s guidance, the main shift is stop sending passwords to SharePoint and start acquiring OAuth access tokens via the Microsoft identity platform. For custom solutions, that typically means using MSAL (Microsoft Authentication Library) and either an interactive sign-in (delegated permissions) or an app-only approach (application permissions) depending on your scenario. 

Key Dates and Impact on Users 

Here’s the timeline Microsoft shared for SharePoint Online and OneDrive for Business: mid-February 2026 is when remaining legacy (IDCRL) logins will be blocked by default. If customers need additional time to complete migration, tenant admins can temporarily allow legacy authentication again (extension) until April 30, 2026. Then, on May 1, 2026, IDCRL is fully retired and cannot be re-enabled. 

In other words, anything still connected with an embedded username/password is likely to break. The risk is concentrated in custom integrations and automations (scripts, refreshes, flows, vendor tools) that still rely on legacy auth. 

How Do I Know If I’m Using Legacy Authentication? 

If you only access SharePoint/OneDrive through the browser, Microsoft 365 apps, or standard Microsoft connectors, you’re typically already using modern authentication. A simple rule of thumb: if a script, dataset, flow, or tool stores a SharePoint username/password, plan to modernize it. For the most common patterns and what to switch to, see How to Transition to Modern Authentication (Action Plan) below. 

Check Microsoft Purview audit logs (recommended) 

If you want a definitive answer (beyond “does this script store a password?”), review your tenant’s activity in Microsoft Purview audit and search for IDCRLSuccessSignIn events. 

1. Open the Microsoft Purview portal and go to Audit. 
2. Run an Audit search for an appropriate time range (start with the last 30–60 days). 
3. Under Activities (operations name), select IDCRLSuccessSignIn.

    

   
4. Submit the search, review results, then export (download) the results for deeper filtering in Excel. 

What to look for in the export 

• For IDCRLSuccessSignIn results, focus on the user/account, time pattern, and any available client/app details (for example, user agent, application name, or client IP) to pinpoint what’s generating the legacy sign-ins. 

• Look for patterns that match automation: recurring events (hourly/daily), service accounts, or sign-ins that line up with scheduled refreshes/flows. Then map those timestamps back to likely owners: Power BI datasets, Power Automate flows, scripts, or vendor tools. 

• If your export includes client/app identifiers, note any unexpected apps accessing SharePoint; those are the best candidates to validate and migrate first. 

• Cross-check suspicious entries with your inventory (scripts, Power BI datasets, Power Automate flows, vendor tools) and then update the matching connection to OAuth. 

Not sure whether something you own is using legacy auth? A good starting point is to check how the connection was set up: if it relies on a stored password, plan to update it. If you’re still unsure, reach out to IT support or the vendor/developer of the tool—many providers have already published “modern auth” upgrade steps. 

How to Transition to Modern Authentication (Action Plan) 

If you own anything that connects to SharePoint behind the scenes, the goal is simple: move every connection to Modern Authentication and test it end-to-end well before the cutoff. Below are the most common “legacy” patterns and what to switch to. 

Common legacy scenarios (and modern replacement) 

1) PowerShell scripts or custom code that pass a username/password 

• If you’re using older SharePoint Online PowerShell patterns like -Credential, Get-Credential or SharePointOnlineCredentials, plan to update. 

• Use updated modules that default to OAuth or use PnP PowerShell with interactive sign-in or an Entra app (certificate/client ID) rather than stored credentials. Additionally, according to Microsoft’s announcement in the M365 admin center (MC1188595), the Microsoft.Online.SharePoint.PowerShell module (version 16.0.26712.12000 or newer) supports app-only authentication with a certificate and an Entra app registration (instead of legacy username/password patterns), using Connect-SPOService. 

• For custom apps, adopt token-based auth via MSAL and supported SharePoint libraries. 

Example: 

$appID = "1e499dc4-1988-48ef-8f4f-9756f4f04548" # This is your Entra App ID 
$tenant = "9cfc52cb-53da-4154-67e9-b20b170b7ba3" # This is your Tenant ID 
$thumbprint = "6EAD7303b5C7E27Dc4245989AD554642940BA093" # This is certificate thumbprint 
$cert = Get-ChildItem Cert:\LocalMachine\My\$thumbprint 
Connect-SPOService -Url 'https://contoso-admin.sharepoint.com' -Certificate $cert -ClientId $appID -TenantId $tenant 

  

2) Power BI reports that connect to SharePoint using “Basic” credentials 

• In Power BI Desktop, open Data source settings for SharePoint connections and switch the authentication method to Microsoft (Organizational) Account / OAuth2. 

• After updating, re-publish and confirm scheduled refresh still works. 

3) Power Automate flows (or workflows) that store a username/password 

• Prefer the official SharePoint connector (modern auth by default) over custom HTTP calls with stored credentials. 

• For custom connectors, use an Azure AD app registration and configure OAuth 2.0 so the flow uses tokens, not passwords. 

4) Third-party tools (migration/sync/reporting) that use “other user” or stored credentials 

• Update the tool to the latest version and confirm it supports modern authentication for SharePoint Online. 

• Run a full test (connect, read/write, scheduled jobs) well before the cutoff dates. 

A few best practices while you’re updating 

• Don’t delay: Modernize your connections before mid-February 2026 (when legacy logins are blocked by default), and no later than May 1, 2026. 

• Extension (if needed): If you need more time, tenant admins can temporarily allow legacy authentication until April 30, 2026. Treat this as short-term mitigation while your complete migration and validation—not a long-term solution. 

• Use official solutions: Where possible, use Microsoft’s supported clients and connectors (like updated SharePoint PowerShell modules, Power BI’s OAuth login, and Power Automate SharePoint actions) instead of hard-coding credentials. These default options are already used by modern auth and will help ensure access continues. 

• Improve security: Embrace modern authentication to benefit from better security (support for MFA, conditional access, etc.) and to eliminate reliance on outdated passwords or legacy API calls. 

• Get help if needed: If you’re unsure how to update a specific application or script, contact your IT support team or the vendor/developer of the tool. 

PowerShell: temporarily allow legacy authentication (extension) 

If an extension is required, tenant admins can use SharePoint Online PowerShell to temporarily allow legacy authentication by setting AllowLegacyAuthProtocolsEnabledSetting and LegacyAuthProtocolsEnabled to $true. 

 

Set-SPOTenant -AllowLegacyAuthProtocolsEnabledSetting $true 
Set-SPOTenant -LegacyAuthProtocolsEnabled $true  

 

Recommendation: Block time now to inventory and modernize your SharePoint connections, then run a full end-to-end test. Doing this early helps you avoid last-minute troubleshooting when a refresh, script, or workflow suddenly fails. 

Next steps (recommended) 

• Run a Purview audit search for IDCRLSuccessSignIn (last 30–60 days) and identify the owners of each recurring legacy sign-in. 

• Prioritize and modernize the highest-impact items first (scheduled Power BI refreshes, production automations, service accounts, and vendor tools), then test end-to-end. 

• If you must use the temporary extension, set a firm internal deadline to turn it back off and complete migration before May 1, 2026. 

Helpful Resources and Support 

For further reading and technical guidance, please see the following official resource: 

• Microsoft 365 Developer Blog – Migrating from IDCRL to Modern Authentication in SharePoint – Explains the retirement decision and provides developer-oriented steps for migrating code and scripts to MSAL/OAuth. 

Conclusion and call to action 

IDCRL retirement is one of those changes that is easy to miss until something breaks—because the impact shows up in background jobs, not in day-to-day browser use. The good news is that the fix is straightforward: identify anything still using stored credentials and move it to modern authentication (OAuth) well before the deadline. 

 

• Inventory: list every script, dataset, flow, and vendor tool that connects to SharePoint/OneDrive. 

• Modernize: replace embedded usernames/passwords with OAuth via supported connectors, updated modules, or an Entra app registration. 

• Test: run each workload end-to-end (including scheduled runs) and confirm it behaves as expected. 

 

Timeline reminder: legacy logins are blocked by default in mid-February 2026, extensions (if used) run through April 30, 2026, and IDCRL is fully retired on May 1, 2026. 

Q&A 

Q: Will this impact end users who only use SharePoint in a browser or the Microsoft 365 apps? 
A: Typically, no. Most interactive sign-ins already use modern authentication. The main risk is with background processes that still send stored usernames/passwords. 

Q: What’s most likely to break? 
A: Anything non-interactive that connects to SharePoint/OneDrive using embedded credentials—PowerShell scripts, scheduled jobs, Power BI refreshes configured with “Basic” credentials, Power Automate flows/custom connectors that store passwords, and some third-party tools. 

Q: How can I confirm whether my tenant is still using IDCRL? 
A: Use Microsoft Purview audit and search for IDCRLSuccessSignIn. Export the results and look for recurring patterns (service accounts, scheduled times, consistent client/app details) to identify the source. 

Q: What happens in mid-February 2026 vs. May 1, 2026? 
A: In mid-February 2026, legacy (IDCRL) logins are blocked by default—so legacy-dependent workloads may start failing unless updated (or temporarily re-enabled). On May 1, 2026, IDCRL is fully retired and cannot be re-enabled. 

Q: We need more time—what does the “extension” do? 
A: It temporarily allows legacy authentication again through April 30, 2026 while you complete migration. You can enable it with: 
Set-SPOTenant -AllowLegacyAuthProtocolsEnabledSetting $true 
Set-SPOTenant -LegacyAuthProtocolsEnabled $true 
Use this as a short-term mitigation and set a firm plan to turn it back off after you modernize. 

Q: What’s the recommended modern auth approach for PowerShell? 
A: Use modern modules and token-based sign-in (OAuth). For automation, use an Entra app registration with a certificate (app-only) where appropriate. The updated Microsoft.Online.SharePoint.PowerShell module (v16.0.26712.12000+) also supports Connect-SPOService with certificate-based app-only authentication. 

Q: What should I do for Power BI datasets that connect to SharePoint? 
A: In Power BI Desktop, update the SharePoint data source authentication to Microsoft (Organizational) Account / OAuth2, then republish and validate that scheduled refresh succeeds. 

Q: What about Power Automate flows or custom connectors? 
A: Prefer the built-in SharePoint connector (modern auth by default). If you’re using custom HTTP actions or custom connectors, update them to use OAuth 2.0 with an Entra app registration rather than stored credentials. 

Admin email template (notify owners identified in Purview) 

Use the template below to contact the user/account you found in your IDCRLSuccessSignIn audit export. Copy/paste it into Outlook, then fill in the placeholders (timestamps, site, and any client details) so the recipient can quickly identify the workload. 

 

Subject: Action required: Update a SharePoint/OneDrive connection using legacy authentication (IDCRL) 

Hi <Name>, 

We’re reaching out because Microsoft is retiring legacy SharePoint authentication (IDCRL). Our audit review indicates a legacy sign-in associated with your account. If the underlying workload isn’t updated, it may fail when legacy authentication is blocked/retired. 

What we observed (from Microsoft Purview audit) 

• User/account: <UPN or service account> 

• Activity: IDCRLSuccessSignIn 

• Timestamp(s): <YYYY-MM-DD HH:MM TZ> (add 2–3 examples if recurring) 

• SharePoint site (if known): <site URL> 

• Client details (if available): <client/app, user agent, IP> 

What we need from you 

1. Please confirm what workload is generating this sign-in (for example: Power BI dataset refresh, Power Automate flow, PowerShell script, scheduled job, or a third-party tool). 

1. If you’re not the owner, please reply with the correct owner/contact (a team name or distribution list is fine). 

Timeline 

• Mid-February 2026: legacy logins blocked by default 

• May 1, 2026: IDCRL fully retired (cannot be re-enabled) 

• Note: if an extension is used, it is temporary and runs through April 30, 2026. 

How we can help We can help update the connection to modern authentication (OAuth). In many cases this is as simple as re-authenticating with “Microsoft (Organizational) Account”/OAuth (Power BI), using the SharePoint connector (Power Automate), or updating scripts to use an Entra app registration with certificate-based authentication. 

Please reply by: <target response date> 

Thanks, 
<Your name> 
<Team/Role> 
<Contact info> 

 

Tip: Consider including 2–3 sample timestamps from the export (especially recurring ones) and, if you have it, the dataset/flow name or server/job name that matches the schedule. If you don’t get a response, follow up with the user’s manager or the owning team for the workload, and consider using the temporary extension only as a short-term mitigation while ownership is confirmed.