Modern endpoint trust is not one control. Microsoft Intune compliance evaluates whether a managed device meets defined requirements, Microsoft Entra Conditional Access uses that compliance signal when deciding whether a user can access resources, and Windows LAPS reduces the risk of reusable local administrator passwords. The current MD-102 scope connects these capabilities because secure endpoint operations require both access enforcement and local privilege control.
SC-300 adds the identity perspective: Conditional Access is a Microsoft Entra decision engine, not an Intune feature that blocks traffic by itself. Intune supplies device and app signals. The existing explanation of Conditional Access provides the identity-policy background, while endpoint administrators need to understand how compliance state and LAPS fit into that access decision.
Compliance policies define the minimum acceptable device state
Intune compliance policies evaluate settings such as operating-system version, encryption, firewall, antivirus, Defender risk, password or PIN requirements, and other platform-specific conditions. The device reports its state to Intune, which calculates a compliance result. Compliance is therefore an assessment signal, not a configuration profile.
A device can be configured by Intune and still be noncompliant if it drifts, misses updates, disables protection, or exceeds the allowed risk threshold. Keep configuration and compliance goals aligned but separate: configuration tries to set the desired state, while compliance verifies whether the current state satisfies the access requirement. That distinction makes troubleshooting much clearer. Conversely, a compliance policy does not necessarily fix the device; actions for noncompliance, configuration policy, scripts, or user remediation may be needed to return it to an acceptable state.
Tenant-wide compliance settings influence every policy
Intune includes compliance-policy settings that affect how the service interprets device state. One important setting controls whether devices without an assigned compliance policy are considered compliant or not compliant. Organizations that use compliance with Conditional Access should review this carefully so an unmanaged policy gap does not become an implicit allow.
Compliance validity also matters. Devices that stop checking in can become noncompliant after the validity period expires, which is important for lost laptops, stale devices, or endpoints disconnected from management. Tune the validity period to balance risk with the realities of travel, offline work, and device-check-in behavior. Devices must report successfully within the configured validity period or they can become noncompliant. A device that has been offline for weeks should not keep an indefinitely trusted posture merely because it was healthy the last time Intune saw it.
Conditional Access consumes the compliance signal
Microsoft Entra Conditional Access can require a device to be marked compliant before granting access to selected resources. Intune sends the compliance result to Entra; Entra evaluates that signal with user, app, risk, location, authentication, device platform, and other policy conditions.
Keep the responsibilities separate when troubleshooting. Use Intune device compliance reports to identify the failed setting, then use Entra sign-in and Conditional Access logs to confirm how that status influenced access. This prevents help desks from changing Conditional Access when the real problem is a disabled firewall or an overdue OS update. If Intune says the device is noncompliant, fix the endpoint or compliance policy. If Intune says compliant but access is denied, inspect the Conditional Access result and other grant controls. This layered model makes it possible to enforce device trust without embedding resource-access logic in every application.
Deploy Conditional Access in report-only mode before enforcement
Device-based Conditional Access can lock out users if policies are broad or compliance coverage is incomplete. Roll out in rings, test supported platforms, and validate enrollment pathways so new devices can still reach the services needed to become compliant. An access policy should not block the onboarding process that creates the trusted device state. Microsoft recommends evaluating Conditional Access in report-only mode before switching the policy on. Confirm that intended devices report compliance and that emergency access accounts are excluded appropriately.
Service accounts and workload identities need separate treatment. User-scoped Conditional Access policies do not automatically protect every noninteractive identity. Use managed identities or workload-identity Conditional Access where appropriate instead of forcing automation through user accounts that were excluded merely to keep scripts running.
Use compliance actions to guide remediation, not only block access
Every compliance policy can mark a device noncompliant immediately, and administrators can configure additional actions such as notifications or grace periods depending on platform and policy. The goal is to give users and help desks a path back to compliance rather than create a mysterious access failure.
Provide clear Company Portal guidance, support instructions, and remediation automation for common problems. Use grace periods only where business risk allows them, and monitor which settings create repeated noncompliance. A high volume of the same failure may indicate a configuration problem or an unrealistic compliance rule rather than widespread user negligence. Compliance improves security only when the organization can distinguish a malicious or unsafe device from a device that simply missed a configuration update.
Windows LAPS removes shared local administrator passwords
Windows LAPS automatically manages a local administrator password on supported Windows devices and can back the password up to Microsoft Entra ID or Active Directory depending on configuration. Intune manages Windows LAPS through endpoint security account-protection policy.
Each managed device receives its own rotated password instead of relying on one shared local administrator credential across the fleet. Configure password age, complexity, backup directory, and post-authentication actions according to the risk model. If the password is used during support, rotation should occur promptly so the retrieved credential does not remain valid longer than necessary. This reduces lateral movement because compromise of one device’s local administrator password does not automatically unlock every other machine.
LAPS should support recovery, not permanent local-admin use
Windows LAPS is best treated as a controlled recovery mechanism. Restrict who can retrieve the password, audit retrieval, rotate after use, and use role-based permissions so help-desk staff receive only the access they genuinely need.
Do not add large user groups to local Administrators simply because LAPS exists. LAPS protects the managed local account; it does not correct excessive membership in other local groups. Monitor local administrator membership through Intune policy and endpoint security tooling, and remove legacy group assignments that bypass the intended least-privilege model. Standard users should remain standard users. Where approved tasks need elevation without permanent admin membership, capabilities such as Endpoint Privilege Management can provide a more targeted model.
Defender risk can strengthen device compliance
Intune can integrate with Microsoft Defender for Endpoint so a device risk score contributes to compliance. A machine showing active security risk can become noncompliant, and Conditional Access can then block or restrict its access while the security team investigates and remediates.
This creates a closed feedback loop: endpoint threat signals affect access, remediation reduces the risk state, Intune reevaluates compliance, and Entra can restore access. Current 2026 Windows behavior also supports faster client-driven reevaluation for selected compliance signals, which can reduce the time between fixing firewall, BitLocker, Defender, or OS state and regaining access.
Design one endpoint-trust operating model
Compliance, Conditional Access, and LAPS solve different problems: compliance describes device health, Conditional Access decides resource access, and LAPS protects local administrator credentials. They should be operated together but not conflated.
Define policy owners, escalation paths, emergency access, password-retrieval roles, compliance monitoring, and remediation metrics. Track noncompliant-device age, access denials caused by compliance, LAPS password retrieval, and local-admin membership changes. Those metrics reveal whether endpoint trust is reducing risk or simply generating support tickets. The strongest endpoint-trust design makes access conditional on current device health while also minimizing the standing local privilege that attackers can reuse after they reach the endpoint.
Test the complete device-trust loop with representative failure cases: outdated OS, disabled firewall, high Defender risk, stale check-in, missing compliance policy, and a help-desk LAPS retrieval. Confirm that Intune reports the expected state, Entra Conditional Access makes the intended decision, users receive understandable remediation guidance, and local administrator credentials rotate after use. End-to-end testing is more valuable than validating each policy screen independently because access failures usually cross product boundaries.
LAPS retrieval should be rare enough to review individually. If help-desk teams retrieve many local administrator passwords every day, the organization may be compensating for poor application packaging, missing remote-support capability, or excessive reliance on manual administration. Use retrieval telemetry to identify recurring support patterns and replace them with safer managed workflows where possible.
Compliance policy should also avoid contradictory requirements across overlapping assignments. A device that receives several compliance policies can be marked noncompliant if any required setting fails. Keep policy scope understandable, document exceptions, and test users who belong to multiple assignment groups so endpoint trust does not become an unpredictable result of group overlap.
Review compliance and LAPS telemetry together during endpoint-security audits.
Audit both regularly.
Compliance architecture should account for overlapping assignments. A device that receives several compliance policies can become noncompliant if any required setting fails, so keep policy scope understandable and test users who belong to multiple groups. Document exceptions and temporary grace periods with owners and expiry dates. Otherwise support teams may see only the final noncompliant state without knowing which organizational policy created it.
Test the complete trust loop with representative failures: outdated OS, disabled firewall, suspended BitLocker, high Defender risk, stale check-in, no compliance policy, and a LAPS password retrieval. Confirm that Intune reports the intended device state, Entra applies the expected Conditional Access result, users receive actionable remediation instructions, and the local administrator credential rotates after use. End-to-end testing is more valuable than validating each product screen independently because real access failures cross service boundaries.
LAPS retrieval frequency is itself a useful security metric. If help-desk teams retrieve many local administrator passwords every day, the organization may be compensating for weak application packaging, missing remote-support capability, or excessive manual administration. Review retrieval logs and recurring use cases, then replace repetitive local-admin workflows with managed applications, Remote Help, Endpoint Privilege Management, or another controlled mechanism where appropriate.