sc.exe privs sets the required-privileges list for a Windows service. It is the write-side companion to Windows Command #46 – sc qprivs, which reads the current setting.

This command is part of Windows Service Hardening. Its purpose is to reduce the privileges available inside a service process token to the minimum the service actually needs. It does not grant a service account new user rights or elevate an account that does not already possess a privilege.

S4 Events — Hardcore Windows Hardening includes practical discussion of Windows Service Hardening and reducing unnecessary service privilege.

Learning Objectives

• Explain what sc.exe privs changes.
• Distinguish required service privileges from account user rights.
• Set one or more required privileges for a service.
• Verify the result with sc.exe qprivs.
• Understand why the change takes effect on the next service start.
• Understand shared-process privilege unions.
• Recognize common failure and recovery risks before modifying production services.

What Required Privileges Mean

Microsoft documents the required-privileges configuration through SERVICE_REQUIRED_PRIVILEGES_INFO. When a service has a required-privilege list, the Service Control Manager removes privileges that are not required from the process token when the service process starts.

This is a least-privilege control. If no required list is configured, the Service Control Manager can use the privileges normally available to the process token. If a list is configured, Windows keeps the privileges needed by the service and removes unneeded ones. Microsoft specifically recommends using the minimum privilege set required by the service.

For compatibility, SeChangeNotifyPrivilege is not removed by this mechanism even when it is not explicitly requested. That is why administrators should not assume the displayed list is a complete description of every privilege present in the final process token.

Basic Syntax

General form: sc.exe privs SERVICE_NAME PRIVILEGE_LIST

When several privileges are required, sc.exe accepts the privilege names as a slash-separated list. A common documented form is SeBackupPrivilege/SeRestorePrivilege.

Example: sc.exe privs DemoService SeBackupPrivilege/SeRestorePrivilege

The privilege names must be valid Windows privilege constants. Do not invent names from display labels. Windows privilege constants use forms such as SeBackupPrivilege, SeRestorePrivilege, SeImpersonatePrivilege, and SeCreateGlobalPrivilege.

Be App Savvy — overview of the Windows Service Control Manager, the component that maintains service configuration and controls service startup and runtime state.

Always Query Before You Change

Before using sc.exe privs, record the existing configuration with sc.exe qprivs SERVICE_NAME. Also inspect the service itself with sc.exe qc SERVICE_NAME. This gives you the service account, startup configuration, binary path, service type, and the current required-privilege list before you modify anything.

This connects directly to Windows Command #38 – sc qc. The safest workflow is read, record, change, restart in a lab, then verify.

The Change Takes Effect on the Next Service Start

Microsoft states that required-privilege changes take effect the next time the service starts. Changing the configuration does not rebuild the token of a service process that is already running.

That means a normal verification sequence is: run sc.exe qprivs SERVICE_NAME, change the list with sc.exe privs, query the setting again, restart the service during an approved maintenance window, then verify service functionality.

If the service is critical, do not test this sequence directly in production. A privilege that looks unnecessary may be required only during startup, backup, recovery, impersonation, object creation, or another code path that is not exercised continuously.

Required Privileges Do Not Grant Account Rights

This distinction is essential. The service account may receive user rights through Local Security Policy, Group Policy, local groups, domain policy, or other security configuration. The sc.exe privs setting does not add those rights to the account. It tells the Service Control Manager which available privileges should remain in the service process token.

For example, listing SeBackupPrivilege does not magically grant backup rights to an account that does not possess them. The Service Control Manager determines whether the service can support the requested privilege configuration when the service starts.

AdvancedInstaller community discussion — useful contrast between account-level “Log on as a service” rights and the separate least-privilege controls applied to a service process.

Shared-Process Services Need Extra Care

Many Windows services share a process such as svchost.exe. Microsoft documents that when several services share one process, the Service Control Manager computes the union of the privileges required by all services in that process.

That means reducing one service’s configured list may not remove a privilege from the shared process if another service hosted in that same process still requires it. Use sc.exe qc and sc.exe queryex to understand the service type and process context before drawing conclusions from a privilege change.

Set a Single Required Privilege

Example: sc.exe privs DemoService SeImpersonatePrivilege

After the command succeeds, verify the stored configuration with sc.exe qprivs DemoService. Do not treat a successful configuration command as proof that the service will still work. The functional test occurs after the service starts and runs through the operations it actually needs.

Set Multiple Required Privileges

Example: sc.exe privs DemoService SeBackupPrivilege/SeRestorePrivilege

The slash separates privilege names for sc.exe. Record the exact original list before replacing it. Treat the list as a complete service-hardening setting, not as an informal note where you can add one privilege without considering the others already required.

Remote Configuration

