We value your privacy

We use cookies to analyze site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Microsoft Intune
  3. Linux management
Microsoft Intune for Linux desktops

What Intune offers Linux is a compliance check and an access gate, not Windows-style control. Know that going in, and it delivers.

On Linux, Intune verifies device health and Entra Conditional Access decides whether that device may open Microsoft 365 web apps in Microsoft Edge. Enrollment is user-driven, four distributions qualify, and configuration management is not part of the deal. For the engineer laptops that keep appearing as a blank line on your SOC 2 evidence list, that narrow scope is exactly the control that has been missing.

Book a Linux management reviewSee what is actually supported
Microsoft Intune Linux desktop management for US organizations
  • 4 distributionsUbuntu LTS 26.04 and 24.04, RHEL 9 and 10
  • Compliance firstDistribution, version, encryption, password
  • Bash scriptsCustom compliance beyond the built-ins
  • Edge, on LinuxWhere the access gate operates
What it does

Seven boundaries that define Linux support in Intune.

Microsoft builds the Linux story from three parts: Intune handles device management and compliance, Entra ID supplies Conditional Access working off those compliance results, and Microsoft Edge is where protected access to Microsoft 365 web apps happens. Everything this page claims fits inside that triangle, because the published guide goes no further.

The distribution list is four entries long

Ubuntu LTS 26.04, Ubuntu LTS 24.04, Red Hat Enterprise Linux 9, and Red Hat Enterprise Linux 10 can enroll. Nothing else can. A team standardized on Debian, Fedora, or an aging Ubuntu release should hear that in the first meeting, not after a pilot stalls.

Compliance verifies; it does not configure

Policies can require a given distribution type, version floor, disk encryption, and password complexity, with the full Linux setting inventory living in the settings catalog. Nothing gets pushed onto the machine. The leverage arrives when Conditional Access starts consuming the pass-fail verdict.

The access gate covers M365 web apps in Edge

Per the published guide, Conditional Access on Linux governs Microsoft 365 web apps opened in the Edge browser: compliant devices get in, noncompliant devices get blocked. And without a Linux device compliance policy in place, Conditional Access does not function for Linux at all.

Bash extends compliance past the built-ins

Requirements the four built-in checks cannot express, a mandated package, a kernel floor, a hardened config file, become enforceable through custom compliance: you supply a Bash script plus a definition of the settings and value pairs it reports. Those scripts deserve code review like any other production automation.

Enrollment belongs to the employee

A licensed user can enroll a personal Linux device at any moment; enrollment registers the machine in Entra ID and runs the first compliance evaluation. Microsoft states there is nothing for admins to switch on beyond the prerequisites, so participation rises and falls with how well you communicate, not how well you configure.

The client software is a user install, twice

The Microsoft Intune app for Linux goes on via the Terminal, and Microsoft Edge at version 102 or later provides the protected browser. Since no console pushes either one, the enrollment guide you write and the help channel you staff are the actual deployment infrastructure.

A broker update rewrites device identity

Identity Broker 2.0.2 and later replaces the earlier Java-based architecture. Devices crossing that version line get automatically re-registered and re-enrolled, and they emerge holding brand-new Intune and Entra device IDs. Assignments, filters, and group memberships built on the old IDs need a post-update audit.

The silent assignment breaker

After the identity broker update, your Linux devices may not be who your policies think they are.

Microsoft flags this in its own documentation as an important note. Nothing visibly errors when it happens, which is precisely what makes it worth planning for.

  • The trigger: Microsoft Identity Broker versions 2.0.2 and up, shipped with the Intune app for Linux, represent a major architectural change from the earlier Java-based broker.
  • The effect: a device updating across that boundary is re-registered and re-enrolled automatically, and Intune plus Entra both mint fresh device IDs for it.
  • The required response, per Microsoft: audit every device-based assignment, filter, and Entra group membership that references device IDs, and confirm policies still land where intended.
  • What goes wrong otherwise: the renamed device drops out of its old groups, the compliance policy aimed at those groups stops reaching it, and the first symptom anyone notices is a blocked Microsoft 365 sign-in with no obvious cause. Ten minutes of checking after each broker update buys out that whole scenario.
Ask us to review your device-based assignments
How we approach it

Four commitments behind every Linux engagement we run.

Linux projects rarely break on the technology. They break when the kickoff deck promised Windows-grade management and the platform shipped a compliance gate. We never let that gap open.

The promise matches the platform, from the first call

We describe exactly what ships: compliance evaluation plus Conditional Access over Microsoft 365 web apps in Edge, nothing grander. Framed accurately, that is a real answer for the insurance form and the SOC 2 evidence request, and the project gets measured against a bar it can clear.

