Microsoft Entra ID

How to Monitor Service Principal Sign-Ins in Microsoft Entra

Service principals often run critical automated tasks with elevated privileges, which makes them high-value targets for attackers. Since they operate silently without user interaction, unauthorized access can slip by undetected. To minimize this risk, it’s crucial to keep a close watch on their sign-in activity and spot anomalies early. This guide shows how to track service principal logins in Microsoft Entra to strengthen visibility and control over non-user access.

Monitor Service Principal Sign-Ins Using Microsoft Entra Admin Center

Microsoft 365 Permission Required

Security Reader Least Privilege

Global Admin Most Privilege

Log in to the Microsoft Entra admin center.
Navigate to Entra ID»Monitoring & health»Sign-in logs»Service principal sign-ins.
Here, you can view service principal sign-ins from the last 24 hours. Sign-ins by the same service principal under identical conditions are grouped into a single row. Click on a row to view more details.

Monitor Service Principal Sign-Ins Using Microsoft Entra Admin Center

Note: You can modify the Date filter on the Microsoft Entra sign-in logs to view service principal sign-ins from the last 30 days.

Analyze Service Principal Sign-In Activity Using Windows PowerShell

Microsoft Graph Permission Required

AuditLog.Read.All Least Privilege

Directory.ReadWrite.All Most Privilege

Connect to the Microsoft Graph PowerShell using the below cmdlet.

Windows PowerShell

 Connect-MgGraph -Scopes "AuditLog.Read.All"

Run the below cmdlet to audit all service principal sign-ins in Microsoft 365.

Windows PowerShell

 Get-MgBetaAuditLogSignIn -Filter "signInEventTypes/any(t:t eq 'servicePrincipal')" -All |
Select-Object CreatedDateTime, Id, ServicePrincipalId, ServicePrincipalName,
ResourceDisplayName, ResourceId, @{Name = "Status"; Expression = { if
($_.Status.ErrorCode -eq 0) { "Success" } else { "Failed" } }} | Format-Table

The cmdlet retrieves all service principal sign-in activity records for the last 30 days.

Analyze Service Principal Sign-In Activity Using Windows PowerShell

Simple & Quick
Track Service Principal Sign-In Activity Using AdminDroid

AdminDroid Permission Required Delegated

Any user with the report access delegated by the Super Admin.

Log in to the AdminDroid 365 portal.
Navigate to the Sign-ins by apps and service principals without user involvement report under Reports»Entra»Analytics»Sign-In Analytics»Sign-Ins»Sign-In Types» Service Principal Sign-Ins.
This report offers detailed insights into the service principal sign-in activity with information such as sign-in time, service principal name, signed-in application name, sign-in status, and more.

Track Service Principal Sign-In Activity Using AdminDroid

AdminDroid Entra ID Auditing Tool

Monitor Service Principal Login Patterns to Stay Ahead of Security Threats

AdminDroid's sign-in activity monitoring tool helps admins stay on top of service principal sign-in activity by revealing app sign-in patterns. In addition, it provides insightful reports on service principal consents, usage, access trends, and more. These reports enhance visibility and offer greater control over app-based authentication across your organization.

Track All Service Principal Changes To Avoid Credential Disruptions

Monitor all service principal changes to identify unauthorized credential updates that can disrupt automated workflows or background processes dependent on existing sign-in credentials.

Monitor Application Sign-In Patterns to Detect Misconfigurations

Use the organization sign-in count based on application report to get an overview of interrupted or failed service principal sign-ins, which may indicate configuration issues or brute-force attempts.

Verify Scope Assignments to Reduce Risky Service Principal Access

Analyze the service principal OAuth2 permission scopes to ensure minimal access right and remove excessive or unused scopes assigned to Microsoft Entra service principals.

Identify Disabled Service Principals to Improve Access Control

Use the sign-in disabled service principals report to identify registered applications where user sign-ins are disabled and take appropriate action to remove or re-enable them.

Identify Service Principals with Soon-to-Expire Credentials

Find all service principals withcredentials nearing expiry to renew certificates or client secrets in time and avoid authentication failures in automated workflows.

Audit Objects Linked to Service Principals to Maintain Least Privilege

Audit service principals with access assigned objects report to identify which users, groups, or applications have been granted access through specific service principals.

