NIST CSF 2.0 on Windows Endpoints: Mapping Govern, Identify, Protect, Detect, Respond, and Recover to Real Audits

Most compliance frameworks tell you what "good" looks like. The NIST Cybersecurity Framework (CSF) 2.0 is different: it tells you how to organize good into six functions — Govern, Identify, Protect, Detect, Respond, and Recover — and it deliberately leaves the "how do I check this on an actual machine" part to you. This post closes that gap for Windows endpoints. For each function, here is what it means in practice and which WinSentinel audits give you evidence for it.

Govern: who owns the risk, in writing

Govern is the function CSF 2.0 added, and it is the one most endpoint programs skip. It asks: who decided this configuration is acceptable, and where is that decision recorded? A fleet where every machine has a different local admin policy is not a technical problem first — it is a governance problem. The audit trail starts with a baseline: a written standard for local administrator membership, password policy, audit policy, and update deadlines, applied the same way everywhere.

WinSentinel's local admin, LAPS, audit policy, and update policy checks give you the raw material: a per-machine verdict against that baseline. The governance step is yours — record the baseline, record the exceptions, and review the exceptions on a schedule. An exception nobody reviews is just drift with a nicer name.

Identify: know what you actually have

You cannot protect an asset you have not inventoried. On Windows, "inventory" means more than a hostname list: installed software, enabled optional features, running services, scheduled tasks, startup entries, and saved Wi-Fi networks all expand what an attacker can reach. WinSentinel audits each of these surfaces on a single machine, with the full set of 64 audit modules available in the free tool — no module is held back from a one-machine audit.

The practical habit: run the full audit on a newly imaged machine before it joins the network, and again after any major software rollout. The delta between those two runs is your real change record, and it is far more useful than a screenshot of a dashboard that says "compliant."

Protect: close the doors you can name

Protect is where most Windows hardening guides live, and it maps cleanly to audits: SMB signing and SMBv1 retirement, NTLM hardening and LDAP signing, LSA protections like Credential Guard and disabling WDigest, firewall rule hygiene, BitLocker and Secure Boot status, and application allowlisting with WDAC or AppLocker. Each of these is a setting an attacker tests early — pass-the-hash needs NTLM weaknesses, credential theft needs an unprotected LSASS, lateral movement needs weak SMB and firewall rules.

The mistake to avoid is treating Protect as a one-time project. Protections decay: a troubleshooting session disables a firewall rule, a legacy app demands SMBv1 back, a vendor installer re-enables an old protocol. Re-running the audit on a schedule turns Protect from a project into a posture.

Detect: prove you would notice

Detect is the function that separates a hardened machine from a monitored one. Windows gives you the telemetry for free — advanced audit policy, PowerShell module and script block logging, Sysmon if you deploy it, and Windows Event Forwarding to collect it centrally — but only if someone configured it and someone reads it. WinSentinel checks whether those logging surfaces are actually enabled and correctly configured, because a log source that was never turned on is the most common detection failure there is.

Ask this question of every detection control: if an attacker ran this technique tonight, which log would show it, and who would see that log tomorrow? If you cannot answer both halves, the control is decoration.

Respond and Recover: the two functions you rehearse, not read about

Respond asks whether you can contain a compromised machine: disable the account, isolate the host, revoke the session, preserve the logs. Recover asks whether you can rebuild it: is BitLocker recovery keyed and escrowed, are shadow copies and backups actually restorable, is the rebuild image current? WinSentinel's audits of recovery environment configuration, VSS tampering, backup-related services, and credential hygiene feed both answers.

Run a tabletop exercise at least once a year, even a small one: pick one machine, assume it is compromised, and walk through containment and rebuild using only the evidence your audits produce. The gaps you find in that hour are worth more than a year of green checkmarks.

Putting it together: one machine, then the fleet

CSF 2.0 works best as a loop, not a checklist. Govern sets the baseline, Identify inventories the estate, Protect hardens it, Detect watches it, and Respond and Recover prove you can survive a failure. Start on one machine — the free WinSentinel audit covers the full module set there, so a single-machine assessment is already complete evidence. When you scale to many machines, that is where fleet orchestration earns its keep: a central view that rolls each machine's audit results into organization-level posture, flags drift from the baseline, and alerts when a node regresses. That centralized rollup is the Pro tier's job; the audits themselves are the same ones you already ran locally.

The framework does not ask you to be perfect in all six functions at once. It asks you to know, function by function, where you stand — and to have evidence, not opinions, for each answer. Start with one machine this week, map its results to the six functions, and you will have the most honest CSF self-assessment your organization has ever produced.