Root Lock Firewall

• 1: Inbound default-accept is the other Unix inheritance
• 1.1: A listener will accept a stranger by default
• 1.2: Observe real traffic, approve a list, seal it
• 1.3: Where the packet boundary holds
• 1.4: Walkthrough: observe, approve, seal
• 2: Where a host-shaped firewall belongs
• 3: What sits under a closed firewall image
• 4: What Cisco and Fortinet incidents needed to exist
• 5: A sealed host filter beside a campus NGFW
• 6: What the firewall prototype covers today

1 - Inbound default-accept is the other Unix inheritance

Root Lock Firewall | Prototype

Overview: A listening service on a Linux host accepts inbound connections unless a packet filter refuses them. Root Lock Firewall is that filter on a closed HeartSuite appliance: observe real traffic, approve a finite allowlist, seal it.

Root Lock controls outbound destinations per program, at the kernel, using literal IP addresses. The two products address different layers and are designed to be used together on the appliance image.

In this section

• The security problem Root Lock Firewall solves — Why inbound default-accept is a different OS assumption from Root Lock’s outbound allowlist.
• Root Lock Firewall overview — Closed appliance, stateful inspection, observation through Firewall Lockdown, and what stays with Root Lock.
• Walkthrough — The intended Dashboard journey from first boot to a sealed ruleset.
• Protection limits — Where the packet boundary holds, and what to use alongside it.

1.1 - A listener will accept a stranger by default

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: A process that is listening will accept a connection from anywhere the routing table can reach, unless a packet filter refuses the packet first.

Two different defaults

Root Lock by HeartSuite starts from one Unix inheritance: a program that can run may open files and make outbound connections as the user who launched it.

Root Lock Firewall starts from the other: a process that is listening will accept a connection from anywhere the routing table can reach, unless a packet filter refuses the packet first.

Those are independent controls. Approving 93.184.216.34 for /usr/bin/curl does not close port 22. Closing port 22 does not stop curl from calling an address you never reviewed.

What inbound default-accept enables

1. Unsolicited reachability

Any service that binds a port is reachable from every address that can route to the host. Installing the service rarely meant “the entire internet.”

Scanners, credential stuffing, and exploit kits treat that reachability as the starting condition.

2. Login and management planes on the filter itself

Campus and branch firewalls accumulated a second job: they became the remote-access concentrator and the administrative website. The packet filter then has to defend its own web VPN, SSO broker, and management GUI.

Incidents in 2024–2026 on Cisco Secure Firewall and FortiOS followed that surface. See Recent firewall campaigns.

3. Rules nobody can still explain

Stateful policy that is never observed, reviewed, and reduced becomes an any-any rule with exceptions stacked on top. The filter is “on.” The allowlist is not known.

Extra tools then appear to find which rules still matter.

What another NGFW blade answers

Application catalogs, TLS interception, URL clouds, and sandbox subscriptions answer a different question: what is inside a flow you already decided to accept. Root Lock Firewall answers which inbound sockets on this box a human approved, and whether that set is sealed.

They add policy surface. They also add a management and update plane that has to stay reachable.

Root Lock Firewall addresses the first question and refuses the second as product identity. Inspection stays stateful. Delivery is a closed image. You reach the Dashboard on the console or serial console.

What Root Lock already covers

Root Lock already blocks outbound connections to destinations that are not on a program’s allowlist, including from processes running as root. That is kernel grant policy. Inbound port policy is Root Lock Firewall.

Root Lock Lockdown can record a thin inbound permit for SSH scope and named services. That path is accept-only. Observation of real traffic, a reviewed allowlist of this box, and Firewall Lockdown are Root Lock Firewall.

Root Lock Firewall is the product that takes inbound (and this host’s path) as its job.

That is a smaller remote plane. An approved port stays an approved port. A wide seal stays a wide seal. The hypervisor console stays in the trust boundary. See Protection limits.

1.2 - Observe real traffic, approve a list, seal it

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: A listening service on a general-purpose host accepts inbound packets unless a filter refuses them. That is the Unix default this product closes.

Root Lock Firewall is the host-shaped stateful packet filter on a closed HeartSuite appliance. Root Lock by HeartSuite is the hardened OS under it. You receive an image.

The Dashboard shows traffic as it happens. You approve a finite allowlist for this box’s inbound and outbound path. Firewall Lockdown seals that set.

