Microsoft Intune compliance as an access condition — beyond Conditional Access

If you run Microsoft Intune, you've already done the hard work: defining compliance policies, rolling them out to your fleet, getting devices to report as compliant. Entra Conditional Access then uses that signal to gate Microsoft 365 — Outlook, Teams, SharePoint, OneDrive — and any SAML / OIDC app you've wired into Entra.

That covers cloud apps. It does not cover everything else.

Your internal monitoring dashboard. The Postgres database on your homelab. The Jenkins instance behind your firewall. The Plex server. The Ansible runner. The IP camera console. The home assistant. The dev environment that lives on a teammate's laptop.

Conditional Access does not directly gate those private resources unless you put them behind an Entra-integrated access layer. Intune knows the device's compliance state — but there's no built-in way to turn that signal into "deny access to my private services until the device becomes compliant again" for everything else you run.

This post is about closing that gap.

What HostAnywhere reads from Intune

For access decisions, HostAnywhere treats Intune compliance as a simple policy signal: compliant, non-compliant, or unknown. The underlying Intune state can include richer values (conflict, error, not applicable), but for the purpose of "does this rule apply right now," we reduce it to that three-state model. Devices in a remediation grace period count as compliant — same as Conditional Access treats them — using the policies you've configured in the Microsoft Intune admin center.

HostAnywhere polls Microsoft Graph every 5 minutes and caches each device's compliance status. The status becomes a condition you can attach to any Access Control rule:

• device.posture.intune.compliant == true — device is compliant.
• device.posture.intune.compliant == false — device is explicitly non-compliant.
• Missing or unknown posture — no Intune match for this device, or no fresh compliance state. A rule that requires compliant == true will not match.

For sensitive rules, unknown posture should fail closed: if Intune hasn't reported recently or the device isn't in Intune at all, don't grant access. Default-deny at the bottom of your policy handles this naturally.

Setup

You need:

