A baseline decays. Not because anyone changed it, but because the product moved underneath it: a protocol retires, a minimum version starts being enforced, a default flips for tenants that did nothing. This is the calendar, in date order, of what has already landed and what has a date on it. It is the most perishable article in the wave and it is the one I would read first.
Start with the one where Microsoft cannot agree with itself
Android device administrator management ended for devices with access to Google Mobile Services. Three currently published Microsoft pages give three different dates for it: August 2024 on one, the end of 2024 on another, December 2024 on a third. The linked announcement post says December. All three pages are live as I write this.
I lead with this because it is the correct posture for the whole article. The dates in a retirement calendar are not facts you memorise, they are claims you re-check, and the vendor’s own surfaces disagree often enough that a calendar assembled from memory or from a summary will contain errors that read as authoritative. Everything below was read from Microsoft’s own pages at the end of July 2026. By the time you read it, some of it will have moved, and the ones most likely to have moved are flagged.
The substance of the Android one, since the date is contested but the effect is not: device administrator management is deprecated and unavailable for devices with access to Google Mobile Services, with support continuing for some Android 15 and earlier devices without GMS. Google deprecated the API in 2020. If you still have device administrator enrollments on GMS devices, you are past the end of a road rather than approaching it.
What has already landed
| Date | What changed | What a baseline owner does about it |
|---|---|---|
| September 2024 | WSUS deprecated. No new features; still supported for production and still a role in Windows Server 2025. | Plan the transition, do not panic. Use the Windows scan source policy per update class. |
| October 2024 | Android support floor formalised at 10 and above for user-based management, with an annual October cadence: support ends for one or two versions each October until only the latest four major versions remain. | Diary an October review of the Android floor, every year. |
| July 2024 | Identity protection and account protection preview profiles deprecated and replaced by a consolidated Account protection profile. Old instances remain editable. | Migrate to the consolidated profile; only it can be created new. |
| 1 October 2024 | Windows LAPS automatic account management ships with Windows 11 24H2. | Available where the fleet is on 24H2; on 23H2 and earlier a named account that does not exist fails silently. |
| 11 February 2025 | KB5014754 strong certificate mapping enforcement. SCEP profiles need the SID; PKCS needs connector 6.2406.0.1001 or later plus the registry change. Compatibility mode ended September 2025. | If certificate authentication broke and nobody knows why, start here. |
| April 2025 | Windows Autopatch extended to Business Premium and A3 and above; feature activation removed. | Check whether you are still running manual rings on a tenant that could use Autopatch. |
| End of June 2025 | The old Intune Connector for Active Directory, running as local SYSTEM, removed; enrollments from it stop being accepted. Replacement uses a managed service account. | Hybrid join and Autopilot for existing devices depend on this. |
| 14 October 2025 | Windows 10 end of support. It remains an allowed version in Intune, so devices still enrol, with no guarantee of functionality. | Allowed is not supported. See the ESU note below. |
| October 2025 | 32-bit Microsoft 365 Apps on Windows Arm stop receiving new feature updates; security updates end December 2026. | Interacts with hotpatch on Arm64, which needs CHPE disabled. |
| 2 December 2025 | Intune network endpoints moved to Azure Front Door IP ranges, service tag AzureFrontDoor.MicrosoftSecurity. | A firewall allowlist keyed to old IP ranges breaks device and app management. Check the allowlist, not the console. |
| 19 January 2026 | Intune app SDK and app wrapper minimums enforced on iOS: below 20.8.0 or 21.1.0 the app is blocked from launching. Android Company Portal minimum 5.0.6726.0. | Any line-of-business iOS app using the SDK needs a rebuild. |
| March 2026 | Guided scenarios removed from the admin center, all except Windows 365 Boot. Objects previously created remain. | Documentation that walks a guided scenario is now wrong. |
| 1 April 2026 | Tenant-level hotpatch opt-out becomes available in the admin center. | This is the control you needed before the May date below. |
| 20 April 2026 | Intune Data Warehouse beta connector for Power BI retired over roughly two weeks. | Move to connector v2 or the OData feed; reports built on the beta connector lose their data source. |
| Late April 2026 | Intune Management Extension minimum version 1.58.103.0. Devices on earlier versions stop receiving anything that depends on the extension: Win32 apps, PowerShell scripts, remediations, platform scripts. | It auto-updates, but a stale device silently stops getting Win32 apps. Learn the failure signature. |
| May 2026 security update | Hotpatch enabled by default for all eligible Autopatch-managed devices. | The default changed for tenants that did nothing. This is the article’s centrepiece. |
| 18 May 2026 | Certificate connector 6.2510.3.3007 released, the current version. | See the connector section below; this one has a clock on it. |
| June 2026 | Apple MDM Restrictions intelligence settings deprecated with the 26.4 release; use the DDM configurations released March 2026. Managed Home Screen lock-task password moved from app config to device configuration. | More restrictions settings will deprecate as Apple moves capability to declarative management. |
| July 2026, rolling | Intune Suite capabilities redistributed into Microsoft 365 tiers, gradually, with thirty days notice per tenant. | Covered in the licensing article. Check the tenant, not the calendar. |
The most consequential row in this table is a default that changed for people who did nothing, which is exactly the kind of change no change-control process catches.
What is coming, with dates
| Date | What changes | Preparation |
|---|---|---|
| 31 October 2026 | Google Play strong integrity enforcement. Intune enforces the stronger definition. An Android 13 or later device that has not had a security update in the past twelve months drops from strong integrity to device integrity. | The named mitigations are the app protection Min OS version and Min patch version conditional launch settings, and the compliance Minimum security patch level. Set them now. |
| December 2026 | 32-bit Microsoft 365 Apps on Windows Arm stop receiving security updates. | Move to 64-bit, which is also the CHPE prerequisite for hotpatch on those machines. |
| Later in CY2026, after iOS and iPadOS 27 ship | Intune minimum moves to iOS and iPadOS 18. Userless automated device enrollment is nuanced: the supported version becomes 18 while the allowed version becomes 16 and later. | Apple sets the date. Audit the fleet against 18 before then. |
| Later in CY2026, after macOS 27 ships | Intune minimum moves to macOS 15. Devices already enrolled on 14 and below stay enrolled; new devices on 14 and below cannot enrol. | The enrol-versus-remain distinction is exactly the enrollment restriction seam from the critical tier. |
| Announced, no date | Intune will end support for creating legacy iOS, iPadOS and macOS software update policies, following Apple’s deprecation of the legacy commands in the 26 releases. | Migrate to declarative device management update policies. Watch for the date. |
| Annually, each October | Android support floor moves by one or two versions. | A standing calendar item rather than a one-off. |
If you act on exactly one row, make it the October 2026 Android one. It is the only item on the list with a hard date, an end-user-visible failure, and a mitigation that lives entirely in settings a baseline already owns.
The certificate connector has a clock on it, and most people do not know
This one gets its own section because it is the clearest example of a component people install once and never look at again, and it is on a documented expiry schedule.
Each connector release is supported for six months after the release of a new version. Connectors that are out of support keep functioning for up to eighteen months after the release of a new version, and after eighteen months functionality might fail. So the outer bound on ignoring it is eighteen months, and the point where you are unsupported is six.
The current version is 6.2510.3.3007, released 18 May 2026. The one before it was 6.2510.3.2002 in February 2026, which added SCEP validation blocking unknown OID extensions. The one worth remembering historically is 6.2406.0.1001 from September 2024, which is the strong certificate mapping release tied to KB5014754.
Status is visible under tenant administration, connectors and tokens, certificate connectors, where a deprecated connector shows a warning and then an error once the six-month grace expires. Auto-update requires outbound 443 to the update endpoint, which is the part that fails silently in a locked-down network. There is a precedent for a hard stop: connectors older than 6.2101.13.0 lost revocation in August 2022 and issuance in September 2022.
The baseline row is short. A certificate connector is a six-month-lifecycle component with an eighteen-month outer bound, installed and forgotten is a documented outage path, and connector health monitoring is coming to the admin center but is not there yet.
Supported, allowed, and the difference that matters
Microsoft draws a distinction here that almost nobody states correctly, and it is the thing that decides whether an old device is a risk or a fault. Supported versions are the three most recent operating system versions; those devices enrol and take advantage of all applicable functionality, and new eligible features work on them. Allowed versions are devices running a non-supported version within three versions of the supported ones; those devices can enrol and use eligible features, but there is no guarantee they work as expected.
Windows 10 is currently allowed, not supported. It enrols. It is not promised to work. That distinction is what you put in front of someone who says the Windows 10 fleet is fine because Intune still manages it.
Current floors, briefly. Apple with user affinity is iOS and iPadOS 17 and later, macOS 14 and later, with app protection requiring iOS 17 or later. Without user affinity, iOS and iPadOS 15 and macOS 12 are allowed. Android is 10 and later for user-based management and 8.0 and later for userless, with app protection at 10 or higher, and Microsoft Teams Android devices carved out and continuing to be supported. Linux is Ubuntu Desktop 24.04 and 26.04 LTS with GNOME, and Red Hat Enterprise Linux 9 and 10.
Two constraints worth carrying into any design that touches virtual desktops. Intune does not support managing devices with Unified Write Filter enabled. And Intune does not support a cloned image of a machine that is already enrolled, physical or virtual, because replicated enrollment or identity tokens produce enrollment and synchronisation failures. The second one is the source of a specific and miserable class of Azure Virtual Desktop incident.
Windows 10 after end of support, and the answer nobody wants
The most common question I get about this calendar is how to keep a Windows 10 fleet patched through Intune after October 2025, and the honest answer is that you cannot, because Extended Security Updates are not an Intune feature.
Commercial ESU is purchased through volume licensing, costs sixty-one dollars per device for year one, doubles each consecutive year, runs for a maximum of three years, and applies only to Windows 10 version 22H2. The multiple activation keys appear in the Microsoft 365 admin center, and activation happens per device with slmgr.vbs, or by phone for disconnected machines, or through the Volume Activation Management Tool at scale. Microsoft’s own enablement documentation contains no mention of Intune at all, and the ESU overview mentions Intune only as one of the tools for upgrading eligible machines to Windows 11.
There are free entitlement paths, and they are all virtual: Windows 10 virtual machines on Windows 365, Azure Virtual Desktop and the various Azure hosting surfaces, plus Windows 10 endpoints connecting to a Windows 365 Cloud PC, which carry the entitlement for up to three years with an active subscription.
So the baseline position is that ESU is a licensing and activation exercise that lives outside Intune, and the Intune-native answer to Windows 10 is the upgrade. Anyone who tells you there is an Intune policy for this is thinking of a settings catalog item that checked the signed-in user’s ESU subscription status, which is already deprecated and only ever worked on Windows 10.
How to keep this from going stale
An article like this is a snapshot and pretending otherwise would be dishonest. What survives is the practice rather than the table.
Read the message center for your own tenant rather than a blog, including this one, because the redistributions and rollouts that matter arrive per tenant with their own dates. Diary the standing items: the Android floor each October, the certificate connector every six months, the Apple floors whenever Apple ships a major release. And when you find two Microsoft pages disagreeing, which you will, record both rather than picking the one you prefer, because the one you prefer is usually the one that agrees with what you already built.
The last article in this wave is the checklist, which puts every claim in this series next to the article that defends it.
Best Practices
‹ Previous: [BP 4.4] Intune Licensing: The Suite That Dissolved Into Microsoft 365
Next: [BP 4.6] The Intune Quick Checklist ›
