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 — and where it does not
• 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: This is not 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 by HeartSuite does not provide that filter.

Root Lock controls outbound destinations per program, at the kernel, using literal IP addresses. Root Lock Firewall is the inbound and host-path stateful filter for a closed HeartSuite appliance: observe real traffic, approve a finite allowlist, seal it.

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 out of scope.
• Walkthrough — The intended Dashboard journey from first boot to a sealed ruleset.
• What Root Lock Firewall does and does not cover — Where the packet boundary holds, where it does not, 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.

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 not the same control. 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 — not a missing “next-gen” blade. 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.

Why another NGFW blade does not close this

Application catalogs, TLS interception, URL clouds, and sandbox subscriptions answer a different question: what is inside a flow you already decided to accept. They do not answer “which inbound sockets on this box did a human approve, and is that set 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, not through a public administrative VPN.

What Root Lock already covers — and what it leaves open

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. It is not inbound port policy.

Root Lock Lockdown can record a thin inbound permit for SSH scope and named services. That path is accept-only. It is not observation of real traffic, not a reviewed allowlist of this box, and not 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, not a claim that an approved port is safe, that a wide seal is minimal, or that the hypervisor console is out of scope. See What Root Lock Firewall does and does not cover.

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, not the filter. You receive an image, not a package.

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 does not change the 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. The sealed image does not fetch rules or reputation from a public CDN.

You do not install Root Lock Firewall onto an existing Ubuntu or Debian kernel. Install scripts that appear in development trees are for laboratory layer installs on a test guest, not the customer model.

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. You do not place the appliance in front of another server in v1.
• 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.

The product does not inspect application payloads, terminate TLS in order to classify applications, or subscribe to a URL or sandbox cloud. That refusal is the design, not a missing license.

Observation, approval, and Firewall Lockdown

The human act is the same one 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. It does not mean an NGFW somewhere else is healthy.

Firewall Lockdown and Root Lock Lockdown are paired on the appliance and are not the same act. 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 What Root Lock Firewall does and does not cover for residuals.

Status

Root Lock Firewall is a prototype. Capabilities, configuration, and deployment details are subject to change. Root Lock remains the shipped kernel product.

1.3 - Where the packet boundary holds — and where it does not

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

Overview: Root Lock Firewall enforces one thing: inbound and this-host path traffic that is not on the sealed allowlist is refused — including traffic aimed at services running as root.

An attacker who uses a port you approved is constrained by that rule, not stopped at the application.

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 enforces. 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 Root Lock Firewall does not cover. Content on an allowed port is outside a stateful packet filter. 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. This is a deliberate division of layers, not a gap.

Outbound destinations per program

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

What Root Lock Firewall enforces. The host path is still subject to the sealed host filter. That is not the same as per-program outbound policy.

What Root Lock Firewall does not cover. Which program may reach which literal IP is Root Lock’s domain. See Network and Remote Access.

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 enforces. v1 filters INPUT and OUTPUT of this image. The workload is meant to run on the image.

What Root Lock Firewall does not cover. Sitting in front of other hosts (FORWARD, NAT as a product surface) is not v1. An edge SKU would change placement. Until then, do not treat this box as a campus or DC inline firewall. 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 enforces. Connection state and the allowlist you sealed.

What Root Lock Firewall does not cover. Those blades are refused as product identity. They are the policy surface Root Lock Firewall is designed not to become. If you need them, keep the specialist tool and do not expect this image to replace it.

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 enforces. Under Firewall Lockdown, an attacker who already has remote root cannot rewrite the sealed allowlist. Change goes through Maintenance on the console.

What Root Lock Firewall does not cover. Physical presence, a cloud serial console, or control of the hypervisor under a virtual appliance returns the box to whoever holds that path. Restrict console access in the hypervisor or cloud IAM.

A later hardware appliance removes the hypervisor residual; it does not remove physical presence. 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 enforces. 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 Root Lock Firewall does not cover. Seal makes a chosen ruleset immutable. It does not prove the ruleset is minimal.

Inventory advisories can flag breadth. They cannot unsay an approval. 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).