Custom checks are engineered, not improvised

The four built-in signals rarely cover everything an engineering org must attest to. We author the Bash compliance scripts that fill the gap, package or service or config-state checks with defined settings and value pairs, and we put them through review, versioning, and testing before they judge anyone's laptop.

The enrollment experience is the deliverable

Every install step here is performed by the end user, so we invest where the leverage is: clear terminal-level instructions, the Edge requirement explained, the encryption expectation delivered early because Microsoft notes encrypting during OS installation beats retrofitting it, and a named support channel for the moment something fails.

Broker updates get a standing audit step

Since Identity Broker 2.0.2 and later re-registers devices under new Intune and Entra IDs, we bake the follow-up into operations: after each broker transition, device-based assignments, filters, and group memberships get reconciled against the new identities before any user feels the difference.

Where this fits

Six US situations where Linux enrollment earns its keep.

Different industries, same silhouette: valuable credentials on self-managed Linux machines, and a governance program that has never had a lever to pull on them.

The Ubuntu-first engineering team

Production access, deploy keys, and cloud consoles concentrate on exactly the laptops IT has never seen. Enrollment surfaces distribution, version, encryption, and password posture, and the Edge gate ensures a failing machine cannot open Microsoft 365 web apps until it is fixed.

The SOC 2 questionnaire that asks about all endpoints

Auditors and enterprise customers increasingly refuse to let non-Windows devices remain a footnote. An enrolled Linux population converts the answer from we trust our engineers into a compliance policy, an enforcement mechanism, and an exportable report.

The company that inherited its Linux estate

An acquisition here, a contractor cohort there, and suddenly a dozen unmanaged laptops hold internal access. Because users enroll themselves and no admin-side enablement is needed beyond the prerequisites, bringing that population in is an email campaign with a support channel, not a project plan.

The RHEL workstation environment

Red Hat Enterprise Linux 9 and 10 both sit on the supported list, so engineering and lab workstations built on RHEL join the same compliance-plus-Conditional-Access regime as everything else, with no additional management product to license or operate.

The contract that names a specific control

When a customer agreement or a NIST-derived control set demands proof of a particular package, service, or configuration on Linux endpoints, a Bash custom compliance script with its settings and value pairs turns that clause into something Intune evaluates continuously rather than something asserted annually.

The research computing fleet

University labs accumulate Linux machines that answer to no one. Enrollment folds them into the institutional compliance view, and the graduated response options, alert first, lock or retire if needed, fit an academic culture that resists heavy-handed enforcement.

Three positions

The three states of Linux desktops in US companies.

Column two is where most engineering organizations actually live: senior technical staff on self-administered laptops that no security control has ever touched, holding credentials that matter more than most of the managed fleet.
Device known to the organization
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Encryption verifiable
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Password complexity enforced
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Distribution and version tracked
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Custom checks possible
Enrolled with compliance and Conditional AccessYes, via Bash
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Noncompliant devices blocked from work apps
Enrolled with compliance and Conditional AccessYes, in Edge
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Remote lock or retire available
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNo
Linux banned by policy, used anywayNo
Users have a supported path
Enrolled with compliance and Conditional AccessYes
Unmanaged developer machinesNot applicable
Linux banned by policy, used anywayNo
Audit answer for Linux access
Enrolled with compliance and Conditional AccessEvidence
Unmanaged developer machinesNone
Linux banned by policy, used anywayPolicy only
Administrative effort
Enrolled with compliance and Conditional AccessLow
Unmanaged developer machinesNone
Linux banned by policy, used anywayNone
Feature
Enrolled with compliance and Conditional Access
Unmanaged developer machines
Linux banned by policy, used anyway
Device known to the organization
YesNoNo
Encryption verifiable
YesNoNo
Password complexity enforced
YesNoNo
Distribution and version tracked
YesNoNo
Custom checks possible
Yes, via BashNoNo
Noncompliant devices blocked from work apps
Yes, in EdgeNoNo
Remote lock or retire available
YesNoNo
Users have a supported path
YesNot applicableNo
Audit answer for Linux access
EvidenceNonePolicy only
Administrative effort
LowNoneNone
The honest boundary

Linux in Intune: supported column by column.

Everything below traces to the published deployment guide. Where the guide is silent, this page stays silent too, which is a feature of the page and not a gap.

Capability

Supported distributions

Position for Linux
Ubuntu LTS 26.04 and 24.04, Red Hat Enterprise Linux 9 and 10

Capability

Enrollment

Position for Linux
User initiated, on personal devices, with no administrator enablement beyond the prerequisites

