How to Configure Security Policies

Overview

Why a security policy needs a configuration level before anything else

A security policy is only as useful as the catalog of settings it draws from, and that catalog changes completely depending on who the policy targets. A policy aimed at a computer covers a small, fixed set of machine-wide restrictions. A policy aimed at a user opens up a much larger catalog organized into categories like Desktop, Internet Explorer, Network, System, and more. Picking the wrong configuration level first means building against the wrong list of settings entirely.

Security Policies is built around that split: choose a Configuration Level (Computer or User), pick the individual policies to Enable or Disable from whichever catalog that level exposes, save the policy, then deploy it to the endpoints that should receive it. Every deployment reports its own stage and progress, and a per-endpoint output log shows exactly which registry values were set, deleted, or reverted.

This guide walks the full workflow end to end: opening the Security Policies module, building a Computer-level policy, building a User-level policy from the larger catalog, deploying a policy to specific endpoints, and confirming the deployment applied the expected registry changes on a live endpoint.

• Configuration Level changes the entire catalog: Computer level exposes a small, fixed policy list; User level exposes a multi-category catalog (Desktop, Internet Explorer, Network, System, Active Desktop, Explorer, Start Menu and Taskbar, Task Scheduler, Windows Installer, Control Panel, and more).
• Every individual policy is a three-way switch: each setting is Enable, Disable, or Not Configured - leaving it Not Configured means the policy doesn't touch that setting at all.
• The Apply checkbox label follows the configuration level: it reads Apply On Startup for Computer-level policies and Apply On User Login for User-level policies.
• Deployment scope is the same across modules: target All Endpoints, Specific Endpoints, Specific Departments, Specific Locations, or Windows devices from a single deployment.
• The output log names the exact registry change: each applied policy logs whether a registry value was set to a specific value or deleted to revert to the OS default.
• See deployment status per task: Stage (Initiated/Completed) and per-endpoint task Status (Success/Failed) are both tracked, alongside the full output log.

Prerequisites

Confirm these before creating a security policy. Picking the wrong Configuration Level, or leaving every setting at Not Configured, are the most common reasons a "created" policy has no real effect once deployed.

1. Administrator access: your account holds a role permitted to manage the Device Control -> Security Policies module.
2. Agent installed and reporting: the endpoint agent is installed, registered, and reporting healthy on every target device you plan to deploy to.
3. Configuration Level decided: know whether the restrictions you need belong at the Computer level (a small, fixed set) or the User level (the larger, category-based catalog), since the two expose entirely different policy lists.
4. Individual settings identified: have a clear list of which specific policies should be Enabled or Disabled, rather than working through every category live during creation.
5. Deployment scope confirmed: know whether this policy should go to specific endpoints, a department, a location, or the whole fleet.

Architecture: how a security policy definition becomes a registry change

A security policy entry defines which individual settings are enabled or disabled for a given configuration level. A deployment decides which endpoints receive it and under what policy. The output log is the record of what the endpoint agent actually changed.

Step 1: Open Security Policies

Get oriented before creating anything, so you know where policies and deployments each live.

Instructions

1. From the main console, go to Endpoints -> Device Control.
2. Select the Security Policies module.
3. Note the two sections in the left sidebar: Security Policies (definitions) and Security Policy Deployments (rollouts and status).

Path: Console / Endpoints / Device Control / Security Policies

Result: You're in the Security Policies module with visibility into any existing policies before authoring a new one.

Step 2: Create a Computer-level policy

Build a policy from the small, fixed catalog that applies at the machine level, independent of who signs in.

Instructions

1. Go to Security Policies -> Create.
2. Enter a Name describing the policy's intent, e.g. Windows Security.
3. Set Configuration Level to Computer.
4. Optionally enter a Description and toggle Apply On Startup if the policy should apply as soon as the machine boots.
5. Under Group Policies -> Computer, set each relevant setting to Enable or Disable, leaving the rest at Not Configured.

Path: Console / Device Control / Security Policies / Create

Console: Computer-level catalog

Result: The policy's Computer-level settings are staged. Nothing is applied to an endpoint yet - that happens once the policy is deployed in Step 4.

Step 3: Create a User-level policy from the group policy catalog

Switch to the User configuration level to reach the full, category-based catalog of settings.

Instructions

1. In Configuration Level, choose User. The Apply On Startup checkbox becomes Apply On User Login, and the Group Policies section switches to a row of category tabs.
2. Browse the tabs - Desktop, Internet Explorer, Network, System, Active Desktop, Explorer, Start Menu and Taskbar, Task Scheduler, Windows Installer, Control Panel, and more - to find the settings you need.
3. Within any tab, set the relevant policies to Enable or Disable.

Path: Console / Device Control / Security Policies / Create

Console: sample User-level tabs and policies

Result: A User-level policy is staged against the specific category settings you enabled or disabled, ready to be saved as its own policy or combined with a Computer-level policy under a different name.

Step 4: Save the policy and deploy it to endpoints

Save the definition, then push it out to the endpoints that should receive it.

Instructions

1. Select Create to save the policy. It appears in the Security Policies list with its Configuration Level.
2. Go to Security Policy Deployments -> Create.
3. Enter a Deployment Name, e.g. Windows Security, and an optional Description.
4. Set Scope to All Endpoints, Specific Endpoints, Specific Departments, Specific Locations, or Windows.
5. If you chose Specific Endpoints, search and select each target endpoint under Endpoints.
6. Under Security Policy, choose the policy you created, e.g. Windows Security.
7. Set Deployment Policy, e.g. OOB Instant deployment policy.
8. Optionally set Notify To, then select Publish and confirm in the dialog asking "Are you sure you want to Publish Deployment: <deployment name>?"

Path: Console / Device Control / Security Policies / Security Policy Deployments / Create

Console: deployment definition

Result: A new deployment is created and immediately begins rolling out. It starts in the INITIATED stage with 0/1 progress before it's picked up by the targeted endpoint agent.

Step 5: Monitor the deployment and confirm the registry changes

Verify the whole chain - policy, deployment, and endpoint agent - actually results in applied settings, rather than assuming the deployment succeeded.

Instructions

1. Return to Security Policy Deployments and locate the deployment by name.
2. Read the Stage column: INITIATED means the deployment has started but not finished; COMPLETED confirms the endpoint agent finished applying it.
3. Select the deployment's view icon to open its Tasks list, showing each targeted endpoint's Status (SUCCESS or FAILED) and Last Updated time.
4. Open a task's view icon to see the per-endpoint Output log.

Path: Console / Device Control / Security Policies / Security Policy Deployments

Console: deployment status

Result: Confirmed, evidence-backed rollout - the task output names the exact registry value each enabled or disabled setting touched, and any setting left at Not Configured is simply skipped rather than logged as applied.

Best practices for security policies

Troubleshooting: common issues and resolutions

Frequently asked questions