Packets are judged by connection state on Linux netfilter’s nft path. Execution, file access, and per-program outbound destinations remain Root Lock’s domain.

What you receive

You receive a virtual appliance (QCOW2 or OVA). Hardware follows later, after real deployments, and keeps the same inspection class.

The image is closed:

• A custom Root Lock kernel is already the operating system.
• The packet filter is already installed and constrained by that kernel.
• You reach the box on the console or serial console. There is no public administrative SSH by default, and no Docker runtime.
• HeartSuite is the update authority. Rules and reputation stay off a public CDN under seal.

Delivery is the closed image. Install scripts that appear in development trees are for laboratory layer installs on a test guest. They remain laboratory.

What the filter decides

Root Lock Firewall is a host-shaped stateful firewall.

• Host-shaped. It filters traffic to and from this box. The workload runs on the image.
• Stateful. Allow and deny follow connection state, not a stateless access list alone.
• Literal addresses. Critical rules use IP addresses, not hostnames. DNS is not the enforcement mechanism.

Inspection stays connection state on the sealed allowlist. Application payloads, TLS termination for classification, and URL or sandbox clouds stay outside product identity.

Observation, approval, and Firewall Lockdown

You use the same observe → approve → seal path Root Lock already uses for programs and destinations:

observe what is real → approve what is necessary → seal what was earned.

Silence on the strip means Firewall Lockdown and Root Lock Lockdown are both in place.

Firewall Lockdown and Root Lock Lockdown are paired on the appliance. Firewall Lockdown seals the packet allowlist. Root Lock Lockdown seals the kernel allowlist (programs, files, outbound destinations).

Changing either after seal requires the maintenance path.

What stays on Root Lock

See Network and Remote Access for Root Lock’s outbound queue, and Protection limits for residuals.

1.3 - Where the packet boundary holds

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: A listening service accepts packets from anywhere the routing table can reach, unless a filter refuses them. Root Lock Firewall refuses inbound and this-host path traffic that is not on the sealed allowlist — including traffic aimed at services running as root.

An attacker who uses a port you approved is constrained by that rule. Application content on that port stays with a WAF and Root Lock.

An attacker uses a service you already approved

The scenario. You approved inbound HTTPS to the workload on this image. An attacker exploits a bug in that web application over the allowed port.

What Root Lock Firewall does. Packets to ports that are not on the allowlist still fail. Scanners probing closed ports still fail. A listener on a port that is not already in the sealed allowlist is not an approved path.

What it does not cover. If the attacker uses a port you already approved, this particular gate does not apply to application content on that port. Packets to ports off the allowlist still fail. A listener that binds a port the image already left open (including baseline ports open to any source) is still that approved path.

A WAF, application hardening, and Root Lock by HeartSuite (what that process may execute, read, write, and call outbound) address the blast radius inside the approved service.

Outbound destinations per program

The scenario. A compromised approved program opens an outbound connection to an address you never reviewed.

What Root Lock Firewall does. The host path is still subject to the sealed host filter. That is independent of per-program outbound policy.

What it does not cover. If a compromised approved program opens an outbound connection to an address you never reviewed, this particular gate does not apply to per-program destinations. The sealed host filter on this image still holds. Which program may reach which literal IP stays Root Lock.

Traffic through this box to another server

The scenario. You want to place the appliance in front of a backup server or a subnet and publish NAT or forwarded ports.

What Root Lock Firewall does. v1 filters INPUT and OUTPUT of this image. The workload is meant to run on the image.

What it does not cover. If you want this box in front of other hosts, this particular gate does not apply to FORWARD or NAT. v1 still filters INPUT and OUTPUT of this image. See Deployment scenarios.

Application identification, TLS interception, and URL clouds

The scenario. A buyer expects App-ID, TLS man-in-the-middle, URL categories, sandbox detonation, or SD-WAN on the same appliance.

What Root Lock Firewall does. Connection state and the allowlist you sealed.

What it does not cover. If the requirement is App-ID, TLS interception, or URL clouds, this particular gate does not apply to those blades. The sealed host allowlist on this image still holds. Keep the specialist tool for that inspection.

Physical access and the console

The scenario. Someone who can reach the serial console or the hypervisor console boots Maintenance and removes the seal.

