# Conditional Access policies enforce strong authentication for private apps

When Conditional Access policies don't protect Private Access applications by requiring strong authentication, threat actors can use phishing attacks…

Source: https://maester.dev/docs/tests/ZTA.25396

<!-- This file is generated by website/scripts/generate-test-docs.mjs. Do not edit manually. -->

## Overview

When Conditional Access policies don't protect Private Access applications by requiring strong authentication, threat actors can use phishing attacks, credential stuffing, or password spraying to get user credentials and sign in to private applications with just a compromised password.

Without strong authentication:

- Threat actors gain initial access to internal resources that should be protected by stronger controls.
- If multifactor authentication is missing or phishable methods like SMS or voice are used, adversary-in-the-middle attacks can happen where threat actors intercept authentication tokens and session cookies.
- Threat actors can move laterally from the initially compromised private application to other internal resources.

Microsoft recommends enforcing phishing-resistant authentication methods such as FIDO2 security keys, Windows Hello for Business, or certificate-based authentication for access to private applications, with multifactor authentication as the minimum acceptable baseline.

## Remediation

- [Configure Conditional Access policies to require phishing-resistant authentication](https://learn.microsoft.com/entra/identity/conditional-access/policy-all-users-mfa-strength?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.

<details>
<summary>About this check</summary>

| | |
| --- | --- |
| Severity | High |
| Effort to fix | Medium |
| Impact on users | Medium |
| Pillar | Network |
| Category | Global Secure Access |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Conditional Access |
| Area | Authentication |
| ATT&CK | [T1110.003](/docs/tests?mitre=T1110.003) Password Spraying, [T1110.004](/docs/tests?mitre=T1110.004) Credential Stuffing, [T1557](/docs/tests?mitre=T1557) Adversary-in-the-Middle |
| Licence | Entra_Premium_Private_Access, AAD_PREMIUM |
| Tenant | Workforce |

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`.

</details>

<p class="mt-ms-note not-content"><svg class="mt-ms-note__logo" viewBox="0 0 21 21" aria-hidden="true"><rect width="10" height="10" fill="#f25022"/><rect x="11" width="10" height="10" fill="#7fba00"/><rect y="11" width="10" height="10" fill="#00a4ef"/><rect x="11" y="11" width="10" height="10" fill="#ffb900"/></svg><span>A Microsoft check, part of the <a href="/docs/tests/packs/zero-trust-assessment">Zero Trust Assessment</a> pack. Text from ZeroTrustAssessment 3.1.0, © Microsoft, <a href="/docs/tests/packs/zero-trust-assessment#licence">MIT licence</a>.</span></p>
