📚💻CS - Compliance Settings
Two tenant-wide switches that decide what 'compliant' even means before a single policy runs: how a device with no policy is treated, and how long a verdict stays valid.
What this policy is about 📚
Compliance policies get all the attention, the BitLocker check, the OS floor, the Defender signal. But before any of those run, two tenant-wide switches decide the ground rules, and both ship set to trust first.
They live under Devices → Compliance → Compliance settings, and every managed device evaluates them as a built-in device compliance policy, visible right there in the device's compliance state:
- Mark devices with no compliance policy assigned as. The default verdict for a device that no policy targets. Ships as Compliant. That is the one this page turns around.
- Compliance status validity period (days). How long a device's last reported verdict stays good before it goes stale and flips to not compliant. Ships as 30.
The first is a security hole with a friendly name. The second is a dial most people never touch and a few people crank the wrong way. This page sets both, and, more importantly, sequences the change so it doesn't lock your customers out of their own tenant.
"No policy assigned = compliant" means the device you never enrolled, never hardened, and never checked still sails through a require compliant device rule. The compliance engine you built is only as honest as its default answer, and the default answer is "sure, come in."
Why this matters 🕵️
Compliant-by-default is a hole under everything you built. 🕳️ The whole point of device compliance is to pair it with Conditional Access: a resource requires a compliant device, and non-compliant devices get blocked or challenged. That deal only holds if "no policy" means "not trusted." Leave the default at Compliant and any device that slips out of policy scope, an enrollment that half-finished, a platform you never wrote a policy for, a machine someone manually excluded, is quietly waved through the CA gate as a good citizen. You are not enforcing compliance at that point; you are enforcing it for the devices that happened to get a policy, which is a different and much weaker sentence.
A stale verdict is a lie with a timestamp. ⏳ Compliance is a snapshot, not a live feed. A device reports "compliant," then goes dark, off the network, in a drawer, sold on marktplaats without a wipe. The validity period is how long that last snapshot keeps voting. Set it too long and a device silent for months still holds a compliant verdict and, with it, a CA grant. The validity period is the expiry date on trust, and expiry dates exist for a reason.
Turn the default around and the model finally says what everyone assumed it already said: prove you're compliant, or you're not.
The rollout that doesn't page you at 2 AM 🧯
Here is where people get hurt. Flipping the default to Not compliant is one click, and if a Conditional Access policy is already enforcing "require compliant device," that one click can mark a pile of devices non-compliant and lock their users out in the same breath. The setting is correct; the order is what saves you.
Do it in this sequence, not the other one:
- Give every device a policy first. A device is only caught by this switch if no compliance policy targets it. Assign your baseline compliance policies broadly (all devices, per platform) so the population of "no policy assigned" shrinks to near zero before the default changes.
- Put the compliance-requiring CA policy in report-only. Require Compliant Device and its siblings go to Report-only, so you can watch what would be blocked without blocking it.
- Read the blast radius. Sign-in logs and the CA what-if now show you exactly which devices would fall over. A mature tenant with lots of unmanaged-but-signing-in devices is precisely where this bites, so look before you leap.
- Then flip the default to Not compliant. With policies assigned and the CA still in report-only, turning the switch does what it should: it catches genuine gaps, not your whole fleet.
- Then enforce the CA. Only once the report-only data is boring do you move the CA policy to On.
Skip straight to step 4 with an enforcing CA already live, and you have not hardened the tenant, you have written yourself a Monday-morning incident. 📟
🛠️ Configuration
Both switches live in the same pane and can be set together in one Graph call.
Microsoft Intune admin center
Where: Microsoft Intune admin center → Devices → Compliance → Compliance settings.
Role: An Intune role with device-compliance write is enough. Global Administrator is not required, so don't use one.
| Setting | Value | Why |
|---|---|---|
| Mark devices with no compliance policy assigned as | Not compliant | Makes "no policy" mean "not trusted," which is the only reading that lets Conditional Access do its job. |
| Compliance status validity period (days) | 30 | Long enough to survive a normal holiday, short enough that a device dark for over a month stops voting. See the reasoning below. |
Save. Tenant-wide, all platforms, effective as devices next check in.
Microsoft Graph (PowerShell)
Both switches are properties of the deviceManagement settings object, so one PATCH does the pair:
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"
$Body = @{
settings = @{
secureByDefault = $true # Mark no-policy devices as Not compliant
deviceComplianceCheckinThresholdDays = 30 # Compliance status validity period (days)
}
} | ConvertTo-Json
Invoke-MgGraphRequest -Uri 'https://graph.microsoft.com/v1.0/deviceManagement' -Method PATCH -Body $Body
# Read it back to confirm
(Invoke-MgGraphRequest -Uri 'https://graph.microsoft.com/v1.0/deviceManagement?$select=settings' -Method GET).settings
secureByDefault = $true is the "Not compliant" default. deviceComplianceCheckinThresholdDays is the validity period, valid range 1 to 120.
The validity period, chosen on purpose ⏳
The default is 30 days, and for once the default is close to right, so long as you pick it deliberately instead of inheriting it.
The tension is simple. Too long (the 120-day ceiling) and trust barely expires; a laptop can vanish for a quarter and still hold a compliant verdict. Too short (1 to 7 days) and ordinary life trips the wire: the machine that sat in a drawer over the holidays, the seasonal worker back after six weeks, the laptop that spent a fortnight at the repair shop, all flip to not compliant and, if a compliance CA is enforcing, get bounced at the door on their first day back. That is a helpdesk queue, not a security win.
For the MKB reality this blueprint is written for, the deciding factor is the calendar on the wall. A Dutch or Belgian summer holiday is routinely three weeks. Set the period below that and you will spend September re-compliancing people who did nothing wrong except take the leave they are entitled to. So:
- 30 days is the golden-master value. It clears a three-week holiday with a week of buffer, and it still expires trust on anything genuinely abandoned. Keep it here unless you have a specific reason not to.
- Tighten toward ~14 days only if your fleet checks in daily and you genuinely have no long-absence workers, and you accept the extra re-compliance friction that comes with it. This is a hardening choice with a support cost, not a free win.
- Do not extend past 30 to silence noise. A validity period stretched to 60 or 120 is not solving stale devices, it is agreeing to ignore them.
Remember what this dial is: a backstop for silence, not the enforcement itself. Managed devices normally re-evaluate compliance every few hours, so a healthy device never gets near the limit. The period only matters for devices that stop talking, which is exactly the population you want trust to expire on.
Caveats ⚠️
This setting has a hard dependency on your CA rollout. The value is right; the sequencing is everything. Re-read the rollout section above before you touch it in a tenant that already enforces device compliance. The failure mode is not "slightly less secure," it is "users blocked." 🧯
The validity period is a backstop, not a policy. It does not check anything about the device. It only decides when a missing report becomes a not-compliant verdict. Real compliance still comes from your assigned policies. Don't reach for this dial expecting it to enforce posture; that is a category error.
It is genuinely tenant-wide. One value for Windows, macOS, iOS, iPadOS and Android alike. There is no per-platform validity period, so pick a number that survives your longest legitimate absence across the whole fleet, not just the laptops.
License fit (MKB lens). Both switches are part of base Intune device management and cost nothing extra on Business Premium. The value they unlock, Conditional Access that actually trusts its own compliance signal, is where the platform earns its keep, but the switches themselves are free. 💼
Reversibility. Clean-revert, and that cuts both ways. Flip secureByDefault back to $false and the hole reopens instantly, no residue, no trace, usually courtesy of someone "just fixing" one stubborn device at 4pm on a Friday. Alert on the value itself, because the person who reopened it is never the person who writes it down. 🔁
👥 Assignment scope
Tenant-wide by definition. There is no group to assign here; these are service defaults, not a targeted policy. The scoping lives one layer over, in the compliance policies you assign and the Conditional Access policies that consume the result.
Where the exception actually goes. When a device legitimately cannot be compliant, a break-glass workstation, an appliance, a contractor's unmanaged machine, you do not soften this default for the tenant. You exclude that device (or its user) from the compliance-requiring CA policy through a named exception group, so the gap is one signed-for device, not an open door.
At tenant takeover, look before you flip. Two questions decide whether this is a one-click change or a project: is a device-compliance CA policy already enforcing? and how many devices are signing in with no compliance policy assigned? The product of those two is your blast radius. A greenfield tenant flips clean; a mature one with an enforcing CA and a long tail of unmanaged devices needs the report-only runway first.
Verify on a schedule. secureByDefault reading $false on a periodic Graph check is the signal that someone reopened the default. Pair it with an eye on the validity period drifting upward, because a number quietly changed from 30 to 90 is how "we don't have stale devices" becomes true on paper and false in reality. 🚨
🔗 Related
- 🚦🟢💻CA - Require Compliant Device 🪟: the policy that gives this switch teeth, and the one to stage in report-only before you flip the default.
- 📚🪟💻Compliance - Device Health - Bitlocker: a baseline compliance policy to assign broadly, so "no policy assigned" is a near-empty set before the default changes.
The compliance engine only tells the truth if its default answer is "prove it." Turn the default around, put an expiry date on trust, and stage it behind report-only so the only devices that fall over are the ones that were lying anyway. 📚