# All risky workload identity sign ins are triaged
Threat actors increasingly target workload identities (applications, service principals, and managed identities) because they lack human factors and often…
Source: https://maester.dev/docs/tests/ZTA.22659
## Overview
Threat actors increasingly target workload identities (applications, service principals, and managed identities) because they lack human factors and often use long-lived credentials. A compromise often looks like the following path:
1. Credential abuse or key theft.
1. Non-interactive sign-ins to cloud resources.
1. Lateral movement via app permissions.
1. Persistence through new secrets or role assignments.
Microsoft Entra ID Protection continuously generates risky workload identity detections and flags sign-in events with risk state and detail. Risky workload identity sign-ins that aren’t triaged (confirmed compromised, dismissed, or marked safe), detection fatigue, and a large alert backlog can be challenging for IT admins to manage. This heavy workload can let repeated malicious access, privilege escalation, and token replay to continue to go unnoticed. To make the workload manageable, address risky workload identity sign-ins in two parts:
- Close the loop: Triage sign-ins and record an authoritative decision on each risky event.
- Drive containment: Disable the service principal, rotate credentials, or revoke sessions.
## Remediation
- [Investigate risky workload identities and perform appropriate remediation ](https://learn.microsoft.com/entra/id-protection/concept-workload-identity-risk?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
- [Dismiss workload identity risks when determined to be false positives](https://learn.microsoft.com/graph/api/riskyserviceprincipal-dismiss?view=graph-rest-1.0&preserve-view=true&wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
- [Confirm compromised workload identities when risks are validated](https://learn.microsoft.com/graph/api/riskyserviceprincipal-confirmcompromised?view=graph-rest-1.0&preserve-view=true&wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
## Run it
The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```
Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.
About this check
| | |
| --- | --- |
| Severity | High |
| Effort to fix | High |
| Impact on users | Low |
| Pillar | Identity |
| Category | Access control |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Identity Protection |
| Area | Applications and workload identities |
| ATT&CK | [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts, [T1098.001](/docs/tests?mitre=T1098.001) Additional Cloud Credentials |
| Licence | P2 |
| Tenant | Workforce, External |
Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.