Microsoft PL-300: Intune Compliance Policy Design

An Intune compliance policy is an evaluation contract: a managed device either satisfies the organization’s required conditions or it does not. The design becomes useful when those conditions are risk-based, platform-aware, measurable, and connected to a clear remediation path. A long list of settings that nobody can explain creates support noise without necessarily improving access security.

Compliance is especially important because Microsoft Entra Conditional Access can consume the result and require a device to be marked compliant before allowing access to protected resources. That makes a compliance policy more than an endpoint report. It can become an input to an identity decision. The companion article on Conditional Access explains the enforcement side; this article focuses on creating a reliable device signal.

Candidates preparing for MD-102 should be able to distinguish compliance from configuration, choose sensible settings per platform, handle noncompliance over time, and monitor the policy lifecycle. These skills sit naturally inside the broader Microsoft security model because endpoint health only matters when its meaning is consistent and trustworthy.

Define the risk statement before the setting

Start with what the organization is trying to prevent. “Devices must use encryption” is easier to defend than “turn on every available compliance setting.” Encryption protects data at rest. A minimum operating-system version can keep unsupported or vulnerable builds out of protected services. A maximum OS version may be useful during controlled rollout if a new release breaks a critical application. Each setting should map to a consequence the security or application owner understands.

Document whether a rule is mandatory for access, informative for reporting, or temporary during a migration. This prevents policy accumulation. A control added for a one-time incident can quietly become permanent and continue blocking users years later if nobody owns its removal.

Use separate policies when different device populations genuinely have different requirements. Corporate Windows workstations, frontline shared devices, mobile platforms, and specialized systems may not expose the same compliance signals. Consistency means comparable risk outcomes, not forcing every platform to use identical settings.

Keep compliance separate from configuration intent

Configuration profiles attempt to establish desired state. Compliance policies evaluate state. If BitLocker is required, a configuration profile may enable encryption while the compliance policy checks whether the device is encrypted. The distinction matters because remediation and access decisions should be based on observed state rather than the assumption that a configuration command succeeded.

This separation also helps troubleshooting. If a device is noncompliant, administrators can ask whether configuration failed, the user has not completed a required action, the device has not checked in, or the compliance rule is evaluating a different signal than expected. Treating configuration and compliance as one concept hides these failure modes.

For the Endpoint Administrator role, the strongest designs pair configuration with verification but keep the policies independently understandable. That lets operations change how a setting is deployed without rewriting the business meaning of compliance.

Review tenant-wide compliance settings first

Intune has tenant-level compliance behavior that affects every platform policy. One of the most consequential choices is how to treat devices that have no compliance policy assigned. If they are considered compliant, a newly enrolled or mis-scoped device can potentially satisfy a Conditional Access requirement before an intended policy evaluates it. Many security-focused environments therefore choose to mark devices without a compliance policy as noncompliant.

The compliance status validity period also matters. It determines how long a device can go without successfully reporting its compliance state before Intune treats it as noncompliant. A shorter period reduces stale trust but can disrupt devices that legitimately connect infrequently. Choose the period from the risk and operating model instead of leaving the default unexamined.

Changes to these tenant settings have broad effects. Pilot and communicate them like any other security control, especially if Conditional Access consumes the resulting compliance signal.

Choose platform settings that can be remediated

A policy that blocks access without telling the user how to become compliant creates tickets rather than security. For each rule, define the expected remediation. Update the operating system, enable encryption, set a secure password, remove a rooted state, resolve a Defender risk finding, or run a custom remediation process. If no practical action exists, decide whether the rule belongs in compliance or in monitoring.

Use custom compliance where supported only when built-in settings cannot express an important requirement. Custom scripts and JSON definitions expand what can be measured, but they also add code ownership, testing, versioning, and troubleshooting responsibilities. A fragile script can make hundreds of healthy devices appear noncompliant.

Keep user-facing text concise. Company Portal should help a user or technician understand the next action. Avoid exposing internal threat language when a simple statement such as “Update Windows to the required version” is enough.

Design actions for noncompliance as a timeline

Every compliance policy automatically marks a failing device noncompliant, but Intune can also perform time-ordered actions such as user notifications. Use the timeline to match urgency. A lost encryption state or active high-risk signal may deserve immediate access restriction. A routine OS maintenance requirement may allow a grace period with reminders before access is affected.

Be careful not to treat grace periods as universal. The delay belongs to the compliance action plan, while Conditional Access enforces the current compliance result. If a rule marks the device noncompliant immediately, a Conditional Access policy that requires compliance can block immediately even if a later email is scheduled. Test the complete interaction between compliance evaluation and access enforcement.

Communicate deadlines in business terms. Users respond better to “update by Friday to keep access to Microsoft 365” than to a list of policy object names. The technical schedule and the change-management message should describe the same event.

Scope assignments with the same care as settings

A perfect policy assigned to the wrong population is still a failed control. Use groups and filters deliberately, and maintain a documented inclusion model. Filters can help distinguish corporate versus personal devices, ownership, model, enrollment profile, or other supported attributes without creating hundreds of static groups.

Watch for gaps between enrollment and policy assignment. Newly enrolled devices need to receive the correct compliance rules quickly enough that the organization does not rely on undefined state. Review assignment failures and the population of devices showing no applicable policy.

Pilot assignments should include representative hardware and user scenarios, not only IT staff. Shared devices, remote users, replacement devices, and recently upgraded operating systems often reveal timing or platform differences that a small administrative pilot misses.

Monitor compliance as an operational service

Use Intune reporting to track overall compliance, policy-level failures, setting-level failures, stale devices, and recurring problem categories. A rising failure rate after a policy change is a signal to investigate whether risk actually increased or the rule was deployed badly. Operations should be able to separate true security exceptions from configuration defects and reporting delays.

Review exceptions periodically. Devices excluded for testing, executives, acquisitions, or unsupported applications have a habit of becoming permanent. Record the reason, owner, compensating control, and expiration date for any exception that bypasses normal compliance expectations.

The MS-102 perspective is useful because endpoint compliance feeds a broader Microsoft 365 control plane. Device state, identity policy, application access, and governance should be reviewed together rather than as independent dashboards.

Measure success by trusted access decisions

The goal is not a green compliance percentage. A tenant can show 99 percent compliant while important devices have no assigned policy or while rules check low-value settings. Success means the compliance signal accurately separates devices that meet the organization’s minimum trust requirements from those that do not.

Test both directions. A healthy device should become compliant and gain expected access. A deliberately broken test device should become noncompliant and lose access where policy requires it. Then remediate the device and verify that the signal recovers without manual administrative intervention.

When compliance behaves predictably, the organization gains a reusable security primitive. Microsoft platforms can consume that device trust in identity decisions while endpoint teams retain a clear process for configuration, remediation, monitoring, and exceptions.

Use custom compliance sparingly and engineer it like code

Windows and Linux scenarios can use custom compliance when built-in checks do not represent an important organizational requirement. The mechanism adds a discovery script and a JSON definition that maps detected values to compliance rules. That flexibility is powerful, but it means the compliance service now depends on code that your organization owns.

Treat that code as a production component. Version it, review it, test expected and unexpected device states, handle missing commands and timeouts, and make output deterministic. A script that returns malformed data or assumes a particular local path can turn healthy endpoints into a mass compliance incident. Keep custom checks narrow enough that a support technician can still explain why a device failed.

Before creating a custom rule, ask whether the requirement belongs in configuration, Defender risk, inventory, or application control instead. Compliance should represent access-relevant device health. Turning it into a generic inventory engine makes the signal harder to trust and harder to connect to an enforcement decision.