AD3.8 The Exception Workflow

Building the exception register

Create a SharePoint list or Excel document with these columns: Device Name, User, Failing Compliance Check, Business Justification, Alternative Control, Approved By, Date Approved, Expiration Date, Review Date, Status (Active/Expired/Removed).

Alternative controls for common exceptions:

A device that can't run BitLocker (no TPM): restrict the device to on-premises network access only via conditional access named locations. The device can access M365 only from the office network — if lost or stolen off-site, it can't authenticate. Document the hardware refresh date when the device will be replaced.

A device that can't be updated to the minimum OS version (old hardware): same network restriction. Additionally, ensure the device has all available security updates for its current OS version — even if the version is no longer fully supported, individual security patches may still be available. Set a hardware replacement date.

A specialized device that needs the firewall disabled (network testing, manufacturing control): isolate the device on a separate network segment. It should not have access to M365 data or corporate email. If it needs limited M365 access, use a dedicated service account with minimal permissions and restrict sign-in to the device's IP address via conditional access.

The key principle: every exception has an alternative control that limits the blast radius. An exception is never "exempt from security" — it's "protected by a different mechanism." The alternative control may be weaker than full compliance, but it's documented, approved, and reviewed.

Implementing exceptions in Intune and Conditional Access

Technically, exceptions are implemented in one of three ways:

Method 1 — Separate compliance policy with relaxed requirements. Create a second compliance policy (e.g., "Windows Compliance — Legacy Devices") that omits the failing check (e.g., no BitLocker requirement). Assign exception devices to a group that receives the relaxed policy instead of the standard policy. This is the cleanest approach — the device is still evaluated against a compliance policy, just one with different requirements.

Method 2 — Conditional access group exclusion. Add exception devices to a security group that's excluded from CA003. This removes the device compliance requirement entirely for those devices. Use this sparingly — it bypasses all compliance checks, not just the one that's failing. Only appropriate for devices that can't meet ANY compliance requirements (legacy test equipment, specialized hardware).

Method 3 — Named location restriction. Instead of a compliance exception, add a conditional access policy that restricts the exception device to a specific network location. The device can access M365 only from the office network — if lost or stolen elsewhere, it can't authenticate. This is the strongest alternative control: instead of requiring device compliance, you require physical presence.

For NE, the recommendation is Method 1 for most exceptions (device-specific relaxed policy) and Method 3 for high-risk exceptions (network-restricted access).

Worked example: processing an exception request

Request: The facilities team uses a Windows 10 tablet mounted on the wall in the reception area for visitor check-in. The tablet runs a visitor management kiosk application and accesses a SharePoint list to log visitor data. It can't be upgraded to Windows 11 (the kiosk application doesn't support it), and BitLocker can't be enabled (the device uses a legacy BIOS without UEFI/TPM).

Assessment: The device accesses one SharePoint list with non-sensitive data (visitor names and arrival times). It doesn't access email, Teams, or confidential documents. The risk of the device being stolen is low (wall-mounted in a monitored reception area). The risk of the OS version being exploited is medium (Windows 10 has known vulnerabilities but the device is on the corporate network behind a firewall).

Decision: Approve the exception with these alternative controls: (1) create a separate compliance policy without BitLocker or OS version requirements, assigned only to this device, (2) restrict the device's service account via conditional access to access only the specific SharePoint site (not all of SharePoint), (3) set expiration for when the kiosk vendor releases Windows 11 support, (4) schedule quarterly review.

Implementation: Create security group "Exception — Kiosk Devices." Create compliance policy "Kiosk Compliance" with firewall and AV checks only (no BitLocker, no OS version). Add the kiosk device to the group. Create a CA policy that restricts the kiosk account to the kiosk SharePoint site via app-enforced restrictions. Document everything in the exception register.

The quarterly exception review — step by step

Set a 30-minute calendar appointment on the first business day of each quarter. During the review, work through each active exception in the register:

Step 1 — Is the exception still needed? Check whether the original justification still applies. Has the hardware been replaced? Has the vendor released the update? Has the temporary condition been resolved? If the justification no longer applies, close the exception and apply the standard compliance policy to the device.

Step 2 — Is the alternative control still in place? For named-location-restricted devices: verify the CA policy still exists and the device is still in the correct group. For devices with separate compliance policies: verify the policy is still assigned and the device is evaluating against it. For network-segmented devices: verify the network segmentation is still active. Alternative controls can drift just like compliance — a network change, a group membership update, or a CA policy modification can silently remove the alternative control.

Step 3 — Has the expiration date passed? If yes, the exception requires re-approval. Contact the original approver (or their successor) with the current status: "This exception was approved on [date] for [reason] with an expiration of [date]. The expiration has passed. The device still requires the exception because [current status]. Requesting re-approval with a new expiration of [date]." Document the re-approval in the register.

Step 4 — Document the review. Add a "Last reviewed" date to each exception entry. If the exception was renewed, note the new expiration. If it was closed, note the closure reason and date. This audit trail demonstrates that exceptions are actively managed, not forgotten.

Setting up named location restrictions for exception devices

Named locations in conditional access restrict sign-in to specific IP ranges — typically your office network. For exception devices that can't meet full compliance, named location restriction ensures the device can only access M365 from a trusted network.

Navigate to entra.microsoft.com → Protection → Conditional Access → Named locations → New location → IP ranges location.

Name: "NE Office Networks" IP ranges: Add your office public IP addresses (check whatismyip.com from your office network). Add VPN gateway IPs if remote workers connect through VPN. Mark as trusted location: Yes.

Then create a conditional access policy for exception devices:

Name: "CA-Exception — Network Restricted Access" Users: Include → Select group → "Exception — Kiosk Devices" (or whatever group contains your exception devices) Cloud apps: All cloud apps Conditions: Locations → Include: Any location → Exclude: "NE Office Networks" Grant: Block access

This policy blocks exception devices from accessing M365 from any location except your office network. If the kiosk tablet is stolen and taken off-site, it can't authenticate. The device works normally in the office but is useless anywhere else. This is the strongest alternative control for devices that can't meet full compliance — geographic restriction as a substitute for device-level protection.