Microsoft has officially set a deadline for organizations still running Red Hat Enterprise Linux 8 desktops under its Intune management umbrella. Starting in July 2026, the company will no longer list RHEL 8 among the supported Linux distributions for new enrollments or ongoing managed access scenarios. While already enrolled devices won’t be immediately cut off, any continued reliance on an unsupported OS version risks future breakage, compliance gaps, and lost access to critical corporate resources.

The change, buried in the March 2026 service update (2603) for Microsoft Intune, marks a significant pivot for Linux endpoint management. It forces IT teams to plan a controlled migration to either RHEL 9 – the conservative default – or the newer RHEL 10, but only after rigorous validation. The catch: there is no bulk enrollment option for Linux. Every migration batch requires a scheduled sign-in appointment with the assigned user, making this more of a people and scheduling challenge than a pure technology refresh.

What Actually Changed

On March 30, 2026, Microsoft published its Intune service release notes for version 2603, and among the usual flurry of new features and deprecations, one line stood out to Linux administrators: “Support for Red Hat Enterprise Linux 9 and later… Support for RHEL 8 LTS will end in July 2026.” Previously, Red Hat Enterprise Linux 8 was a supported platform for enrolling desktops into Intune and enforcing device-based Conditional Access policies. Now, it is conspicuously absent from the official enrollment list, which currently includes only RHEL 9 LTS and RHEL 10 LTS.

The same update also heralded a major architectural shift for the Microsoft Intune app on Linux, which now incorporates the Microsoft Identity Broker (version 2.0.2 or later). This broker replaces the older Java-based component and enables modern authentication experiences such as phish-resistant MFA, smart card authentication, and certificate-based authentication with Microsoft Entra ID. It also brings a new bit of behavioral change: the Identity Broker can automatically re-register and re-enroll devices, potentially generating new Intune and Entra device IDs even if the hostname stays the same. That means a simple operating system upgrade might inadvertently orphan the old device record and break group memberships, policy assignments, and access rules.

These changes are not just about a version bump. The supported management stack for Linux, as documented by Microsoft, remains a tightly coupled combination of Intune, Microsoft Entra ID, Microsoft Edge, and the Identity Broker. Any desktop that falls outside the supported version matrix may check in, report compliance, or retain access in unpredictable ways – or not at all.

What It Means for You

For home users or those experimenting with Intune on personal projects, this deadline is a soft signal. If you’re running a single RHEL 8 desktop enrolled in a test tenant, you can likely wait until the July cut-off before repaving your machine. But the moment you rely on that device for accessing company resources protected by Conditional Access, you are living on borrowed time.

For IT administrators and security teams, the stakes are much higher. Every RHEL 8 endpoint in your fleet represents a pending compliance risk. Here’s what the end-of-support truly means:

  • No more hand-holding: Microsoft will not proactively block old devices, but it also won’t test, document, or troubleshoot behaviors specific to RHEL 8. If a future Intune service update breaks enrollment or policy delivery for that OS, you’ll be on your own.
  • Conditional Access at risk: Device-based Conditional Access for Linux web sessions depends on the entire supported stack. An unsupported OS could lead to users being blocked from SharePoint, Exchange Online, or any Entra ID-protected app.
  • Enrollment is non-negotiable and user-driven: Unlike Windows Autopilot or Apple Device Enrollment, there is no bulk or automated enrollment path for Linux. The process requires the user to install the Intune app, sign in with their Entra ID account, and walk through the enrollment prompts. So migration capacity is limited by how many user appointments you can schedule.
  • Desktop environment matters: Microsoft requires GNOME for the supported Linux enrollment scenario. KDE, Xfce, or other environments are not officially supported, and using them could break the sign-in workflow or identity integration.
  • Device identity can shift: Because the new Identity Broker can trigger automatic re-registration, your post-migration device may appear as a brand-new object in Intune and Entra ID. That means all device-targeted policies, group memberships, and reporting filters need to be re-examined after the upgrade.

In short, leaving an RHEL 8 desktop untouched after July 2026 is a gamble no regulated or security-conscious organization should take.

How We Got Here

Microsoft’s support for Linux management in Intune has been a slow and steady journey. Full desktop enrollment support for Ubuntu arrived first, followed by Red Hat Enterprise Linux. The initial promise was simple: bring the same compliance and Conditional Access controls to Linux that Windows and macOS enjoy. However, the management stack was never as mature; early limitations included reliance on a Java-based broker, no bulk enrollment, and sparse policy options.

Over the past year, Microsoft has been investing heavily in modernizing Linux management. The Identity Broker transition away from Java, introduced in 2025, paved the way for stronger authentication. The Intune app for Linux received a major overhaul. More recently, in the March 2026 release, support for Ubuntu 26.04 LTS was added, and RHEL 8 was officially deprecated.

The timing is aligned with Red Hat’s own lifecycle: RHEL 8 entered its End of Maintenance phase in May 2024 and is now in the Extended Lifecycle Support (ELS) period. Microsoft’s decision to drop support for it in Intune effectively aligns with the broader industry shift toward RHEL 9 as the stable long-term platform and RHEL 10 as the bleeding-edge option for those ready to adopt it.

It’s also worth noting that Microsoft’s support list has never validated every possible workload or hardware combination. The company’s “supported” stamp applies to the core management stack – Intune, Entra ID, Edge, and the Identity Broker. Your specific VPN client, security agent, printer driver, or development toolchain still needs your own validation, regardless of the RHEL version you choose.