Capability

Device registration

Position for Linux
Registered with Microsoft Entra ID during enrollment, then evaluated for compliance

Capability

Compliance settings

Position for Linux
Distribution type, version, device encryption, and password complexity, all in the settings catalog

Capability

Custom compliance

Position for Linux
Your own Bash scripts, using a custom script that identifies settings and value pairs

Capability

Conditional Access scope

Position for Linux
Microsoft 365 web apps in the Microsoft Edge browser for Linux

Capability

Conditional Access prerequisite

Position for Linux
A device compliance policy is required for Conditional Access to work with Linux devices

Capability

Actions for noncompliance

Position for Linux
Sending alerts, remotely locking devices, or retiring devices

Capability

Required client software

Position for Linux
The Microsoft Intune app for Linux, and Microsoft Edge version 102 or later

Capability

Least privileged admin role

Position for Linux
The built-in Policy and Profile Manager Intune role for enrollment tasks
CapabilityPosition for Linux
Supported distributionsUbuntu LTS 26.04 and 24.04, Red Hat Enterprise Linux 9 and 10
EnrollmentUser initiated, on personal devices, with no administrator enablement beyond the prerequisites
Device registrationRegistered with Microsoft Entra ID during enrollment, then evaluated for compliance
Compliance settingsDistribution type, version, device encryption, and password complexity, all in the settings catalog
Custom complianceYour own Bash scripts, using a custom script that identifies settings and value pairs
Conditional Access scopeMicrosoft 365 web apps in the Microsoft Edge browser for Linux
Conditional Access prerequisiteA device compliance policy is required for Conditional Access to work with Linux devices
Actions for noncomplianceSending alerts, remotely locking devices, or retiring devices
Required client softwareThe Microsoft Intune app for Linux, and Microsoft Edge version 102 or later
Least privileged admin roleThe built-in Policy and Profile Manager Intune role for enrollment tasks
How an engagement runs

Five steps, where documents outnumber configurations.

Plan on 3-6 weeks, remote end to end. The console work is measured in hours; the survey, the compliance design, and the enrollment materials consume the calendar, and they are what determine adoption.
  1. 1

    Survey the fleet against the supported list

    An inventory of who runs Linux and on what, compared against Ubuntu LTS 26.04 and 24.04 and RHEL 9 and 10. The percentage that falls outside those four releases sets the project's honest ceiling and belongs in the plan from day one.

  2. 2

    Stand up prerequisites under a minimal role

    License assignments verified, user groups prepared, MDM authority confirmed, and administration handed to the Policy and Profile Manager role, which Microsoft identifies as the least privileged role able to complete device enrollment tasks.

  3. 3

    Design the compliance policy and its custom extensions

    The built-in four, distribution type, version, encryption, password complexity, configured from the settings catalog, then Bash scripts drafted and reviewed for anything contractual or internal standards demand beyond them. Noncompliance consequences, alert, lock, or retire, get chosen with stakeholders in the room.

  4. 4

    Produce the enrollment kit and launch it

    Step-by-step instructions covering the Intune app install from the Terminal and Edge 102 or later, the encryption requirement stated up front so users can opt in during OS installation, and a support route published beside it all. Then the launch is a communication, because the enrollment itself is self-service.

  5. 5

    Switch on the gate and schedule the housekeeping

    With the compliance policy live, the Conditional Access policy protecting Microsoft 365 web apps in Edge activates. Operations inherit two standing tasks: a compliance-state review cadence, and the post-broker-update reconciliation of assignments and group memberships against new device IDs.

Straight answers

What US organizations ask about Intune for Linux.

Four, per the published guide: Ubuntu LTS 26.04, Ubuntu LTS 24.04, Red Hat Enterprise Linux 9, and Red Hat Enterprise Linux 10. Anything else, including older Ubuntu releases, sits outside enrollment support, so a distribution survey belongs at the very start of planning.

No. The published architecture assigns Intune the device management and compliance role, Entra ID the Conditional Access role, and Edge the protected-browser role for Microsoft 365 web apps. Verification and gating, in other words. Pushing configuration onto the machine the way Windows profiles do is not part of the offering, and pretending otherwise is how these projects sour.

Microsoft 365 web apps inside the Microsoft Edge browser on Linux. Compliant devices are granted access, noncompliant devices are refused. One dependency is absolute: without a Linux device compliance policy in the tenant, Conditional Access simply does not operate against Linux devices.

Four built-in dimensions: distribution type, version, device encryption, and password complexity, with every available Linux setting housed in the settings catalog. Requirements past those four are handled by custom compliance, where you provide a Bash script and the settings and value pairs it evaluates.

