PA-08: Risky Service Principal Detection

Overview

This guide walks you through detecting, investigating, and responding to risky service principals (workload identities) in your tenant using Microsoft Entra ID Protection. Service principals authenticate machine-to-machine, without a human and without MFA, and they often carry broad permissions. A compromised one is a persistent, automated foothold. This control ensures risky workload identities are monitored and that no medium or high-risk service principal stays active.

Control ID: PA-08 Category: Privileged Access Baseline Level: Level 2 (Enhanced Security) Severity: Critical License Required: Microsoft Entra ID P1, plus the Microsoft Entra Workload ID Premium add-on (required for workload identity risk detection)

Why This Matters

Compromised service principals provide persistent, automated access to your tenant. Unlike user accounts, service principals operate without MFA and can perform actions at scale. Detecting risky service principals is critical for preventing supply chain attacks.

Attackers increasingly target application credentials rather than user passwords, because a service principal secret rarely rotates, has no MFA, and often goes unwatched. ID Protection risk detections for workload identities surface anomalies such as leaked credentials, sign-ins from unfamiliar infrastructure, or admin-confirmed compromise, so you can act before the identity is abused at scale.

Expected State

• Identity Protection monitors service principal risk
• No medium or high-risk service principals are active
• Compromised service principals are investigated and disabled promptly

Prerequisites

Before You Start

1. Confirm the Workload ID Premium add-on is provisioned in the tenant. Without it, the risky workload identities report and workload risk-based Conditional Access are unavailable.
2. Have an owner map for your critical service principals so you can tell a real compromise from expected behavior.

Time Estimate

TrueConfig Remediation

This control is auto-remediable. TrueConfig can disable a service principal that ID Protection has flagged as compromised, cutting off automated access immediately. Because disabling a workload identity can break a running integration, the remediation is scoped to confirmed-risky principals and shows you which identity will be disabled before it acts. Workload identity risk features require the Microsoft Entra Workload ID Premium add-on.

Step-by-Step Instructions

Step 1: Open the Risky Workload Identities Report

1. Sign in to the Microsoft Entra admin center.
2. Go to Protection > Identity Protection.
3. Select Risky workload identities.
4. Review the list. Each entry shows the service principal, its risk level (low, medium, high), risk state, and the detections that raised the risk.

Step 2: Investigate a Flagged Service Principal

For each medium or high-risk identity:

1. Select the service principal to open its detail.
2. Review the risk detections. Common workload risk detections include:
   • Leaked credentials (a client secret or certificate found in a public location)
   • Anomalous service principal activity or sign-in from unfamiliar infrastructure
   • Admin-confirmed service principal compromised
   • Suspicious sign-ins to the workload identity
3. Identify the application and its owner. Check:
   • What API permissions and app roles it holds (broad permissions raise the stakes)
   • Where it legitimately runs from
   • Whether the activity matches a known deployment, or looks like abuse

Step 3: Respond to a Confirmed-Risky Identity

If the identity is compromised or the risk is real:

1. Disable the service principal to stop it immediately:
   • Go to Identity > Applications > Enterprise applications.
   • Open the application, go to Properties, and set Enabled for users to sign in to No, then Save. This blocks the service principal from authenticating.
2. Rotate or remove its credentials:
   • Go to App registrations > the app > Certificates & secrets.
   • Remove the compromised secret or certificate and issue a fresh one only after the app is verified clean.
3. Review what it touched using sign-in and audit logs (see LOG-06 and the unified audit log) to scope the incident.
4. Once remediated and rotated, you can re-enable the service principal and, in ID Protection, confirm compromised or dismiss the risk to update its state.

Step 4: Set Up Ongoing Detection and Alerting

1. In Identity Protection, you can create a workload identity risk policy to automatically block or restrict sign-in for high-risk workload identities. Start in report-only to gauge impact. (See CA-12 for the Conditional Access side of workload identity control.)
2. Forward ID Protection risk events to your SIEM (via the Entra diagnostic settings or Microsoft Graph) so risky workload identities generate an alert to your security team.
3. Pair this with regular credential hygiene: expire and rotate app secrets (see APP-02 and APP-05), and prefer workload identity federation over long-lived secrets where possible (see APP-10).

Verification Checklist

• Workload ID Premium is provisioned and the risky workload identities report is visible
• The report has been reviewed and every medium/high-risk identity triaged
• No confirmed-compromised service principal remains enabled
• Compromised credentials have been removed or rotated
• Broad or unused permissions on flagged apps have been reduced
• Risk events flow to your SIEM or generate an alert
• A workload identity risk policy is in place (report-only or enforced)

Troubleshooting

"Risky workload identities is empty or unavailable"

This feature requires the Microsoft Entra Workload ID Premium add-on. Confirm it is licensed and assigned. An empty report can also simply mean no risk has been detected yet.

"Disabling the service principal broke a production integration"

Disabling stops all authentication for that identity. Before disabling a business-critical workload, confirm the compromise and coordinate with the app owner. If the identity is legitimate but flagged, investigate the detection and dismiss the risk rather than disabling.

"A leaked-credentials detection appeared for an app we control"

Treat it as real. Remove the leaked secret or certificate immediately, issue a new one, and audit where the credential was exposed (source control, logs, config files). Then confirm or dismiss the risk in ID Protection.

"We keep getting risk detections from our CI/CD service principal"

CI/CD identities that sign in from cloud-hosted, changing IP ranges can look anomalous. Reduce this by moving CI/CD to workload identity federation (no stored secret) and scoping the identity to least privilege. See APP-10.

"How do I tell risk state from risk level"

Risk level is how risky the identity currently looks (low/medium/high). Risk state is the lifecycle status (at risk, confirmed compromised, dismissed, remediated). Investigate by level, then set the state as you resolve each case.

Cost Considerations

Note: If you cannot license Workload ID Premium tenant-wide, prioritize covering the service principals with the broadest Graph permissions and directory roles, since those are the highest-impact if compromised.

Related Controls

• CA-12: Conditional Access for Workload Identities - Apply location and risk-based controls to service principal sign-ins
• APP-05: Service Principal Credential Hygiene - Keep workload credentials clean and rotated
• APP-10: Workload Identity Federation Adoption - Eliminate long-lived secrets entirely
• LOG-06: Sign-In Log Anomaly Baseline - Establish normal activity to spot workload anomalies

Additional Resources

• Microsoft Learn: Securing workload identities with Identity Protection
• Microsoft Learn: Investigate and remediate risky workload identities
• Microsoft Learn: Microsoft Entra Workload ID