What Root Lock Firewall does. Under Firewall Lockdown, an attacker who already has remote root cannot rewrite the sealed allowlist. Change goes through Maintenance on the console.

What it does not cover. If someone holds the serial console, a cloud serial console, or the hypervisor, this particular gate does not apply to that path. The sealed allowlist still holds against remote rewrite. Restrict console access in the hypervisor or cloud IAM.

A later hardware appliance removes the hypervisor residual. Physical presence stays a console path. See Architecture and compatibility.

An allowlist that is too wide

The scenario. Observation ran on a noisy network, a broad rule was approved to “make it work,” or the image already opened ports to any source, and then that set was sealed.

What Root Lock Firewall does. The sealed set, including the wide rule and any baseline ports that were never a discovery product. Critical rules use IP addresses, not hostnames. DNS is not the enforcement mechanism.

What it does not cover. If a broad rule was approved and sealed, this particular gate does not unsay that approval. The sealed set still holds until you unseal it. Inventory advisories can flag breadth. Re-enter Maintenance, reduce, and seal again.

Complementary tools

For how this sits next to campus NGFWs and cloud security groups, see How Root Lock Firewall compares.

1.4 - Walkthrough: observe, approve, seal

Prototype: Keys, strip text, and ceremony steps shown here are the intended appliance path and may change. The screenshots are docs mock-ups of that path, not a capture of the shipping Root Lock TUI ([f] is still File Access there).

Root Lock Firewall ships as the closed image. You boot it, open the serial or local console, and the Dashboard is the interface.

1. First boot is observation

The merged system strip reports traffic observation: logging only, rules not fully enforced. That is the honest state: what is listening and what is arriving.

The Suggested Next Step points at pending firewall events.

2. Open Firewall Rules

From the Dashboard, open Firewall Rules with [f].

Each pending event is something that already happened on this box during observation: a listener, an inbound attempt, a repeated source.

Firewall Rules groups related events when they share a service or origin so you are not paging through identical lines. View samples with [v] before approving a group.

[a] Approve creates an allowlist entry for that traffic. [s] Skip leaves it for later. [s] is Skip, not Seal. There is no blind “allow all pending.”

An approval is a decision you make. The Dashboard does not confirm a suggestion it already chose.

3. Empty the queue before you seal

An empty queue is required. The Suggested Next Step offers Seal Firewall with [l] only when the precondition checklist also passes.

Most appliances need several days of representative traffic before that offer is earned. A development host that never saw production clients will under-teach the allowlist.

The image already leaves a small set of ports open to any source (workload ports, and the SSH port even when no administrative SSH listener is running). Observation does not produce those. Seal keeps them. Narrow them through Maintenance after you know the workload.

[l] opens Firewall Lockdown. Advance with [y] to see the review: rule counts, samples, and what the box already has for logging. Logging and SIEM destinations are not configured on this path.

4. Type YES, then reboot the host

The confirmation word is YES — uppercase, case-sensitive.

After you confirm, reboot from the console or hypervisor so Firewall Lockdown is applied with Root Lock Lockdown. The Dashboard does not reboot the host. [r] shows reboot instructions after the seal is accepted.

After reboot the strip is quiet when both seals are in place. Mutate keys are absent from Firewall Rules and from inventory. Absence is the signal that the set is sealed.

5. Inventory is read-only

After reboot, [l] opens the same Firewall Lockdown surface as inventory. It shows the allowlist that is in effect, and whether Root Lock Lockdown is present.

Advisories can flag a rule that is broader than the traffic that earned it. Edit through Maintenance.

6. Change only through Maintenance

To change a sealed rule, open Maintenance with [m]. Enter reduced posture with [e], then type YES.

Edit or re-observe on Firewall Rules, then seal again with [l], YES, and a host reboot. Unsealing does not reboot. SSH from a laptop is not the recovery path. Console or serial is.

See Root Lock Firewall overview for the observe → approve → seal grammar, and Protection limits for the console recovery path.

2 - Where a host-shaped firewall belongs

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: Root Lock Firewall fits when the workload can live on a closed HeartSuite image and you want a sealed inbound allowlist for this box. Delivery is that image. Campus NGFW blades stay the specialist tool.

Where Root Lock Firewall fits

A single-purpose workload on a closed image

