Fleet says Microsoft endpoint tooling leaves non-Windows gaps

At a glance

What this is: This is Fleet’s analysis of how Microsoft’s endpoint tooling leaves macOS and Linux with weaker inventory, compliance, and vulnerability visibility than Windows.

Why it matters: It matters because IAM and endpoint teams that rely on conditional access, telemetry, and compliance signals need trustworthy device state across every OS, not only the one with the deepest native controls.

Context

Endpoint governance only works when the control plane can see the real state of every device. In mixed fleets, the common failure is not lack of policy but lack of comparable signal across operating systems, especially when macOS and Linux are treated as exceptions instead of first-class managed endpoints.

Microsoft stack users often inherit that blind spot through inventory drift, narrow compliance checks, and limited native vulnerability insight. The result is a policy story that looks consistent on paper but becomes uneven in practice once devices move beyond Windows.

The article frames that gap as a practical governance problem, not a theoretical platform debate. For teams running conditional access, device compliance, and security telemetry, the starting position described here is increasingly typical.

Key questions

Q: How should security teams enforce device posture in conditional access policies?

A: Security teams should connect endpoint compliance signals directly to authorization so a device that fails encryption, patching, or firewall checks cannot reach sensitive resources. The policy must use current device state, not enrollment history. This only works when MDM, identity, and access control share the same decision path.

Q: Why do endpoint inventories fail to reflect real security risk on mixed fleets?

A: Inventory fails when it refreshes too slowly and misses software classes that defenders need to see. If package managers, browser extensions, local tools, or short-lived changes never reach the control plane in time, the organisation is making patching and exposure decisions from an outdated picture rather than the real device state.

Q: What are the best practices for managing macOS and Linux devices in Microsoft-centric environments?

A: Do not rely on Windows-native assumptions to govern non-Windows endpoints. Use controls that can express the state you actually care about, tie compliance to remediation, and verify that the device posture feeding access decisions is current across all operating systems, not only the one with the richest default policy model.

Q: What happens when endpoint compliance is built on a narrow checklist?

A: The organisation can end up with green status on devices that do not meet the real baseline. That creates a false sense of control, leaves gaps in vulnerability and software governance, and allows access to continue because the policy measured a proxy instead of the security state that matters.

Technical breakdown

Why fixed compliance checklists fail on mixed fleets

A fixed compliance checklist only works when the control surface matches the operating system and the policy can express the actual security state you care about. On macOS, Intune evaluates a six-item checklist and does not support custom compliance policies, which means the platform can certify only a narrow proxy for device health. That is a policy model, not a device-state model. When teams need to know whether a security agent is installed, a kernel is patched, or a required certificate exists, the checklist cannot represent the condition. The practical issue is not that the policy is wrong, but that the policy language is too thin for the governance decision it is being asked to make. See the Mobile Device Security Guide.

Practical implication: Treat device compliance as an expressiveness problem and move critical checks to a policy engine that can evaluate the exact state you require.

How drifted inventory breaks vulnerability and software governance

Inventory is only useful when it is current enough to support security decisions. In the article’s model, MDM inventory refreshes slowly and misses software classes that matter to defenders, including Python packages, browser extensions, and other locally installed tools. That creates a split between what the console shows and what the endpoint is actually running. Vulnerability governance then fails in two ways: known software risk does not surface, and security teams lose the ability to tie change, exposure, and remediation to the same asset record. This is why endpoint inventory is not just an asset management function. It becomes the evidence layer for patching, exposure management, and detection. See the Vulnerability Management Guide.

Practical implication: Correlate inventory with live endpoint telemetry so your vulnerability workflow is driven by current state, not stale snapshots.

Why conditional access needs device trust, not just identity signals

