Join our Newsletter — 33% off our NHI Course

When should teams use per-user installation instead of machine-wide provisioning for Store apps?

Use per-user installation when the app is meant to appear in self-service for a logged-on user and can be installed in that user’s session. Use machine-wide provisioning only when the app must be present on the device image for all users and you are prepared to handle the extra licensing and package-hosting overhead.

Why the installation model matters for Store apps

The choice is less about packaging mechanics and more about who should be able to obtain the app, when it should exist on the device, and how much operational overhead you are willing to carry. Per-user installation fits a logged-on user’s session and keeps distribution scoped to that person. Machine-wide provisioning is a device-level decision, so it changes the deployment, licensing, and package-management burden.

Per-user installation is usually the better fit when the app is a self-service entitlement rather than a device baseline. That makes it easier to target only the users who need it, avoid preloading software for everyone, and keep the install lifecycle tied to the user’s account rather than the shared device state.

Machine-wide provisioning is the stronger choice when the app must be available on a managed device before any particular user signs in, or when the organisation wants the app to behave like part of the standard image. That model is useful for shared devices, kiosk-like use cases, and situations where administrators want the package present for all users without relying on first-run installation.

What changes operationally when you choose device-wide provisioning

Machine-wide provisioning usually introduces more coordination than user-scoped installation. The package has to be staged on the device, accounted for in the image or deployment flow, and managed across all future users of that endpoint. It also tends to increase the number of places where ownership, licensing, and removal decisions need to be tracked, because the app is no longer just a personal install.

Per-user installation reduces that shared-state complexity. The app appears only for the intended user, which simplifies scoping and reduces the chance that an application is visible to people who do not need it. For most business apps, that is the safer default unless the endpoint itself, not the user, is the true unit of deployment.

If you are deciding between the two, IAM and IGA Basics is the right place to think about whether the entitlement should be user-scoped or device-scoped. Joiner-Mover-Leaver (JML) Guide also helps frame the lifecycle side of the decision, especially when the app should follow the user’s onboarding and offboarding state.

When per-user install is the safer default, and when device scope wins

Per-user install is the safer default when the app is intended for individual productivity, needs to follow a person across sessions, or should be removable without affecting other users on the same device. It is also the better fit when you want the application to be requested or activated on demand rather than silently present on every endpoint.

Machine-wide provisioning wins when the device itself is the managed asset, such as a shared workstation, lab machine, or standard corporate image, and the app must be available before the user context is established. In that case, the deployment model is part of endpoint standardisation, not user preference.

For lifecycle-heavy environments, the NHI Lifecycle Management Guide is useful as an analogy for why provisioning scope matters: when something is created at the wrong layer, later cleanup and ownership become harder. The same practical lesson applies here, even though the subject is a Store app rather than an identity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
CIS Controls v8 CIS-5 — Account Management App provisioning scope is an account and entitlement decision.
Recommendation — Align app deployment to user and device account ownership, and remove access when entitlement ends.
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Store app access and provisioning often depend on managed credentials and their lifecycle.
AC-6 — Least Privilege Per-user installation is the least-privilege option when the app need not exist for all device users.
Recommendation — Manage application-related credentials so installs and access remain bounded to the intended user or device. Limit software availability to the smallest set of users and devices that actually need it.

Practitioner Guidance

What to verify: Confirm whether the app must be present for every user of the device or only for selected users. If the answer depends on the user’s role, start with per-user installation; if it depends on the endpoint’s role, machine-wide provisioning is more appropriate.

Common mistake: Do not use machine-wide provisioning just because it feels simpler during rollout. That often creates avoidable licensing overhead, broader exposure on shared devices, and more work later when the app needs to be removed, replaced, or audited.

Decision rule: If the app is meant to be self-service and user-owned in practice, keep it user-scoped. If it must be guaranteed on the device image for everyone who signs in, provision it at the machine level and accept the extra operational overhead as part of the design.

Practitioner takeaway: The key decision is whether the app belongs to the user session or to the device baseline, because that choice determines not just visibility, but also how cleanly you can govern deployment and removal over time.