Overall, AdminDroid Entra ID management tool simplifies service principal sign-in oversight by providing detailed visibility into each authentication attempt. It also offers actionable insights into users, groups, devices, applications and security settings and helps elevate Microsoft 365 management to the next level.

Explore a full range of reporting options

Download Live Demo

Important Tips

Set up app management policies in Microsoft Entra to block custom secrets for service principals and stop unauthorized sign-ins with malicious secrets.

Create identity workbooks in Microsoft Entra to gain visual, in-depth insights into service principal sign-in activities and detect suspicious or unusual access patterns.

Analyze Conditional Access impacts on service principals sign-ins to identify suspicious sign-in attempts originating from untrusted IPs or unfamiliar locations.

Common Errors and Resolution Steps

The following are the possible errors and troubleshooting hints while monitoring service principal sign-ins in Microsoft 365.

Error The term 'Get-MgBetaAuditLogSignIn' is not recognized as the name of a cmdlet, function, script file, or operable program.

This error occurs in Powershell when the Microsoft.Graph.Beta module is not installed or not imported properly.

Fix To resolve this error, install and connect the Microsoft.Graph.Beta module, before running the 'Get-MgBetaAuditLogSignIn' cmdlet.

#To install the Microsoft Graph beta module
Install-Module Microsoft.Graph.Beta -Scope CurrentUser -AllowClobber -Force
#To import and connect Microsoft Graph beta module
Import-Module Microsoft.Graph.Beta 
Connect-MgGraph

Error Connect-MgGraph : ClientSecretCredential authentication failed.

This error occurs in PowerShell when you connect to Microsoft Graph with an expired or incorrect client secret.

Fix Ensure the client secret is valid. If it’s expired, generate a new client secret in the application, and then reconnect to Microsoft Graph Powershell with the updated credentials.

Error Get-MgBetaAuditLogSignIn : Calling principal does not have required MSGraph permissions AuditLog.Read.All

This error occurs when you run the 'Get-MgBetaAuditLogSignIn' cmdlet without required permissions to access sign-in logs.

Fix Disconnect the current session and reconnect to Microsoft Graph using the AuditLog.Read.All scope as follows.

Connect-MgGraph -Scopes "AuditLog.Read.All"

Error Get-MgBetaAuditLogSignIn : One or more errors occurred.

This error occurs when one or more versions of Microsoft Graph module is installed in Powershell.

Fix List all available Microsoft graph modules in PowerShell using the following cmdlet and remove unused versions.

#To list all the available versions of Microsoft Graph beta module
Get-Module -Name Microsoft.Graph.Beta -ListAvailable
#To uninstall a specific version of the Microsoft Graph beta module
Get-InstalledModule -Name Microsoft.Graph.Beta* | Where-Object { $.Version -eq "<Version>"} | ForEach-Object { Uninstall-Module -Name $_.Name -RequiredVersion $_.Version -Force }

Microsoft Entra ID

Frequently Asked Questions

Audit Service Principal Sign-Ins for Better Access Control in Microsoft 365.

What are the reasons to track service principal sign-ins?

How to restrict service principal sign-ins in Microsoft 365?

How to detect risky service principals in Microsoft 365?

How do you handle service principal failed login attempts?

1. What are the reasons to track service principal sign-ins?

Service principals use client secrets and certificates to access Microsoft 365 resources. Anyone with these credentials can access your organization’s data through the service principal, which makes it difficult to hold users accountable. That’s why monitoring Microsoft Entra service principal sign-ins is critical to detect unusual activity. It helps maintain visibility into which resources are accessed and by whom.

Here are a few key reasons to audit service principal sign-ins in Microsoft Entra

Detect compromised service principals: Service principals often have broad access and are rarely monitored in Microsoft 365. This makes them attractive targets for cyber threat actors. Monitoring their sign-ins helps detect risky threats early and improves the overall security posture of your environment.
Track risky sign-in patterns: Monitoring service principal sign-ins helps you understand usual sign-in activity, such as typical sign-in times and IP addresses. This pattern makes it easier to spot risky sign-ins from unusual times or unexpected locations. Detecting such deviations early allows quick remediation such as revoking access for the service principal.
Identify expired credentials: Service principals are commonly used in automated tasks and background services. When a client secret or certificate expires, these workflows can suddenly fail, often without warning. Tracking service principal sign-ins helps you spot authentication failures caused by expired credentials. This allows you to renew them before they disrupt critical automation further.
Resource utilization: Service principals act as access channels through which applications interact with resources like APIs, databases, or storage. Therefore, it's essential for admins to track which applications are in use and what resources they access to detect unauthorized or excessive access before it becomes a security risk.
Manage user consent to applications: By tracking sign-ins, you can identify unused or malicious applications usage in your organization. Once detected, revoke the user consent granted to those applications to prevent further data exposure.

