DEV Community

AdminPackStudio
AdminPackStudio

Posted on

Compliance before Conditional Access — an Intune enrollment & compliance runway that won't lock out Outlook

#microsoft #security #powershell #devops

Compliance before Conditional Access

In the last post we walked through rolling Conditional Access (CA) from report-only to enforce without a Monday-morning lockout.

This one is the part that has to come first. A "Require compliant device" policy is only as good as the compliance signal behind it. If enrollment is half-done and complianceState is noise, that CA policy isn't really a security control. It just shuts off email.

Here's the order we use: enroll → configure → measure → gate access.

1. Write down your enrollment paths before you click anything

One short page per tenant is enough:

Device type Typical path Watch out for
Corporate Windows (Entra joined) Autopilot or automatic MDM enrollment Prefer Autopilot for new hardware
Corporate Windows (hybrid joined) MDM via GPO or Autopilot hybrid Confirm sync / SCP health first
BYOD Windows Company Portal, user-driven More friction; scope carefully
Shared / kiosk Autopilot self-deploying / kiosk profile Run its own pilot

Add: pilot group name, production group name, owner. Future you will thank you when someone asks "why didn't this laptop get the profile?"

2. Prerequisites that cause most "Intune is broken" tickets

  • [ ] License: the user has an Intune-eligible license (for example Microsoft 365 Business Premium, E3/E5 with Intune, or Intune Plan 1).
  • [ ] MDM user scope: Entra ID → Mobility (MDM and MAM) → Microsoft Intune → MDM user scope = pilot group, not "All" on day one, and not still "None."
  • [ ] MAM user scope: None or a tight pilot unless you already need app protection.
  • [ ] Pilot group: 3–10 users/devices you can break without paging the CEO.
  • [ ] Break-glass account: cloud-only emergency admin, excluded from risky CA experiments.

In our experience, fixing the license and the MDM scope clears a big share of "device stuck pending" tickets. Check those two before you start reading logs.

3. Configuration is not compliance (and neither is CA)

These three get mixed up all the time:

Layer What it does Changes the device?
Configuration Pushes settings (BitLocker, Defender, update rings) Yes
Compliance Evaluates whether the device meets your bar No. It only marks compliant / noncompliant
Conditional Access Uses signals (incl. "compliant") to allow / MFA / block sign-ins Blocks access, not the OS

The trap: a compliance policy that requires BitLocker does not turn BitLocker on. If you don't also assign a disk encryption policy, devices stay noncompliant forever and the compliance policy gets the blame.

4. A starter Windows compliance baseline (pilot only)

One policy, one OS class, one pilot group. Name it like a change ticket:

WIN - Baseline Compliance - Pilot v1

Setting Starter value Note
BitLocker Require Pair with a disk encryption config policy
Secure Boot Require where hardware supports Don't require on known old hardware in the pilot
TPM Per org standard Align with BitLocker
Minimum OS The build you actually patch to Not aspirational
Firewall / AV / antispyware / real-time Require Defender counts
Password / PIN Match org policy Don't invent a stricter PIN than your auth methods

Noncompliance actions for the pilot: mark noncompliant after grace = on. Notifications are optional. Remote lock / retire / wipe = off. Don't put destructive actions in front of a signal you haven't learned to trust yet.

Grace period: start around 3 days while BitLocker is still encrypting, then tighten once the fleet encrypts quickly.

Remember: "noncompliant" usually means "policy hasn't finished applying," not "compromised." Tell the helpdesk this explicitly.

5. Verify one device end to end

For each pilot device:

  1. dsregcmd /status: is the join state what you expect?
  2. Settings → Accounts → Access work or school: is the work account connected?
  3. Intune admin center → the device: Compliance, Configuration, Managed by.
  4. Sync from Company Portal (or the Intune blade).
  5. Capture the result for your change log.

If you'd rather capture this as data than as screenshots, a read-only local check is easy. This minimal example only reads state and changes nothing:

# Read-only: join state + BitLocker + Defender quick signal
$dsreg = dsregcmd /status
$joined = [bool]($dsreg | Select-String 'AzureAdJoined\s*:\s*YES')
$bl = Get-BitLockerVolume -MountPoint $env:SystemDrive -ErrorAction SilentlyContinue  # needs elevation for full detail
$def = Get-MpComputerStatus -ErrorAction SilentlyContinue

