# Restrict access to high risk users
Assume high risk users are compromised by threat actors. Without investigation and remediation, threat actors can execute scripts, deploy malicious…
Source: https://maester.dev/docs/tests/ZTA.21797
:::note[Maester checks this too]
[MT.1013](/docs/tests/MT.1013) (At least one Conditional Access policy is configured to require new password when user risk is high.), [CIS.M365.5.2.2.6](/docs/tests/CIS.M365.5.2.2.6) (Enable Identity Protection user risk policies) check the same setting. Running both reports it twice.
:::
## Overview
Assume high risk users are compromised by threat actors. Without investigation and remediation, threat actors can execute scripts, deploy malicious applications, or manipulate API calls to establish persistence, based on the potentially compromised user's permissions. Threat actors can then exploit misconfigurations or abuse OAuth tokens to move laterally across workloads like documents, SaaS applications, or Azure resources. Threat actors can gain access to sensitive files, customer records, or proprietary code and exfiltrate it to external repositories while maintaining stealth through legitimate cloud services. Finally, threat actors might disrupt operations by modifying configurations, encrypting data for ransom, or using the stolen information for further attacks, resulting in financial, reputational, and regulatory consequences.
Organizations using passwords can rely on password reset to automatically remediate risky users.
Organizations using passwordless credentials already mitigate most risk events that accrue to user risk levels, thus the volume of risky users should be considerably lower. Risky users in an organization that uses passwordless credentials must be blocked from access until the user risk is investigated and remediated.
## Remediation
- [Deploy a Conditional Access policy to require a secure password change for elevated user risk](https://learn.microsoft.com/entra/identity/conditional-access/policy-risk-based-user?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci).
- Use Microsoft Entra ID Protection to [investigate risk further](https://learn.microsoft.com/entra/id-protection/howto-identity-protection-investigate-risk?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 | Medium |
| Impact on users | High |
| Pillar | Identity |
| Category | Access control |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Conditional Access |
| Area | Authentication |
| ATT&CK | [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts |
| 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`.