Tracking service principal sign-ins isn’t just a best practice, it’s a necessity to secure Microsoft Entra applications. With the right visibility, you gain control over how applications interact with your environment. It also reduces the risk of silent breaches through unmanaged service principals.

2. How to restrict service principal sign-ins in Microsoft 365?

Service principals often hold elevated permissions and are a common target for attackers. If they are misused or left unmanaged they can create serious security risks. Blocking sign-ins from unused or suspicious applications reduces the attack surface. This ensures only trusted apps access the organization's resources.

Below are some effective ways to control service principal sign-ins in Microsoft 365.

Disable sign-in access for service principals in Entra ID

Log in to the Microsoft Entra admin center and navigate to Entra ID» Enterprise apps.
Click the service principal you want to restrict and go to Properties under the Manage tab.
Set Enabled for users to sign-in? to No, and click Save to disable user sign-ins to the application.

disable-sign-in-access-for-apllication-in-entra

Note: Disabling user sign-in for a service principal application only blocks delegated access. It does not block application access via client secret, certificate-based authentication (CBA), or managed identity.

Restrict service principal sign-ins using Conditional Access policy

While the previous method completely blocks service principal access, Conditional Access policy gives you more control. You can restrict sign-ins based on specific conditions like location, network, risk level, and more. This ensures legitimate access is allowed while blocking unusual or risky sign-in attempts.

Follow the steps below to create a Conditional Access policy for service principals in Microsoft 365(requires Microsoft Entra ID P1 or P2 license).

Log in to the Microsoft Entra admin center and navigate to Entra ID»Conditional Access.
Click +Create new policy and enter a name for the policy.
Under Assignments, go to Users or workload identities.
Select Workload identities under What does this policy apply to. Under Include, click Select service principals and choose the appropriate service principals from the list.
In the Target resources section, go to Include and select All resources (formerly 'All Cloud apps').
Under the Conditions section, configure specific requirements to determine when the policy should trigger.
Under Access controls, go to 'Grant', select Block access and click 'Select'.
Set Enable policy to On and click 'Create' to create a Condition Access policy for Microsoft Entra workload identities.

Note: You can also use Report-only mode to test your Conditional Access policy before enabling it.

disable-service-principal-sign-ins-using-ca-policy-1

disable-service-principal-sign-ins-using-ca-policy-2

By either disabling sign-in access or applying Conditional Access policies, administrators can control service principal sign-ins in Microsoft 365. This approach helps minimize the risk of unauthorized access, supports enforcement of security requirements, and restricts potentially malicious sign-ins.

3. How to detect risky service principals in Microsoft 365?

Service principals in Microsoft 365 operate without user involvement. Moreover, they do not support two-step verification such as Multi-Factor Authentication, which makes them easier to hack. If compromised or misused, they can pose serious security risks by allowing unauthorized access.

Without proper monitoring, they may access sensitive data and carry out harmful actions without leaving a trace. This makes early detection of risky service principals critical to protect the environment and prevent potential threats.

Identification of potentially malicious service principals in Microsoft Entra by Microsoft

Microsoft Entra applies offline risk detection mechanisms, like behavior analytics and threat intelligence to identify suspicious or compromised identities. This early warning system helps organizations respond quickly and reduce the risk of unauthorized access.

Threat intelligenceMicrosoft compares service principal activity against known attack patterns from both internal and external threat intelligence sources. If a match is found, the service principal is flagged as suspicious.
Suspicious sign-in analysisMicrosoft analyzes the usual sign-in activity for each service principal. It checks patterns such as access time, IP address, and resource use. If later sign-ins show major changes, like access from a new location or use of different credentials, the system flags them. These changes are treated as potential threats.
Admin confirmed compromiseAdministrators can verify whether a service principal is compromised using the Microsoft Entra portal or the Graph API. If confirmed, the identity is flagged as high risk and must be resolved as soon as possible.
Leaked credentials detectionMicrosoft monitors sources such as GitHub, the dark web, and public paste sites for exposed secrets or certificates. If any leaked credential matches an active service principal in the tenant, the identity is automatically flagged as risky.
Anomalous service principal activityMicrosoft monitors administrative actions performed by service principals. If any unusual changes occur in directory settings or policies, the actions are marked as anomalous.
Malicious application detectionWhen Microsoft identifies that an app violates its terms of service, the associated service principal is automatically disabled and marked as risky.
Suspicious API trafficMicrosoft watches for strange or unexpected use of the Graph API. Suspicious API calls, unauthorized attempts to explore the directory, or unknown automated access.

