Security Policy via the command line

Van Fifty 40 Reputation points
2026-06-09T20:42:07.9133333+00:00

I read here that to set the Local Security Policy (I am using Win11 Enterprise) via the commandline to change settings such as passwordcomplexity, one can use secedit to export the security settings and then the given item can be modified and the entire configuration reimported.

I exported the security settings using secedit /export /cfg c:\test\secpol.cfg and shorted the configuration file to something like the following:

[Unicode]
Unicode=yes
[System Access]
MaximumPasswordAge = 60
PasswordComplexity = 1
[Version]
signature="$CHICAGO$"
Revision=1

I then imported the partial configuration using secedit /configure /db c:\windows\security\local.sdb /cfg c:\test\secpol.cfg /areas SECURITYPOLICY

The changes were applied successfully when I view it via secpol.msc.

I would like to know if only reimporting a specific section like I have done will have any negative consequences? I also found that I needed to include the [Version] section to prevent secedit from generating an error on import.

Also one comment in the above link mentioned: "...The one thing to note is that exporting the policy violates the system security, since it exposes it..." I am assuming that applies to if you export the entire configuration and leave the file accessible, correct?

[Moved from Windows for home | Windows 11 | Security and privacy]

Windows for business | Windows 365 Enterprise
0 comments No comments

Answer accepted by question author
Jason Nguyen Tran 26,970 Reputation points Independent Advisor
2026-06-11T00:33:26.8633333+00:00

Hello Van Fifty,

Using secedit to export, modify, and reimport security policy settings is a valid approach, and reimporting only a specific section (like [System Access]) generally does not cause negative consequences as long as the required [Version] header is present. Windows expects that section for consistency, which is why you saw errors without it. The partial import simply overwrites the targeted settings, leaving other areas of the policy untouched.

That said, it’s important to be cautious: if the configuration file is incomplete or malformed, you could unintentionally reset or clear other policy areas. To minimize risk, always keep a full backup of the original exported configuration before applying changes. This way, you can restore quickly if something doesn’t behave as expected.

Regarding the comment you read about exporting “violating system security,” you’re correct in your assumption. The concern is mainly about exporting the entire policy and leaving the file accessible, since it exposes sensitive configuration details. As long as you handle the file securely, store it in a protected location and delete it when finished, the risk is minimal.

In practice, your approach of importing only the relevant section is fine, and many administrators use it to streamline changes. Just remember to validate the applied settings with secedit /analyze or by checking secpol.msc afterward, which you’ve already done successfully.

I hope the response provided some helpful insight. If you find this answer useful, please hit “accept answer” so I know it addressed your concern.

Jason

Was this answer helpful?

1 person found this answer helpful.
0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.