Modern Authentication, Conditional Access and External Identities

What it is

Modern authentication evaluates every request using many signals, not just a password. In Microsoft Entra ID, this is built from Conditional Access, continuous access evaluation, risk based policies and protected actions. This topic also covers external identities (partners, customers and verified credentials) and how to validate that Conditional Access really implements Zero Trust.

How it works

Conditional Access

A Conditional Access policy is an if then statement: if these assignments match, then apply these access controls.

Authentication strengths define which MFA methods are acceptable: MFA, passwordless MFA or phishing resistant MFA (FIDO2 security keys, Windows Hello for Business, certificate based authentication, passkeys). Require phishing resistant strength for administrators and sensitive apps.

A baseline of Zero Trust aligned policies:

Always exclude emergency access (break glass) accounts from the policies, protect them separately and monitor their use, and use report only mode before enforcing a new policy.

Risk scoring with Microsoft Entra ID Protection

ID Protection calculates user risk (the account is probably compromised) and sign in risk (this sign in is probably not the real user), each as low, medium or high, using signals such as leaked credentials, impossible travel, anonymous IP addresses and unfamiliar sign in properties. Use risk as a condition in Conditional Access: require MFA for medium sign in risk, and require a secure password change for high user risk. Risk detections can also flow to Defender XDR and Sentinel.

Continuous access evaluation (CAE)

Normally an access token stays valid until it expires, even if the situation changes. CAE lets supporting services, such as Exchange Online, SharePoint Online, Teams and Microsoft Graph, react in near real time to critical events: the user is disabled or deleted, the password changes or sessions are revoked, MFA is enabled for the user, the user is flagged as high risk, or the user moves to a location that violates a policy. The service rejects the token and the client must reauthenticate. CAE aware clients get longer lived tokens (up to 28 hours) because revocation is fast, so security improves without frequent prompts. Strict enforcement blocks access when the location rule cannot be evaluated. Token protection and CAE complement each other.

Protected actions

Protected actions are sensitive operations in Microsoft Entra, such as deleting or changing Conditional Access policies or creating or changing cross tenant access settings, that you protect with a Conditional Access authentication context. When an admin attempts one, Entra requires the extra control you set, for example phishing resistant MFA with a compliant device, even though they already hold the role. This guards against a stolen admin session making dangerous changes.

Validate alignment with Zero Trust

Common gaps are excluded groups that grow, legacy authentication still allowed, workload identities not covered, and apps not covered because a policy targets only some apps.

External identities

Verified ID supports identity proofing during onboarding and account recovery, so that a help desk can confirm a person with a verifiable credential instead of guessable questions.

A worked scenario

An architect reviews a Conditional Access setup and finds legacy authentication allowed for one group and admins protected only by regular MFA. They add a block legacy authentication policy, require phishing resistant strength for admins, add risk based policies, and place Conditional Access policy changes under protected actions. They enable CAE strict enforcement for Exchange and SharePoint, and use report only mode and the What If tool before enforcement.