[pscustomobject]@{
    Computer          = $env:COMPUTERNAME
    EntraJoined       = $joined
    BitLockerStatus   = $bl.ProtectionStatus
    DefenderRealTime  = $def.RealTimeProtectionEnabled
    CollectedAt       = (Get-Date).ToString('s')
}
Enter fullscreen mode Exit fullscreen mode

6. Trend compliance weekly instead of eyeballing a blade

Portal views aren't version-controlled. A weekly CSV of managed devices tells you whether you're actually getting healthier. With Microsoft Graph PowerShell and a read scope:

# Read-only: requires DeviceManagementManagedDevices.Read.All
Connect-MgGraph -Scopes 'DeviceManagementManagedDevices.Read.All'

Get-MgDeviceManagementManagedDevice -All `
  -Property 'deviceName','operatingSystem','osVersion','complianceState','lastSyncDateTime','isEncrypted' |
  Select-Object DeviceName, OperatingSystem, OsVersion, ComplianceState, LastSyncDateTime, IsEncrypted |
  Export-Csv ".\intune-devices-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
Enter fullscreen mode Exit fullscreen mode

Use a least-privilege role (for example Intune Reader or Global Reader if that's enough), run it from an admin workstation, and keep the CSVs somewhere your org allows. Device lists don't belong in public chats.

7. Pilot exit criteria — then, and only then, CA

Move past the pilot when:

  1. ≥90% of pilot devices have been compliant for 7 consecutive days
  2. The top noncompliance reasons are understood and written down
  3. The helpdesk can fix the top 3 issues without escalating
  4. You have a baseline CSV archived

Then pair with CA in report-only:

  • Name: CA - Require compliant device - REPORT ONLY
  • Users: the same pilot group
  • Target: Office 365 (not "All cloud apps" on day one)
  • Grant: require device to be marked compliant
  • Watch sign-in logs / Insights for 3–7 days

One Autopilot gotcha: if a broad "require compliant device" policy also targets the Intune enrollment apps, new devices can get stuck in ESP. A device has to enroll before it can be compliant, and the policy won't let it enroll until it's compliant. Check Microsoft's current guidance on excluding those apps and validate in report-only first.

Rule of thumb: keep CA expansion one step behind compliance expansion.

8. Editing a live compliance policy without mass noncompliance

The bad pattern: edit the production policy, 800 devices go noncompliant, CA blocks Outlook.

The better pattern:

  1. Duplicate → ... - Pilot v2
  2. Assign v2 to the pilot only; leave v1 where it is
  3. Take a snapshot before and after
  4. Promote v2 only after ≥48 hours of clean pilot results
  5. Confirm break-glass is still excluded from CA, and keep a rollback (reassign v1)

Quick triage map

Symptom Likely cause First check
Device never appears in Intune MDM scope / license Mobility MDM scope; license; dsregcmd /status
Autopilot hangs on ESP Blocking app or policy timeout, or a CA loop ESP blocking apps; network; CA targeting enrollment apps
BitLocker compliance fail No TPM / policy conflict / still encrypting Disk encryption assignment; TPM; grace period
Compliance flips daily Conflicting policies / AV conflict / grace too tight Which setting fails; duplicate policies
Company Portal "can't connect" Time / proxy / TLS inspection Clock; inspection exclusions

Want the full runbooks?

This post is the short version. The Intune & M365 Admin Starter Pack ($19 during launch week; normally $29) is five markdown playbooks: enrollment & device hygiene, baseline compliance with report-only CA phasing, PowerShell inventory snapshots, M365 admin hygiene, and a break/fix runbook with 7 common Intune failure cards. It also includes three read-only PowerShell scripts: a local enrollment snapshot, a Graph device snapshot, and a compliance policy summary. The scripts never wipe, retire, or change policy.

👉 https://cashflow4375.gumroad.com/l/joonf

Once compliance is green and you're ready to gate access, the companion Entra ID Conditional Access Starter Pack ($29) covers report-only → enforce, a starter policy library, break-glass, and CA troubleshooting: https://cashflow4375.gumroad.com/l/nhuyrc

If you only take the free version, the checklist above will still get you most of the way. Questions or corrections are welcome in the comments.

— Admin Pack Studio

Not affiliated with or endorsed by Microsoft. Operational guidance for admins authorized to manage their tenant. Test in a pilot first; AS-IS, no warranty.

Top comments (0)