A backup receiver, an internal service, a regulated workload that should run one job: the workload lives on the appliance. You observe what actually arrives, approve the sockets that job needs, and seal.

Root Lock by HeartSuite is already the operating system, so a new binary and a new outbound destination still go through the kernel allowlist.

Virtual appliance on a hypervisor you administer

QCOW2 or OVA on KVM, or the equivalent import on a commercial hypervisor. Console or serial is how you reach the Dashboard. Restrict who can open that console.

The hypervisor is part of the trust boundary. See The virtual appliance residual.

Next to cloud security groups and provider DDoS tools

Security groups and the provider’s volumetric controls stay useful in front of any VM. Root Lock Firewall is the host allowlist on the image after that outer layer.

Cloud firewall services stay the provider’s policy plane. Booting on AWS, Google Cloud, Azure, DigitalOcean, or Linode leaves that plane in place.

Teams who already review Root Lock queues

If the team already reviews Programs, File Access, and Internet Access, Firewall Rules is the same human act applied to this box’s sockets. That is the intended buyer. FortiManager-class estate management stays with the campus tool.

Where another tool belongs

In front of other machines

v1 has no FORWARD or NAT product surface. Keep the existing edge firewall in front of a backup server, a subnet, or a pair of application hosts, or wait for an edge SKU that changes placement.

Campus, branch, or “NGFW refresh”

App-ID, TLS interception, URL clouds, SD-WAN, SSL-VPN as identity, and a central management empire stay with the specialist tool.

Using this image as a FortiGate or Cisco Secure Firewall replacement is a misfit.

Install-on-my-Ubuntu

Delivery is the image.

Root Lock on a server you already own remains the kernel product. Inbound on that server stays the OS or cloud control you already run, unless you move the workload onto this appliance.

Dedicated hardware

A hardware appliance (TPM / measured boot) is planned. v1 is the virtual image. Until hardware ships, the hypervisor is part of the trust boundary.

Shared-kernel container hosts

This appliance is a closed image. Container hosts stay the separate Root Lock container-host kernel product. See Root Lock Deployment Scenarios.

A WAF or API gateway requirement

Payload inspection, bot scores, and schema validation stay with a WAF in front of an allowed HTTPS port.

Alongside Root Lock

On the HeartSuite appliance image the two layers are designed to run together.

Root Lock without this image is still a complete kernel product. Root Lock Firewall on that server is an optional SKU.

Adding a second packet-filter manager next to Root Lock Firewall on the appliance is a hole in the composition.

For residuals inside an approved port, see Protection limits.

3 - What sits under a closed firewall image

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: Root Lock Firewall is a stateful host filter on a closed HeartSuite image. You boot the image, open the Dashboard on the console or serial console, observe, approve, and seal.

The image already carries a custom kernel, a userspace stateful-inspection engine HeartSuite updates, a console TUI, and host-integrity grants. You do not allowlist those programs.

That shape is required by the kernel underneath. Root Lock by HeartSuite is a custom Linux kernel. Delivery is the closed image on that kernel.

Laboratory install scripts exist for layer-installing the prototype on a throwaway guest. They remain laboratory.

Two layers, one box

Workload on this image
        │
        ▼
Root Lock Firewall     stateful allowlist for this host's path
        │
        ▼
Root Lock programs, files, per-program outbound IPs
                        plus the kernel the filter is allowed to run on

Root Lock Firewall owns the host packet filter. Root Lock owns what may execute and which literal outbound addresses each program may use.

On this image there is one filter owner. A second manager (UFW, firewalld, or a hand-maintained ruleset beside the product) is a composition hazard.

Root Lock’s own packet path — SSH scope and accept-only service permits at Lockdown — remains thin. See Lockdown for that Root Lock path.

Linux netfilter on the nft path

The Root Lock kernel carries nftables. The older iptables table is absent. Public documentation therefore describes the data path as Linux netfilter, nft path. Older iptables tools on this image load no table, so a rule you thought you applied does nothing.

A userspace stateful-inspection engine drives the filter. The Dashboard writes allowlist entries. Engine internals, a vendor web panel, and a cluster GUI stay off the glass.

HeartSuite is the update authority for that engine. External reputation and geo downloads are off under seal.

The engine is still userspace software. Root Lock is what constrains which binaries may run and which addresses they may call. That residual is why the two layers ship together on the image.

