Intune Enterprise App Management: A Practical Review for IT Admins

Enterprise App Management (EAM) has been available in Intune since February 2024, but for most of that time it remained a separately licensed add-on. Two changes made it far more relevant this year: auto-update reached general availability, and on July 1, 2026, EAM became part of eligible commercial Microsoft 365 E5 subscriptions. Microsoft scheduled the rollout of these new entitlements to existing eligible customers to be completed by August 1, 2026.

That does not mean every Intune tenant now has access to EAM. Tenants without an eligible Microsoft 365 subscription still need EAM as a standalone add-on or through the Intune Suite, and the packaging change does not extend EAM to Education or Frontline plans. However, for eligible Microsoft 365 E5 customers, the separate licensing barrier is largely gone.

This is not a step-by-step guide. It is a practitioner’s look at what EAM does today, where it can reduce administrative effort, and which operational gaps still limit its use.

What EAM Actually Does

At the core of EAM sits the Enterprise App Catalog. It is a collection of prepackaged Win32 applications prepared by Microsoft for Intune. The catalog contains both Microsoft and third-party applications, currently based on EXE and MSI installers.

When you add an application from the catalog, Intune prefills the install command, uninstall command, detection rules, requirements, and return codes. You skip most of the traditional packaging work. You do not create and upload the .intunewin package yourself, and you do not need to search for silent installation switches. You select the application, review the settings, and assign it.

Microsoft recommends keeping the prepopulated configuration where possible, but you can modify it when needed. You can replace the default install or uninstall command with a PowerShell script, add custom requirement rules, or use custom detection logic. Once you start replacing Microsoft’s prepared configuration, however, the responsibility for testing and maintaining that behavior moves back to you.

Enterprise App Catalog applications are installed directly by the Intune Management Extension. EAM does not use WinGet under the hood. This matters because EAM applications follow the existing Intune Win32 delivery, detection, reporting, and troubleshooting flow rather than the WinGet management model.

There are also two different update models, and they should not be confused. Some catalog applications are self-updating. In that model, the vendor’s own update mechanism performs the upgrade, while Intune checks whether the detected version meets the configured minimum version.

EAM auto-update is different. When auto-update is enabled for an Enterprise App Catalog application with a Required assignment, Intune detects when a newer version becomes available in the catalog and automatically updates the application on the targeted devices through the Win32 application delivery flow.

It is worth knowing which update model an application uses before assuming that EAM itself is keeping it current.

Where EAM Saves Time

The value shows up in a few concrete areas.

You can deploy common third-party applications without preparing the package yourself. Citrix Workspace, Zoom, and similar applications are already available in the catalog with Microsoft-prepared installation logic.

You can keep Required applications current with auto-update. When a newer version becomes available in the catalog, Intune automatically updates the Enterprise App Catalog application on targeted devices. You no longer need to create a new application and configure a new supersedence relationship for every release. EAM auto-update applies to Enterprise App Catalog applications with a Required assignment on supported Windows 10 and Windows 11 devices.

Available applications use a different update workflow. They are not covered by the new EAM auto-update feature, so an administrator still needs to create the newer catalog application and establish the supersedence relationship. However, an Available Win32 assignment can use Intune’s existing supersedence auto-update option to update devices where a user previously installed the superseded application through Company Portal. It is not as hands-off as EAM auto-update for Required assignments, but it is not necessarily a completely manual device-by-device process either.

You can also centralize applications that are already part of your environment. The immediate benefit is often not deploying new software. It is reducing the packaging and lifecycle work around applications your organization already depends on—the ones currently maintained through custom scripts, manually created packages, or a separate application management tool.

Even when auto-update is not enabled, Intune gives you visibility into newer catalog versions. The Enterprise App Catalog apps with updates view shows the provisioned version and the latest available version, and the guided update workflow can create the new application with a supersedence relationship.

EAM also does not require a separate management console. It is managed from Intune, uses the Win32 application platform, and sits alongside your existing Win32, line-of-business, and Microsoft Store applications. The Managed Apps report can show the application, version, resolved intent, and installation state for a specific device.
Licensed applications can exist in the catalog, but Intune does not purchase, validate, or distribute those licenses for you. Purchasing the required license and assigning it within your organization remains your responsibility. The installer must also be accessible to Microsoft’s catalog process: applications whose download is behind a paywall or sign-in screen are not supported for catalog addition.

Where the Limitations Begin

This is the part that matters more than a feature list, because it is where EAM still looks unfinished next to a mature application management tool.

No rollout rings or phased deployment. When a new version becomes available, auto-update targets the complete assigned population rather than moving through pilot and production stages. Devices still process the update according to their own check-in and enforcement timing, so installation is not literally simultaneous. However, there is no native EAM auto-update workflow for validating the version with a pilot group before expanding it to the remaining devices.