This walkthrough is the intended console path on a Root Lock Firewall appliance image. There is no package to install on a foreign kernel. You boot the image, 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: the box is teaching you what is listening and what is arriving.

The Suggested Next Step points at pending firewall events, not at a catalog of blades.

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. It is not enough. 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. They are not editable here.

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.

What this demonstrates

• Observation is a state, not a hidden log.
• Approval is per event, with consequence, matching the Root Lock review grammar. See Root Lock Firewall overview.
• Firewall Lockdown is earned and reversible only through Maintenance. See What Root Lock Firewall does and does not cover.

2 - Where a host-shaped firewall belongs

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

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, not instead of a provider DDoS tool

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.

It does not replace a cloud firewall service, and it does not become one by booting on AWS, Google Cloud, Azure, DigitalOcean, or Linode.

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, not a team that wants a FortiManager-class estate.

Where Root Lock Firewall does not apply

In front of other machines

v1 has no FORWARD or NAT product surface. Do not put this appliance in front of a backup server, a subnet, or a pair of application hosts and expect it to publish them.

Keep the existing edge firewall for that job, or wait for an edge SKU that changes placement.

Campus, branch, or “NGFW refresh”

Root Lock Firewall does not ship App-ID, TLS interception, URL clouds, SD-WAN, SSL-VPN as identity, or a central management empire. Buyers who need those keep the specialist tool.

Using this image as a FortiGate or Cisco Secure Firewall replacement is a misfit, not a configuration problem.

Install-on-my-Ubuntu

You cannot add this product to a general-purpose server the way you add UFW. The customer model 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 Phase 2. 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. It does not ship a container engine and is not a Docker or Kubernetes node. See Root Lock Deployment Scenarios.

A WAF or API gateway requirement

Payload inspection, bot scores, and schema validation are out of scope. Put a WAF in front of an allowed HTTPS port if that is the requirement.

Alongside Root Lock

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

Root Lock without this image is still a complete kernel product. Missing Root Lock Firewall there is missing an optional SKU, not a hole in Root Lock.

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 What Root Lock Firewall does and does not cover.

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.

Closed image, not a package

Root Lock Firewall is the stateful packet-filter layer of a HeartSuite appliance image. The customer model is: boot the image, use the Dashboard on the console or serial console, observe, approve, 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. You cannot treat this product as software you drop onto a distribution kernel you already run.

Laboratory install scripts exist for layer-installing the prototype on a throwaway guest. They are not the product.

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, not a hardening step.

Root Lock’s own packet path — SSH scope and accept-only service permits at Lockdown — remains thin. It is not this product. See Mode Switching and Lockdown for that Root Lock path, and do not read it as Root Lock Firewall.

Linux netfilter on the nft path

The Root Lock kernel carries nftables and does not carry the older iptables table. 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. It does not expose an engine configuration mall, a vendor web panel, or a cluster GUI.

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. It is also why “we have no bugs” is not a claim this documentation makes.

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 a set you already chose. It is not a cryptographic proof that the live filter table equals the review queue you clicked through.

Completeness of that correspondence is an engineering property under test, not a slogan. If a later engine can make the seal hashable, the product class does not change: it is still 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 What Root Lock Firewall does and does not cover.

Those omissions are the architectural answer to the campaign class in Recent firewall campaigns. They shrink the remote attack surface of the filter. They do not make the box unreachable to someone who holds the hypervisor console or the rack key.

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. Root Lock Firewall does not claim to survive a hostile hypervisor.

Later marketing names two SKUs without changing 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.

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.

Root Lock Firewall is a host-shaped stateful filter on a closed image. It is not Cisco ASA, Cisco FTD, or FortiOS.

These incidents are here so the residual is visible, not as a claim that this appliance would have stopped another vendor’s CVE.

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

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 is designed to do. 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 Root Lock Firewall does not claim. A bug in our own console stack, or a hypervisor administrator, is still in scope for whoever holds that path. Hard-coded passwords at a vendor are a class we refuse to ship; they are not a proof we have none.

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 is designed to do. SSL-VPN is not product identity. You reach the Dashboard on the console or serial console. Remote access, if you need it, stays a separate decision — not a website on the filter.

