Microsoft MD-102: Compliance Policies and Conditional Access

Microsoft Intune device compliance and Microsoft Entra Conditional Access are often taught together because one can provide the device-state signal that the other uses in an access decision. They are not the same control. Intune compliance evaluates whether a device meets defined requirements. Conditional Access evaluates an authentication context and applies access controls based on signals such as user, device, location, risk, application, or compliance state. Understanding that boundary is the key to troubleshooting Microsoft MD-102 scenarios.

As of October 5, 2026, candidates preparing for the Microsoft MD-102 exam should use the current Microsoft Learn scope. Microsoft has already published an updated skills outline effective October 27, 2026; candidates testing on or after that date should use the revised guide. Both versions keep Intune compliance and Conditional Access device-state decisions in scope.

The Microsoft 365 certifications show where endpoint administration sits among modern-work roles. For MD-102, the important chain is policy assignment, device evaluation, the compliance signal, Conditional Access enforcement, reporting, exceptions, and the diagnostic path when users are unexpectedly blocked or allowed.

Compliance is a device-state evaluation

An Intune device compliance policy describes conditions that a managed device should meet. Examples can include operating-system requirements, password characteristics, encryption state, threat level from an integrated security service, or other platform-specific checks. Intune evaluates the device and produces a compliance status that administrators can report on and other controls can consume.

That evaluation has timing and scope. The policy must target the right users or devices, the device must check in and report the required state, and grace periods or platform behavior can affect when a status changes. A device that appears healthy to the user can still be noncompliant because one measured requirement has not been satisfied or because the service has not received fresh evidence.

Conditional Access consumes signals to make an access decision

Conditional Access is an identity control plane. A policy evaluates an access attempt against assignments and conditions, then applies grant or session controls. Requiring a compliant device is one possible grant requirement. The policy does not perform the underlying compliance check itself; it relies on the device-state signal available through the identity and management integration.

That separation explains many incidents. If the device is incorrectly marked noncompliant, changing Conditional Access may hide the symptom but leave the compliance problem unresolved. If the device is compliant but access is still blocked, the issue may be a different Conditional Access policy, authentication strength, user or group assignment, risk condition, application scope, or another grant requirement. Troubleshooting should establish which layer produced the decision.

Policy design should make ownership and intent obvious

Compliance policies are easier to operate when each has a clear purpose and bounded scope. A single enormous policy with many unrelated requirements can make exceptions and troubleshooting difficult. Separating baseline requirements from workload- or population-specific requirements can improve clarity, provided the team understands how multiple policies combine and how a single failing requirement affects the device’s overall status.

Names, descriptions, assignments, and change records matter. An administrator investigating a blocked executive or shared device should be able to tell why a requirement exists, who owns it, and which exception process applies. Policy sprawl without documentation turns a technical control into an operational risk.

Assignments and exclusions are part of the security design

The most secure-looking policy provides little value if it is assigned to the wrong population. Compliance and Conditional Access both require careful targeting. Groups, device platforms, applications, and exclusions should reflect the intended control boundary. Broad permanent exclusions are particularly risky because they can become invisible paths around the control after the original reason is forgotten.

Safer exception design is explicit and temporary where possible. Document the business reason, approving owner, compensating control, and expiration or review date. Emergency-access accounts and break-glass procedures have their own purpose and should not become a general solution for policy problems. An exception process is part of governance, not evidence that the policy should be ignored.

Evaluation timing can make a correct policy look broken

Endpoint state is not always instantaneous. A device can be remediated locally before Intune has processed the new state, or a user can attempt access before a recent policy change has propagated through the relevant services. Troubleshooting should therefore include timestamps: last device check-in, last compliance evaluation, policy assignment change, authentication attempt, and sign-in decision.

This prevents two opposite mistakes. One is repeatedly changing a correct policy because the administrator is impatient with propagation. The other is waiting indefinitely when a device has actually stopped checking in or a configuration conflict prevents the expected setting from applying. Time is evidence when it is compared with expected service behavior and current status.

