Can unauthorized devices be blocked from remotely accessing the network (e.g. MDM, allow-lists)?
Credentials can be stolen. A device requirement means stolen credentials alone are not enough, which is why this question sits alongside the multi-factor ones.
What the carrier is actually asking
The carrier is asking whether access can be limited to devices the organisation knows and manages, through device management, certificates, or allow-lists. It is asking about a control that operates on the device rather than on the person.
Why it is underwritten
Device conditions defeat credential theft and most session theft, because an attacker with a valid password and a valid one-time code still fails without an enrolled device. Carriers see this as a meaningful step above multi-factor alone.
Where the answer lives in Microsoft 365, Entra ID, and Azure
This is directly measurable in Entra ID, where device state is a condition in the same policy engine that governs authentication.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Entra ID | Conditional Access policies requiring compliant or hybrid-joined devices | Device requirement enforced for the applications that matter, with exclusions enumerated |
| Microsoft 365 | Intune compliance policy definition | Compliance means something: encryption, patch level, and security agent health, rather than merely being enrolled |
| Microsoft 365 | Default compliance status for devices with no policy result | Set to not compliant, so an unevaluated device fails closed rather than open |
| Entra ID | Device registration and join restrictions | Who can join devices, since unrestricted join lets an attacker enrol their own machine |
| Entra ID | Certificate-based authentication where used | Device certificates as an alternative path to the same outcome |
The default compliance status setting decides what happens to a device that has not yet been evaluated. Left at compliant, an unevaluated device passes the policy. Set to not compliant, it fails. It is one setting and it decides whether the control holds at the edges.
What a defensible yes requires
- A device condition is enforced for corporate applications, not only for administrative ones.
- Compliance is defined meaningfully, covering encryption, patching, and agent health.
- Unevaluated devices fail closed.
- Device registration and join are restricted.
- Contractors and personal devices are handled explicitly, through application protection or restricted browser access.
How this answer goes wrong
A compliance policy exists and no Conditional Access policy requires it, so compliance is a report rather than a gate. Or the policy is enforced and the default compliance status leaves unevaluated devices treated as compliant, which is the gap an attacker enrolling a new device walks through.
Frequently asked
Does this block contractors?
Only if you want it to. The usual design allows unmanaged access through a browser with downloads blocked and application protection enforced, which is a middle path worth describing.
Is device compliance better than multi-factor?
It is complementary and defeats a different attack. Multi-factor stops password reuse; device conditions stop token theft and unmanaged endpoints.
What about mobile?
Application protection policies deliver an equivalent outcome without managing the whole device, which is usually the right answer for personal phones.
How do we start?
Enforce the device condition for the most sensitive applications first, then widen. Enforcing everywhere at once generates support load that leads to broad exclusions.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture