Reviewing a managed IT provider’s compliant-device access rollout: what evidence should you ask for?
Your managed IT provider says it has rolled out “compliant-device access”. What would help you decide whether the work matches the access decision your business agreed to make?
Recommendation: ask to see three things together: the device requirements and reported status, the access policy’s scope and controls, and the assessment made before enforcement. A view showing compliant devices cannot, on its own, tell you which people and resources an access policy covers. Microsoft describes device-compliance evaluation in Intune and a separate Conditional Access policy in Microsoft Entra that can use the resulting status. Microsoft: device-based Conditional Access
This is a service-review conversation, not a universal configuration checklist. Agree on the intended access decision first, then ask the provider to connect each piece of evidence to it. For related service context, see Q360’s managed IT services overview.
1. What does “compliant” mean for your devices?
Intune compliance policies define rules for evaluating managed devices and can be assigned to user or device groups. Microsoft also describes a separate tenant-wide setting for how devices without an assigned compliance policy are treated. Microsoft: device compliance policies
Recommendation: request a readable summary of the configured requirements, intended assignments and an appropriately redacted status view. Ask which device populations were meant to receive a policy, which have not received one and when the status was captured. Ask to see the setting for devices with no assigned policy alongside any headline compliance count. That keeps the discussion focused on whether devices in your agreed scope were assessed, rather than only how many show a favourable status.
You can ask for this explanation without requesting an unfiltered export of employee names or device identifiers. Useful review questions include:
- Which requirements were chosen, and why do they fit the agreed scope?
- Which devices have not received a policy or need further investigation?
- Who will explain exceptions to the business and own the follow-up?
The useful answer is specific to your environment. Do not treat an example requirement as something every organisation must adopt.
2. Which access decisions use that status?
A device’s compliance status is only one part of the review. Microsoft’s device-based Conditional Access guidance separately describes included and excluded identities, target applications and grant controls. For the compliant-device grant decision described there, it specifies Require device to be marked as compliant. Microsoft: device-based Conditional Access
Recommendation: ask for a policy summary identifying the intended people, protected resources, exclusions, grant requirement and current policy state. Ask your provider to explain one access situation that falls within the agreed scope and one that falls outside it. A statement that “Conditional Access is enabled” does not answer those questions.
Exclusions deserve their own conversation. Microsoft recommends excluding emergency-access accounts to reduce the risk of administrative lockout. Microsoft: require device compliance Recommendation: ask who authorised each relevant exclusion, why it exists and when it will be reviewed. An exclusion may serve an agreed purpose, but the review record should make clear that an excluded identity is not subject to that policy. Microsoft: device-based Conditional Access
3. What did the provider learn before enforcement?
In Microsoft’s example deployment, a device-compliance Conditional Access policy is set to Report-only first; its impact is reviewed before the policy is moved to On. That guidance also says an Intune compliance policy should be created and at least one compliant device should be available before proceeding with the example. Microsoft: require device compliance
Recommendation: request a redacted account of the assessment. What people and resources were in scope? What unexpected results appeared? Which changes followed, and who accepted any remaining exceptions? Ask separately for the policy’s current state. Report-only findings may inform an enforcement decision, but Report-only and On are different states. Microsoft: require device compliance
If open issues remain, record them as open issues. Agree on owners and the evidence needed for another decision rather than treating a configured policy as proof of a completed rollout.
4. What if the evidence does not match the agreed scope?
Consider two illustrative scenarios, not customer outcomes. First, the device-status view looks healthy, but an application you expected to protect is absent from the access-policy summary. Microsoft’s guidance identifies target resources as a separate access-policy choice. Microsoft: device-based Conditional Access Second, the access policy names the intended resource, but devices you expected to assess have no assigned compliance policy. Microsoft documents a tenant-wide setting that determines how devices without an assigned policy are treated. Microsoft: device compliance policies
Recommendation: use the first mismatch to revisit access-policy scope and the second to revisit device-policy assignment and the no-policy setting. Neither example establishes what has happened in your environment.
Finish with a short review record: the intended access decision, the evidence examined, unresolved differences, follow-up owners and the policy’s current state. Ask your provider to explain the result in business terms: who should be able to reach which resources, under what device condition, and what remains outside this rollout? That is a clearer basis for a sign-off decision than a single dashboard view.
Want to discuss how endpoint management and IT compliance alignment fit your managed IT needs? See what Q360 offers.
#ManagedIT #MicrosoftIntune #ConditionalAccess #Q360