Service Principal and Managed Identity Sign-Ins

The authentication layer nobody watches

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 creates an exploitable blind spot that sophisticated attackers know exists.

Service principals authenticate to Entra ID using client secrets (strings that function as passwords) or certificates. They authenticate without any user context — no interactive prompt, no MFA challenge, no Conditional Access evaluation unless Workload Identities Premium licensing is in place with explicit workload identity policies. The authentication flows through the OAuth 2.0 client credential grant, producing a sign-in event in the AADServicePrincipalSignInLogs table and nowhere else. If your security operations center monitors only SigninLogs and AADNonInteractiveUserSignInLogs, every service principal authentication is invisible to your detection rules.

The scale of this blind spot is significant. A typical M365 tenant with 1,000 users has 200-500 application registrations and corresponding service principals. Many were created years ago for projects that ended. Many have credentials that have never been rotated. Many have permissions granted during initial setup and never reduced. Many have owners who left the organization. Each one authenticates independently, and each one is a potential entry point that bypasses every user-focused security control you've deployed.

Consider the permission asymmetry. A compromised user account gives an attacker access to that user's mailbox, files, and team memberships — a significant but bounded blast radius. A compromised service principal with Mail.ReadWrite application permissions gives the attacker access to every user's mailbox in the tenant. A service principal with Directory.ReadWrite.All gives the attacker the ability to create users, assign roles, modify groups, and grant additional application permissions. The access scope of a single service principal often exceeds that of a Global Administrator — and unlike the Global Administrator, the service principal authenticates silently with no MFA challenge, no risk evaluation, and no anomalous sign-in alert.

The Midnight Blizzard breach (Section 0.7) operated through exactly this gap. The attackers added credentials to a dormant OAuth application, authenticated as that application, and accessed senior leadership mailboxes for over two months. The sign-in evidence existed in AADServicePrincipalSignInLogs the entire time. Nobody was querying the table.

Reading the service principal sign-in record

The AADServicePrincipalSignInLogs table shares some field names with the user sign-in tables but the record structure reflects a different authentication model. There is no user, no device, no MFA challenge. The identity is the application, the credential is a secret or certificate, and the access target is a resource API.

{
  "ServicePrincipalName": "Contoso-HR-Sync",
  "ServicePrincipalId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "AppId": "12345678-abcd-ef01-2345-6789abcdef01",
  "ResourceDisplayName": "Microsoft Graph",
  "ResourceIdentity": "00000003-0000-0000-c000-000000000000",
  "IPAddress": "20.42.65.100",
  "Location": {
    "city": "San Jose",
    "countryOrRegion": "US"
  },
  "ServicePrincipalCredentialKeyId": "f8e7d6c5-b4a3-2190-8765-432109876543",
  "ServicePrincipalCredentialThumbprint": "",
  "ResultType": "0",
  "ConditionalAccessStatus": "notApplied",
  "TimeGenerated": "2025-11-14T14:22:08Z"
}

Every field in this record answers a security question. ServicePrincipalName identifies which application authenticated — is this one you recognize? AppId is the immutable identifier you use to look up the application registration in the Entra admin center. ResourceDisplayName tells you what the application accessed — Microsoft Graph means directory and mail operations, Office 365 Exchange Online means mailbox access, Azure Key Vault means secret retrieval. IPAddress reveals where the authentication originated — for legitimate Azure-hosted applications, this is an Azure datacenter IP that should be consistent. For an attacker using a stolen secret, this IP won't match the application's normal pattern.

ServicePrincipalCredentialKeyId is the critical investigation field. This identifies which specific credential was used — the exact client secret ID or certificate thumbprint. A service principal can have multiple credentials (most have at least two for rotation purposes). If the sign-in used a credential you don't recognize, an attacker may have added their own secret to the service principal. This is exactly how Midnight Blizzard established persistence — they added new credentials to a dormant OAuth application, then authenticated with those credentials. The audit log event "Add service principal credentials" records this action, and Section 1.9 teaches the correlation pattern that connects the credential addition to the subsequent sign-in.

ConditionalAccessStatus shows notApplied in most tenants because Conditional Access for workload identities requires Workload Identities Premium licensing and explicit policy configuration. Without it, service principal authentication bypasses your entire Conditional Access framework. Every policy you built in EI3 and EI4 for user sign-ins — phishing-resistant MFA, compliant device, trusted location — does not evaluate on service principal authentication. EI10 covers deploying Conditional Access for workload identities.

Discovering what's in your tenant

Before you can monitor service principal authentication, you need to know what's authenticating. Most practitioners are surprised by the volume.

// Service principal activity overview — 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 sign in from multiple IPs? Do you recognize all of them?

Run this in your developer tenant. Even a new tenant has active service principals — Microsoft's internal services create them automatically. The security-relevant question for each result: do you recognize this application, is the IP consistent with where you'd expect it to run, and are the resources it accesses appropriate for its function? Any service principal you can't identify requires investigation — look up the AppId in the Enterprise Applications blade.

For each unrecognized service principal, check three things. First, is it a Microsoft first-party service? Microsoft creates dozens of service principals in every tenant for internal operations — names like "Office 365 Exchange Online," "Microsoft Graph," and "Windows Azure Active Directory" are normal. Second, does it have an owner assigned? A service principal without an assigned owner is a governance gap — nobody is accountable for its credentials or permissions. Third, when was it created and when do its credentials expire? A service principal created three years ago with credentials expiring in six months has been operating with the same secret for 18 months — that's 18 months of exposure if the secret was ever leaked.