Track risky service principals in Microsoft Entra ID

Go to the Identity Protection page in the Microsoft Entra admin center.
Click Risky workload identities under the Report section.
Here, you can view all service principals flagged as risky based on their risk levels.

identify-risky-sign-ins-using-workload-identities

Important note: Microsoft flags a service principal as high-risk when it has high confidence that the account is compromised. Give priority to these risky workload identities and take appropriate action to contain the risk.

4. How do you handle service principal failed login attempts?

Repeated or unexpected service principal login failures in Microsoft 365 can signal potential security issues or cause critical workflows to fail. Ignoring them could lead to service disruptions or missed threat indicators. To keep your environment secure and stable, it’s important to investigate and resolve failed login attempts quickly.

Identify service principal sign-in failure reason in Microsoft Entra

In the Entra portal, navigate to Entra ID»Monitoring & health»Sign-in logs»Service principal sign-ins.
In the Add filter option, choose Status in the Filter field, select Failure in the Value field, and click Apply.
Then, click a specific record to view the reason for that sign-in failure.

handle-service-principal-failed-login-attempts

Different ways to handle failed service principals login attempts

Every error code included in the failure message indicates a distinct cause of the issue. Here are a few commonly encountered service principal sign-in errors.

Error code: 7000222 – The provided client secret keys are expired
- Generate a new client secret for the application in Microsoft Entra and update your app or script with the new key. Alternatively, consider using certificates for authenticating service principals, as they are more secure and easier to manage long-term.
- To prevent this sign-in issue, monitor applications with expiring credentials and rotate them proactively before they expire.
Error code: 53003 - Access has been blocked by Conditional Access policies
- Conditional Access policies help secure sign-ins, but they can sometimes block legitimate access unintentionally. If a sign-in fails unexpectedly, review the Conditional Access policy that caused the block and make necessary adjustments.
- To prevent similar issues in the future, use the What If tool to test CA policy. It helps verify how policies are applied and ensures that valid sign-ins won't be blocked.
Error code: 7000229 - The client application{app-id} is missing service principal in the tenant{tenant-id}
- A service principal is automatically created whenever an application is registered in Microsoft Entra. However, in certain cases, such as when the app is created using PowerShell or APIs, it may not be created automatically.
- To handle this, you can either trigger an interactive sign-in from a user in the tenant, which will automatically create the service principal, or manually create it using PowerShell or Microsoft Graph.
Error code: 500014 - InvalidResourceServicePrincipalDisabled – The application's service principal is disabled.
- Check if the application's service principal is disabled, either mistakenly by an admin or intentionally by Microsoft for a first-party app.
- If it was disabled unintentionally, re-enable it in the Microsoft Entra portal. Otherwise, no action is needed for Microsoft-managed first-party apps.
Error code: 650056 - Misconfigured application
- Each Microsoft 365 resource can only be accessed with specific permissions granted to the application’s service principal. If those permissions are missing or misconfigured, access attempts will fail with this error.
- To handle this issue, ensure the application has the correct API permissions and that the required user or admin consent has been granted. Also, check that the application identifier in the request matches the registered client application ID.
Error code: 65001 - The user or administrator has not consented to use the application
- Microsoft Entra enforces consent based on the sensitivity of permissions requested by an application. While basic permissions may allow user consent, higher-privilege scopes require admin approval.This error indicates that the application is missing the required consent to access the requested resource.
- To handle it, review the app’s permissions and consents in Microsoft Entra. Then, confirm that the required permissions have been assigned to the application and that the appropriate consent (user or admin) has been granted.
Handy Tip: The errors mentioned above are typically the most common sign-in issues in Microsoft Entra apps. For other errors, use the Error code lookup tool to find detailed explanations and recommended actions.