What Root Lock Firewall does not claim. We do not terminate customer VPNs. If you need AnyConnect-class remote access, keep a dedicated concentrator. This image will not become one by configuration.

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 is designed to do. 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. It is not a reimage, and it does not claim to wipe firmware, ROM, or a hostile hypervisor.

What Root Lock Firewall does not claim. Firmware, hypervisor, or ROM below a virtual appliance is not this product. A hostile hypervisor still owns the disk.

Hardware Phase 2 is the honest answer to that residual, and it is not shipped. We do not claim seL4-level assurance of the filter engine.

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 is designed to do. 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 Root Lock Firewall does not claim. Email, webhook, and syslog out to addresses you approved are still ordinary outbound policy (Root Lock) plus whatever you configured for alerts. That is not an inbound SSO plane. A bug in an update channel we do ship would be 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 is designed to do. 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 Root Lock Firewall does not claim. A port you approved stays a port you approved. A seal that is too wide stays too wide. Rate-limit extras that ship in the image baseline are not a promise to absorb a volumetric flood; that flood belongs in front of the host. See What Root Lock Firewall does and does not cover.

Reading this page as a kernel reviewer

The useful sentence is not “they had CVEs, we will not.” Every large filter will.

The useful sentence is: the management and remote-access plane of the filter has been the expensive surface, and this appliance is designed not to have that plane.

If we later add a public administrative listener, a cloud SSO toggle, or vendor-static accounts, this page becomes false and should be rewritten — not footnoted.

5 - This is not 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 not “which application catalog matches this flow?” It is “did a human approve this socket on this box, and is that set sealed?”

Application identification, TLS interception, and fleet NGFW management are outside its scope. 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. It does not replace Root Lock. On the appliance 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.

Do not use it as a silent rename of Root Lock Lockdown.

What Root Lock Firewall is not

Root Lock Firewall is not an NGFW. It has no application catalog, no TLS interception, no URL cloud, no sandbox blade, no SD-WAN, and no SASE fabric. Enterprise NGFWs sell infinite policy surface and paid inspection. This appliance sells a finite, observed, reviewed, sealed allowlist.

Root Lock Firewall is not a proxy or a WAF. It does not terminate or interpret application payloads. Put a WAF in front of an allowed HTTPS port if that is the requirement.

Root Lock Firewall is not a cloud firewall service. A virtual appliance that boots on AWS, Google Cloud, or Azure is not AWS Network Firewall, Azure Firewall, or Cloudflare. Keep provider controls as an outer layer.

Root Lock Firewall is not an inline perimeter box in v1. It filters this host. FORWARD and NAT are not a product surface yet. Do not place it in front of other machines.

Root Lock Firewall is not UFW, firewalld, or a second filter beside itself. One owner of the host filter. A second manager on the same image is a composition hazard.

Root Lock Firewall is not a drop-in replacement for a vendor web panel. There is no configuration mall and no cluster GUI. The Dashboard writes allowlist entries. Engine internals stay off the glass.

Root Lock Firewall is not Root Lock. Root Lock inbound permits at Lockdown are a thin accept path for SSH and named services. They are not this product.

Why not “the same as Cisco or Fortinet, smaller”

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. It is not a claim that this prototype has no bugs. It is not a claim that it replaces a FortiGate or a Cisco Secure Firewall in a campus or inline role.

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.

Root Lock Firewall alone vs with Root Lock

Root Lock Firewall alone is not a planned customer shape. The image includes the Root Lock kernel. A packet filter on a general-purpose kernel you already run is a different product, and it is not this one.

Root Lock alone is the shipped shape for servers that need execution and outbound control and already have an inbound filter (OS or cloud). That remains valid.

Both on the appliance is the intended Root Lock Firewall deployment: kernel grants under a sealed host filter.

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.

The question is no longer whether they can turn the filter off. It 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 Preview until the proud KVM roundtrip exists.

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

Planned

Next

Subsequent

Items that are not on this roadmap as product identity: App-ID catalogs, TLS interception, URL clouds, sandbox blades, SD-WAN, SASE, SSL-VPN concentrator, cloud firewall / FWaaS, proxy / WAF, a drop-in vendor-panel replacement, UFW as a second manager.