Compare
Kensa vs Ansible Lockdown
Both harden Linux against STIG, CIS, and NIST 800-53. The difference is the change model: Kensa runs each change as a transaction that validates and rolls back on failure, and emits audit-ready evidence. Ansible Lockdown applies hardening roles.
What they share
Open sourceAgentless, over SSHAuthored in YAMLRun from CI or a workstation
Side by side
| Dimension | Kensa | Ansible Lockdown |
|---|---|---|
| Change model▲ | Transactional: capture pre-state, apply, validate, then commit or roll back. | Task-based: applies hardening tasks idempotently. |
| Rollback on failure▲ | Automatic. The captured pre-state is restored when validation fails. | Not built in. Reverting a failed change is manual. |
| Framework mapping▲ | One rule maps to STIG, CIS, and NIST 800-53 at once. | Separate roles per baseline and per OS. |
| Audit evidence▲ | Structured, machine-verifiable evidence per check (command, expected vs actual, timestamp). | Task pass/fail output; no unified evidence chain. |
| Multi-OS maintenance▲ | One rule handles multiple RHEL versions with conditional logic. | Per-OS roles and repositories to maintain. |
| Transport | Agentless, over SSH. | Agentless, over SSH. |
| Licensing model | Open source. | Open source. |
▲ marks where the two differ most.
When to choose which
Choose Kensa when
You want remediation that validates and rolls back automatically on failure, one rule set that satisfies STIG, CIS, and NIST 800-53 together, and machine-verifiable evidence to hand to auditors.
Ansible Lockdown fits when
Your team already runs Ansible for configuration management and wants hardening roles inside that workflow, and you do not need transactional rollback or a unified evidence chain.