1.5 Entra ID Protection

60–90 minutes · Module 1 · Free

Entra ID Protection is arguably the most important component in this entire ecosystem. Identity is the foundation of every investigation scenario in this course. AiTM phishing (Module 13) — you detect it in sign-in logs. BEC (Module 14) — you trace account compromise in sign-in logs. Token replay (Module 16) — you find it in non-interactive sign-in logs. Conditional access is the control that prevents most of these attacks from succeeding in the first place.

This is the most important subsection in the module

Every investigation scenario in this course starts or passes through Entra ID sign-in logs. Conditional access is the control that prevents most attacks from succeeding. If you only read one subsection in depth, make it this one.

Understanding Entra ID Protection is not one subsection among nine — it is the foundation that everything else builds on. Module 4 goes deep on sign-in log investigation. This subsection maps the architecture.

Risk Engine. Continuously evaluates every sign-in and every user for risk indicators. Two types of risk. Sign-in risk: is this specific authentication event suspicious? Detection types include unfamiliar location, anonymous IP, impossible travel, token issuer anomaly, password spray, and AiTM-detected phishing. User risk: has this user’s account been compromised? Detection types include leaked credentials found in dark web dumps, anomalous user activity, and threat intelligence indicators. Risk levels are low, medium, and high.

Conditional Access. The policy engine that evaluates every authentication request against defined conditions — who is signing in, from where, on what device, to which application, at what risk level — and enforces access decisions: allow, block, require MFA, require a compliant device, require a password change, limit the session. This is the primary preventive security control in the M365 ecosystem. Correctly configured conditional access stops most attack chains before any investigation is needed.

Authentication Methods. MFA configuration, passwordless authentication (FIDO2 keys, Windows Hello for Business, Microsoft Authenticator), and authentication strengths. Controls how users prove their identity and how strongly that proof is trusted.

Identity Governance. Access reviews, entitlement management, and Privileged Identity Management (PIM). Controls who has access to what and ensures that access remains appropriate over time.

Sign-In Logs. Every authentication event recorded with: user, application, IP address, location, device, client app, conditional access result, risk level, MFA result, and authentication method. This is the single most queried data source in security investigations.

Audit Logs. Every administrative change in the directory: user creation and deletion, group membership changes, role assignments, policy modifications, application registrations.

Key data tables

SigninLogs — interactive user sign-ins. AADNonInteractiveUserSignInLogs — app-based and token-based sign-ins (critical for token replay detection). AADServicePrincipalSignInLogs — application and service principal authentication. AADManagedIdentitySignInLogs — managed identity authentication. AuditLogs — directory changes.

How it connects

Sign-in risk signals are consumed by conditional access in real time. User risk signals trigger automated remediation (forced password change, MFA re-registration). Risk detections generate alerts in the Defender XDR incident queue. Sign-in and audit logs are ingestible into Sentinel for custom detections and long-term retention. Conditional access integrates with Defender for Cloud Apps (session control) and Intune (device compliance).

Key takeaways

Identity is the foundation — every investigation starts with sign-in logs
Two risk types: sign-in risk (is this authentication suspicious?) and user risk (is this account compromised?)
Conditional access is the primary preventive control in the M365 ecosystem
SigninLogs and AADNonInteractiveUserSignInLogs are the most queried tables in security investigations
Module 4 teaches sign-in log investigation in depth — this subsection maps the architecture

Licensing

Entra ID P1 includes conditional access, basic sign-in logs, and MFA (included in M365 E3 and Business Premium). Entra ID P2 adds risk-based conditional access, risk detections, the identity protection dashboard, PIM, and access reviews (included in M365 E5 or available as an add-on).

Investigation decision: High-risk sign-in detected

Entra ID Protection flags a high-risk sign-in for a finance department user. The sign-in originated from an IP in a country where your organisation has no operations. MFA was satisfied. The user claims they did not sign in.

Step 1: The user says they did not sign in, but MFA was satisfied. What is the most likely explanation?

Check your understanding

1. What is the difference between sign-in risk and user risk?

Sign-in risk evaluates the user account; user risk evaluates the authentication event

Sign-in risk evaluates a specific authentication event; user risk evaluates whether the account itself is compromised

They are the same thing measured at different times

Sign-in risk asks: "Is this specific authentication suspicious?" (anomalous location, anonymous IP). User risk asks: "Has this account been compromised?" (leaked credentials, anomalous activity patterns). Both feed into conditional access for risk-based enforcement.

2. Why is AADNonInteractiveUserSignInLogs critical for token replay detection?

It records failed sign-in attempts

It records admin configuration changes

It records token-based and app-based sign-ins that occur without user interaction

When an attacker replays a stolen session or refresh token, the resulting sign-in is non-interactive — the attacker is not entering credentials at a login page. These events appear in AADNonInteractiveUserSignInLogs, not SigninLogs. Missing this table means missing the majority of token replay activity.

3. A conditional access policy requires MFA for all users. An AiTM attacker still gains access. Why?

The policy was not applied to the correct users

MFA was disabled for that application

The attacker captured a session token that already contained the MFA claim — the token bypasses MFA entirely

AiTM attacks capture the complete session token after MFA is satisfied. The token is already "MFA-authenticated" — when replayed, conditional access sees a valid MFA claim and allows access. This is why phishing-resistant MFA methods (FIDO2, certificate-based auth) and token protection policies are needed to counter AiTM.

4. Which conditional access condition would most effectively block a stolen token from an unmanaged device?

Require compliant device

Require MFA

Block legacy authentication

Requiring a compliant device means the sign-in must come from a device managed by Intune that meets your compliance policies. An attacker replaying a stolen token from their own unmanaged device would be blocked — the device is not enrolled, not compliant, and therefore denied access regardless of the token's MFA claim.

← 1.6 Microsoft Sentinel 1.4 Defender for Cloud Apps →