EI3.7 Grant Controls: MFA, Auth Strength, Device, Terms of Use

The grant control options

Every conditional access policy must specify either a grant or a block control. The grant controls available are:

Require multifactor authentication: the original MFA grant control. Satisfied by any second factor. Authenticator push, SMS, OATH token, phone call, FIDO2, passkey, WHfB, CBA. This is the broadest MFA requirement. Use it for baseline policies that need universal coverage without specifying which MFA method. Does NOT distinguish between phishing-resistant and phishing-capable methods.

Require authentication strength: the granular MFA grant control from EI2.7. Specifies which authentication methods satisfy the requirement: MFA strength (any second factor), Passwordless MFA strength (no password as first factor), Phishing-resistant MFA strength (domain-verified methods only), or a custom strength. Use this when you need to enforce specific method types.

Require device to be marked as compliant, covered in EI3.6. Requires Intune enrollment and compliance.

Require Hybrid Azure AD joined device, covered in EI3.6. Requires on-premises AD domain join + hybrid join.

Require approved client app, restricts access to Microsoft-approved client applications (Outlook, Teams, OneDrive, SharePoint, etc.) rather than any browser or client. This is primarily useful for mobile device management scenarios where you want to allow mobile access but only through managed applications.

Require app protection policy, requires the application to be protected by a Microsoft Intune app protection policy. App protection policies provide data protection (prevent copy/paste to unmanaged apps, encrypt app data, require PIN to open the app) without requiring full device enrollment. This is the BYOD-friendly alternative to device compliance, you protect the app and its data rather than the entire device.

Require password change, forces the user to change their password. Used in risk-based policies: when user risk is high (Identity Protection detects compromised credentials), force a password change. This control is becoming less relevant as organizations move to passwordless authentication, if the user does not have a password, "require password change" has no effect. The adaptive risk remediation feature (GA April 2026) provides alternative remediation for passwordless users.

Block access, denies the sign-in entirely. No grant, no prompt, just block. Block is the most restrictive control and always wins over grant controls. Use it for: blocking legacy authentication, blocking sign-ins from blocked countries, blocking access to specific applications from specific user groups, and blocking high-risk sign-ins.

Require terms of use, presents the user with a terms of use document that they must accept before accessing the application. This is a compliance control rather than a security control, it creates an auditable record that the user agreed to the organization's acceptable use policy, data handling policy, or security policy. Terms of use documents are created in Entra ID at Identity → Protect & secure → Conditional Access → Terms of use. Multiple documents can be created for different scenarios (general acceptable use, BYOD access agreement, sensitive data access acknowledgment). The user's acceptance is recorded in the audit log and can be required to re-accept on a configurable schedule (quarterly, annually). For security purposes, terms of use is most useful for BYOD and external user policies, requiring explicit acknowledgment that data access from personal devices is subject to monitoring and that sensitive data must not be downloaded to unmanaged devices.

The block vs grant decision framework

Deciding when to block vs when to grant with controls is one of the most consequential design decisions in conditional access. The wrong choice either locks out legitimate users (over-blocking) or allows attackers through (under-blocking).

Block when the access should never occur. Legacy authentication protocols should never succeed because they bypass MFA, block them. Sign-ins from countries with no business presence should never succeed, block them. Guest users accessing internal-only applications should never succeed, block them. There is no legitimate scenario where these sign-ins are acceptable, so granting with conditions is inappropriate.

Grant with controls when the access is legitimate but needs verification. A user signing in from a new location needs MFA but should not be blocked, they may be traveling. A user on a personal device needs session restrictions but should not lose access entirely, they may be working remotely. An elevated-risk sign-in needs additional verification but may be a false positive, blocking every medium-risk sign-in generates unacceptable friction.

The test: Ask "Is there any scenario where this sign-in should succeed?" If the answer is no, block. If the answer is "yes, but only if the user satisfies additional requirements," grant with those requirements. If the answer is "yes, always," the sign-in does not need this policy.

Combining grant controls

When a policy has multiple grant controls selected, the combination logic matters:

"Require all the selected controls" (AND): The user must satisfy every selected control. If the policy requires MFA AND a compliant device, the user must complete MFA AND use a compliant device. If either is not satisfied, access is blocked.

