--- title: "Can unauthorized devices be blocked from remotely accessing the network (e.g. MDM, allow-lists)?" url: https://insuranceposture.com/questions/network-and-logging/can-unauthorized-devices-blocked-from-remotely-accessing-network category: "Network, logging and monitoring" canonical_key: q_net_013 evidence_state: verified updated: 2026-08-24 --- # Can unauthorized devices be blocked from remotely accessing the network (e.g. MDM, allow-lists)? URL: https://insuranceposture.com/questions/network-and-logging/can-unauthorized-devices-blocked-from-remotely-accessing-network Section: Network, logging and monitoring Evidence state: Verifiable from your tenant 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 | **Fail closed on unevaluated devices** 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. ## If this answer turns out to be wrong Remote access exposure and log retention are what a forensic report describes first, which makes them the answers most often revisited after a loss. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [how an application answer ends in a denied claim](https://insuranceposture.com/glossary/claim-denial). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary). ## 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 - [Are users able to access email through a non-corporate (BYOD/personal) device?](https://insuranceposture.com/questions/access-control/users-able-access-email-through-non-corporate-device) - [Is MFA enforced on all remote access (VPN, RDP, remote network admin)?](https://insuranceposture.com/questions/multi-factor-authentication/mfa-enforced-remote-access) - [Is endpoint security centrally managed to monitor and force signature/agent updates?](https://insuranceposture.com/questions/endpoint-and-patching/endpoint-security-centrally-managed-monitor-force-signature-agent-updates) - [Is port-level network access control (e.g. 802.1X) used to admit only approved devices?](https://insuranceposture.com/questions/network-and-logging/port-level-network-access-control-admit-only-approved-devices) --- Insurance Posture by SecValley. https://insuranceposture.com The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished. SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact. Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.