Table of Contents
- What breaks when Microsoft blocks IDCRL in SharePoint Online and OneDrive—and how do admins fix it fast?
- Microsoft SharePoint/OneDrive: IDCRL ends January 31, 2026 (MC1184649). OAuth and OpenID Connect take over.
- Key dates and what they mean
- Why Microsoft is doing this
- What administrators should do now
- Temporary fallback (only during the transition)
- Operational guidance (to avoid outages)
Microsoft is retiring the legacy IDCRL authentication protocol for SharePoint Online and OneDrive for Business. The change lands on January 31, 2026, with a short fallback window before modern authentication becomes permanent. Microsoft reiterated the deadline in the Microsoft 365 Message Center (ID MC1184649).
For most organizations, the practical impact is simple: anything that still depends on IDCRL—older clients, custom scripts, or legacy integrations—may start failing unless it is updated to use OpenID Connect or OAuth.
Key dates and what they mean
January 31, 2026: Modern authentication is enforced by default.
- SharePoint Online and OneDrive for Business will authenticate with OpenID Connect and OAuth.
- IDCRL is blocked by default.
- A temporary admin override remains available, so IT can revert to IDCRL for a limited time if a business-critical workflow breaks.
May 1, 2026: Modern authentication becomes mandatory.
- OpenID Connect and OAuth are required.
- The ability to switch back to IDCRL ends (Microsoft states the reversion is disabled after April 30, 2026).
Why Microsoft is doing this
IDCRL (Identity Client Run Time Library) is an older approach that does not align with modern security expectations. Microsoft positions this retirement under the Secure Future Initiative (SFI) and the “secure by default” model.
From a risk standpoint, modern protocols help reduce exposure tied to legacy sign-in patterns and improve compatibility with stronger controls (conditional access, modern token handling, better auditing). Recent public reporting and Microsoft threat write-ups around SharePoint-related phishing and account compromise reinforce the broader message: legacy authentication paths create avoidable attack surface, especially when strong controls like MFA are missing or bypassed.
What administrators should do now
Treat this as a migration project with an inventory step first. The goal is to find every dependency on IDCRL and shift it to OpenID Connect or OAuth before the cutoff.
- Inventory usage: Identify which clients, scripts, tools, add-ins, and line-of-business apps still use legacy sign-in flows.
- Validate configuration: Check tenant and app settings that may still permit or rely on older authentication.
- Coordinate owners: Notify IT admins, application owners, and security teams so changes land with a clear timeline and rollback plan.
- Update documentation: Record the new standard (OpenID Connect/OAuth), plus any app registration patterns and support procedures.
- Use telemetry: Monitor sign-in logs and client usage signals to locate legacy authentication attempts and confirm the decline as you remediate.
Temporary fallback (only during the transition)
If a critical workload fails after January 31 and cannot be remediated immediately, Microsoft allows a short-term revert through PowerShell by setting legacy auth controls to True:
- AllowLegacyAuthProtocolsEnabledSetting
- LegacyAuthProtocolsEnabled
Use this only as a short bridge. Plan to remove the dependency, because the fallback stops after April 30, 2026, and modern authentication becomes non-optional starting May 1, 2026.
Operational guidance (to avoid outages)
Keep the execution tight: test, change, verify, then retire the exception.
- Test critical user journeys (sync, file open/save, sharing, automation jobs).
- Prioritize service accounts and unattended scripts, since they often hide legacy auth.
- Schedule a controlled cutover window, even if Microsoft flips the default, so support teams are ready.
- Track exceptions explicitly and assign each one an owner and removal date.