Microsoft PL-300: Conditional Access with Intune

Conditional Access and Microsoft Intune solve different parts of the same access decision. Intune evaluates whether a managed device meets the organization’s compliance requirements. Microsoft Entra Conditional Access uses that compliance signal together with user, application, platform, location, risk, authentication, and session context to decide whether access should be granted. The architecture works only when those responsibilities stay distinct.

A common failure is to treat “require compliant device” as a single switch that automatically creates endpoint security. It does not. The compliance policy has to evaluate meaningful device state, the device must report that state, Entra must receive the result, and the Conditional Access policy must target the correct users and resources. The identity and security model is therefore a chain of signals and enforcement points, not one policy object.

For candidates studying MD-102 or SC-300, the important skill is designing that chain so a noncompliant endpoint loses access predictably without locking administrators out, breaking enrollment, or confusing users with policies that contradict one another.

Start with the compliance signal you actually need

Intune compliance policies should measure conditions that matter to the organization’s risk model. Examples include supported operating-system versions, encryption state, password or device-lock requirements, rooted or jailbroken status, Microsoft Defender risk signals, or custom compliance checks where supported. Avoid adding settings simply because the console offers them. Every requirement should have an owner, a remediation path, and a reason that failing it changes access risk.

Compliance is not the same as configuration. A configuration profile sets or attempts to set a device state. A compliance policy evaluates whether the resulting state meets a rule. Some settings overlap conceptually, but the operational questions differ: configuration asks “what should the device be configured to do?” while compliance asks “is this device acceptable for access right now?” The dedicated compliance policy discussion goes deeper into that distinction.

Also review the tenant-wide setting for devices with no compliance policy assigned. If unassigned devices are treated as compliant, a Conditional Access policy that requires compliance can provide less assurance than administrators expect. The policy assignment model and the tenant defaults are part of the security boundary.

Build Conditional Access around target resources

Device compliance should be required where a managed endpoint materially reduces risk. That often includes Microsoft 365, administrative portals, line-of-business SaaS applications, or sensitive data services. Scope by resources deliberately instead of creating a collection of overlapping policies whose combined effect nobody can predict. Microsoft increasingly recommends policies that target all resources when the control is broadly appropriate, with careful exclusions for accounts and flows that truly need them.

Use report-only mode before enforcement. Review sign-in logs, Conditional Access insights, device platforms, client types, and failure reasons. Report-only does not prove the final user experience in every case, but it reveals whether the policy targets unexpected identities or resources before it starts blocking them.

Keep emergency-access accounts outside policies that could prevent recovery from a tenant-wide mistake. Those accounts should be tightly controlled and monitored rather than used for daily administration. Exclusion is not permission to ignore them; it is a resilience control for the identity system itself.

Understand what “compliant” means at sign-in time

Intune reports a device’s compliance state to Microsoft Entra ID. Conditional Access then evaluates that signal when the client can present a device identity that Entra recognizes. A device can be well configured yet fail the access rule if the sign-in does not carry the expected device context. Browser choice, registration state, platform support, and enrollment all influence whether the device can satisfy the grant control.

This is why troubleshooting should separate three questions: Did Intune evaluate the device? Did Entra receive and associate the compliance result with the correct device object? Did the sign-in present that device in a way Conditional Access could evaluate? Jumping directly to the Conditional Access policy often misses an enrollment or registration problem earlier in the chain.

Administrators working toward the Endpoint Administrator role need both views. Endpoint management shows why the device is compliant or not; Entra sign-in logs show why access was granted or denied.

Use authentication strength and device trust together

A compliant device should not replace strong user authentication. Device trust and authentication answer different questions. One says the endpoint meets management requirements; the other says the person or workload proved identity with an acceptable method. High-value resources often warrant both, especially for administrators or sensitive operations.

Conditional Access grant controls can combine requirements. The design should reflect consequence rather than applying maximum friction everywhere. A low-risk browser session might require multifactor authentication, while privileged administration could require a compliant device plus a phishing-resistant authentication strength. A finance application could add location or session constraints if the business risk justifies them.

The important architectural point is composition. Conditional Access is strongest when identity, device, risk, and resource sensitivity contribute independent evidence instead of one signal being stretched to solve every security problem.

Stage enforcement so remediation remains possible

If a device becomes noncompliant, the user still needs a path to understand and fix the problem. Compliance actions can notify users or introduce grace periods, while Conditional Access controls access to protected resources. Decide which failures should block immediately and which should allow time for remediation. A missing critical security control may justify immediate restriction; an aging OS build might have a planned warning period before enforcement.

Test the enrollment and remediation journey before targeting all users. A policy that requires compliance must not accidentally make it impossible for a legitimate user to enroll the device or reach the management tools needed to become compliant. Microsoft explicitly notes that the compliant-device grant control does not block Intune enrollment, but surrounding controls can still complicate onboarding if they are not tested together.

Pilot with representative platforms and user types. Include remote users, administrators, newly enrolled devices, replacement devices, and common browser/app combinations. Endpoint access policies fail operationally when the pilot contains only IT staff using one standard Windows build.

Keep policy responsibilities small and explainable

Conditional Access becomes difficult to operate when one policy contains every possible condition and exception. Prefer a set of policies with clear purposes: require compliant devices for defined resources, require stronger authentication for administrators, block unsupported platforms, or apply session controls to specific use cases. Naming should state the purpose and scope so sign-in logs are understandable during an incident.

At the same time, avoid unnecessary policy fragmentation. Ten policies that all target the same users and applications with slightly different conditions can create emergent behavior that is harder to predict than one well-designed rule. Maintain a policy matrix showing targeted identities, resources, conditions, grant controls, exclusions, owner, and reason.

The same discipline applies to Intune. Platform-specific compliance rules should be understandable enough that support teams can explain why a device failed. Security improves when help-desk remediation and identity enforcement use the same vocabulary.

Monitor the signal path continuously

Compliance is dynamic. Devices stop checking in, certificates expire, operating systems age out, risk levels change, and users replace hardware. Monitor the Intune compliance dashboard, stale-device behavior, policy assignment errors, and Entra sign-in failures. A design that worked at rollout can weaken silently if devices without policy assignment are treated as compliant or if an important population is excluded from scope.

Review the compliance-status validity period because a device that stops reporting can eventually become noncompliant. This protects against indefinitely trusting stale state, but it can also affect intermittently connected devices. The value should match the operational reality and risk of the environment.

Conditional Access with Intune is successful when access decisions remain explainable from device state through sign-in policy. That chain is foundational to both identity administration and modern endpoint operations: measure the endpoint, protect the identity, target the resource, and keep enough evidence to explain every block.

Plan separately for managed, registered, and unmanaged endpoints

Not every endpoint should be forced through the same device-control path. Corporate Windows devices might be fully enrolled and evaluated by Intune, while personally owned mobile devices may be governed through app protection and a different Conditional Access grant. Browser-only access from an unmanaged endpoint might be blocked for sensitive services or limited through session controls. Design these patterns explicitly so exceptions do not turn into accidental bypasses.

Keep the policy taxonomy aligned with ownership and management state. A requirement for a compliant device makes sense only where the platform and enrollment model can produce that compliance signal. If contractors, partners, or specialized endpoints cannot enroll, decide whether they need a separate resource scope, a different authentication and session model, or no access at all. Do not add broad exclusions merely to make failures disappear.

This separation also makes the user experience easier to support. Help-desk staff should know whether a blocked user is expected to enroll in Intune, use an approved app, switch to a managed workstation, or request a business exception. Endpoint control becomes part of platform operations when the access path is documented as clearly as the technical policy.