What the seal actually is

Firewall Lockdown makes the chosen allowlist immutable on the running appliance and is applied together with Root Lock Lockdown. After reboot, the Dashboard treats the ruleset as read-only.

The seal is immutability of the set you chose. Reduce through Maintenance.

Completeness of correspondence between the live filter table and the review queue is an engineering property under test. If a later engine can make the seal hashable, the product class stays a stateful host filter.

No administrative web plane

You administer the box from the console TUI. The appliance is designed without:

• a public administrative SSH listener by default
• a VPN web server as product identity
• cloud single sign-on into the filter
• vendor-static administrative accounts

The host filter’s image baseline can still include the SSH port and the usual workload ports, open to any source. That is a port shape, not a running listener.

Starting a listener on those ports is reachable from any source until you narrow the baseline through Maintenance. See Protection limits.

Those omissions are the architectural answer to the campaign class in Recent firewall campaigns. They shrink the remote attack surface of the filter. Someone who holds the hypervisor console or the rack key still reaches the box.

The virtual appliance residual

A virtual appliance runs on someone else’s hypervisor. Control of that hypervisor is control of the disk and of the serial console. A hostile hypervisor owns the disk.

Two deliveries, same inspection class:

• a virtual appliance on a hypervisor you trust
• a hardware appliance for environments where the hypervisor is not trusted

Until hardware ships, treat hypervisor and cloud serial-console IAM as part of the product’s trust boundary. The sealed allowlist on this image still holds.

Compatibility notes

4 - What Cisco and Fortinet incidents needed to exist

Prototype: The protections described on this page reflect Root Lock Firewall design intent. Root Lock Firewall is under active development. Incident facts below are taken from vendor and CISA publications, not from HeartSuite exploitation tests.

Overview: Root Lock Firewall is a host-shaped stateful filter on a closed image.

These incidents are here so the residual is visible. Campaign facts stay with the vendor advisories.

Where an attack is application content on a port you approved, or a new binary, or an outbound callback, those dimensions belong to Root Lock by HeartSuite and a WAF.

Cisco FTD static accounts (CVE-2024-20412)

What happened. In October 2024 Cisco published a critical advisory for Firepower Threat Defense on Firepower 1000, 2100, 3100, and 4200 series. The devices contained static accounts with hard-coded passwords.

An unauthenticated local attacker who reached the CLI could log in as those accounts, read sensitive data, change some configuration, or leave the device unable to boot. SSH is enabled by default on the management interface.

Cisco listed example account names in the advisory (csm_processes, report, sftop10user, Sourcefire, SRU).

Source: cisco-sa-ftd-statcred-dFC8tXT5.

What the campaign needed. A management CLI that accepted vendor-static credentials, reachable from serial or from SSH that ships enabled.

What Root Lock Firewall does. No vendor-static administrative accounts as a product feature. You reach the box on the console TUI of an image you control. There is no public administrative SSH by default.

What it does not cover. If the attacker holds a hypervisor console, or a bug in our own console stack, this particular path still belongs to whoever holds it. Console or serial remains the administrative path. Hard-coded vendor-static accounts stay off the image.

Cisco ASA/FTD VPN web server (CVE-2025-20333) and CISA ED 25-03

What happened. On 25 September 2025 Cisco disclosed a critical bug in the VPN web server of Secure Firewall ASA and FTD. Improper validation of HTTP(S) requests let an authenticated VPN user run code as root.

Cisco later described an unauthenticated companion (CVE-2025-20362) and stated that exploitation was attempted. CISA issued Emergency Directive 25-03. Affected features include SSL VPN and AnyConnect client-services on an interface.

Source: cisco-sa-asaftd-webvpn-z5xP8EUB.

What the campaign needed. A TLS web listener on the firewall whose job is remote access, not packet filtering.

What Root Lock Firewall does. Product identity is a sealed host filter. You reach the Dashboard on the console or serial console. SSL-VPN stays a dedicated concentrator.

What it does not cover. If the requirement is AnyConnect-class remote access, this particular gate does not apply — that stays a dedicated concentrator. Console or serial remains how you reach this image.

Persistence that survived the Cisco patch (April 2026)