"Require one of the selected controls" (OR): The user must satisfy at least one of the selected controls. If the policy requires MFA OR a compliant device, the user can complete MFA from an unmanaged device OR sign in from a compliant device without additional MFA (if MFA was already satisfied by device registration). OR logic reduces friction but provides weaker guarantees.

For security architecture, AND is almost always the correct choice. The combination "require phishing-resistant MFA AND compliant device" ensures that the user proves their identity with a strong method AND the device is managed and secure. This is the foundation of Zero Trust: both the identity and the device are verified.

The one scenario where OR is appropriate: when you want to accept either a managed device OR MFA as a way to verify the user's security posture. This is sometimes used for standard users accessing standard applications, users on managed devices get seamless access (the device satisfies the OR condition), while users on unmanaged devices must complete MFA. This reduces friction for managed device users while maintaining a security baseline for everyone.

Between policies (as covered in EI3.1), the combination is always AND. If Policy A requires MFA and Policy B requires a compliant device, the user must satisfy both, even though they are in separate policies. This means you can build layered policies: a baseline policy requires MFA for all users, and a separate policy requires compliant devices for privileged users. Privileged users satisfy both (MFA AND compliant device) because both policies match their sign-ins.

// EI3.7 — Analyze which grant controls are being enforced
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| mv-expand CAPolicy = parse_json(ConditionalAccessPolicies)
| where tostring(CAPolicy.result) == "success"
| extend GrantControls = tostring(CAPolicy.enforcedGrantControls)
| extend SessionControls = tostring(CAPolicy.enforcedSessionControls)
| extend PolicyName = tostring(CAPolicy.displayName)
| where isnotempty(GrantControls) or isnotempty(SessionControls)
| summarize 
    PolicyCount = dcount(PolicyName),
    EvaluatedSignIns = count()
    by GrantControls, SessionControls
| order by EvaluatedSignIns desc
// Shows which control combinations are most commonly enforced
// Expect: ["mfa"] as the most common grant control
// Look for: ["authenticationStrength"] for phishing-resistant policies
// Missing: ["compliantDevice"] if you haven't deployed device compliance yet

Understanding which grant controls are blocking users, not just which are succeeding, is equally important for maintaining the architecture:

// EI3.7 — Find sign-ins blocked by grant controls
// These are users who could not satisfy the required controls
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 53003  // Blocked by conditional access
| mv-expand CAPolicy = parse_json(ConditionalAccessPolicies)
| where tostring(CAPolicy.result) == "failure"
| extend PolicyName = tostring(CAPolicy.displayName)
| extend GrantControls = tostring(CAPolicy.enforcedGrantControls)
| summarize 
    BlockedCount = count(),
    AffectedUsers = make_set(UserPrincipalName, 10)
    by PolicyName, GrantControls
| order by BlockedCount desc
// High block count for a policy = many users cannot satisfy the control
// Check: are these users supposed to be blocked? (legitimate enforcement)
// Or are they users who should have access but lack the required credential/device?
// Common cause: policy requires compliant device but user's device is not enrolled

When a user reports being blocked, the investigation follows a standard sequence: identify the blocking policy from the sign-in log's ConditionalAccessPolicies array (the policy with result "failure"), identify the unsatisfied grant control, determine why the user cannot satisfy it (no phishing-resistant method registered, device not enrolled, device non-compliant, signing in from a blocked country), and either remediate the user's state or confirm the block is intended.

Environment: Your M365 developer tenant with Sentinel workspace.

Exercise: Run the grant control analysis query above. Examine which grant controls are currently being enforced in your tenant. If you only have the report-only policy from EI3.1, the query may return limited results: the report-only policy evaluates but does not enforce.

Create a second report-only policy:

• Name: "EI3-Test-PhishingResistant-Admins"
• Assignments: CA-Target-Admins group
• Target resources: All cloud apps
• Grant: Require authentication strength → Phishing-resistant MFA
• Enable: Report-only

After 24 hours, run the grant control query again. You should see both report-only policies in the ConditionalAccessPolicies array, one requiring MFA (the baseline) and one requiring phishing-resistant MFA (the admin policy). The combination shows the layered enforcement: admins must satisfy both.

The reference above captures the operational configuration. The principle below crystallises the design decision.