• A Microsoft Entra tenant with Intune licensed (a work or school tenant — personal Microsoft accounts aren't supported for this integration).
• A registered Entra application with Microsoft Graph DeviceManagementManagedDevices.Read.All scope.
• HostAnywhere on the Developer plan or higher.

In the HostAnywhere dashboard, Integrations → Microsoft Intune → paste the tenant ID, client ID, and client secret. We test the connection, pull the list of managed devices, and match them to HostAnywhere devices using available identifiers (hostname and Entra device ID).

Devices in HostAnywhere that aren't in Intune simply have no Intune posture state. Devices in Intune that aren't in HostAnywhere show up as warnings until you reconcile.

Example rule: gate the internal admin panel

Imagine an internal billing-admin dashboard reachable on the HostAnywhere mesh at https://billing-admin.mesh.local (running on one of your servers).

A typical rule reads as:

Allow tag:finance → device:billing-admin
on tcp/443
when device.posture.intune.compliant == true
and device.posture.crowdstrike.zta_score >= 70

A finance team member's laptop must be both Intune-compliant and have a Falcon ZTA score of 70 or higher to reach the dashboard.

If the laptop falls out of compliance because a security update is overdue, then at the next posture refresh the rule stops matching. With a default-deny policy underneath, access is denied until the device becomes compliant again. The user remediates the device, Intune marks it compliant again, and access returns automatically at the next refresh. No manual access-rule change required.

What this means in practice

Conditional Access is excellent at what it does — gating Microsoft 365 and Entra-federated apps. It's not designed to be the access gate for everything else in your environment.

Most teams plug the gap with one of three things:

1. Buy a ZTNA product (Zscaler, Netskope, Palo Alto Prisma Access, Twingate, Cloudflare Zero Trust), where posture-based access is often packaged into higher per-user tiers. Significant lift to set up and the per-user cost curve gets steep fast for small teams.
2. VPN with manual posture checks. Fragile. Users either have access or they don't; compliance state is a separate manual review.
3. Hope — gate by network location and trust that being on the corporate LAN means being compliant. The pandemic showed why this doesn't hold up.

HostAnywhere is option four: take the Intune compliance signal you've already built, and use it as a condition on access to anything your team needs to reach — not just Microsoft 365.

What HostAnywhere doesn't replace

We're not Conditional Access for Microsoft 365 — Microsoft is. If your goal is gating Teams or OneDrive, Conditional Access is the right tool. Intune compliance is read natively by Conditional Access; you don't need HostAnywhere in the picture.

We're not a full MDM. We don't push policies to devices, manage configurations, or wipe lost devices. Intune (or Jamf, or Kandji) handles that.

We're not an MDM replacement for fleet management. We consume the compliance signal; we don't generate it.

What we cover is the access gate for everything that isn't a Microsoft 365 app: your homelab, your internal services, your dev infrastructure, your team's private mesh.

What about non-Intune fleets?

If your fleet is on Jamf, Kandji, Mosyle, or something else, we don't have a built-in integration for those yet. Some teams use a combination — Intune for Windows, Jamf for Mac — and our Intune connector reads the Intune state for whichever devices Intune manages. The rest stay in an "unknown posture" state and won't match a rule that requires compliance.

If your environment is heterogeneous, you can mix posture conditions per rule. A rule can require Intune compliance for some device tags and CrowdStrike ZTA for others. Most real fleets aren't pure-Intune or pure-anything else.

The pricing math, plainly

For a five-person team that already pays for Intune (E3/E5 or Business Premium), what's the cheapest path to compliance-gated access to internal services?

At the time of writing, many ZTNA products package device posture integrations into per-user paid tiers. That can make compliance-gated access expensive for small teams. HostAnywhere Developer is $9/month flat within plan limits and includes posture integrations.

Vendor pricing and packaging change frequently; check current pricing pages before making budget decisions.

For larger teams the math shifts — enterprise-focused ZTNA products bundle dedicated support, deeper certifications, and broader policy surfaces that may justify per-user pricing. For small-to-mid teams that already have Intune in place, a flat per-network plan keeps the bill predictable as the team grows.

Limitations to know about

• We read compliance as a binary (Microsoft's model). We don't surface the specific policy that's failing or the remediation steps. The Intune portal handles that.
• We don't push compliance evidence back to Intune. The flow is one-way: Intune → HostAnywhere → access decision.
• Posture caches for 5 minutes. A device that just became compliant won't get access until the next refresh. Same in reverse: a device that just fell out of compliance has up to a 5-minute grace period before its existing connections are revoked.
• Stale or missing posture must be handled deliberately. If the Microsoft Graph API is unreachable or a device hasn't reported recently, the cached compliance state can be stale or missing. For sensitive resources, we recommend fail-closed behavior when Intune posture is unknown or older than your tolerance.

Practical notes from real setups

A few things worth knowing before you wire this up:

• Work tenant vs. personal Microsoft account. Intune integrations require a Microsoft Entra work or school tenant with Intune licensing and app registration support. If setup fails with Microsoft Graph or client-secret errors, verify that you are using a work/school tenant, the correct tenant ID, a valid client secret, and the required Graph permissions.
• Grace periods are honored. Microsoft's compliance model gives devices a grace window before they flip to non-compliant after a policy violation. HostAnywhere reads compliance the same way Conditional Access does: a device in grace still counts as compliant. This means short transient policy failures don't cause flapping access.
• Compliance is per-device, not per-user. A user on a compliant Windows laptop and a non-compliant personal iPhone will get different access decisions on the two devices. The rule applies to the device making the request, regardless of who's signed in.
• Hybrid posture is normal. Most fleets aren't pure-Intune. A common shape is "Intune compliance required on Windows devices, CrowdStrike ZTA threshold required on Mac devices." You can express that with two rules tagged appropriately, both pointing at the same destination resource.

How to try it

Sign in to hostanywhere.io on the Free plan. Upgrade to Developer to unlock integrations. Connect Intune. Add a test rule with intune.compliant == true.

For the exact Microsoft Entra app registration steps and Graph API scopes, see our docs.

Try HostAnywhere Free at hostanywhere.io — 10 devices, no credit card.