No discovery-based update-only targeting in EAM auto-update. Auto-update works through a Required assignment, and Required makes the application mandatory for the targeted population. Intune still uses detection rules, so a device already running the target version does not reinstall it. But when the application is missing, Required installs it instead of treating the device as not applicable.

That means you cannot assign an auto-updated application broadly to All Devices and expect EAM to update only the machines where the application is already installed. Devices with an older version receive the update, but devices without the application receive a new installation as well. In practice, each application needs to be targeted at the users or devices that are actually expected to have it.

There is an important distinction for Available applications. If the application was installed by a user through Company Portal, Intune’s existing Win32 supersedence auto-update workflow can update that tracked installation after the administrator creates the new application and supersedence relationship. However, the new EAM auto-update feature does not independently discover arbitrary existing installations across the environment and build an update-only scope from them.

The remaining gap is most visible with applications installed outside the tracked Company Portal workflow, deployed through another method, or already scattered across the estate without a clean assignment group. EAM does not currently provide a native equivalent to the Update Only assignment offered by some dedicated third-party tools, where the update is applicable only when the product was previously installed and is not installed on devices where it never existed.

For now, EAM auto-update is most useful when an application already has a clearly defined Required deployment scope. I would expect installation-aware targeting to receive more attention as adoption grows and administrators provide feedback, because it would make auto-update useful across a much larger part of the application estate.

No rollback or automatic uninstall remediation. If a problematic version is released, recovery takes place outside the auto-update workflow. You need to assign an Uninstall intent, deploy a remediation script, or use another manual recovery method.

Reporting reflects only the latest state. Auto-update reporting stores the latest reported state for each device. It does not retain a complete history of previous versions, enforcement activity, or earlier actions at the device level. It tells you where the device currently stands, but not the complete path it took to get there.

No running application detection. Intune currently cannot determine whether an Enterprise App Catalog application is running before beginning an update. Applications that need the process to be closed depend on the installer’s own behavior or on additional custom logic created by the administrator.

Auto-update applications cannot be blocking apps in ESP or Autopilot device preparation. Regular Enterprise App Catalog applications can be selected as blocking applications, but applications using EAM auto-update cannot.
Do not manage the same application in multiple ways. Microsoft does not support targeting the same product through EAM auto-update and another application type, such as a separate Win32 or line-of-business deployment. Competing deployments can produce a race condition in which the installed version changes between the versions managed by each assignment. If you migrate an existing application to EAM auto-update, the older deployment method should be retired first.

Beyond auto-update, EAM still favours a standardized deployment model. It supports custom PowerShell install and uninstall scripts, custom requirement rules, and custom detection logic, so customization is no longer as limited as it was at launch. But replacing Microsoft’s prepared configuration also moves responsibility for testing and maintaining that behavior back to the administrator. An incorrect script can cause installation or update failures.

EAM gives you room to customize, but it does not turn the catalog into a complete application orchestration platform. It still lacks the native rollout controls and update-only deployment model available in more mature third-party application management products.

The catalog also has practical gaps. Proprietary applications, industry-specific software, and heavily customized packages might not fit the catalog model. Applications whose installer is behind a paywall or sign-in flow are excluded by design. For those applications, traditional packaging skills are still required.

The Enterprise App Catalog is also limited to managed Windows devices, with the current EAM requirements focused on 64-bit Windows. If you manage a mixed estate, macOS, iOS, and Android applications still require other deployment and lifecycle-management methods.
The one-hour catalog cache is another operational caveat, although it is smaller than the deployment-control gaps above. Enterprise App Catalog data can be cached for up to one hour. If Microsoft revokes a version because of a security issue, devices can remain exposed until the updated catalog state is reflected. Microsoft posts a notification when a malicious version is removed, but identifying affected devices and performing remediation remains the customer’s responsibility.

Microsoft also does not assert compliance, authorization, authenticity, or integrity for applications distributed through Intune. The administrator remains responsible for deciding whether an application and its version meet the organization’s security and compliance requirements.

What Changed in 2026

EAM has matured significantly in 2026. Auto-update reached general availability with Intune service release 2606, which rolled out during the week of June 29, 2026. This closed one of the biggest lifecycle gaps in the original implementation. Before auto-update, Microsoft still prepared the package and installation logic, but an administrator had to create the newer catalog application and complete the guided supersedence workflow for each release. Support for GCC High and DoD cloud environments also became generally available in the same service release.

Microsoft has also introduced Service Level Objectives for catalog update availability. The target is for approximately 80–90% of application updates to complete automated validation and become available in Intune within 24 hours of ingestion. Updates requiring manual validation are expected to complete within seven days. These are operational targets rather than contractual guarantees, but they give administrators a clearer idea of how quickly EAM is expected to react to a new vendor release. Auto-update does not mean instant update availability.

