4.2 Signals and Controls

Signals: the conditions Entra evaluates

A signal is a piece of context Conditional Access collects in Phase 1 and uses to decide whether a policy applies. In the policy editor these live under Assignments and Conditions. The signals SC-900 expects you to recognize are:

Signals never grant standing access by themselves — they only decide whether the policy's controls fire. They are why this topic sits with Zero Trust and identity rather than pure network security.

Grant controls: what the policy requires

After conditions match, Entra applies an access control. The first choice is binary: Block access or Grant access. Block is the most powerful control and stops Phase 2 immediately. If access is granted, the admin can require one or more grant controls:

• Require multifactor authentication — the most common control.
• Require authentication strength — forces a specific method set, e.g. phishing-resistant MFA (FIDO2, Windows Hello, certificate).
• Require device to be marked as compliant — Intune compliance.
• Require Microsoft Entra hybrid joined device.
• Require approved client app and Require app protection policy — mobile app protection.
• Require password change — used to remediate compromised accounts.
• Require terms of use — user must accept a ToU document.

When several controls are selected, the default is Require all the selected controls (AND); admins can switch to Require one of the selected controls (OR), e.g. "compliant device OR MFA."

Session controls and MFA's dual role

Beyond grant decisions, session controls limit what a user can do after access is granted:

• App-enforced restrictions (Exchange Online, SharePoint Online — limited vs. full access).
• Conditional Access App Control — routes the session through Microsoft Defender for Cloud Apps to block download/print of sensitive files or require labeling.
• Sign-in frequency — how often the user must reauthenticate.
• Persistent browser session — whether "stay signed in" is allowed.
• Token protection — binds the refresh token to the device.

A classic SC-900 nuance is that MFA appears in two places. In the authentication chapter, MFA is an authentication method that proves identity. In Conditional Access, "Require MFA" is a grant control applied when conditions match. The capability is identical; only the framing changes. If a question says "all users must use MFA," that is authentication/security defaults; if it says "require MFA only when signing in from outside the corporate network," that is a Conditional Access control.

A quick elimination method

Label each phrase in the question:

• Wording about context (location, device, client, risk) → a signal/condition.
• Wording about a requirement or action (must do MFA, must be compliant, blocked) → a control.
• Wording about continued need over time → governance / access reviews (Section 4.4–4.5).
• Wording about temporary admin elevation → Privileged Identity Management (Section 4.5).

This keeps you from picking a familiar product just because it shares the objective area. The exam rewards the most specific identity capability.

• Context phrase → signal.
• Required action phrase → control.
• Recertification phrase → access review.
• Elevated-role phrase → PIM.

Worked example: reading a policy in plain language

Consider a realistic policy and translate each part into the signal-and-control vocabulary. " This single policy is one of Microsoft's most recommended baseline rules because legacy authentication protocols cannot perform MFA and are a top vector for password-spray attacks.

Now a second policy: for the Finance group, accessing the finance application, from any location, require MFA and require a compliant device, all selected controls. The signals are the user group, the target app, and location; the controls are two grant controls combined with AND. Because Conditional Access combines multiple policies with AND as well, a Finance user who is also subject to the legacy-auth block policy must satisfy both rule sets.

A common trap is the emergency access (break-glass) account. Best practice is to exclude at least one cloud-only Global Administrator account from all Conditional Access policies so a misconfigured policy or an MFA outage cannot lock every admin out. If a question asks how to avoid a tenant-wide lockout, excluding break-glass accounts is the answer.

• Legacy-auth block: a baseline policy that stops protocols that cannot do MFA.
• Combined controls default to require all (AND).
• Break-glass accounts are excluded to prevent lockout.
• Report-only mode lets you preview a policy's effect before enforcing it.

Reading every policy as signal → condition → control turns even unfamiliar wording into a quick elimination exercise: identify what is known about the request, what makes the policy match, and what the policy then enforces.