The second query establishes a detection baseline. A service principal that normally authenticates from one or two Azure datacenter IPs and suddenly authenticates from a residential IP in another country is the strongest signal of credential compromise available in the non-human identity space.

// Detect service principal sign-ins from new IPs
// Compares last 24 hours against 30-day 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: SPs authenticating from IPs never seen in 30-day baseline
// Triage: infrastructure change, or credential compromise?

This query uses leftanti join to find service principal sign-ins from IPs that don't appear in the 30-day historical baseline. Results require human triage — a legitimate infrastructure migration (moving an Azure Function to a new region) also produces new IPs. But combined with other signals — was the credential recently modified? was there an unusual AuditLogs event? — a new IP for a stable service principal is a strong investigation trigger. EI13 builds this into an automated detection rule.

Managed identity sign-ins

Managed identities authenticate using Azure-managed credentials that are automatically rotated and never exposed to administrators. Their sign-ins appear in the AADManagedIdentitySignInLogs table. Because no extractable credential exists, an attacker cannot steal a managed identity secret — the credential lives inside Azure's infrastructure and isn't accessible through any API or portal.

There are two types. System-assigned managed identities are tied to a single Azure resource — when the resource is deleted, the identity is deleted. User-assigned managed identities can be shared across multiple resources, which is convenient for scenarios where several Azure Functions need the same permissions, but creates a larger blast radius if one of those resources is compromised. The sign-in log doesn't distinguish between the two types directly, but you can determine the type by looking up the ServicePrincipalId in the Enterprise Applications blade.

This makes managed identities fundamentally lower risk than service principals, but they still need monitoring for two reasons. First, if the Azure resource using the managed identity is compromised — a VM breached through an unpatched vulnerability, an App Service exploited through a code injection — the attacker inherits every permission the managed identity has. A managed identity on a VM that normally accesses Azure Key Vault but suddenly starts calling Microsoft Graph to enumerate users is the signal. Second, managed identity sign-ins reveal permission sprawl — if a managed identity has broader permissions than its workload requires, the sign-in log shows exactly which resources it actually accesses, making right-sizing straightforward.

The managed identity table has a simpler schema than the service principal table. There is no ServicePrincipalCredentialKeyId because managed identities don't have discrete credentials. The key fields are ServicePrincipalName (the managed identity name), ResourceDisplayName (what it accessed), IPAddress (the Azure infrastructure IP), and ResultType (success or failure). Monitoring focuses on resource access patterns — what is each managed identity accessing, and has that pattern changed? A managed identity that accesses the same three resources every day for six months and then suddenly accesses Microsoft Graph for the first time warrants investigation, regardless of whether the sign-in succeeded.

Credential lifecycle and the security implications

Service principal credentials have a lifecycle that creates security risk at every stage. A client secret is created with an expiration date — but many organizations set expiration to 24 months or configure certificates with multi-year validity. During that window, the secret provides persistent access with no re-authentication requirement. There is no session timeout forcing re-authentication, no idle timeout revoking access, and no MFA prompt interrupting automated workflows. The secret works until it expires or is explicitly deleted.

Failed authentication attempts from service principals are an underused detection signal. The ResultType field encodes the failure reason — 7000215 means "invalid client secret provided" (someone tried the wrong secret), 7000222 means "the provided client secret keys are expired" (the secret's expiration date passed), 700027 means "client assertion failed signature validation" (a certificate problem). A burst of 7000215 failures against a specific service principal may indicate an attacker testing stolen credentials that don't quite match — perhaps a secret from a previous rotation cycle.

The ServicePrincipalCredentialKeyId field tracks which credential authenticated. A service principal with two credentials — a primary and a rotation backup — produces sign-ins with two different key IDs, both expected. A service principal with three credentials, where you only created two, means someone added a credential you didn't authorize. The audit log records this as "Add service principal credentials" with the acting identity and the new credential's key ID. The correlation between AuditLogs (credential added) and AADServicePrincipalSignInLogs (credential used for the first time) is the detection pattern for persistence through application credential injection — the exact technique Section 0.5 described at Stage 3 of the kill chain.

Certificate-based authentication for service principals provides stronger security than client secrets because certificates use asymmetric cryptography — the private key never leaves the certificate holder. But certificates introduce their own lifecycle challenges: expiration tracking, certificate authority trust, and revocation management. Whether you use secrets or certificates, the sign-in log records the credential identifier, enabling you to track exactly which credential authenticated and when.

Workload identity federation eliminates extractable credentials entirely for supported scenarios. Instead of a client secret, the service principal trusts tokens from an external identity provider — GitHub Actions, Azure DevOps, or another cloud provider. The trust relationship replaces the credential with a federated assertion that cannot be replayed from a different context. The sign-in log still records the authentication, but the ServicePrincipalCredentialKeyId references the federated credential configuration instead of a secret or certificate.

EI10 teaches the long-term solution: migrating service principals from secrets and certificates to managed identities and workload identity federation wherever the architecture supports it. Until that migration is complete, the sign-in log is your primary detection mechanism for service principal credential compromise.