As of 2025, there's a Security Technical Implementation Guide (STIG) for NixOS: a hardening baseline in the exact same checklist format the Defense Information Systems Agency (DISA) uses for RHEL or Ubuntu. It features 103 controls spanning auditing, cryptography, SSH, and kernel hardening. That it exists at all is a milestone: it means NixOS now turns up in places that require a formal, government-grade security baseline. On a recent client engagement, we had to implement it.

This process highlighted exactly how NixOS differs from other Linux distributions. Traditionally, hardening a system means manually going through checklists, writing fragile bash scripts, and hoping nothing drifts. The NixOS STIG is unusual because it ships the declarative configuration alongside the requirement. We took those snippets and packaged them into reusable modules. Instead of manually hardening a server, you simply import the baseline. Because the entire system state is declared in code, verifying compliance effectively becomes static analysis for server configs. From these same modules, we automatically generate the compliance report that maps each control to the exact configuration that meets it: the specific artifact an auditor actually asks for.

Having the setting is one thing; proving it holds is another. Each control comes with a NixOS VM test that boots a machine and checks that the rule is enforced (e.g., verifying that audit rules are set). This allows for automatic testing before system upgrades: a change that breaks compliance fails in CI, long before an auditor ever sees it. The same checks include a script for live systems so a running machine can be verified in place (though it is important to note we are strictly verifying that the STIG configurations are correctly set, not executing a penetration test to see if they prevent specific exploits).