A security hardening baseline is the agreed set of settings every device must have: which services are off, which protocols are disabled, how long a password lasts, who can log on remotely, whether the firewall is on. Most companies write one, apply it once, and assume it holds. It does not. Settings drift back through software installs, helpdesk fixes, group policy conflicts and users with local admin. This guide explains what a good baseline contains, why configuration drift happens, and how drift enforcement keeps the baseline true on every endpoint, every day, with evidence to show for it.
What a security hardening baseline actually is
A baseline is a list of configuration checks with an expected value for each. "SMBv1 is disabled" is a check. "The Guest account is disabled" is a check. "LLMNR is off", "the screen locks after 15 minutes", "PowerShell script block logging is on" are checks. A baseline for a Windows workstation commonly runs to several hundred of them.
You do not have to write one from scratch. Two public sources cover most of what a company needs:
- The CIS Benchmarks from the Center for Internet Security, available at https://www.cisecurity.org/cis-benchmarks, give a consensus list per operating system and application, each check with a rationale and a remediation.
- Microsoft publishes its own security baselines for Windows, Edge and Microsoft 365 Apps, documented at https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines.
Both are good starting points. Neither is a finished policy for your estate. A point-of-sale terminal, a developer laptop, a domain controller and a shared kiosk need different baselines. The work is choosing which checks apply to which group of machines, and which checks you deliberately leave out because they break something you need.
Baseline versus patching versus vulnerability management
These three are often confused because they all produce a "findings" list. They are different jobs:
| Discipline | Question it answers | Fixed by |
|---|---|---|
| Patching | Is the software version current? | Installing an update |
| Vulnerability management | Which known weaknesses exist here? | Patches, workarounds, removal |
| Hardening baseline | Is the device configured the way we decided? | Changing a setting |
A fully patched machine with RDP open to everyone, no firewall and the built-in Administrator account enabled is still an easy target. Patching closes holes the vendor made. Hardening closes holes you left open. If you are also building a patch process, see patch management rings for how to roll updates out safely.
Why configuration drift happens
Drift is the gap between the baseline you set and the state the machine is in now. It rarely comes from an attacker. It comes from ordinary work:
- A software installer re-enables a service or opens a firewall port it needs, and leaves it that way after uninstall.
- A helpdesk technician turns off a control to fix a user's problem and forgets to turn it back on.
- Two group policies set the same value to different things, and the winner changes when a machine moves OU.
- A user with local admin rights changes something because a tutorial told them to.
- A machine is rebuilt from an old image that predates the baseline.
- A laptop is off the network for weeks and never receives the policy refresh.
Each of these is small. Together they mean the estate you think you have and the estate you actually have diverge a little more every week. Applying a baseline is a one-time push. Enforcing it is a loop that measures, compares and corrects.
What good drift enforcement looks like
The pattern that works has four parts.
1. Measure on the device, not from a report
The agent on the endpoint reads the live value of each setting at a fixed interval and whenever something relevant changes. A report generated at deployment time tells you what you pushed, not what is there now. Reading from the registry, the service control manager and the local security policy on the machine itself is the only reliable source.
2. Compare against the baseline for that group
A single global baseline is a mistake. Servers that host remote desktop sessions must allow RDP. Kiosks may need auto-logon. Group machines by what they are for, give each group its baseline, and let a machine inherit the stricter rule when it belongs to two groups.
3. Correct automatically, within limits
When a value drifts, set it back. For most checks this is safe and should be automatic. For a few it is not: forcing a service off on a machine where a line-of-business application needs it will create a ticket every hour. Mark those as "report only" for that group, record why, and review the exception on a schedule. The decision should be per check, per group, not a single switch for the whole policy.
4. Keep the trail
Every correction is a change to a production machine. Keep who or what made it, when, on which device, and what the value was before. Without the trail you cannot tell drift from sabotage, and you cannot show an auditor that the control works. IT audit evidence from live data explains why "we have a policy" is not evidence but "the agent measured this value on this date" is.
Checks that belong in almost every baseline
Priorities differ, but a short list of settings shows up in almost every incident write-up when they are wrong. If you have nothing today, start here.
- SMBv1 disabled, and SMB signing required where the network can take it.
- LLMNR and NetBIOS name resolution off, so a rogue responder on the LAN cannot harvest credentials.
- The local Administrator account disabled or renamed, with a unique password per machine.
- The Guest account disabled.
- Windows Firewall on for all three profiles, with inbound default deny.
- Remote Desktop off unless the group needs it, and Network Level Authentication required when it is on.
- Screen lock after a short idle period, password required on resume.
- Autorun and AutoPlay disabled for all drives.
- PowerShell script block logging and module logging on, and transcripts kept.
- Credential Guard or LSA protection on where the hardware supports it.
- Anonymous enumeration of SAM accounts and shares denied.
- Audit policy covering logon, account management, policy change and object access.
- WDigest cleartext credential storage off.
- Office macros from the internet blocked.
Thirty enforced checks beat three hundred reported ones.
Standing admin rights undo every baseline
If users hold local admin, no baseline survives contact with them. They can stop the service that enforces it, change the setting, or uninstall the agent. Remove standing admin rights, then grant elevation for a named task for a limited time. Just-in-time admin rights covers the approach. Pair it with application control with default deny so that even a user who obtains elevation cannot run an unapproved tool against the baseline.
A practical hardening baseline checklist
Use this as the plan for the first ninety days.
- Pick a public reference (CIS Benchmark or Microsoft baseline) for each OS you run.
- Define device groups by purpose: workstations, laptops, RDS hosts, servers, kiosks, POS.
- For each group, choose the checks that apply and record the ones you exclude, with a reason.
- Measure the current state before you enforce anything, so you know the size of the gap.
- Start with the fourteen checks above in enforce mode on a pilot group.
- Set the rest to report only, watch for a week, then move checks to enforce in batches.
- Decide per check what happens on drift: auto-fix, fix and notify, or report only.
- Record every correction with device, time, previous value and the policy that triggered it.
- Review exceptions monthly and expire them; an exception without an end date is a gap.
- Rebuild your golden images from the baseline, so new machines do not start drifted.
- Make sure the enforcement agent itself is tamper-protected and reports when it is stopped.
- Tie compliance to a number per group that someone owns and that trends over time.
How Tracemark does it
Hardening is part of Tracemark's Exposure Management, alongside vulnerability ranking, open-port risk and the ransomware readiness score. The same agent that enforces DLP and device control on the endpoint reads the hardening state, so there is nothing extra to deploy.
The console shows the risky settings found on each device. A misconfiguration is fixed in one press from the console, and when the setting drifts back it is re-fixed. That re-fix is the drift enforcement loop described above: measure the live value on the device, compare, correct. Because the agent works offline with policies cached on the device, a laptop that is away from the network keeps its policy, and the events it generates are queued and sent when it reconnects.
Endpoints can be organized into dynamic groups built by rule, so a machine that changes role moves to the right group without anyone editing a list. Every change made from the console lands in the admin trail with who, what and when. The IT audit controls in Governance & Audit are measured from live data, where "not measured" is never counted as a pass, and the evidence is sealed into a pack the auditor can open. The combination means you can show an auditor the measured state, not a screenshot from the day you deployed.
Hardening sits next to vulnerability prioritization in the same product, so the team that fixes exploited CVEs first also sees the misconfigurations on the same machines.
Frequently asked questions
Is a CIS Benchmark the same as a security hardening baseline?
No. The benchmark is a reference list of recommended checks. Your baseline is the subset you chose to apply to a given group of machines, plus the exceptions you recorded. Applying every benchmark check to every device usually breaks something and gets the whole effort switched off.
How often should drift be checked?
Often enough that a drifted setting does not stay drifted through a full working day. An agent that reads settings on the device can check continuously or on a short interval at almost no cost. A scheduled scan from the network once a week leaves a window that is too long.
Should every drift be fixed automatically?
Most should. The exceptions are checks where the fix is known to break a required application on a specific group. Set those to report only for that group, document the reason, and give the exception an expiry date. Do not turn off enforcement for the whole policy because of one check.
How do I prove the baseline is enforced during an audit?
Show the measured value per device with a timestamp, the policy it was compared against, and the record of corrections. Evidence that the control ran and what it found is what auditors accept. A policy document and a screenshot of a settings page are not evidence that the setting is in place on the machines.
Try it
Try Tracemark free for three months. Claim it at tracemark.ca