What happened. On 23 April 2026 Cisco published that the ArcaneDoor actor had a persistence mechanism in the FXOS base operating system of affected ASA/FTD hardware. It remained after customers upgraded to the September 2025 fixed releases.

Cisco’s recommended removal is a reimage. A reload / reboot CLI command does not clear it. Cisco documented that only a cold power cycle is an emergency alternative, and warned that pulling power can corrupt the device.

Source: cisco-sa-asaftd-persist-CISAED25-03. CISA’s September 2025 background also described ROM persistence across reboot and upgrade on ASA.

What the campaign needed. A large, long-lived appliance OS under the filter, plus a first foothold (the VPN web server class above), plus persistence below the patch you thought you installed.

What Root Lock Firewall does. A smaller closed image, HeartSuite as the only update authority, and a custom kernel that already removes a class of in-kernel bypass primitives.

Supported recovery of a sealed box is Maintenance on the console, then a return and re-seal. That cycle unseals policy so you can change it. Firmware, ROM, and a hostile hypervisor stay outside that recovery.

What it does not cover. If the hypervisor is hostile, this particular gate does not apply below the image. The sealed allowlist on this image still holds. Firmware and ROM stay with whoever holds that path.

A later hardware appliance is the honest answer to that residual. The filter engine is userspace software under Root Lock. Formal seL4-style assurance of that engine is outside this prototype.

FortiCloud SSO into other customers’ devices (CVE-2026-24858)

What happened. On 27 January 2026 Fortinet disclosed an authentication-bypass in FortiOS, FortiManager, FortiAnalyzer, FortiProxy, FortiSwitchManager, and FortiWeb. An attacker with a FortiCloud account and a registered device could log into devices registered to other accounts when FortiCloud SSO was enabled.

Fortinet states the feature is off in factory defaults, but registering the device to FortiCare from the GUI enables the toggle unless the administrator turns it off. The bug was exploited in the wild.

After SSO, Fortinet observed configuration-file download and creation of local admin accounts (audit, backup, itadmin, and others).

Source: FG-IR-26-060 (CVE-2026-24858).

What the campaign needed. A cloud identity plane that can administer the filter, turned on as a side effect of “register this device.”

What Root Lock Firewall does. No cloud SSO into the filter. HeartSuite is the update authority. There is no FortiCare-shaped registration step that opens an administrative identity provider on the box.

What it does not cover. If email, webhook, or syslog go out to addresses you approved, this particular gate does not apply to those outbound channels. They stay ordinary outbound policy (Root Lock) plus whatever you configured for alerts. There is still no inbound SSO plane. A bug in an update channel we ship is our bug, disclosed as such.

Unsolicited inbound on a closed port

What happens on a general-purpose server. A forgotten listener or a default service is reachable from the internet. Scanners find it. Credential stuffing follows.

What Root Lock Firewall does. During observation those attempts become review events. After Firewall Lockdown, packets to sockets that are not on the sealed allowlist are refused, including when the service runs as root.

What it does not cover. If you approved the port, this particular gate does not unsay that approval. A seal that is too wide stays too wide. Packets to sockets off the sealed allowlist still fail. Volumetric flood absorption stays in front of the host. See Protection limits.

5 - A sealed host filter beside a campus NGFW

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: A listening service on a Linux host accepts inbound packets unless a filter refuses them. Root Lock Firewall is that host-path filter on a closed HeartSuite appliance: observe real traffic, approve a finite allowlist for this box, seal it.

The question it answers is: did a human approve this socket on this box, and is that set sealed?

Application identification, TLS interception, and fleet NGFW management stay with the campus tool. Root Lock by HeartSuite handles execution, files, and per-program outbound destinations on the same image.

Root Lock Firewall and Root Lock

Three OS-level controls are unrestricted by default on Linux: file access, network communication, and program execution. Inbound reachability is a fourth default: a bound port is open to the routeable world.

Root Lock and Root Lock Firewall share a review grammar and a seal. They close different defaults.

Root Lock is production-ready today on a server or a cloud image. You review programs, file paths, and outbound destinations, then enable Lockdown. Anything not on that allowlist is blocked at the kernel, including from root.

Root Lock Firewall is the host packet filter for a closed appliance. You review inbound and this-host path events, then enable Firewall Lockdown. On the HeartSuite appliance image they are designed to run together.

For production deployments today

