Device assurance policies
Per-platform posture checks evaluated at sign-in — API only, no console screen yet — and why every device reads as unknown until the sensor sends its first posture report.
A device assurance policy states what a device has to look like before it counts as trustworthy: an agent installed and reporting recently, a minimum operating system version, disk encryption on, a screen lock configured, endpoint protection healthy. This is real, evaluated at every sign-in — and it is honest to say up front that today it is an API-only feature with no console screen, and that every device currently evaluates as unknown because the sensor does not yet send the data it needs. Read both of those before you build anything on it.
What a policy can check
A policy applies to one platform (Windows, macOS, Linux, iOS or Android) and lists an ordered set of checks:
- Agent required — the endpoint sensor has to be present at all.
- Maximum report age — how stale the last posture report is allowed to be before the device is treated as not reporting.
- Minimum OS version, compared per platform.
- Disk encryption — BitLocker, FileVault or LUKS, depending on platform.
- Screen lock configured.
- EDR healthy — the endpoint protection service is running and reporting well.
For a given platform, the first ACTIVE policy that covers it is the one evaluated at sign-in. If a platform has no active policy at all, there is nothing to fail: the device is reported as unknown and no device is touched or penalised for the absence of a policy.
Why every device reads as unknown today
In practice this means a policy you configure today that denies or steps up on a device without a compliant posture will match every device, because none of them can currently prove compliance. Do not activate a device-assurance sign-on condition that denies on failure until the sensor side ships — write the policy, test it against the reports endpoint, and hold off on making it consequential.
The wire contract the sensor will eventually use already exists and is exercised today through the general sensor ingest path: POST /xdr/sensor/ingest with a posture channel event. A device bound to a sensor is also re-judged at every sign-in against how old its last report is, so a sensor that goes quiet stops vouching for the device rather than continuing to rely on a stale report indefinitely — once reports exist to go stale.
The endpoints
| Method & path | Notes |
|---|---|
GET/POST/PUT/DELETE /organizations/{orgID}/device-assurance/policies[/{id}] | Manage per-platform policies. |
GET /organizations/{orgID}/device-assurance/reports | The latest posture facts recorded per (organisation, sensor): verdict, failed checks, and the principals/users the report has been matched to. |
GET /organizations/{orgID}/device-assurance/checks | The catalogue of check types a policy can reference. |
How a report attaches to a device and a user
A posture report is keyed to a sensor, and it is used to mark known devices — the same device records described in Adaptive MFA and risk signals. It first updates the device the sensor is directly bound to, then extends to the recently-used devices of every principal the platform can resolve as using that sensor. A report never overwrites a device already marked compromised — a posture check improving is not allowed to erase a compromise finding from another module.
What to do with this today
- If device compliance is a genuine requirement for you, write the policy now over the API so it is ready — but do not wire it into a
denysign-on outcome until the sensor collectors ship, or you will deny every device including the compliant ones. - Use the reports endpoint to confirm for yourself that posture is coming through as
unknownacross the board; that is expected, not a fault to chase. - Watch for the sensor update that adds posture reporting — once it ships, re-test a device assurance policy against a real machine before relying on it in a sign-on rule.