Block sign-ins from unknown or unsupported device platforms by creating a Conditional Access policy that targets device platforms and denies access for platforms you do not allow. Leave room for testing and exception handling, because some browsers or operating systems may report as unknown. Check sign-in logs to confirm which platforms are being blocked.
conditional access is often the right control when you need to stop sign-ins from platforms you do not trust, but the policy has to be written around the device platform signal itself. That means defining the platforms you allow, then denying the rest, while making sure you have a tested path for legitimate edge cases such as browsers or operating systems that report as unknown.
Because this is a platform-screening control rather than a device-compliance control, the main operational question is whether the platform claim is reliable enough to use for enforcement. In practice, that means checking sign-in logs, testing report-only or pilot coverage first, and deciding what to do with devices that cannot present a stable platform signal.
For a policy pattern and rollout approach, the Conditional Access Guide covers policy design, report-only testing and gap analysis, which are the core steps before moving a platform block into enforcement. If your environment also depends on device trust, the Device Trust and Posture Guide helps separate platform filtering from posture-based access so you do not mix the two controls.
How the platform block works in Conditional Access
A device platform condition lets you target sign-ins based on the operating system or client platform reported during authentication. The practical use case here is simple: permit the platforms you support, then deny the ones you do not. That can help reduce exposure from unsupported operating systems, unmanaged endpoints, and environments you have not validated for security or compatibility.
The control is only as good as the platform signal. Some sign-ins may show up as unknown because the browser, device, or client stack does not expose a clean platform identifier, or because the sign-in path does not reliably provide one. That is why platform blocking should be treated as a policy control that needs observation, not as a one-time checkbox. The Microsoft 365 Security Guide is useful here because it ties Entra sign-in controls to the surrounding hardening and audit workflow.
If you are managing access across a broader identity stack, device platform filtering is most effective when it is aligned with your identity provider settings and session controls. The Identity Provider and SSO Security Guide is relevant because sign-in policy outcomes often depend on the trust chain, session handling, and federation behaviour upstream of the Conditional Access decision.
What usually goes wrong when you block unknown platforms
The most common failure mode is overblocking. A browser may not identify itself cleanly, a newer operating system version may be misclassified, or a managed client may appear as unknown during a partial rollout. If you enforce too quickly, users can lose access before you have verified that the platform signal is dependable in your tenant and application mix.
The opposite problem is assuming that platform filtering is a substitute for device posture. It is not. A supported platform can still be unmanaged, out of date, or otherwise unsuitable for sensitive access. If you need trust in the endpoint itself, you need a separate device posture or compliance requirement. The Zero Trust Identity Guide is a good reference for understanding why policy should verify context continuously rather than rely on platform identity alone.
When you have a large or mixed endpoint estate, the risk is not just blocked access, it is inconsistent enforcement. Windows, macOS, mobile, browser-based, and legacy client paths may behave differently, so the same policy can produce different results depending on the access route. That is why sign-in logs and pilot groups matter more than the policy statement itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Platform-based sign-in restriction depends on controlled account access pathways. |
| IA-2 — Identification and Authentication (Organizational Users) | Conditional Access platform blocking is enforced during user authentication decisions. | |
| AC-19 — Access Control for Mobile Devices | Blocking unsupported platforms is a mobile and endpoint access control issue. | |
| Recommendation — Restrict account sign-in paths to approved device platforms and revoke exceptions that are no longer needed. Require trusted authentication flows before allowing sign-ins from approved platforms. Apply mobile and endpoint access restrictions that deny unsupported device platforms by policy. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | This control family covers limiting access based on approved device conditions and exceptions. |
| CIS-8 — Audit Log Management | Sign-in logs are needed to confirm which platforms are being blocked. | |
| Recommendation — Limit sign-in access to approved device platforms and document any exception process. Review authentication logs to verify blocked platforms and tune the policy from evidence. | ||
Practitioner Guidance
What to verify: Before enforcing a deny rule, confirm which sign-in paths report a stable platform value and which ones surface as unknown. Validate this separately for browsers, managed desktop clients, mobile devices, and any legacy or embedded application flows.
Decision rule: If the platform signal is consistent and the user population is known, enforce the block for unsupported platforms. If the platform is frequently unknown for legitimate users, keep the policy in testing or narrow the scope until you can distinguish real exceptions from false positives.
What to measure: Track the volume of blocked sign-ins, the share of unknown-platform events, and the users or apps affected after rollout. A sudden rise in unknown-platform blocks usually means the policy is catching more than unsupported devices, or that one client type needs an exception path.
Common mistake: Treating platform blocking as a replacement for device compliance, session control, or browser hardening. It is a coarse access filter, useful for reducing exposure, but it does not by itself prove that a device is healthy or trustworthy.
Practitioner takeaway: The safest rollout is the one that proves the platform signal first, then applies denial only where the tenant can distinguish unsupported devices from legitimate but hard-to-classify clients.
Related resources from NHI Mgmt Group
- How do you block device code flow with Conditional Access in Microsoft Entra ID?
- How do you block device code flow phishing with Conditional Access?
- Why do risky sign-ins, legacy authentication, and non-compliant devices increase the need for Conditional Access?
- Why do non-interactive sign-ins help attackers bypass Conditional Access and MFA controls?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org