Root Lock is the shipped product for execution, files, and outbound destinations. Inbound on that deployment remains an OS packet filter or a cloud security group, as the Network page states.

Root Lock Firewall is the prototype that takes inbound on a HeartSuite appliance as its job. Use it when the workload can live on the image and the team wants the same observe → approve → seal act on sockets.

Firewall Lockdown seals the packet allowlist. Root Lock Lockdown seals the kernel allowlist.

A finite observed sealed allowlist

This appliance is a finite, observed, reviewed, sealed allowlist for this host. Campus NGFW blades — application catalogs, TLS interception, URL clouds, sandbox, SD-WAN, SASE — stay the specialist tool. Enterprise NGFWs sell infinite policy surface and paid inspection.

Payload interpretation stays with a WAF in front of an allowed HTTPS port.

A virtual appliance that boots on AWS, Google Cloud, or Azure stays a host filter on that image. Provider controls (AWS Network Firewall, Azure Firewall, Cloudflare) stay the outer layer.

v1 filters this host. FORWARD and NAT stay later. Keep the existing edge box in front of other machines.

One owner of the host filter. UFW, firewalld, or a second manager on the same image is a composition hazard.

The Dashboard writes allowlist entries. Engine internals stay off the glass. There is no configuration mall and no cluster GUI as a drop-in vendor-panel replacement.

Execution, files, and per-program outbound destinations stay Root Lock. Root Lock inbound permits at Lockdown remain a thin accept path for SSH and named services.

A smaller remote plane is a different tool

Campus firewalls earned a second job: they became the remote-access concentrator and the administrative website. The packet filter then has to survive bugs in its own VPN web server, cloud SSO, and static accounts. That is a different tool shape from a sealed host filter with a console TUI.

Named incidents (vendor advisories, not HeartSuite testing):

Root Lock Firewall is designed without those surfaces:

• no VPN web server as identity
• no cloud SSO into the filter
• no vendor-static administrative accounts
• console or serial as the administrative path
• HeartSuite as the update authority
• seal plus a custom kernel under the filter

That is a smaller remote attack surface. A bug in this prototype remains in scope. Campus and inline FortiGate / Cisco Secure Firewall roles stay with those boxes.

See Recent firewall campaigns for the honest residual on each incident.

What Root Lock Firewall complements

Root Lock Firewall and Root Lock address complementary OS-level defaults. Root Lock Firewall covers inbound and this-host path at the packet filter. Root Lock covers execution, files, and outbound destinations at the kernel.

The HeartSuite appliance image, and a Root Lock server you already run

The HeartSuite appliance image is the intended Root Lock Firewall deployment: kernel grants under a sealed host filter. The image includes the Root Lock kernel. A packet filter on a general-purpose kernel you already run stays a different product.

Root Lock on a server you already run is the shipped shape for hosts that need execution and outbound control and already have an inbound filter (OS or cloud). That remains valid.

Positioning relative to common categories

How Root Lock Firewall can be circumvented. Under Firewall Lockdown paired with Root Lock Lockdown, an attacker who already has remote root cannot rewrite the sealed allowlist. Changing it takes Maintenance on the console or serial console. SSH is not enough.

What remains is whether you approved too wide a rule, whether an allowed port is still a hole in the application, whether the filter program can be killed, and whether someone who holds the hypervisor owns the disk.

Physical presence, cloud serial, or hypervisor control returns the box to whoever holds it.

Every security system has a known way to be taken out of the picture. Being explicit about it is how customers evaluate fit.

6 - What the firewall prototype covers today

Prototype: Root Lock Firewall is under active development.

Current capabilities

Root Lock Firewall currently includes the following as the prototype contract on the appliance image.

The intended observe → approve → seal path is Dashboard, Firewall Rules, Firewall Lockdown, and Maintenance. Treat the rows as that contract, not as a GA feature list. This documentation stays Prototype until that path exists on a real KVM image.

See Architecture and compatibility for the nft-path constraint and the virtual-appliance residual.

Planned

Next

Subsequent

Product identity stays a sealed host-shaped stateful filter. App-ID catalogs, TLS interception, URL clouds, sandbox blades, SD-WAN, SASE, SSL-VPN concentrator, cloud firewall / FWaaS, proxy / WAF, a vendor-panel replacement, and UFW as a second manager stay outside that identity.