I am currently working on hardening our Windows OS systems. I'm reviewing guidance from CIS and Microsoft Security Compliance Manager. What I have found is that many of the security settings are already set to the recommended setting by default. This means that if I do nothing and leave the policy set to "Not Configured", the system will be in the ideal security state.

Here is my question: Is it prudent to go ahead and use group policy to enforce ALL security settings to the desired state?

Advantages I see*: Local administrators cannot change the policy. Malicious changes will revert during next group policy refresh.

Disadvantages I see: OS updates that change the default configuration will not be applied because the GPO will enforce a different setting. Lower group policy load times.

Is there any standard or guidance from Microsoft or another security authority (SANS, etc...) that addresses this issue?

Thanks in advance!

3 Answers 3


From the Microsoft perspective, I can tell you that this is something that the team responsible for publishing the security configuration baselines has changed position on over the years. In the past, they use to publish baselines with the recommended values specifically set, even if they were already the default. However, they no longer do that. Now, for policies that already have secure defaults, they are left as "not configured" instead. This makes administration and management significantly simpler, which experience appears to show is the better option.


If you don't enforce a policy and you have a security audit, one of the questions from the auditor will be: "How do you know these settings are applied? How do you know someone didn't change the defaults?"

How are you going to answer that?


Myron, I tend to agree with your thinking. I still do. It looks like Microsoft is, understandably, striking a balance between security and sanity.

Xander, thanks for that answer. I found a reference from Aaron Margosis at Microsoft that confirms what you said. Here is what the author said:

As mentioned, we’re enforcing defaults only for security-sensitive settings that are otherwise likely to be set to an insecure state by an authorized user. So, for example, on Windows client the User Rights Assignment, “Change the time zone” (SeTimeZonePrivilege) is granted to Administrators, Users, and Local Service. In the past we enforced that through the security baseline. Changing that setting requires administrative rights, and it’s unlikely that an authorized administrator would change it to a less-secure value. On the other hand, administrators are known to disable User Account Control, so we enforce that default.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .