Root Lock by HeartSuite Overview
Core concepts and purpose of Root Lock by HeartSuite.
Introduction and Overview
Overview of Root Lock by HeartSuite, setup process, and system requirements.
Root Lock by HeartSuite | Humans in Command
Overview: Every attack does three things: run a program, access files, make a network connection. Root Lock by HeartSuite enforces default-deny on all three at the kernel, per program, including as root.
In Lockdown, anything not on the allowlist is blocked before it can act. By design, remote root has no intended path to change the sealed allowlist while the machine is running. Unsealing takes the maintenance kernel from a physical or serial console. Lockdown covers activation. Circumvention and recovery covers residual risk.
In this section
- Root Lock Overview — Core features, how it protects against malware, and the setup checklist.
- The Setup Journey — Initial setup, then the Dashboard checklist from installation to Lockdown, Cloud Path and Local Path, and how the Dashboard guides you.
- System Requirements — Compatible systems, kernel versions, and prerequisites.
- Deployment Scenarios — Environments and workloads where Root Lock fits best, plus notes on incompatible stacks.
- How Root Lock Compares — What Root Lock replaces, what it complements, and how it can be circumvented.
For detailed installation steps, see Installation. Getting Started covers Cloud Path and Local Path. On a single host they converge at the Dashboard after initial setup. Many hosts still install through Cloud Path or Local Path on each machine — see Central Policy.
From install to Lockdown
Initial setup runs unattended. Then the Dashboard walks you from program allowlisting to Lockdown.
What this kernel needs — and what differs by stream
Architecture, supported distributions, kernel features the Root Lock kernel omits, and which hosts the installer runs on. Confirm these before you install.
Deployment Scenarios
Environments and workloads where Root Lock by HeartSuite’s kernel-level allowlisting fits best.
What Root Lock replaces — and what it does not
It replaces tools an attacker who already has remote root can unload. It does not replace your SIEM, NDR, or scanner. Includes how it can be circumvented.
Containers, microVMs, and the sealed host
Shared-kernel Docker is not the default. Long-lived container sets use the Container-host install. Untrusted work runs in a microVM with Root Lock as the guest kernel.
Security as Economics
No scan, no score, no guess: the allowlist entry exists or it does not. What that does to attacker cost, patching urgency, and alert volume.
Where Linux security tools actually sit
EDR, LSM, eBPF, gVisor, and a compiled-in kernel are not the same layer. This taxonomy shows the bypass surface of each.
When Root Isn't Enough
Three real attacks, all as root: a new binary cannot run, files stay out of reach, outbound destinations stay closed. And what this does not cover.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.