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 malware running as root. Under Lockdown there is no permissive mode, nothing to unload, and the allowlist cannot be edited. An attacker who already has remote root cannot turn it off.
In Setup Mode, Root Lock logs activity so you can review and approve it through the Dashboard queues. Lockdown then enforces what you approved.
Root Lock operates standalone — no SaaS policy server, no agent-to-console channel. The Root Lock kernel sits beside your existing kernel in GRUB; you can boot back to the existing kernel. The scenarios below are where that model fits, then where it is not a fit by design.
Production servers
A web server serves pages. A database answers queries. A reverse proxy forwards traffic. Each has a shape you review and approve in the Dashboard queues after a few days of Setup Mode logging, then you activate Lockdown.
On a homogeneous fleet of these servers, install each host through Cloud Path or Local Path. Harvest a baseline from one reference host, then apply it with Ansible — see Central Policy.
Patches, package upgrades, and new services follow the same path: open a maintenance window, install the changes in Setup Mode, approve the new entries, then re-engage Lockdown.
CVE-2026-31431 — privilege escalation via AF_ALG — shows what Lockdown means on a production server. An attacker who exploits it ends up with root. On a Root Lock kernel AF_ALG is not compiled in, so that path is gone.
Even if it had been, Lockdown constrains the root shell the exploit produces: the kernel refuses to clear immutable flags, blocks mount operations, and blocks writes to the audit log, so a program added from that shell is gone after reboot.
See Kernel Security Transparency for the full CVE status table and scanner guidance.
Closed appliances and embedded devices
A kiosk, a point-of-sale terminal, an industrial control gateway, a network appliance, a medical device, a defence endpoint — these systems don’t have interactive users. They have a job. The programs that do the job are fixed.
An attacker’s first move is usually to introduce a new program. In Lockdown, Root Lock blocks that move before it starts. By design, remote root cannot add to the sealed allowlist while the system runs.
File Backup is the recovery layer. The kernel restricts the backup directory to Root Lock’s own backup tooling — no other allowlisted program, however privileged, can read or overwrite it. If an approved program is compromised and corrupts a file, previous versions remain intact and restorable from the Dashboard’s Backup.
Regulated workstations and analyst systems
In financial, legal, healthcare, and defence workplaces, a workstation’s toolchain is set by policy, not preference. The Dashboard includes review queues that let you approve each tool and add it to the allowlist. In Lockdown, only the tools you approve can execute — everything else is blocked.
Lockdown seals the allowlist against change: the files are immutable (chattr +i), and the running kernel refuses the write, including from root. A compromised user session cannot quietly add an unauthorized tool, because the kernel itself will not accept the change.
In regulated industries — financial services, healthcare, defence — auditors ask a specific question: can an administrator, or an attacker who has compromised an administrator account, disable your security controls? With Lockdown active, remote root cannot disable enforcement the way an agent can be killed. sshd is stopped when Lockdown seals, unless you chose to leave it running before the seal, and SSH cannot lift the seal. Unsealing takes reaching the boot path: a keyboard and monitor on a physical machine, a serial console, or — on a virtual machine — the hypervisor that owns the guest’s disk image and memory. After unseal, SSH is how you work in Setup Mode. See Circumvention and recovery.
On VMs the hypervisor is the outer protective layer; Root Lock protects everything inside. Platform controls that protect the boot path (measured boot, disk encryption with keys held by the platform, controlled hypervisor access) extend that protection upward.
For environments subject to SOC 2, PCI DSS, HIPAA, or ISO 27001, that is a concrete answer to the privileged-access control question — and a clear specification of which controls remain the platform’s responsibility.
For managed security providers, this answer is the same for every Root Lock-protected server they manage: under Lockdown, no administrator credential, root session, or SSH session can unseal or rewrite the security policy. sshd is stopped when Lockdown seals, unless you chose to leave it running before the seal. After unseal, SSH is how you work in Setup Mode. For the competitive comparison on this point, see How Root Lock Compares.
Build, CI, and release infrastructure
A build host sits at the top of a supply chain. Compromise it, and every downstream consumer is at risk.
CVE-2024-27198 — JetBrains TeamCity, unauthenticated RCE — shows what that means. An attacker who reaches a TeamCity server can execute any program without credentials. On a Root Lock build host, that program has no allowlist entry. The kernel refuses to run it.
A supply chain attacker who compromises the build pipeline itself — using its own credentials and tooling — does not introduce a new program. In the May 2026 TanStack incident, 84 malicious package versions across 42 packages were published in six minutes using valid pipeline credentials. The program check does not stop that attack, because the pipeline tools already have allowlist entries.
What contains it is the network allowlist: under Lockdown, a compromised build tool cannot reach destinations outside its approved list, regardless of credential validity.
Root Lock restricts the host to only approved programs, controlling which can execute, which files they can access, and which network connections they can make:
- Compilers, linkers, signing tools, and release scripts you approved in Setup Mode.
- Network destinations they need to fetch dependencies and publish build artifacts.
File Backup keeps versioned copies of signing keys and build output. The kernel restricts those copies to Root Lock’s backup tooling — a compromised compiler, linker, or signing tool cannot read or overwrite them. So even if an approved tool is compromised, the previous versions remain intact and restorable from the Dashboard’s Backup.
Offline and air-gapped deployments
Some systems cannot assume the network is there. Industrial control networks, defence systems, classified environments, ships, aircraft, and recovery-of-last-resort servers either have no outbound connectivity or cannot be permitted to reach the internet at all.
Root Lock operates standalone — the allowlist lives on the machine, enforcement happens inside the kernel, and logs go to whichever local channel you configure. There is no telemetry upstream and no policy server to round-trip with.
An offline Root Lock system protects exactly the same way as an online one. Cloud-dependent EDRs degrade sharply in these environments; Root Lock does not.
AI agent and automation sandboxes
Autonomous agents are powerful because they decide what to do next. That is also why they need a cage. Pwn2Own Berlin 2026 added an AI/ML tools category for the first time; every target fell.
Run Root Lock as the guest kernel inside a per-task virtual machine — a Kata Container, a Firecracker microVM, or plain KVM. You build the allowlist once: run a representative agent task in Setup Mode, review and approve the tools it uses through the Dashboard queues, then bake that allowlist into the VM image.
Each task VM boots from that image with the allowlist already on the disk. The image is not sealed. You run the seal on that machine, and the seal takes effect on the next boot. The allowlist holds for the life of the task. Then the VM is gone.
An attacker who already has root inside the VM cannot turn this off. Its enforcement is not an LSM policy that can be unloaded or set permissive, and there is no userspace shim to detach and no agent to kill. gVisor filters syscalls in userspace to protect the host; Root Lock, as the guest kernel, protects the workload.
You get the most reliable allowlist from Setup Mode when the same programs run in the same way across tasks, because repeating activity is what you can review and approve in the Dashboard queues with confidence. Agents that call unpredictable tools at runtime are harder to allowlist than agents whose action space is well-scoped to a defined set of tools.
Shared-kernel containers
Docker, containerd, Kubernetes, CRI-O, and Podman are not a supported workload on a Root Lock host, by design. Under Lockdown, Root Lock refuses the new mounts a runtime makes each time it starts or reschedules a container. The installer can notice that one of those engines is present, but it records the host as a standard host and does not adapt Setup Mode for container images.
Build and run OCI images on another host. Root Lock protects the fixed-workload machines around that runtime. For a task that should sit in its own machine, install Root Lock as the guest kernel in a virtual machine.
Where Root Lock is not a fit
A few workloads are incompatible with the Root Lock kernel as shipped — not a fit by design.
- Shared-kernel container guests (OpenVZ, LXC, Docker/Podman guests on a provider kernel, systemd-nspawn) — Root Lock must boot its own kernel by design. Full VMs under KVM or cloud hypervisors are supported; Root Lock runs as a guest kernel inside them.
- Shared-kernel container engines on this host (Docker, containerd, CRI-O, Kubernetes, Podman) — not a fit by design, including a long-lived or fixed set of containers. Under Lockdown, Root Lock refuses the new mounts a runtime makes each time it starts or reschedules a container. Build and run those images on another host. See Shared-kernel containers above.
- Hosts where eBPF-based tooling must run locally — not a fit by design. Falco, Cilium, Tetragon, bpftrace, and similar tools need the BPF syscall, and Root Lock does not enforce through eBPF. On 6.18.9-hs the BPF syscall is off, so there is no eBPF program to load. These tools can still observe the Root Lock host from adjacent infrastructure via network taps or log forwarding. For on-host forensics, use strace and /proc inspection.
- Hypervisor hosts running virtual machines — Root Lock protects workloads running inside a kernel. A hypervisor host grants trusted access to guest workloads it does not control — the inverse model. KVM host mode is not a supported configuration. Root Lock runs as a guest on KVM, cloud hypervisors, and other platforms.
- A VM nested inside another VM without hardware virtualization — a VPS or cloud guest is already a virtual machine. Install Root Lock there, or on a host that exposes
/dev/kvm. Nesting a second guest without hardware virtualization causes the installer to stop at the start. See Bare metal, virtual machines, and nested VMs. - Rootless containers — not a fit by design. Under Lockdown, Root Lock refuses the new mounts a runtime makes. Run them on a separate host.
- Applications that update daily or on an unpredictable schedule — each update that adds a new binary, dependency, or network destination requires a maintenance window: open Setup Mode, run the update, approve the new allowlist entries, and re-engage Lockdown. That process fits controlled patch schedules. At daily cadence the overhead is daily. Applications with a predictable update cycle are a better fit.
See System Requirements → Software Compatibility Notes for the full list.
Kubernetes-native runtime security, cross-platform endpoint protection across Windows and macOS, developer per-application sandboxing, and enterprise backup at fleet scale each have dedicated tools built for them. Root Lock is built for one thing: Linux systems where the security policy must survive a compromised root account.
If the host is a fit, continue to Getting Started.