I85PREP
⌘ K
MD-102 study materials
MD-102 study resources

Blocking Unhealthy Devices Without Breaking BYOD or Frozen Firmware

MD-102 · Put your knowledge to work in context.

All case studies

Blocking Unhealthy Devices Without Breaking BYOD or Frozen Firmware

Contoso has 1,500 corporate Windows 11 laptops, 260 corporate-owned iOS and Android phones, and 400 personally owned phones that HR policy forbids IT from enrolling. Security leadership wants email and Teams access blocked from any device that is not healthy, starting next month. Field engineers carry Android 11 tablets whose firmware is frozen by the vendor and who already use the Outlook app. Marketing uses unmanaged Macs. Today there is exactly one Conditional Access policy requiring MFA for all cloud apps, and no compliance policies exist. Licensing is Microsoft 365 E3 with Entra ID P1. Security also wants to prove after go-live which users were blocked and why.

1. Design the control set across the three populations and explain how you avoid locking out the Android 11 tablets and the Macs.

Read the worked answer

Layer 1 - compliance policies per platform (Windows, iOS, Android): BitLocker/encryption required, minimum OS, Defender/device health, and a grace period plus a 'mark device noncompliant after N days' action. Do not mark noncompliant immediately; a laptop that skips one check-in should not lose email at 9am.

Layer 2 - Conditional Access:

  • Policy A: Require device to be marked compliant, scoped to Windows, iOS and Android platforms only.
  • Policy B: Require app protection policy (plus Require approved client app) for the BYOD group, so unenrolled personal phones get Outlook/Teams with MAM instead of being refused outright.
  • Macs: exclude them from the device-state policies. They cannot be enrolled under your HR rule, so the only sane control is app-level - Require MFA plus app-enforced restrictions on SharePoint/Exchange - otherwise you block a whole department on day one.

Android 11 tablets: set the Android minimum OS to a version the frozen firmware actually meets (11), not to 'latest'. A compliance policy that no device in a population can satisfy is not a security control, it is an outage. Put the tablets in a named group so the exception is visible and reviewable, not a silent exclusion.

Also: block legacy authentication and other client apps. Without that, the native mail client walks straight past both the compliance policy and the MAM policy.

2. What must be true for the MAM-without-enrollment path to work, and what are the two biggest bypasses you must close?

Read the worked answer

Preconditions:

  • Users are licensed for Intune (E3 covers it) and targeted by an app protection policy.
  • The apps in scope support MAM - Outlook, Teams, Edge, OneDrive, and the iOS broker (Microsoft Authenticator) is installed on iOS.
  • The Conditional Access grant checks for app protection policy, not device compliance, for that population.

Bypass 1 - other client apps. If Exchange ActiveSync or the native mail client is still allowed, users read corporate mail with no MAM controls at all. Close it with a CA policy that applies to 'Exchange ActiveSync' and 'Other clients' and blocks them, so the only path is a MAM-managed app.

Bypass 2 - data escaping the app. Default MAM allows copy/paste and Save As. Set data transfer to 'policy-managed apps only', block Save As to personal locations, restrict cut/copy/paste, and set conditional launch (require PIN, block jailbroken/rooted devices). Otherwise the data is protected for the thirty seconds it stays in Outlook.

Expectation setting: MAM-WE protects corporate data inside managed apps; it does not inventory or wipe the personal phone. Any executive expecting a remote wipe of a personal device has misunderstood the design - the action available is selective wipe of corporate data.

3. How do you sequence enforcement, and how do you produce the 'who was blocked and why' evidence?

Read the worked answer

Sequence:

  1. Deploy compliance policies first and let them settle for a week so devices report in. A CA policy that requires compliance before any device can report compliance blocks everybody.
  2. Turn the CA policies on in report-only mode. Users are not blocked; every would-be block is logged.
  3. Review report-only results against the pilot group; fix the populations that would have been hit (frozen Android, unenrolled Macs, devices with a stale check-in).
  4. Enable for a pilot ring, then broadly, keeping an emergency exclusion group that is documented and empty.

Evidence:

  • Microsoft Entra sign-in logs, filtered on the Conditional Access result and the specific policy name, give you user, app, device, and failure reason per attempt.
  • Intune compliance reports give device state and the failing setting.
  • Turn on Intune diagnostic settings to the Log Analytics workspace so the data survives past the short default report retention; queries over the exported sign-in and compliance tables then produce the monthly 'blocked by policy X' breakdown.

Judgement: do not go straight to 'block' because leadership asked for next month. Report-only costs you a week and is the only way to find the population you forgot.