HardeningKitty: auditing and applying Windows hardening settings from PowerShell

What HardeningKitty solves, and who is meant to run it

A Windows baseline document tells you what a setting should be. It does not tell you what your machine currently has. HardeningKitty closes that gap: it retrieves the configuration of a system, assesses it against a finding list, and reports each check as passed or as a finding with a severity. The README describes the project as having started as a simple hardening list for Windows 10 and then shifting focus to the audit of well-known frameworks and benchmarks. That shift matters, because the audit is now the centre of the tool and the hardening is a second mode on top of it.

The audience is narrow and identifiable. It is a Windows administrator or blue team member who already has a baseline to work from, whether that is a CIS Benchmark, a Microsoft Security Baseline, a DoD STIG or the BSI SiSyPHuS Win10 guideline, and who wants the checking done mechanically instead of by reading the Local Group Policy Editor screen by screen. The README states the checklist can be used in private and business environments and that the settings should be treated as security and privacy recommendations to be weighed against usability. That sentence is doing real work: this is not a tool that decides for you.

How the audit works: registry reads, modules, finding lists

HardeningKitty reads settings from the registry and uses other modules to read configurations outside the registry. That two-path design is the core of the mechanism. A large share of Windows hardening settings live under registry keys, and those can be read directly. Others do not live in the registry at all, for example account policies and user rights assignment, which is why the sample output groups results under categories such as Account Policies, User Rights Assignment, Administrative Templates: Printer and MS Security Guide. Each of those categories is backed by a different read path rather than by one uniform query.

Against each read value the module compares the recommended value from the active finding list and assigns a severity. The sample run in the README ends with a score and a breakdown: total checks, passed, and counts at Low, Medium and High. So the output is not a pass or fail verdict on the machine, it is a weighted picture. A finding such as LSA Protection being empty against a recommended value of 1 comes back Medium, while Point and Print Restrictions findings tied to CVE-2021-34527 come back High. Severity is a property of the finding list entry, not something the tool derives from your environment, so the ranking reflects the baseline author's judgement rather than your exposure.

The lists directory at the repository root holds those finding lists, and a separate script, Update-HardeningKittyListManifest.ps1, exists to regenerate the manifest that ties them together. If you maintain your own list, that script is the piece you will end up running.

Installing the module and running a first audit

The README's install path is manual and version-stamped. Create a directory named HardeningKitty under a path listed in PSModulePath, create a subdirectory for the version, and copy the module manifest, the module file and the lists directory into it. The README uses 0.9.3 as the version in its example; substitute the release you downloaded.

PS C:\tmp> $Version = "0.9.3"
PS C:\tmp> New-Item -Path $Env:ProgramFiles\WindowsPowerShell\Modules\HardeningKitty\$Version -ItemType Directory
PS C:\tmp> Copy-Item -Path .\HardeningKitty.psd1,.\HardeningKitty.psm1,.\lists\ -Destination $Env:ProgramFiles\WindowsPowerShell\Modules\HardeningKitty\$Version\ -Recurse

The README also provides an InstallHardeningKitty function that queries the GitHub releases API for the latest release, downloads the zipball, expands it, moves the files into place and imports the module. That is the path to take if you want the current release rather than a pinned one, and it requires outbound access to api.github.com from the machine you are hardening.

For a one-off run without installing into PSModulePath, the README's How To Run section copies the script and the lists to the target system and imports the module from the working directory:

PS C:\tmp> Import-Module .\HardeningKitty.psm1
PS C:\tmp> Invoke-HardeningKitty -EmojiSupport

Run it with administrative privileges to reach machine settings. The README adds a detail worth following: for the user settings it is better to execute with a normal user account, ideally the account used for daily work, because user-scope settings are read from that profile's context. The default mode is audit. It writes a CSV report and a log file with automatic timestamped names, and the ReportFile and LogFile parameters override those names and paths. The Filter parameter takes a PowerShell ScriptBlock to narrow the run, for example `{ $_.ID -eq 4 }` in the README's example. What you should see on screen is a per-category walk with one line per check, then a final score line with the totals.

HailMary mode, and the absence of an undo

Auditing is read-only and safe to repeat. Applying settings is not. HardeningKitty can harden a system according to predefined values, and the README describes a HailMary mode that makes it possible to apply the settings of any hardening checklist on a Windows system. The stated reason HailMary exists is Windows 10 Home, where the Group Policy Editor is not integrated and an adjustment has to be made directly in the registry.

That is the honest framing of the feature: it is a workaround for a missing management surface, and it works by writing values that Group Policy would otherwise have written. The README does not document rollback. There is no described mechanism for capturing the prior state of a setting and restoring it, and no described dry-run that shows the exact registry writes before they happen. The audit CSV gives you the current values, which is the closest thing to a pre-change record the project offers, so keeping that CSV is the practical substitute for an undo. If a setting breaks a line-of-business application, you are reconstructing the old value from your own records.

