Block for Service Principal-Less Authentication in March 2026
One of the latest announcements from Microsoft engineering groups to improve the overall security of their cloud infrastructure is Entra’s decision to halt service principal-less authentication from March 2026. It’s an example of eradicating old practices that are unacceptable in today’s threat environment.
Service principal-less authentication happens when an enterprise app (aka a multitenant app) is used without a service principal in the host tenant. Enterprise apps are created by Microsoft and other software vendors. The Microsoft Graph Command Line Tools app (used to connect to the Microsoft Graph with PowerShell) is an example of a multitenant app. In this case, the Microsoft Graph Command Line Tools app has a service principal in the host tenant, which the app uses to hold the set of delegated Graph permissions available in interactive PowerShell sessions.
The Lack of a Service Principal
When an enterprise app doesn’t have a service principal, it probably means that the app only needs a basic level of authentication to allow the app to run. Post authentication, the app takes care of whatever processing it needs to do without using tenant-assigned permissions. Microsoft wants to block this kind of authentication saying that “Service principal-less authentication can be abused if the resource applications (i.e. APIs) perform incomplete validations.” Microsoft says that they have verified that validations aren’t vulnerable to service principal-less authentication, but they want to block the route now to avoid the possibility of a gap appearing in the future.
Reading between the lines, Microsoft doesn’t want apps to simply appear in a tenant, have a fairly loose connection to Entra ID, and be able to process data without administrative oversight.
After the block is active from March 2026, Entra ID will not allow enterprise apps to authenticate if they don’t have a matching service principal. It’s therefore wise to check tenants to identify any apps in this category to allow the problem to be mitigated.
Finding Problem Enterprise Apps
In their documentation, Microsoft explains how to use sign-in logs to identify problem enterprise apps. The advice focuses on looking for information through the Service principal sign-ins tab. I didn’t find anything there, but I found some interesting results by scanning sign-in logs for interactive connections. This code looks for sign-ins that have a service principal of ‘00000000-0000-0000-0000-000000000000’ and reports what it finds (this article describes a more comprehensive script to report service principal sign-ins):
$Uri = "https://graph.microsoft.com/beta/auditLogs/signIns?`$filter=servicePrincipalId eq '00000000-0000-0000-0000-000000000000'"
[array]$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get
$Data = $Data.Value
$Data | Group-Object ResourceDisplayName -NoElement | Sort-Object Count | Format-Table Name, Count
Name Count
---- -----
Exchange Admin Center 1
Microsoft 365 App Catalog Services 1
Microsoft Activity Feed Service 1
Microsoft Office 365 Portal 1
OfficeHome 1
Password Breach Authenticator 1
Microsoft Edge Auth 3
Account Linking 5
IrisSelectionFrontDoor 5
Office365 Shell WCSS-Server 5
6
Augmentation Loop 6
Microsoft News Feed 10
Office 365 Exchange Microservices 10
Edge Sync 14
A bunch of Microsoft apps are in the collection, many of which appear in the Entra documentation explaining how to identify first-party apps. In addition, there’s an odd entry for a nameless app that comes from the Microsoft Services tenant (home tenant identifier f8cdef31-a31e-4b4a-93e4-5f571e91255a with an application identifier of 29d9ed98-a469-4536-ade2-f981bc1d605e). The default domain name for the app is sharepoint.com, so it’s reasonable to conclude that it’s something to do with SharePoint Online.
Figure 1 shows the details of a sign-in for the Office365 Shell WCSS-Server app, generated when I accessed the SharePoint Online admin center.
The Office365 Shell WCSS-Server app is browser code that runs whenever a user navigates to most Microsoft 365 browser apps. The shell, also known as the suite header, is shared code that loads as part of almost all workloads, including SharePoint, OneDrive, Outlook, and Viva Engage. The code is probably performing some internal processing that doesn’t need the tenant to grant permissions, so it doesn’t have a service principal.
Mitigating the Lack of a Service Principal
All of this is very interesting, but Microsoft’s mitigation for service principal-less authentication is for tenants to create a service principal for each of the affected apps. Given that so many Microsoft apps seem to be affected, does this mean that tenant administrators will have to create service principals for these apps?
The answer is no. The Entra ID team confirmed to me that they’ll take care of Microsoft apps and will update the documentation to this effect. The mitigation requirement only arises for third-party enterprise apps. The call to action remains to check if any of these apps exist in your tenant, and if you find some examples, it’s time to contact the app owners to ask them how they plan to function when service principal-less authentication no longer works.
So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem, including Entra ID. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.