Conditional access becomes stronger when identity and device posture are evaluated together. The article describes a model where Fleet sends a non-compliant signal to Microsoft Entra when a host fails policy, and access is blocked until remediation occurs. That matters because identity assurance alone does not tell you whether the endpoint is in a trustworthy state. In a mixed-fleet environment, the trust decision depends on device signals that are specific, current, and policy-driven. This is the operational bridge between IAM and endpoint governance: access policy is only as good as the quality of the device state fed into it. See the [[L3|AI Governance Platform Buyer's Guide]] only if your programme also needs discovery and policy controls for AI tools on endpoints. See the AI Governance Platform Buyer's Guide.

Practical implication: Use device posture as an access input so conditional access can fail closed when endpoint state falls below policy.

Threat narrative

Attacker objective: Exploit blind spots in endpoint governance so risky devices remain trusted long enough to retain access and evade remediation.

1. Entry occurs when unmanaged or weakly managed devices fall outside the visibility boundary of the endpoint control plane, so drift starts without a clear alert.
2. Credential and policy trust are then weakened because compliance decisions rely on incomplete or stale device state rather than current endpoint evidence.
3. Impact follows when a device is reported compliant even though it carries unobserved software, configuration, or vulnerability risk, allowing access to continue under a false green status.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Coverage gaps are a governance failure, not a platform quirk. When one operating system gets full policy depth and others get thinner checks, compliance becomes uneven by design. That matters because security leaders often read a green dashboard as a uniform control outcome when it is really an artifact of uneven visibility. The practitioner conclusion is simple: do not let endpoint posture be defined by the narrowest native policy model.

Device trust is now part of identity governance. Conditional access only deserves the name when it evaluates a reliable, current signal about the endpoint, not just the account. This is where endpoint management, IAM, and security operations converge. If the device state is stale or partial, the access decision is partial too, and partial trust is a governance gap rather than a technical inconvenience.

Shadow AI on endpoints creates an unmanaged governance layer. The article’s point about browser extensions, AI tooling, and local software points to a broader issue: device inventories no longer describe the full operational surface. That is exactly where shadow AI discovery becomes relevant, because unmanaged tools on managed devices are still governed assets. The practitioner conclusion is to treat endpoint discovery as a control boundary, not an inventory report.

Open, code-driven device management raises the standard for evidence. When policies are versioned, reviewable, and reversible, teams can argue about control intent instead of console state. That does not eliminate risk, but it makes the control logic auditable in a way closed workflows often are not. The practitioner conclusion is to prefer management models that let you prove what was enforced, when, and why.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Device-state governance is becoming a prerequisite for any serious conditional access programme. As fleets expand across macOS, Windows, Linux, mobile, and cloud-connected endpoints, the question is no longer whether you have MDM, but whether the policy model can express the actual state you need to trust.

The operational gap is moving from device enrollment to device truth. Teams that cannot see installed software, live state, and endpoint-installed AI tools will keep mistaking managed for governed, which leaves access policy one step behind the environment it is trying to control.

For practitioners

• Document the actual compliance questions your policy must answer Replace platform-default checklists with device-state questions that reflect your security baseline, including software presence, configuration state, and patch status.
• Unify inventory with live telemetry Correlate endpoint inventory with process, package, and network signals so vulnerability and software decisions are based on current state. See the Vulnerability Management Guide.
• Feed device posture into conditional access Use device health as an access gate so non-compliant endpoints are blocked until remediation is complete.
• Bring shadow AI and unmanaged software into discovery Inventory browser extensions, IDE tools, local packages, and other endpoint-installed software that standard MDM views often miss.
• Version control endpoint policy changes Store compliance rules, software definitions, and remediation logic in code so changes are reviewed, reversible, and traceable. See the Infrastructure as Code Security Guide.

Key takeaways

• Mixed-platform endpoint stacks can hide real risk when compliance checks are narrower than the security baseline they are supposed to represent.
• Inventory drift and limited native visibility turn vulnerability management into a snapshot exercise instead of a current-state control.
• Device trust, conditional access, and endpoint telemetry should be governed as one control plane when organisations need reliable enforcement across every OS.

Related NHI Mgmt Group resources: Shadow AI and AI Agent Discovery Guide · Mobile Device Security Guide · Vulnerability Management Guide · AI Governance Platform Buyer's Guide

Key terms

• Device Trust: Device trust is the confidence that a requesting endpoint is known, managed, and in a compliant state. It matters because identity alone does not prove safety. In zero trust programmes, device trust becomes one of the inputs used to decide whether access should be granted or sustained.
• Inventory drift: The gap between the asset record and the real operational state of a device or application. When inventory drift grows, teams lose confidence in ownership, usage, and lifecycle data, which weakens both compliance reporting and identity decisions that depend on that data.
• Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
• Endpoint Telemetry: Endpoint telemetry is the process and event data collected from managed devices to understand local activity. For shadow AI, it includes process spawns, file access, and direct outbound calls from the operating system, giving security teams visibility that network tools and SaaS logs often miss.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners building reliable access controls. It helps security teams connect identity governance to the wider control decisions their programmes depend on.