What to Do Now: A Practical Migration Roadmap

If you manage even a handful of RHEL 8 desktops in Intune, the clock is ticking. Below is a step-by-step plan to get your fleet onto a supported version before the July 2026 deadline. This plan is based on Microsoft’s documented requirements and hard-won lessons from early adopters.

1. Discover and Classify Every Affected Device

Don’t trust your memory or a rough headcount. Gather hard data from multiple sources:

  • Run a Linux device filter in the Intune admin center (Devices > All Devices, filter by OS: Linux) and export the list.
  • Cross-reference with your asset management system, CMDB, procurement records, and support tickets.
  • Identify the installed major RHEL version for each machine – either by querying the OS directly via your management tool or by checking the OS version column in Intune.
  • Tie each device to its assigned user, business owner, hardware model, and primary workload.
  • Flag discrepancies: a machine may be in Intune but not in your CMDB (or vice versa). Resolve those mysteries before migration day.

Once you have a clean inventory, group devices by application requirements, hardware model, and authentication needs. This will help you decide which migration path to take.

2. Choose RHEL 9 or RHEL 10

For the vast majority of organizations, RHEL 9 is the safe default. It is on Microsoft’s supported list, has a proven track record with Intune, and offers broad compatibility with existing enterprise software, drivers, and peripherals. Unless your internal validation team has given RHEL 10 a green light for all required components, do not attempt a fleet-wide jump to RHEL 10.

Reserve RHEL 10 for specific cohorts: brand-new hardware deployments, clean-image standards where every application, VPN client, and security agent has passed testing, or scenarios where a business-critical workload requires a feature only available in RHEL 10. Even then, verify that your hardware vendor supports the new OS and that any required Red Hat Application Streams are aligned with the RHEL 10 lifecycle.

3. Build a Pilot That Mirrors Production

Before you touch a single production workstation, create a representative pilot group that covers:

  • The two or three most common hardware models in your fleet.
  • Every required authentication method: smart cards, FIDO2 keys, certificates.
  • VPN and endpoint-security agents.
  • Printing, scanning, and specialty USB peripherals.
  • Business-critical applications and their dependent Application Streams.
  • Users who are subject to your strictest Conditional Access and Intune compliance policies.

Pilot RHEL 9 first. Only include RHEL 10 if it’s an explicit, validated project goal. Have real users work on these pilot machines for at least a week, hitting all the internal resources they normally access.

4. Plan the User-Assisted Enrollment

This is where many Linux migration projects hit a wall. Because enrollment is per-user and requires active sign-in, you must schedule an appointment with every affected user. Consider:

  • Blocking out 30‑minute windows for each migration.
  • Preparing a remote support session or having desktop support staff available for walk-up appointments.
  • Communicating clearly: the user must install the approved image (or have it deployed by IT), install Intune and Edge, then sign in and complete the enrollment prompts. Do not assume that simply imaging a machine constitutes enrollment.

If you have hundreds of RHEL 8 desktops, start scheduling now. You can parallelize by having multiple techs handle appointments, but the user-interaction step is a hard bottleneck.

5. Reconcile the Device Identity After Migration

After the device is enrolled on the new OS, follow this identity reconciliation checklist:

  • Compare old and new Intune device records (device ID, Entra device ID, join type).
  • Review all device-targeted policy assignments, app deployments, and configuration profiles. If any assignment uses explicit device IDs, update them.
  • Check dynamic Entra group memberships that rely on device attributes – they may now point to the old record.
  • Verify automation scripts or reporting dashboards that reference device IDs.
  • Test Conditional Access: sign in to a protected resource as that user and confirm access is granted.

Do not delete the old device record immediately. Keep it until production verification is complete, then retire it through the normal process.

6. Verify Every Layer of the Stack

A device is not truly migrated until these checks pass:

  • The OS version is confirmed as RHEL 9 or 10, with GNOME installed.
  • Intune, Edge, and the Identity Broker are present and up to date.
  • The user can sign in and access all required corporate resources (email, SharePoint, line-of-business apps).
  • All business applications launch and function normally.
  • Authentication methods (smart card, certificate, etc.) work.
  • VPN connects, printing works, peripherals function.
  • Backup and recovery procedures have been tested.

Only then should you approve the device for production and consider the old record safe to remove.

7. Communicate and Maintain a Runbook

Document every step, decision matrix, and troubleshooting procedure specific to your environment. Share a concise migration guide with users so they know what to expect. Appoint a migration owner who tracks progress and can escalate blockers quickly.

Outlook

Microsoft’s push to modernize its Linux management stack isn’t stopping with RHEL 8 deprecation. The same March 2026 release added Ubuntu 26.04 LTS support and phased out Ubuntu 22.04 LTS, signaling a regular cadence of version refreshes. Admins should build an annual OS review into their endpoint management cycle.

Future Intune updates are likely to bring tighter integration with Microsoft’s security portfolio – the new Microsoft Defender Antivirus settings for Linux servers and hardware-backed attestation via ACME certificates hint at a world where Linux desktops are treated as first-class citizens in zero-trust architectures. But for now, the immediate task is clear: get off RHEL 8 before July 2026, and do it in a way that doesn’t leave your users locked out or your device identities fragmented.