EI1.3 Service Principal and Managed Identity Sign-Ins

The logs nobody monitors

The Entra admin center provides four sign-in log tabs: Interactive user sign-ins, Non-interactive user sign-ins, Service principal sign-ins, and Managed identity sign-ins. In most organizations, the security team monitors the first two and ignores the last two entirely. This is a critical blind spot.

Service principals authenticate to Entra ID using client secrets (essentially passwords for applications) or certificates. They do this without any user context — there is no interactive authentication, no MFA challenge, no conditional access evaluation (unless workload identity conditional access is configured, which most organizations have not done). The sign-in appears in the AADServicePrincipalSignInLogs table and nowhere else.

Service principal sign-in log fields

The AADServicePrincipalSignInLogs table shares many fields with the user sign-in logs but has important differences:

ServicePrincipalId is the unique identifier of the service principal that authenticated. This is the primary identity field — equivalent to UserPrincipalName in the user sign-in logs.

// EI1.3 — Service principal sign-in overview
// Shows all service principal authentication in the last 24 hours
// Most organizations have never run this query
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(24h)
| summarize 
    SignInCount = count(),
    DistinctIPs = dcount(IPAddress),
    LastSignIn = max(TimeGenerated),
    Resources = make_set(ResourceDisplayName, 5)
    by ServicePrincipalName, AppId
| order by SignInCount desc
// Review: Which service principals are most active?
// Which are signing in from multiple IPs?
// Do you recognize all of them?

Detecting anomalous service principal behavior

The most important detection pattern for service principal sign-ins is: a service principal that normally signs in from a consistent IP range suddenly signs in from a new, unfamiliar IP address. This is the strongest indicator that a service principal's credentials have been compromised.

// EI1.3 — Detect service principal sign-ins from new IPs
// Compares last 24 hours against the previous 30 days baseline
let baselineWindow = 30d;
let detectionWindow = 24h;
let baselineIPs = AADServicePrincipalSignInLogs
| where TimeGenerated between (ago(baselineWindow) .. ago(detectionWindow))
| where ResultType == 0
| distinct ServicePrincipalName, IPAddress;
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(detectionWindow)
| where ResultType == 0
| join kind=leftanti baselineIPs 
    on ServicePrincipalName, IPAddress
| summarize 
    NewIPCount = dcount(IPAddress),
    NewIPs = make_set(IPAddress, 10),
    EventCount = count()
    by ServicePrincipalName, AppId
| where NewIPCount > 0
| order by EventCount desc
// Results: service principals signing in from IPs never seen in the 30-day baseline
// Investigate: is this a legitimate infrastructure change or credential compromise?

This query establishes a 30-day baseline of normal IPs for each service principal, then finds any sign-ins in the last 24 hours from IPs not in the baseline. The results require human triage — a legitimate infrastructure migration (moving a service to a new Azure region) will also produce new IPs. But combined with other signals (was the service principal's credentials recently modified? was there an unusual audit log event?), a new IP for a service principal is a strong investigation trigger.

Managed identity sign-ins

Managed identity sign-ins in AADManagedIdentitySignInLogs are generally lower risk because managed identities have no extractable credentials. An attacker cannot steal a managed identity's secret because no secret exists — Azure manages the credential internally and rotates it automatically.

However, managed identity sign-ins still warrant monitoring for two reasons. First, if the Azure resource using the managed identity is compromised (for example, an Azure VM is breached through an RDP vulnerability), the attacker inherits the managed identity's permissions. Monitoring the managed identity's sign-in patterns helps detect this scenario — a managed identity on a VM that normally accesses Azure Key Vault suddenly accessing Microsoft Graph to read user data is anomalous.

Second, managed identity sign-ins reveal the scope of your automated workloads' access. If a managed identity has been granted broader permissions than necessary (a common oversight during initial configuration), the sign-in logs show exactly which resources it is accessing — and which permissions could be reduced without affecting functionality.

// EI1.3 — Managed identity activity overview
AADManagedIdentitySignInLogs
| where TimeGenerated > ago(7d)
| summarize 
    SignInCount = count(),
    DistinctResources = dcount(ResourceDisplayName),
    Resources = make_set(ResourceDisplayName, 10)
    by ServicePrincipalName
| order by SignInCount desc
// Review: What are your managed identities accessing?
// Are any accessing resources they should not need?

The scale of the blind spot

To understand why service principal monitoring matters, consider the numbers. In a typical enterprise M365 tenant with 1,000 users, there may be 200-500 application registrations and corresponding service principals. Some were created years ago for projects that have ended. Some have credentials that have not been rotated. Some have permissions that were granted during initial setup and never reduced. Some have owners who have left the organization.

Each one of these service principals is a potential entry point. An attacker who obtains a client secret for a service principal with Mail.ReadWrite application permissions can read every user's email in the tenant — without generating a single entry in the user sign-in logs. The access appears only in AADServicePrincipalSignInLogs, which nobody is monitoring.