Table of Contents
IDCRL Events Add to the Oddities and Problems for the Microsoft 365 Unified Audit Log
I wish I could report that the Microsoft 365 unified audit log is a paragon of software virtue: always available, always responsive, and dependably accurate. But it’s not. Far too many hiccups have occurred in the history of the audit log since it arrived in 2016, from disappearing data in audit records to truncated event payloads.
Microsoft has tried to make searching the audit log more dependable with high completeness searches (didn’t work) and a Graph API for audit searches (which has its own oddities).
I think many of the problems can be traced back to the way that audit events are stored in special audit mailboxes. This was a good solution in 2016 because the Exchange ESE database excels at handling unstructured information and the data volume was reasonably low. Today, more audit data is generated than ever before and kept for longer, so the processing required to find audit information is more challenging. The situation isn’t helped when developers stuff odd data into the audit log.
IDCRLBlockedDueToSoftEnforcement Events Flood the Unified Audit Log
Most of the time, people who understand and cope with audit log oddities don’t notice problems. Experience inures them against further harm. Then something occurs that makes you wonder if anyone within Microsoft exerts any control over the audit log.
While trying to figure out some background system events that are captured in the unified audit log, I noticed that searches returned a huge number of IDCRLBlockedDueToSoftEnforcement events. These events are linked to the retirement of the legacy Identity Client Run Time Library (IDCRL) authentication mechanism from SharePoint Online. According to Microsoft, IDCRL permanently retired on May 1, 2026. Each event means that a client or app attempted to use IDCRL and was blocked by SharePoint Online.
Six days beforehand, at roughly 16:00 UTC on 25 April 2026, Office applications started to log IDCRLBlockedDueToSoftEnforcement events (including clients called Microsoft Office Existence Discovery and Microsoft Office Core Storage Infrastructure). Even an application called Microsoft Office Word 2014 reported IDCRL events.
Looking at the pattern the logged events, it seemed like SharePoint Online logged up to six events each time Word opened a file with further events being logged when saving files (Figure 1).
Unhelpfully, the audit events note the user as “Unknown,” which makes it harder to correlate the IDCRL events with other events. Also, the audit data payload in many of the events (see example below) contain a property noting that the authentication is OAuth, so you’d wonder why it’s necessary to generate an IDCRL event.
RecordType : SharePoint
CreationDate : 06/05/2026 21:39:59
UserIds : Unknown User
Operations : IDCRLBlockedDueToSoftEnforcement
AuditData : {
"AppAccessContext": {
"AADSessionId": "00b749f9-fa17-196b-5c82-6cfd55fc619e",
"ClientAppId": "d3590ed6-52b3-4102-aeff-aad2292ab01c",
"ClientAppName": "Microsoft Office",
"CorrelationId": "891611a2-e068-a000-16d3-21c0c289d35b",
"TokenIssuedAtTime": "2026-05-06T20:40:11",
"UniqueTokenId": "RMYMDUQXwUuXk0GlQbMOAA",
"UserObjectId": "eff4cd58-1bb8-4899-94de-795f656b4a18"
},
"CreationTime": "2026-05-06T21:39:59",
"Id": "f8590203-f485-4544-71fc-08deabb805b7",
"Operation": "IDCRLBlockedDueToSoftEnforcement",
"OrganizationId": "a662313f-14fc-43a2-9a7a-d2e27f4f3478",
"RecordType": "SharePoint",
"UserKey": "Unknown User",
"UserType": "Regular",
"Version": 1,
"Workload": "SharePoint",
"ClientIP": "2a06:5900:5cb:9d00:d497:ee3c:ec37:98b7",
"UserId": "Unknown User",
"ApplicationId": "d3590ed6-52b3-4102-aeff-aad2292ab01c",
"AuthenticationType": "OAuth",
"BrowserName": "",
"BrowserVersion": "",
"CorrelationId": "891611a2-e068-a000-16d3-21c0c289d35b",
"EventSource": "SharePoint",
"GeoLocation": "EUR",
"IsManagedDevice": false,
"ItemType": "Invalid",
"Platform": "WinDesktop",
"UserAgent": "Microsoft Office Word/16.0.20026.20022 (Windows/10.0; Desktop x64; en-IE; Desktop app;
Microsoft Cor",
"DeviceDisplayName": "2a01:111:2053:3200::ad4:109a",
"ApplicationDisplayName": "Microsoft Office",
"SiteUrl": "https://office365itpros.sharepoint.com/_vti_bin/cobalt.ashx/cellstorageservice"
}
SharePoint Online Still Logging Events and Some Unexplained Delays
As I write this text, SharePoint Online (and OneDrive for Business) is still logging IDCRLBlockedDueToSoftEnforcement events when Office apps attempt to use IDCRL to access “real sites” (those that store documents) and “interesting locations” like “https://office365itpros.sharepoint.com/_vti_bin/cobalt.ashx/cellstorageservice” (part of the backend service to support co-authoring). Many of the events are logged for a site folder rather than a file, which might indicate that Word is trying to read details of the files in a folder.
The errors don’t appear to have any impact on the Microsoft Office apps in terms of their ability to create and edit files stored in SharePoint Online when working with local copies that the OneDrive sync client synchronizes back to the server. I have noticed some delays when opening files through the SharePoint Online browser interface. The file opens and then seems to freeze for several seconds. This might be due to some other server hiccup, but it’s an interesting correlation between delays and events. No audit records are logged when editing files with Word Online, and no delays occur when opening files with Word Online.
Microsoft’s blog announcing the retirement of IDCRL mentions searching for IDCRLSuccessSignIn audit events (zero found in my tenant) without saying anything about IDCRLBlockedDueToSoftEnforcement events, especially those generated by Microsoft Office applications. Maybe no one told the Office developers that the legacy sign-in method was no longer reported.
Tens of Thousands of Unwanted Events
The IDCRLBlockedDueToSoftEnforcement events generated by SharePoint Online for Office applications clutters up the unified audit log, slows retrieval, and makes post-processing more difficult. It also means that tenants that export audit log events to an external repository like Splunk or Microsoft Sentinel have a bunch of unwanted events to deal with.
In one example audit log search that I ran to find all events generated over a 2-day period, 1256 or 4906 events returned by the search (25.6%) were IDCRLBlockedDueToSoftEnforcement events. That’s a bunch of digital debris that just shouldn’t be there. Searching the audit log is difficult enough without Microsoft adding a bunch of non-essential events (“Office slop”) to the mix.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.