A deployment rule that makes specific applications mandatory for targeted users or devices. It is the control layer that turns an application collection into an enforced installation workflow, which is why membership alone is never enough to prove compliance.
What a required apps policy actually does
A required apps policy does more than list approved software. It defines which applications must be present on a target set and turns that requirement into a deployment control, so compliance depends on enforcement rather than user choice.
This matters because the policy is judged by installation outcome, not by whether the app appears in a catalogue or group. A membership-based target can be directionally correct while still failing the control if deployment, reporting, or device state does not prove the app is actually installed.
How required apps policies fit into endpoint and mobile control
Required apps policies sit in the control layer between targeting and remediation. In practice, they are used to ensure baseline tools, security clients, productivity apps, or line-of-business applications are deployed to the right users or devices, often alongside mobile device management and application management workflows. NHIMG’s Mobile Device Security Guide is useful context for how deployment, enrolment, and app management fit together on managed endpoints.
The control usually works best when the target state is unambiguous. If a device is enrolled, compliant, and in scope, the policy can drive installation automatically; if the device is outside scope, missing management trust, or unable to receive software, the policy cannot be assumed to have succeeded just because the assignment exists.
Why membership alone is not enough
Group membership, device tags, or assignment rules only express intent. They do not prove that the application was downloaded, installed, launched successfully, or kept current. That distinction is important in environments where deployment can fail because of platform restrictions, stale inventory, network reachability, conflicting software states, or missing management channels.
For that reason, required app governance is really a closed-loop process: define the mandate, target the right population, confirm installation status, and handle exceptions where the endpoint cannot yet be brought into compliance. Conditional Access Guide is a useful adjacent reference when app requirement is paired with device or sign-in controls that depend on trust in the endpoint state.
Operational signals and common failure modes
A required apps policy becomes weak when reporting lags behind reality, when assignment scopes are too broad, or when the deployment mechanism is allowed to drift from the inventory source. In those cases, an organisation may believe it has enforced a standard application set while some devices remain non-compliant in practice.
Another common failure mode is treating the policy as a one-time rollout instead of a continuing control. Devices change ownership, fall offline, lose management connectivity, or get rebuilt, and the policy must still reassert the required state after those events.
Risk and Threat Considerations
Required app policies create exposure when organisations mistake assignment for enforcement. If the policy is intended to force a security tool, collaboration client, or business application onto managed devices, any gap between target membership and actual installation can leave a device unmanaged, unsupported, or unable to meet baseline security expectations.
Failure mechanism: the endpoint is considered compliant because it is in scope, but the application never installs, is removed, or cannot be validated as present because deployment telemetry, management trust, or reconciliation is incomplete.
Impact: users may operate without required controls, missing software may block dependent access decisions, and administrators may lose confidence in the device posture that other controls assume.
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 technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Required app policies enforce approved software state on managed endpoints. |
| Recommendation — Standardise and verify required software baselines across managed assets. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | App enforcement depends on accurate inventory and reconciliation of managed endpoints. |
| CM-7 — Least Functionality | Mandatory apps are part of defining and enforcing the minimum software set. | |
| Recommendation — Keep authoritative component inventories current before enforcing application mandates. Limit endpoints to the software needed for their approved role and usage. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Application enforcement is a configuration state that must be controlled and evidenced. |
| Recommendation — Control configuration baselines so required software remains in place. | ||
Practitioner Guidance
Why practitioners should care: the policy is only as strong as the evidence that the application is actually installed on the intended device or user population. Treat installation status as the control result, not the assignment itself.
What to watch for: reconcile device inventory, deployment status, and exception handling whenever a required app is tied to security posture or access decisions. If those signals disagree, the policy should be treated as unresolved rather than successful.
Related resources from NHI Mgmt Group
- Why do consumer apps complicate security policy for protected roles?
- What breaks when Content Security Policy is too permissive in Angular apps?
- What breaks when organisations rely on policy language but do not verify MFA is actually enforced everywhere it is required?
- What do security teams get wrong about policy enforcement for tracked SaaS apps?