By their owners. Any employee holding an Intune license can enroll a personal Linux device whenever they choose; the process registers the machine with Entra ID and finishes with a compliance evaluation. Administrators enable nothing beyond the prerequisites, so your communication plan is effectively the rollout mechanism.

Two components, self-installed: the Microsoft Intune app for Linux, added through the Terminal application, and Microsoft Edge at version 102 or later for reaching protected sites and files. Post-enrollment, signing into Edge with the work account is what unlocks the protected resources.

Yes, and Microsoft says so plainly: where encryption is required, employees should hear about it ahead of enrollment so they can choose full-disk encryption during OS installation, a far quicker path than encrypting a running system afterward. Publishing the OS and password requirements at the same time spares everyone the mid-enrollment scramble.

The device gets flagged noncompliant and your configured consequence follows. Microsoft's documented options include sending alerts, remotely locking the device, and retiring it, and users must clear their compliance failures before protected resources reopen. Evaluation runs at enrollment and again at each subsequent check-in.

The likeliest culprit is an identity broker transition. Broker 2.0.2 and later re-architects device identity, and machines updating across that line are automatically re-registered and re-enrolled with new Intune and Entra device IDs. Until device-based assignments, filters, and group memberships are reconciled to the new IDs, policies keyed to the old ones miss their targets.

The built-in Policy and Profile Manager role, which Microsoft identifies as the least privileged role capable of completing device enrollment tasks. Given how little admin-side work Linux enrollment involves, reaching for anything broader adds risk without adding capability, and the scoped choice reads cleanly in a least-privilege audit.

The guide frames the model around employees enrolling personal devices: user initiated, license driven, registered to the individual in Entra. An organization seeking centralized management of a corporate-owned Linux fleet is asking a bigger architectural question, and we would scope that honestly rather than stretch this capability over it.

Often the answer is strongly yes, precisely because of who owns those machines: the engineers carrying production credentials, signing keys, and infrastructure access. Enrollment demands no per-device administrative labor, and the delta, from zero visibility to verified encryption, enforced passwords, and a compliance-gated path to Microsoft 365, is the largest single-step improvement available for that population.
Before you commit

Fifteen questions that keep expectations accurate.

Start with fit, because a wrong answer there ends the project. The remaining two groups shape a rollout that succeeds or fails on how well people are told what to do.

Does it fit

  • Which distributions are actually in use?
    Only four qualify.
  • What needs protecting?
    The gate covers M365 web apps in Edge.
  • Personal machines or corporate?
    The published model is personal enrollment.
  • Are Intune licenses assigned?
    Enrollment requires them.
  • Will engineers accept Edge for work?
    Protection applies nowhere else.

Compliance design

  • Which built-in checks apply?
    Distribution, version, encryption, password.
  • Any requirements beyond those four?
    Bash custom compliance covers them.
  • Encryption communicated in advance?
    Easiest during OS installation.
  • Chosen noncompliance response?
    Alert, lock, or retire.
  • Grace period length?
    Sets the rollout's tone.

Rollout and operations

  • Enrollment guide drafted?
    The app install is self-service.
  • Support channel staffed?
    Enrollment happens without you.
  • Using Policy and Profile Manager?
    The minimal role for the job.
  • Broker update audit scheduled?
    New device IDs break old targeting.
  • Compliance dashboard owner named?
    Data without an owner is decoration.
Related reading

The pages around this one.

Intune compliance policies

Compliance design across platforms, and the machinery Conditional Access relies on.

Learn more

MDM solutions

The full device estate in one strategy: Windows, Apple, Android, and Linux side by side.

Learn more

Entra Conditional Access

The policy engine that converts a compliance verdict into an allow or a block.

Learn more
Next step

Start with a one-question survey: which distro is on each Linux laptop?

That single inventory decides everything downstream. A fleet on current Ubuntu LTS or RHEL is a few weeks from compliance gating; a fleet scattered across unsupported releases needs a different roadmap first. Either way you learn it before committing budget. Engagements are scoped per organization.

Book a Linux management reviewSee Microsoft Intune services

Related Services

Explore more solutions that work great with this service

Microsoft Intune

Device management and endpoint security

Learn more

Microsoft Entra

Identity and access management solutions

Learn more

Managed IT Services

Complete outsourced IT department

Learn more
GR IT SERVICES

IT services for US businesses,
delivering enterprise-grade solutions
remotely, coast to coast.

Microsoft CSP PartnerApple Jamf PartnerCISGuard

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support USA
  • IT AMC USA
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • hello@gritservices.io
  • gritservices.io

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie PolicyCCPA/CPRA