4.1 Endpoint Privilege Management and Enterprise App Catalog
Key Takeaways
- Endpoint Privilege Management is the Intune Suite capability to let standard users complete approved elevated tasks without granting standing local administrator rights.
- A Windows elevation settings policy enables EPM, defines the default elevation response for unmatched requests, and controls elevation reporting back to Intune.
- Use Deny all requests or Require support approval as the safest default response; broad user-confirmed elevation can allow unmatched files to run elevated.
- Enterprise App Management provides the Enterprise App Catalog, a Microsoft-hosted catalog of prepared Win32 apps with prefilled install, uninstall, detection, and requirement settings.
- Enterprise App Catalog updates are not applied automatically; admins create a new app version and use supersedence when a catalog update should replace an older deployment.
Why this matters
The MD-102 exam tests the Intune Suite as an operating model, not as a list of add-ons. You should be able to choose the feature that removes a support bottleneck without weakening endpoint security. Endpoint Privilege Management (EPM) and Enterprise App Management are the two Intune Suite features most likely to appear in least-privilege and app-lifecycle scenarios.
EPM is for controlled elevation. Enterprise App Management is for app discovery, deployment, and update maintenance from the Enterprise App Catalog. Neither feature replaces planning. EPM still needs tight rules and reporting. Enterprise App Catalog apps still need assignments, detection review, vendor licensing, and update control. Both are licensed add-ons: they require the Intune Suite license or the standalone add-on license, which is a common exam distractor because the capability is invisible in the portal until the tenant is licensed.
What to use when
| Operational need | Use | Admin action | Watch for |
|---|---|---|---|
| Users need one approved tool to run elevated | Endpoint Privilege Management | Enable EPM with a Windows elevation settings policy, then create an elevation rules policy for the file or script | Do not make the user a local administrator just to solve one installer or support tool |
| Unknown elevation requests need help desk review | EPM support-approved elevation | Set the default response to Require support approval or create support-approved rules | Scope the approver role and collect business justification where useful |
| A known trusted app must elevate without user prompts | EPM automatic elevation | Create a narrowly matched elevation rule with strong file evidence | Use rarely; weak matching can elevate the wrong binary |
| Admins need common third-party Win32 apps with less packaging work | Enterprise App Catalog | Add a catalog app, review prefilled install and detection settings, then assign it | Microsoft prepares catalog metadata, but the customer still owns app approval and licensing |
| A catalog app has a newer version | Enterprise App Management update workflow | Create a new app from the available update and configure supersedence | Updates are surfaced in Intune but are not automatically deployed |
Endpoint Privilege Management workflow
EPM starts with a Windows elevation settings policy. This policy turns EPM on for the target users or devices, defines how unmatched elevation requests behave, and determines what elevation data is reported. In the Intune admin center it lives under Endpoint security > Endpoint Privilege Management > Policies. The settings policy is the gatekeeper: if EPM status is not Enabled, no elevation rule will function, so a scenario that says "rules are configured but elevation never works" usually points to a missing or disabled settings policy.
The default elevation response is the behavior for any process that does not match a specific rule. Options include Deny all requests, Require support approval, Require user confirmation, and (effectively) allowing nothing without a rule. The exam-safe defaults are Deny all requests or Require support approval, because a permissive default such as broad user-confirmed elevation lets users elevate arbitrary unmatched binaries, which defeats least privilege.
After settings are in place, create elevation rules policies for specific files or scripts. A rule identifies what can run elevated and how that elevation happens. Rules are matched by strong file attributes such as file name, hash, signing certificate, product name, and internal/version metadata. The exam often gives you a business need and asks which EPM behavior fits.
| EPM rule behavior | Meaning | Best-fit scenario |
|---|---|---|
| Deny | Do not allow the matched file to elevate through EPM | Block a risky installer or known unwanted tool |
| Support approved | A helper or admin must approve the request before elevation occurs | A rare tool is needed, but IT wants review before allowing it |
| User confirmed | The user confirms intent, optionally with business justification or Windows authentication | Low-risk self-service elevation with audit context |
| Automatic | The file runs elevated with no prompt | Highly trusted, business-critical software with strong rule matching |
A common exam trap is confusing EPM with Windows Local Administrator Password Solution (Windows LAPS) and with local group management. EPM grants temporary, per-process elevation for standard users. Windows LAPS rotates and escrows the local administrator account password. Local user group membership policy controls who belongs to groups such as Administrators. If the scenario says users should remain standard users while one approved process elevates, choose EPM; if it says rotate the local admin password, choose LAPS.
Enterprise App Catalog workflow
The Enterprise App Catalog is a catalog of prepared Microsoft and non-Microsoft Win32 applications hosted for Intune deployment. When you add a catalog app, Intune prepopulates many fields that would normally require packaging effort, including install and uninstall commands, return codes, restart behavior, requirement rules, and detection rules. This is the value proposition: catalog apps reduce the manual Win32 Content Prep Tool work for common third-party software.
Do not treat the catalog as an autopatch service for every app. For self-updating apps, Intune can confirm that the detected version meets a configured minimum version while the vendor's own updater performs the upgrade. For non-self-updating apps, Intune surfaces available updates, and the admin must create a new app version with a supersedence relationship to replace the older deployment. The catalog never silently mutates an already-deployed app object, so an answer claiming automatic in-place replacement is wrong.
Exam scenario pattern
When a question mentions local admin rights, approved elevation, support review, or keeping users as standard users, think EPM. When it mentions a curated catalog of common Win32 apps, reduced packaging, prefilled detection rules, or catalog updates handled with supersedence, think Enterprise App Management. When it mentions app protection policies, Conditional Access, or mobile app data controls, that is the application-management domain, not the Enterprise App Catalog itself. Tie each choice back to license availability and to the underlying admin action so close distractors do not pull you toward the wrong Intune Suite feature.
A line-of-business installer requires elevation once a month, but the security team does not want users to be local administrators. Which Intune Suite capability is the best fit?
Which statements correctly describe Endpoint Privilege Management planning?
Select all that apply
An app deployed from the Enterprise App Catalog has a newer catalog version available. What should an Intune admin do to deploy that update in a controlled way?