Reporting should connect the device record to the sign-in record

A compliance report tells you which requirement failed. A Conditional Access sign-in record tells you which policy evaluated the access attempt and which grant controls affected the decision. The fastest investigation correlates both views instead of reading only one. Confirm the user, device identity, compliance state, application, policy result, and time of the attempt.

Conditional Access fundamentals cover identity, device, risk, location, application, and session signals. For MD-102, the emphasis is how endpoint state enters that decision and how an endpoint administrator proves whether the problem originated in device management or access policy.

Remediation should fix the failed requirement, not merely unblock the user

If encryption is required and the device is not encrypted, the durable fix is to bring encryption into the expected state and allow the compliance signal to update. If the device is stale, restore management connectivity or enrollment health. If the wrong policy was assigned, correct the assignment. Disabling Conditional Access can restore access quickly but can also remove the security outcome the organization explicitly required.

Operational teams need an escalation path for cases where business continuity and security requirements conflict. A documented temporary exception with approval is different from an administrator silently excluding a user to make a ticket disappear. MD-102 scenarios often favor the action that preserves policy intent while correcting the underlying state.

App protection creates a second important Conditional Access pattern

MD-102 also covers Conditional Access in relation to app protection policies. This matters because organizations may protect corporate data on devices that are not fully enrolled or managed in the same way as corporate endpoints. The access decision can require an approved client application or app-protection policy instead of, or alongside, full device compliance depending on the use case.

Candidates should avoid collapsing all mobile and BYOD scenarios into “require compliant device.” The right control depends on the management model, data sensitivity, application, and organizational strategy. The skill is to recognize which signal proves the required posture and to select a policy design that the platform can actually evaluate for that device population.

MD-102 troubleshooting follows the signal chain

A reliable sequence is policy assignment, device configuration, device evaluation, compliance status, identity registration, Conditional Access evaluation, and user experience. At each stage, ask what evidence proves the expected state. That sequence turns a vague access problem into a small number of testable hypotheses and reduces the temptation to change several policies at once.

Microsoft’s October 27, 2026 MD-102 update can change the exact objective wording, but the operating principle remains useful: compliance produces a posture signal; Conditional Access uses signals to enforce access; reporting and timestamps show where the chain diverged from expectation.

Compliance policies and Conditional Access solve different parts of the problem. Intune evaluates device state against requirements such as platform, configuration, or security conditions and produces a compliance signal. Microsoft Entra Conditional Access then uses that signal alongside identity, application, risk, location, and session context to decide whether access is allowed or constrained. A device can therefore be correctly evaluated as noncompliant while the user still reaches some resources if the relevant Conditional Access policy is not assigned to that access path.

That separation is why troubleshooting should avoid editing both systems at once. First establish whether the device evaluated the intended compliance policy and why it received its current state. Then verify whether the sign-in matched the intended Conditional Access policy and what grant controls were applied. The completed Conditional Access fundamentals resource provides the wider identity-control model, while MD-102 in 2026 places compliance inside the broader endpoint-administration role.

Policy rollout is another exam-relevant operational concern. New compliance or access rules should be tested with representative devices and accounts, with exclusions documented and temporary exceptions reviewed. A rule that is technically correct can still create widespread disruption if platform support, enrollment state, stale device records, or emergency-access requirements were not considered. Good administration protects the control from becoming a self-inflicted outage.

Microsoft’s study-guide change log identifies the July 24 outline as current through October 26, with the next skills update effective October 27, 2026. The compliance-and-Conditional-Access relationship remains present in the announced revision, although exact surrounding objectives and wording can change.

One final troubleshooting clue is state freshness. Compliance depends on the device checking in and reporting information that Intune can evaluate, while Conditional Access acts during sign-in with the signals available at that time. After remediation, an administrator may need to confirm that the device has synchronized, the compliance state has updated, and a new sign-in is being evaluated. Testing with stale state can make a correct fix appear ineffective. A useful validation test follows one device from compliance evaluation through Entra sign-in logs to the Conditional Access result, confirming that the policy signal and access decision agree.