How Enterprise App Management secures your App Catalog from ingestion to device
By: Joe Lurie, Sr. Product Manager | Microsoft Intune One of the most common questions I get from customers when I talk about Enterprise App Management is some version of: "Okay, but how do I know these apps are safe?" It's a fair question. You're trusting a catalog of pre-packaged Win32 apps to land on thousands of managed devices across your organization. If you're responsible for endpoint security, you should be asking that question. This post explains how Enterprise App Management works behind the scenes, how apps get into the catalog, what happens before they're visible to your tenant, and why the architecture matters for your security posture. The architecture: Not a new system, but an extension of what you already trust An important design decision with Enterprise App Management is that it's not a separate app delivery system. It's an extension of the existing Intune Win32 app architecture. From the admin perspective, everything starts in the Intune admin center. But behind the scenes, there's a clean separation between the control plane and the data plane: Control plane: For each app being added to the Enterprise App Management catalog, Intune curates app metadata, including app version, install commands, uninstall commands, detection logic, requirements, and supported configurations. This metadata is validated and normalized before it shows up in your tenant. That's why catalog apps behave consistently whether you're deploying to 50 devices or 50,000. Data plane: Once an app is assigned by an admin, it flows through the same Win32 app delivery and enforcement pipeline you already rely on. Your devices don't know they're installing an "Enterprise App Management app" - they're enforcing a Win32 app with well-defined intent. Same Enrollment Status Page support, same reporting, same retry logic, same Intune Management Extension. No new agent. No new runtime. And finally, Enterprise App Management apps have the same support for App Control for Business with Managed Installer which can automatically tag the apps as safe. This is important because it means Enterprise App Management inherits all the trust and operational maturity of Win32 app management in Intune. Curated content is delivered through established, reliable infrastructure. How Enterprise App Management apps are delivered: The ingestion pipeline This section walks through what happens from the moment an app is sourced to the moment it appears in your catalog. Content ingestion It starts with the catalog. Microsoft receives app metadata, including install and uninstall commands, version info, and download URLs. The data is then ingested, flattened, transformed, and Microsoft's own identifiers are applied. After the data lands in the database, eligibility and filtering gates are applied through allow and deny lists. Apps on the allow list are permitted to download content from controlled internet locations. This process handles both net-new apps and version updates to apps already in the catalog. Security and functional validation This is the part that answers the "how do I know it's safe?" question. Once content ingestion is complete, every app is submitted for security and functional validation. This is a queue-driven service that runs two parallel tracks: Static malware detection scans the installer and related artifacts for malicious content, assigning a VirusTotal score. If an app receives a non-zero score, it's blocked from proceeding, full stop. Static scanning is about establishing baseline trust before deployment. It validates that binaries are intact, that they originate from trusted sources, and they don't carry known indicators of malware or tampering. This process catches embedded malicious payloads, corrupted binaries, and known bad signatures before they can impact any device. Dynamic analysis (detonation) runs in parallel. The app is installed and uninstalled inside a VM detonation chamber, producing install results, logs, and artifacts. This is about validating behavior, not just files. Modern threats don't always look malicious at rest; some issues only surface when an installer or application runs or interacts with the system. Dynamic evaluation catches unexpected system changes, unsafe persistence mechanisms, and activity inconsistent with enterprise deployment expectations. If an app fails automatic validation, it goes through manual validation by Intune engineering. Both layers are required. Static scanning provides speed and broad coverage, while dynamic scanning provides depth and behavioral assurance. After publication: Ongoing scanning The security story doesn't end at publication. Apps already in the catalog are periodically re-scanned. If a version that previously passed validation is later found to fail a malware scan, it's flagged and removed from the catalog. This is a critical detail - the catalog isn't a snapshot-in-time trust decision. It's a continuously validated inventory. Update velocity Once a new app version is received, the target is to have it available in the catalog within 24 hours. Around 80–90% of apps hit that timeline. The remainder are apps that don't pass automatic validation and require manual review, which takes longer. But the pipeline processes updates through the exact same ingestion and validation flow as new apps - no shortcuts. Where Zero Trust fits in If you've been following Microsoft's Zero Trust model, this pipeline should feel familiar. Zero Trust is built on three principles: verify explicitly, use least-privilege access, and assume breach. EAM's validation pipeline maps directly to these: Verify explicitly: Every app is verified through multiple independent signals, including source integrity, static malware scanning, and dynamic behavioral analysis, before it's ever exposed to a tenant. No app gets a pass based on reputation or publisher name alone. Trust is earned through evidence, every time. Use least-privilege access: Enterprise App Management catalog apps ship with prefilled, scoped install and uninstall commands, detection rules, and requirements. You're not handing an installer broad system access and hoping for the best. The deployment surface is defined and constrained by design. Assume breach: This is why the pipeline doesn't stop at initial validation. Ongoing re-scanning means that even apps that previously cleared every check are continuously re-evaluated. If an app that was clean six months ago is later found to carry a risk, it's flagged and pulled from the catalog. The system assumes that trust is perishable, exactly the way Zero Trust says it should be. In practice, this means Enterprise App Management gives you an app lifecycle that's not just convenient - it follows the same security framework your organization is likely already adopting for identity, network, and device access. The app layer is often the last piece to catch up, and Enterprise App Management closes that gap. Here's the ingestion flow that shows how all of this fits together: The Enterprise App Management ingestion pipeline: from source metadata through content ingestion, static and dynamic security validation, manual review for failures, periodic re-scanning, and finally publication to the catalog. Takeaways If you're evaluating Enterprise App Management or explaining it to your security team, here's what I'd suggest that you land on: Enterprise App Management reduces the packaging tax. Pre-packaged apps with prefilled install details, detection rules, requirements, and restart behavior mean you spend less time building the same scaffolding repeatedly and more time on policy and rollout strategy. Patching becomes more predictable. Guided update flows using supersedence and a documented expectation of 24-hour update availability give you a cadence you can plan around, not react to. The security model is layered and continuous. Static scanning, dynamic detonation, manual review fallback, and ongoing re-scanning mean the catalog maintains a high trust bar - not just at ingestion, but over time. And it's all built on the same Win32 delivery infrastructure that you and your devices already trust. The bottom line: Enterprise App Management isn’t just about convenience. It shifts the app lifecycle from a manual, error-prone process to one with built-in security validation, operational consistency, and governance you can defend to your security team. Rather than manually sourcing installers and creating detection rules, use this approach to streamline the process. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam! Want to go deeper? Check out the Enterprise App Management documentation and keep an eye out for upcoming changes to Intune Suite licensing that will make Enterprise App Management available in the Microsoft 365 plans you may already own. And as always, drop feedback at aka.ms/IntuneFeedback.
We’re running into an Intune issue where a Win32 app with a dependency sits at "Download Pending"
Setup: Main App: Installs in User Context Dependency: Installs in System Context Dependency Detection: Hosts file modification detection script Direct file detection does NOT work either When the hosts file modification is present (detection is met), detection works, and everything installs fine manually The Problem: If detection passes (exit 0) → Everything installs fine. If detection fails (exit 1) → Intune never moves forward, just stays at "Download Pending" indefinitely. Happens with both file-based detection and script-based detection. Dependency app as well at parent app install fine via Intune on their own as well as manual testing. What We Need to Know: Does Intune get stuck in "Download Pending" instead of moving forward when dependency detection fails? Could the install context mismatch (dependency in SYSTEM, main app in USER) be causing this? Myth or fact? Does Intune break the install process if a dependency app is in system context and the parent app is in user context? Again, both apps work fine independent of each other. Thanks for any help!
Deploying Script as Win32 App
Hi all, I created a script that is supposed to check if a certain app was installed from a managed installer, then create a file in the C:\Temp folder if it was installed from a managed installer. I would deploy this as a Win32 app so that I could use the detection rules in the Win32 App deployment to check which device was installed via a managed installer. However, it doesn't seem to work. I created a transcript log as well to check if I would get an output from the variables, but it seems to only run the else block in the If Statement. We use a Business Premium license, so I don't access to Enterprise license capabilities like proactive remediation scripts. It is run using the System credentials, I've tested the script locally which works. Thank you, I've included some images of the script and transcript log. Script: Transcript Log Output:
Copy a OVPN file in Powershell from Intune
Sounds easy, my powershell script works fine if i run it on my machine, it copies the file into the %USERPROFILE%\OpenVPN\config folder. Its packaged up using the Intunewinapp program, but when i put it into intune it fails to install and copy the file over. Culd something like defender be stopping this process? The script works, the intune package works when launched from powershell, so what causes it to fail when i run it as a win32 app from intune? Anyone had this issue before? This is my script; $PSScriptRoot = Split-Path -Parent -Path $MyInvocation.MyCommand.Definition $Source = "$PSScriptRoot\Thornes.ovpn" $Destination = "$env:USERPROFILE\OpenVPN\config\" Copy-Item -Path $Source -Destination $Destination -Recurse -Force Thanks
Applications not appearing in Company Portal
I am looking for some help on why my applications I set up in Intune are not appearing in our Company Portal. Background Info: I work for an MSP and we have a client that we are taking on with devices enrolled in Intune. We have a remote agent that we would like to push to one of our clients as a Win32 app and make it a required install for the devices. My Setup: I have run through the process of packaging the app as a .intunewin file, I don't believe there is any error here. I am familiar with the install/uninstall commands and have tested via a direct install on a VM to ensure they work. I have a group set up with both a test user, and the test VM which is enrolled in Intune. I assigned this group and required the install. I also made the application available to all users in the Company Portal. The Issue: I believe all of these settings and setup are correct; however, I am not seeing any install or anything show up in the Company Portal. I verified that the device is definitely Intune-enrolled from within Endpoint Manager, and I verified I was logged in as my test user to the Company Portal app. I also checked the online version and same issue there. Within Intune, if I go to Devices > 'Test VM' > Managed Apps I can see my application listed there, with a status of "Waiting for Install Status". After letting this cook overnight, nothing changed. I synced from the VM and from Endpoint Manager with no success. To eliminate some of the complexity, I set up another app, this time just Spotify from the Windows Store which is fairly cut and dry. Same issue- I made it available for all users, it says that status is "Available for Install" from within Endpoint Manager on my test VM, but I see no apps in the Company Portal on that device. Has anyone experienced this before? Can you see anything I may be missing? Thanks in advance for any help you provide.Win32 applications are not appearing in the company portal
Hello, I am new to Intune and am experiencing an issue with Win32 apps not appearing in the company portal application. I can upload line-of-business apps and these apps do appear the company portal application and I can install them successfully. However, I seem to be missing something when uploading Win32 apps. To clarify, the Win32 application's Assignment is set under "Available for all enrolled devices" to a group that contains the Intune user who is logged in to the company portal. Any ideas why I can upload LOB apps to the company portal but not Win32? Thanks Joe F
Windows 10 and 11 package icons resources
Hello, I have a problem with my Packaged Win32 application icons resources on Windows 10 and 11. The icons look great in the Start menu and Taskbar but when I add a desktop short to my app, the icon is displayed with a blue background color. Here is my scenario : 1. I generate the resources.pri file using native Visual Studio tool (see attached capture) 2. Then I build an APPX package to publish it on the Store using the command line : "C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86\makeappx.exe" pack /d "E:[compiled app folder]" /p e:\package.appx 3. I can sideload my app using the PS1 command Add-AppxPackage -Register [package app folder]\AppxManifest.xml When deployed (sideload or by Store) the icons look nice in the Start menu and taskbar (see captures). When I drag the Icon from the Start menu to the desktop to create a shortcut, then the icon is not correct. Note : I generated all the visual assets using VS for all sizes/scales, and light/dark variants, and unplated. The appmanifest looks like that : <uap:VisualElements DisplayName="PageFabric" Description="PageFabric" BackgroundColor="transparent" Square150x150Logo="Assets\Square150x150Logo.png" Square44x44Logo="Assets\Square44x44Logo.png"> <uap:DefaultTile Wide310x150Logo="Assets\Wide310x150Logo.png" Square310x310Logo="Assets\LargeTile.png" Square71x71Logo="Assets\SmallTile.png"> <uap:ShowNameOnTiles> <uap:ShowOn Tile="square150x150Logo" /> <uap:ShowOn Tile="wide310x150Logo" /> <uap:ShowOn Tile="square310x310Logo" /> </uap:ShowNameOnTiles> </uap:DefaultTile> Anybody has an idea of what I miss for the desktop shortcuts? Thank you!
