Use PowerShell to modify who can read and write Windows Registry keys

PowerShell lets you change Registry permissions without opening the Registry Editor by hand. You run a command that targets a specific Registry path, specifies which user or group gets access, and defines what they can do — read, write, delete, or a combination. The process involves getting the current permissions, building a new permission rule, and applying it to the Registry key.

This approach is faster than clicking through the GUI when you need to change permissions on many keys at once, and it leaves a record of what changed if you run it from a script. You do need to run PowerShell as Administrator, and you need to know the exact Registry path and the username or group name you want to grant access to.

Key Takeaways

  • PowerShell requires Administrator privileges to change Registry permissions; right-click PowerShell and select "Run as administrator" before you start.
  • You must know the full Registry path (for example, HKLM:\Software\MyApp) and the exact username or group name you want to modify permissions for.
  • The process uses three steps: get the current permissions object, create a new permission rule, and apply it using Set-Acl.
  • Permission types include FullControl, ReadKey, WriteKey, and Delete; combining them requires the -bor operator in PowerShell.
  • Changes apply only to the key you specify unless you add the -Recurse flag, which pushes the same permissions down to all subkeys.

Open PowerShell as Administrator and navigate to the Registry

Right-click the PowerShell icon and select Run as administrator. A window will open asking whether you want to allow the app to make changes to your device — click Yes. Without Administrator privileges, PowerShell cannot change Registry permissions.

Once PowerShell is open, you do not navigate to the Registry the way you would in File Explorer. Instead, you reference Registry paths as if they were folders. The top-level Registry hives have short names: HKLM: for HKEY_LOCAL_MACHINE, HKCU: for HKEY_CURRENT_USER, HKU: for HKEY_USERS, and HKCR: for HKEY_CLASSES_ROOT. You can type a path directly into a command without changing directories first.

Get the current permissions on the Registry key

Before you change permissions, retrieve the current access control list (ACL) for the key. Type this command, replacing the path with the Registry key you want to modify:

$acl = Get-Acl -Path "HKLM:\Software\MyApp"

This command reads the permissions on that key and stores them in a variable called $acl. You can use any variable name you want, but $acl is conventional. If the path does not exist, PowerShell will return an error — double-check the spelling and capitalization of the Registry path.

You can view what permissions are currently set by typing $acl.Access and pressing Enter. PowerShell will list each user or group that has access, what type of access they have, and whether the permission applies to subkeys. This step is optional but useful if you want to see what you are starting with.

Create a new permission rule and add it to the ACL

Now you build a permission rule that specifies who gets access and what they can do. The command structure is:

$rule = New-Object System.Security.AccessControl.RegistryAccessRule("DOMAIN\Username", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")

Replace DOMAIN\Username with the actual username or group. If the account is on your local machine, use the computer name instead of a domain — for example, COMPUTERNAME\Username. For the local Administrators group, use BUILTIN\Administrators. The second parameter, "FullControl", is the permission level; other options are ReadKey, WriteKey, Delete, QueryValues, and SetValue. You can combine multiple permissions by separating them with commas and wrapping them in quotes, or by using the -bor operator if you are building the rule in a more complex way.

The "ContainerInherit,ObjectInherit" part tells PowerShell whether the permission should pass down to subkeys. Use this exact string if you want subkeys to inherit the permission. Use "None" if you want the permission to apply only to this key. The last parameter, "Allow", grants the permission; you could use "Deny" to block access instead.

Once you have built the rule, add it to the ACL object:

$acl.AddAccessRule($rule)

Apply the new permissions to the Registry key

Now write the modified ACL back to the Registry key:

Set-Acl -Path "HKLM:\Software\MyApp" -AclObject $acl

Use the same Registry path you used in the Get-Acl command. If the command succeeds, PowerShell will not print anything — silence means it worked. If there is an error, PowerShell will display it in red text; common errors include a path that does not exist, a username that is not recognized, or insufficient permissions on the key itself.

If you want to apply the same permissions to a key and all of its subkeys at once, add the -Recurse flag:

Set-Acl -Path "HKLM:\Software\MyApp" -AclObject $acl -Recurse

This will push the new permission down through the entire tree. Be careful with -Recurse on high-level keys like HKLM:\Software, because it will change permissions on many keys at once and can make the system unstable if you remove access from critical accounts.

Remove a user or group from Registry permissions

To remove someone's access entirely, retrieve the ACL, find the rule that applies to that user, and delete it:

$acl = Get-Acl -Path "HKLM:\Software\MyApp" $rule = $acl.Access | Where-Object { $_.IdentityReference -eq "DOMAIN\Username" } $acl.RemoveAccessRule($rule) Set-Acl -Path "HKLM:\Software\MyApp" -AclObject $acl

The second line searches the current permissions for a rule matching that username. If multiple rules exist for the same user (for example, one that allows and one that denies), you will need to be more specific in the filter. Once you have identified the rule, RemoveAccessRule deletes it from the ACL, and Set-Acl writes the change back.

Frequently Asked Questions

What happens if I change permissions on a key I should not have touched?

If you lock yourself out of a critical Registry key, you may not be able to boot Windows or access system functions. If you have a backup or a restore point, use it. Otherwise, boot into Safe Mode with Command Prompt, log in as Administrator, and use the same PowerShell commands to restore the original permissions — you will need to know what they were before the change.

Can I change permissions on HKEY_LOCAL_MACHINE keys without being an Administrator?

No. HKLM keys are system-wide and protected. You must run PowerShell as Administrator. HKEY_CURRENT_USER keys can sometimes be modified with a standard user account, but HKLM always requires elevation.

How do I give a user permission to read a key but not write to it?

Use "ReadKey" instead of "FullControl" in the permission rule. If you want to combine multiple specific permissions, use [System.Security.AccessControl.RegistryRights]::QueryValues -bor [System.Security.AccessControl.RegistryRights]::EnumerateSubKeys in place of the permission string.

What is the difference between "ContainerInherit,ObjectInherit" and "None"?

"ContainerInherit,ObjectInherit" means the permission flows down to all subkeys and values under the key you are modifying. "None" means the permission applies only to that specific key. Use "None" if you want fine-grained control over which keys each user can access.

Can I undo a permission change if I make a mistake?

If you wrote down or captured the original permissions before making changes, you can reapply them using the same process. If you did not, and you cannot boot the system, you will need to use recovery tools or restore from backup. Always test permission changes on a non-critical key first.