The general SC syntax allows a remote server name before the command. A remote form is sc.exe \\SERVER01 privs DemoService SeBackupPrivilege/SeRestorePrivilege.

Remote service configuration requires network reachability and sufficient Service Control Manager permissions on the target system. An access-denied response is an authorization problem; it does not mean the service lacks the requested privilege configuration.

r/sysadmin discussion — administrators discuss how Windows service control is permission-sensitive and why delegating service-management capabilities requires careful security boundaries.

Why Least Privilege Matters

Windows privileges are not ordinary file permissions. They are operating-system capabilities that can allow sensitive actions such as backing up protected data, restoring files, impersonating security contexts, changing system state, or interacting with protected resources.

If a service is compromised, every unnecessary privilege left in its process token can increase the impact of that compromise. The value of sc.exe privs is therefore not simply configuration convenience; it is reduction of attack surface.

Microsoft’s service-hardening guidance describes this directly: services can declare the privileges they require, and the Service Control Manager removes privileges that are not required. The safest target is the smallest list that allows the service to operate correctly.

Troubleshooting Order

1. Run sc.exe qprivs SERVICE_NAME and save the original list.
2. Run sc.exe qc SERVICE_NAME and record the service account and service type.
3. Confirm the exact Windows privilege constant you intend to use.
4. Make the change only on a disposable or approved test service first.
5. Run sc.exe qprivs SERVICE_NAME again and confirm the stored result.
6. Restart the service because the privilege-token change applies on the next start.
7. Run sc.exe queryex SERVICE_NAME and verify the service actually started.
8. Exercise the service’s real workload, not only its start command.
9. If startup or functionality fails, restore the recorded original configuration.
10. For shared-process services, remember that another service in the same process can keep a privilege present.

Common Mistakes

• Confusing service privilege restriction with account rights: sc.exe privs does not assign a user right to the service account.
• Changing production first: a missing privilege may break a startup or recovery path that is rarely used.
• Forgetting the restart: the running process keeps its existing token until the service starts again.
• Using the display name instead of the service name: SC commands normally expect the service name.
• Ignoring shared hosting: a shared process can retain the union of privileges required by multiple services.
• Failing to record the original list: rollback becomes harder if the old configuration was not captured.

Practice Lab

1. Use a disposable Windows VM and choose a noncritical test service.
2. Run sc.exe qc SERVICE_NAME and record the service account and service type.
3. Run sc.exe qprivs SERVICE_NAME and save the original output.
4. Choose a privilege list appropriate to the test service only if you understand why that service needs it.
5. Apply the list with sc.exe privs SERVICE_NAME PRIVILEGE_LIST.
6. Query the list again with sc.exe qprivs SERVICE_NAME.
7. Restart the service in the lab.
8. Verify status with sc.exe queryex SERVICE_NAME.
9. Run the service’s normal workload and check Event Viewer for startup or privilege-related errors.
10. Restore the original list when the lab is complete.

Knowledge Check

1. What does sc.exe privs change?
2. Does it grant a service account a privilege that the account does not already possess?
3. When does the new required-privilege list affect the service process token?
4. How are multiple privilege names separated in the SC command syntax?
5. Which command should you run before and after the change to inspect the list?
6. What happens when multiple services share one process?
7. Which privilege is retained for compatibility even when it is not explicitly requested?
8. Why is a successful sc.exe privs command not enough to prove the service still works?

Answers

1. The service’s required-privileges configuration.
2. No. It restricts which available privileges remain in the service process token; it is not an account-right assignment mechanism.
3. The next time the service starts.
4. With forward slashes, such as SeBackupPrivilege/SeRestorePrivilege.
5. sc.exe qprivs SERVICE_NAME.
6. The Service Control Manager uses the union of the privileges required by the services sharing that process.
7. SeChangeNotifyPrivilege.
8. Because the real test is whether the service can start and complete its required workload with the reduced token.

Key Takeaway

sc.exe privs is a Windows Service Hardening command, not an elevation command. Use it to reduce a service process to the minimum privileges it truly needs, verify every change with qprivs, restart to apply the new token, and test the complete service workload before treating the configuration as safe.

Primary references: Microsoft Learn — Configuring a Service Using SC, Microsoft Learn — SERVICE_REQUIRED_PRIVILEGES_INFO, and Microsoft Learn — Service Changes for Windows Vista / Running with Least Privilege.

BitcoinVersus.Tech Editor’s Note: Service privilege changes can break software or reduce security if they are applied without understanding the service’s real requirements. Test on disposable systems first and document rollback before changing production services.

Support independent technology education: Bitcoin donations help fund BitcoinVersus.Tech research and publishing.

BitcoinVersus.Tech provides technical education and analysis for informational purposes only.