Zero Trust identity recommendations
On this page
Microsoft Zero Trust identity recommendations (Conditional Access relevant)
Source: Security guidance — Protect identities and secrets
· doc date 2025-09-11, updated 2026-06-15 · retrieved 2026-07-28
This is the Microsoft Entra Zero Trust assessment recommendation set. It is broader than
benchmark guidance and is where Microsoft states the attack narrative behind each control — which
is what makes a recommendation persuasive to a customer rather than merely correct.
Conditional Access policies Microsoft recommends
| Recommendation | Notes |
|---|---|
| Block legacy authentication policy is configured | Legacy protocols don't support MFA. Attackers who get in via legacy auth can set mail-forwarding rules in Exchange for continued access, re-enter without triggering alerts, and blend in with legitimate activity |
| Secure the MFA registration (My Security Info) page | Unprotected registration lets attackers register their own methods via AiTM or from unmanaged devices, hijacking the victim's authentication profile permanently |
| Privileged built-in roles targeted with CA to enforce phishing-resistant methods | Deploy a CA policy targeting privileged accounts requiring phishing-resistant credentials |
| Require MFA for device join and device registration (user action) | Without it, attackers register rogue devices, establish persistence and circumvent controls tied to trusted endpoints |
| All sign-in activity comes from managed devices | Require compliant or hybrid joined devices |
| All user sign-in activity uses phishing-resistant authentication methods | The end state — beyond admin-only phishing resistance |
| User sign-in activity uses token protection / token protection policies are configured | Binds tokens to the issuing device; stolen tokens become unusable elsewhere |
| Restrict device code flow | "Given the security risks and the infrequent legitimate use of device code flow, you should enable a Conditional Access policy to block this flow by default" |
| Authentication transfer is blocked | Prevents device tokens silently authenticating on other devices or browsers, bypassing device compliance |
| CA policies enforce strong authentication for private apps | Microsoft Entra Private Access applications. Phishing-resistant preferred; MFA is the minimum acceptable baseline |
| Directory sync account is locked down to a specific named location | Restrict the highly-privileged sync account to trusted networks via CA |
| Application Proxy applications require preauthentication | With passthrough, CA can't be enforced at all — no MFA, no risk evaluation, no location restriction |
Two of these are commonly missed entirely
Directory sync account locked to a named location. A compromised sync account lets an
attacker manipulate synchronisation, create unauthorised accounts, escalate privileges of
existing accounts and persist by modifying sync rules — from anywhere. Restricting it to a
trusted named location is a legitimate, well-targeted use of location conditions, and it is
one of the few places where location-based control is the right primary answer.
Application Proxy preauthentication. If preauthentication is set to Passthrough,
Conditional Access cannot be enforced at all on that app — all authentication
responsibility falls to the internal application. An organisation can believe an app is
CA-protected when it is entirely exposed. Change Pre-Authentication from Passthrough to
Microsoft Entra ID.
Authentication method recommendations
| Recommendation | Detail |
|---|---|
| Passkey authentication method enabled | Phishing-resistant cryptographic proof; eliminates the credential-based attack chain |
| Security key authentication method enabled | Hardware-backed FIDO2 |
| Security key attestation is enforced | — |
| Privileged accounts have phishing-resistant methods registered | Registration must precede enforcement |
| SMS and Voice Call authentication methods are disabled | Matches benchmark guidance |
| Temporary Access Pass is enabled | Closes the bootstrapping gap: users who can't yet register FIDO2/WHfB otherwise fall back to username + password at their most vulnerable moment |
| Restrict Temporary Access Pass to single use | A multi-use TAP that leaks becomes a reusable backdoor letting an attacker register their own strong methods |
| Users have strong authentication methods configured | — |
| All users are required to register for MFA | "Your account is more than 99% less likely to be compromised if you're using MFA" |
| Reduce the user-visible password surface area | Every password prompt is an interception opportunity |
| Microsoft Authenticator shows sign-in context | Application name + geographic location in notifications |
| Microsoft Authenticator "report suspicious activity" enabled | Generates a high-fidelity userReportedSuspiciousActivity user risk detection, immediately elevating the user to high risk — which risk-based CA policies can then act on |
| Migrate from legacy MFA and SSPR policies | Legacy MFA and SSPR policies were retired 30 September 2025; migrate to the unified Authentication Methods policy |
| Block administrators from using SSPR | A compromised admin can otherwise reset the password to lock out legitimate admins |
| SSPR doesn't use security questions | — |
| Smart lockout threshold ≤ 10, duration ≥ 60 seconds | Matches benchmark guidance–9 |
The TAP → report-suspicious-activity → user risk chain is worth the agent knowing:
enabling report-suspicious-activity turns a user's "that wasn't me" tap into a signal that
a user-risk CA policy can act on automatically. That is a concrete reason to deploy the
user-risk policy, not just a compliance checkbox.
Privileged access recommendations
| Recommendation | Detail |
|---|---|
| Privileged accounts are cloud native identities | Matches benchmark guidance |
| All privileged role assignments are activated just in time, not permanently active | Matches benchmark guidance |
| All privileged role assignments are managed with PIM | — |
| High Global Administrator to privileged user ratio | Flags too many GAs relative to the privileged population |
| Administrative privileges are tightly limited | — |
| Privileged roles aren't assigned to stale identities | Stale privileged accounts can be compromised without triggering behavioural analytics, because there is no baseline of normal activity to deviate from |
| Require password reset notifications for administrator roles | Notify admins when another admin resets their password — detects credential compromise and insider threats |
| Application admin rights constrained to specific Private Access apps | — |
Stale privileged identities is a good finding for the agent to surface: it is invisible
to most reviews precisely because nothing is happening on the account.
Application and workload identity recommendations
- Applications don't have client secrets configured
- Service principals don't have certificates or credentials associated with them
- Application certificates don't exceed 180 days, and are rotated regularly
- Enforce standards for app secrets and certificates
- Microsoft services applications don't have credentials configured
- User consent settings are restricted; admin consent workflow is enabled
- Entra Connect Sync configured with service principal credentials rather than a legacy
user account — connector-account compromise lets attackers manipulate sync, create
backdoor accounts and escalate privileges
Hybrid and legacy
- Use cloud authentication — an on-premises federation server is a central attack
surface; a compromised AD FS lets an attacker forge tokens to impersonate any user and
pivot into the cloud. Migrate to password hash synchronisation.
- Turn off Seamless SSO if unused.
- No usage of ADAL — support ended 30 June 2023. ADAL bypasses Conditional Access
enforcement, Continuous Access Evaluation and advanced token protection, and often calls
deprecated Azure AD Graph endpoints.
- Block the legacy Azure AD PowerShell module.
- Local Administrator Password Solution deployed (matches benchmark guidance).
- Password expiration is disabled (matches benchmark guidance).
- Add organisational terms to the banned password list (matches benchmark guidance).
- Enable security defaults for free tenants — the fallback where P1 is absent.
ADAL is a strong troubleshooting lead: if an application appears not to be governed by
Conditional Access, or CAE and token protection do not seem to apply, ADAL usage is a prime
suspect.
How the agent should use this file
The benchmark guidance catalogue tells the agent what to recommend. This file tells it **why the
control exists and what the attacker does without it** — which is what turns a
recommendation into something a customer will actually fund and schedule.
When justifying a control, prefer the attack narrative here over restating the
configuration. "Without this, an attacker who phishes one credential can register their own
MFA method and own the account permanently" lands better than "benchmark guidance requires a
managed device for security info registration."