The catalog has expanded considerably since launch, and Microsoft continues to add applications on an ongoing basis. The raw catalog size matters less than how closely it overlaps with your own application estate. Different versions, editions, and architectures can also appear as separate catalog entries, so a large catalog does not automatically mean broad coverage for every organization.

The licensing change is likely to have the biggest impact on adoption. As of July 1, 2026, Enterprise App Management is included with eligible commercial Microsoft 365 E5 subscriptions. Microsoft stated that existing eligible customers would receive the new Intune entitlements automatically, with the rollout scheduled to complete by August 1, 2026.

This does not make EAM free, and it is part of a broader Microsoft 365 pricing and packaging change. But for organizations already committed to Microsoft 365 E5, it removes the need to purchase EAM as a separate add-on. The adoption question therefore shifts from whether EAM is worth an additional license to how much of the existing packaging workload and third-party tooling it can realistically absorb.

EAM vs. Dedicated Third-Party Tools

EAM does not yet match the deployment control of a mature third-party application management platform. Tools such as Patch My PC provide explicit update rings, phased deployments, dedicated pre-install and post-install scripting controls, and Update Only assignments that do not install an application on devices where it was never previously present. EAM does not currently offer native equivalents for all of these workflows.

That does not make EAM ineffective. It simply means the two solutions currently address different levels of complexity.

EAM is strongest with common, relatively low-risk applications where a standardized package and a clearly defined Required assignment are acceptable. For that part of the application portfolio, it can remove packaging and update work that a third-party platform would otherwise perform. For eligible Microsoft 365 E5 tenants, it can now do that without requiring a separate EAM add-on purchase.

Dedicated third-party tools remain relevant where the organization needs controlled pilot rings, phased production rollout, installation-aware update targeting, deeper scripting hooks, broader application coverage, or more mature lifecycle controls. The rollout and update-only targeting gaps alone can be enough to justify retaining those tools in environments with formal change-control requirements.

The Practical Take

EAM is not a complete replacement for a mature third-party application management platform, and it does not eliminate the need for application packaging skills. What it does well is remove a meaningful amount of repetitive work for common Windows applications, while keeping deployment, assignment, and reporting inside Intune.

The Microsoft 365 E5 packaging change improves the value proposition. When EAM no longer requires a separate add-on purchase, the question shifts from whether the feature is worth buying to how much of your existing tooling and manual effort it can absorb.

For most Windows-heavy tenants, the honest answer is a meaningful amount, but not all of it.

Evaluate EAM against your real application inventory rather than the size of Microsoft’s catalog. Keep your packaging capability for proprietary, customized, and industry-specific applications. Consider auto-update a strong fit for Required applications with a clearly defined deployment scope and no need for phased rollout not a hands-off guarantee and not something to run alongside another deployment method for the same product.

Frequently Asked Questions

Does Intune Enterprise App Management automatically update applications?

Yes, but the new EAM auto-update feature only applies to Enterprise App Catalog applications that have auto-update enabled and are assigned as Required.

Available assignments are not covered by this feature. For those applications, an administrator still needs to create the newer catalog application and configure the supersedence relationship. Intune’s existing Win32 supersedence auto-update behavior can then update managed installations that users previously installed through Company Portal.

Does EAM replace Patch My PC?

Not as a complete replacement in most mature environments. EAM works well for standardized Windows applications, but it currently lacks native phased deployment, rollback, discovery-based update-only targeting, and some of the advanced lifecycle controls available in dedicated third-party platforms.

The two can also serve different parts of the same application estate: EAM for straightforward catalog applications and a more advanced platform for applications requiring deeper control.

Is Enterprise App Management included in Microsoft 365 E5?

Yes. Enterprise App Management became part of eligible commercial Microsoft 365 E5 subscriptions as part of the July 1, 2026 packaging changes. Microsoft stated that existing eligible customers would receive the entitlement automatically, with rollout scheduled to complete by August 1, 2026. Standalone EAM and the Intune Suite remain available for organizations without an eligible subscription.

Can EAM update only devices where an application is already installed?

Not through the native Required-based EAM auto-update workflow. A Required assignment makes the application mandatory across the targeted group, so devices where the application is missing receive a new installation as well.

EAM does not currently create a discovery-based Update Only scope for arbitrary existing installations. Available applications previously installed through Company Portal can use Intune’s separate supersedence auto-update workflow after an administrator creates the newer application and supersedence relationship, but that is not the same as the native Update Only assignment offered by some third-party tools.

Further Reading

For Microsoft’s official documentation, requirements, current limitations, and update guidance, see Microsoft Intune Enterprise App Management.