A modern endpoint can be successfully enrolled, fully patched and still inappropriate for access to a sensitive application if the risk context has changed. Equally, a healthy managed laptop may be blocked because a compliance signal never reported correctly. The distinction between policy intent and observed device state lies at the heart of Microsoft MD-102 scenarios about compliance and Conditional Access. Microsoft Intune assesses device posture against configured requirements, while Microsoft Entra Conditional Access evaluates access conditions and can require the device to be marked compliant. These are complementary layers rather than two names for the same setting.
Imagine a sales organization accessing confidential customer records. Company laptops must use supported operating systems, encryption and appropriate endpoint protection. Employees may also use approved personal devices for limited workloads. The identity system should not grant broad access simply because a password and second factor are valid; it must consider which application is requested and whether the device meets the agreed trust standard. But enforcing “require compliant device” for everyone before devices can report compliance risks breaking the business. A reliable design starts with the data and users, then pilots the policy and tests exceptions deliberately.
Separate device health from access decisions
Intune compliance policies evaluate specified properties for supported platforms. Common considerations include minimum OS version, encryption, password or lock requirements and device threat signals where supported integrations are configured. Each platform may expose different capabilities. The outcome of evaluation can contribute to a compliant or noncompliant status that Conditional Access uses. Administrators must know exactly what a policy checks, how often evaluation occurs and whether a device has reported the required evidence. An enrolled device is not compliant by definition.
Conditional Access policies combine subjects, targeted resources, conditions and grant or session controls. They can require a device to be compliant, require appropriate authentication strength or enforce other access constraints. The system applies policy at sign-in and relevant session evaluations, not as a magical continuous inspection of every endpoint activity. A correct configuration depends on targeting users and apps accurately and understanding how multiple policies combine. The explanation of Microsoft Entra Conditional Access is a useful foundation; endpoint administrators must then translate its principles into a practical device compliance rollout.
Use an access diagram to follow a sign-in: the user authenticates, the client and device present identity signals, applicable Conditional Access policies are evaluated, and required controls either succeed or prevent access. A compliant status can be necessary without being sufficient if another control requires stronger authentication. Conversely, a policy that does not target the application cannot protect it even if every device is compliant. Troubleshoot the actual matched policies and status, not a single green or red icon in the device portal.
Design compliance policies by risk and platform
Begin with a small set of business requirements. A regulated finance team might need corporate ownership, encryption, current support status and monitored endpoint protection. A low-risk collaboration tool on a personal phone may use different information-protection controls. Configure device compliance rules that the chosen platforms can actually report. Requiring a signal unsupported on a class of devices can produce mass failures; ignoring unsupported platforms can inadvertently create a gap. Test each platform with real hardware and representative ownership modes before global targeting.
Noncompliance consequences deserve explicit planning. Intune can mark a device noncompliant and administrators can configure actions such as notifications or other policy-dependent steps; Conditional Access then uses the status for protected resources. Immediate blocking may be appropriate for severe compromise but disruptive for a newly enrolled laptop that has not finished evaluation. Define grace periods and remediation instructions in ways that match security risk. Users need a clear explanation of what failed and what action is safe, not a generic error encouraging them to reinstall the management app repeatedly.
Consider conflicting policies. A user might belong to several groups with different requirements, or a device may have configuration controls that interfere with compliance collection. Document assignment rules and evaluate effective policy rather than assuming the last edited profile wins. Use scope tags and administrative roles to separate management responsibility, but remember that delegated administration itself must be governed. The Microsoft SC-300 identity and access context can help teams responsible for the identity side of the boundary; MD-102 remains focused on configuring and supporting the endpoint signals.
Roll out Conditional Access without locking out the organization
A safe deployment sequence begins with policy design, representative pilot populations and report-only evaluation. Exclude designated emergency access accounts according to the organization’s tested break-glass approach; protect those accounts with strong compensating controls and alert on use. Check that the pilot includes remote workers, administrators, mobile platforms and device states that are legitimately different. Broadly requiring compliance without first establishing Intune policies and a working compliant device population can cause avoidable lockouts.
Report-only mode helps reveal what would have happened, but it does not prove every business process will continue under enforcement. Some legacy clients, service accounts or shared-device workflows may surface only under live use. Confirm sign-in logs, policy results and remediation pathways. When moving to enforcement, expand gradually with a clear rollback owner and a predefined threshold for stopping the rollout. Avoid building endless permanent exclusions in response to every support ticket; investigate whether the exception reflects a legitimate design requirement or an underlying device-management failure.
Dependency management is vital. If the identity or device management service is unavailable, the organization needs to know which sessions remain usable and how essential staff can operate within approved continuity procedures. A compliance requirement that blocks the very service needed to fix a device is difficult for users, though Microsoft’s supported enrollment flows include mechanisms intended to permit new enrollment even under certain compliance requirements. Validate your exact policies and clients rather than generalizing from one happy-path test. Documentation and emergency support channels must remain accessible when ordinary cloud access is restricted.
Understand how signals become stale or misleading
Device state is not instantaneous. A new compliance requirement may take time to be evaluated, and a laptop that has been offline can show stale posture information until it checks in. Set policies around appropriate validity and remediation rather than assuming continuous real-time certainty. A device might report encryption enabled while a separate compromised account is used elsewhere. No single compliance indicator proves an entire session is trustworthy. Combine posture, sign-in risk, application authorization and monitoring according to the sensitivity of the protected activity.
Integration with endpoint detection services adds useful context, but may have prerequisites, platform coverage differences and latency. A device reported at risk should trigger a predictable response path, including what the user sees and how security staff validate and clear the event. If a device is removed from quarantine without the underlying detection resolving, the policy process can cycle endlessly. Define owners across endpoint operations, security response and identity administration. Operational handoffs are part of control effectiveness, not merely ticket-routing convenience.
Logs must establish why access was blocked. Capture correlation identifiers, device identity, evaluated compliance state, applicable policy and time of evaluation. Support teams should not ask users to disable security products or export sensitive tokens as a first troubleshooting step. An audit should also be able to distinguish an access denial caused by real noncompliance from a deployment mistake. Both appear as blocked access to the user, but they require very different corrective actions.
Protect exceptions and administrative pathways
Exceptions create an alternate trust boundary and should be treated as such. A device that cannot meet a standard may need a limited virtual desktop, browser-only session or supervised access channel rather than full unrestricted exemption. Record the reason, scope, owner and expiration of an exception. Separate emergency access from routine help-desk permissions, and monitor changes to the policies that govern high-value applications. An attacker who can alter policy assignments can undermine protection even if every endpoint is healthy.
Conditional Access is not the application authorization layer. A user on a compliant machine may still lack permission to export a financial report or change another employee’s data. Application services must enforce record and action authorization themselves. The same is true of local administrator rights on managed endpoints. An organization that focuses exclusively on sign-in posture can overlook overprivileged apps, weak API scopes and insecure local management paths. The principle behind role-based access control remains essential after an access session is established.
Governance should include change review and regular testing. A policy alteration can affect thousands of devices and business applications. Pilot assignment changes, review effective scope and require appropriate approval for high-impact exclusions. Maintain a small set of diagnostic scenarios: a compliant corporate laptop, an unencrypted laptop, a supported personal device and a device that has lost management contact. Re-run them after major tenant or platform changes. You should be able to predict the expected grant or denial before opening the sign-in logs.
Read MD-102 scenarios as a chain of responsibility
When a question says users are blocked, do not jump immediately to disabling Conditional Access. Determine whether the device is enrolled, which compliance policy applies, what it reported, which Conditional Access policies target the resource and whether the user has an approved remediation route. When the question asks for stronger security, begin with the application’s sensitivity and the specific control gap. That approach also prevents confusing app protection policies with device compliance requirements, which may solve different problems on personally owned endpoints.
For operational reporting, measure successful protected sign-ins, genuine policy violations, false blocks, remediation time, aged exceptions and lost-device response. Avoid treating an ever-higher block count as security success. The goal is authorized access from appropriate devices and reliable denial when requirements are not met. Intune and Conditional Access work well together when the organization’s policies are clear, device signals are trustworthy enough for the risk and support teams can explain the outcome to an affected user.