There is a second constraint in the same area. The README states the script was developed for English systems and that on other languages the analysis may be incorrect, with a request to open an issue when that happens. Category names, account names and some values are compared as strings, so a localised Windows build can produce findings that reflect a language mismatch rather than a real misconfiguration. Treat the score from a non-English system as unreliable until you have checked the individual lines.

Where HardeningKitty is the wrong tool

It is the wrong tool if you need to know the state of a fleet. HardeningKitty runs on the machine it is auditing and writes its report locally. There is no server component, no agent that reports back, and no aggregation across hosts in the README. Getting a fleet-wide view means collecting the CSVs yourself, and the timestamped automatic naming means you will be parsing filenames to work out which host and which run each file belongs to.

It is also the wrong tool if you want configuration enforced continuously. A hardening run is a point-in-time action. Nothing in the described design watches for a setting being changed back, by an application installer, by a later Group Policy refresh, or by a user with local administrator rights. On a domain-joined machine where Group Policy already delivers the same settings, running HailMary mode can put you in a position where the registry value and the policy value disagree, and the tool will not tell you which one will win after the next policy refresh.

Finally, it is the wrong tool if you need a compliance attestation with an audit trail. The output is a CSV and a log file. There is no signing of results, no tamper evidence, and no mapping of a finding back to a control identifier beyond the ID and the name in the finding list. For a formal audit you will be transcribing these rows into whatever system holds your evidence.

How it compares with Microsoft's own tooling

The obvious alternative is Microsoft's Security Compliance Toolkit, which ships the same class of content: the Microsoft Security Baselines as Group Policy objects, plus Policy Analyzer and LGPO.exe for comparing a machine against them and applying the result. The difference in approach is where the baseline lives. Microsoft's toolkit treats the baseline as Group Policy, so applying it means importing a GPO or using LGPO.exe to write the policy, and the resulting state is a managed policy setting that the operating system reports as such. HardeningKitty reads the effective configuration and, in HailMary mode, writes registry values directly.

That difference explains the trade-off. The Microsoft route gives you policy semantics, refresh behaviour and a management console, but it assumes the Group Policy machinery is present and that you are willing to manage GPOs. HardeningKitty gives you a single PowerShell module with no infrastructure, works where the Group Policy Editor is absent, and can score a machine against CIS, STIG and BSI lists that Microsoft does not ship. What it does not give you is policy semantics, and it does not give you the rollback that removing a GPO would give you.

A second alternative is to script the checks yourself against your own baseline. That is more work but it produces exactly the findings your organisation cares about, with your own severities, instead of the severities in a vendor list. HardeningKitty's own lists are editable, and Update-HardeningKittyListManifest.ps1 exists for regenerating the manifest, so the middle path is to fork the list rather than to abandon the tool.

Licence, releases and what maintenance costs

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. Nothing in the README adds terms on top of that. The practical licence question is not the code but the finding lists: the README names CIS Benchmarks, Microsoft Security Baselines, DoD STIG and BSI SiSyPHuS Win10 as sources, and those documents carry their own terms from their publishers. If you redistribute the lists or build a product around them, check the terms attached to the source benchmark rather than assuming the MIT licence on the module covers the content. This is a question for your own legal review, not one this article can settle.

On maintenance, the release cadence visible in the repository is uneven. v.0.9.4 is dated 2026-07-21, v.0.9.3 is dated 2024-12-23, and v.0.9.2 is dated 2023-12-04. That is roughly a year between the two earlier releases and about nineteen months before the current one. The last push to the repository was on 2026-08-31, so there is recent activity, but the gap between 0.9.3 and 0.9.4 is the number that matters for planning: if you pin a version, expect to sit on it for a long time, and expect a baseline refresh to arrive as a new release rather than as a continuous stream.

Upgrade cost is low by construction. The install is a copy of three items into a versioned directory, so a new release sits alongside the old one and you switch by importing the new path. The work is not the upgrade, it is re-reading the finding list diff: a new release can add checks, change recommended values and change severities, and your score will move even if nothing on the machine changed. Keep the CSV from the previous run before you upgrade, or you will not be able to tell a real regression from a list change.

Editorial conclusion

Adopt HardeningKitty if you already work from a CIS or Microsoft baseline document and want the checking and the writing done by one PowerShell module on a machine you control, including Windows 10 Home where the Group Policy Editor is absent. Do not adopt it as a fleet configuration manager: there is no agent, no central reporting and no rollback, and the README notes that the script was developed for English systems, so non-English builds may produce incorrect analysis. Before running it in audit mode on production, open lists/ and confirm which finding list you are scoring against, and read the entries whose Recommended value differs from your current setting, because Invoke-HardeningKitty in HailMary mode writes those values without a documented undo.

Frequently asked questions

Official sources

1. 0x6d69636b/windows_hardening on GitHub
2. Issues
3. License: MIT
4. README
5. Releases