How a Firewall Appliance Is Made: Fast Path, Hardened OS, Signed Firmware

A firewall appliance is a small server built for one job: an x86 or Arm CPU runs a hardened Linux or BSD system, kernel code or dedicated silicon moves packets, and signed images keep the boot chain honest. What most often goes wrong is the management plane: the web UI, API, SSH and VPN portal that attackers look for.

This post follows the box from reference design to end of support, using open sources only: NIST, CISA and Canadian Centre for Cyber Security guidance, the Common Criteria portal, and the documentation of open source projects such as OpenBSD pf, FreeBSD, OPNsense, Linux nftables, DPDK, AF_XDP, Suricata, strongSwan and WireGuard. It is vendor neutral, defensive and has no product rankings.

Key takeaways

• A firewall has three planes. The data plane filters and forwards packets, the control plane builds the routes and state the data plane uses, and the management plane is how people and tools configure the box.
• The fast path is where designs differ most: kernel networking, user space frameworks such as DPDK or AF_XDP, or network processors, FPGAs and ASICs that handle established flows.
• Manufacturing is mostly contract work. A brand adapts a silicon reference design, an original design manufacturer builds it, and the factory flashes firmware and provisions per device keys and certificates.
• Secure boot is a chain: an immutable root verifies firmware, firmware verifies the kernel, the kernel verifies modules, and the update client verifies packages. NIST SP 800-193 frames the goal as protect, detect and recover.
• CISA BOD 23-02 (13 June 2023) names firewalls among the devices whose management interfaces must not be reachable from the internet without a separate policy enforcement point. It binds US federal civilian agencies; the logic applies to everyone.
• Firmware trains, content updates (IPS signatures and threat feeds) and end of support dates are three different clocks. Track all three.
• The controls that do the most are plain: an inventory of versions and support dates, management only on an isolated network, logs shipped off the box, and hash or signature checks before every update.

From bare board to a deployed firewall: the step table

What is inside a firewall appliance?

Open a rack or desktop firewall and you find something close to a small server or a home router, depending on the price. The difference is how the parts are wired for packet work.

The general purpose CPU

Every appliance has a host CPU: usually x86 for mid range and larger boxes, or an Arm system on chip for branch and small models. It runs the operating system, management software, routing daemons, VPN key exchange, logging and any inspection that cannot be offloaded. On many smaller boxes it also does all the forwarding. Deep inspection and TLS handling are CPU heavy, which is why NIST SP 800-41 Rev. 1 asks buyers to test a prototype with the intended configuration in a lab before deployment rather than trusting headline numbers.

The fast path: network processors, FPGAs and ASICs

The fast path handles packets that belong to an established, allowed flow. A first packet goes to the slow path on the CPU, where the full policy is evaluated. Once allowed, the flow can be installed in a fast path table so later packets skip the policy engine. The options, from most flexible to most specialised:

• Kernel networking. The operating system's own stack does the work: netfilter with nftables on Linux, pf or another packet filter on BSD systems. Simple, well understood, and enough for many branch and home sized boxes.
• User space data planes. DPDK takes network interfaces away from the kernel and hands them to a user space process. Its programmer's guide describes an Environment Abstraction Layer that hides platform details and notes that most of its sample applications use a polling mode for performance. Linux also offers AF_XDP, which the kernel documentation describes as an address family optimised for high performance packet processing, with XDP programs redirecting frames into memory shared with user space.
• Network processors and SmartNICs. Programmable chips with many small cores or match action pipelines that parse headers, look up flows, count and forward. They bring their own firmware and driver stack.
• FPGAs. Reprogrammable logic loaded with a flow table or pattern matcher. The bitstream is one more piece of firmware to sign and update.
• ASICs. Fixed function silicon for flow lookup, NAT or encryption. Fastest per watt, least flexible, and tied to the supplier's SDK for the product's life.

Crypto accelerators

IPsec and TLS at high rates are expensive for a general CPU, so many appliances use AES and SHA engines inside the SoC, a separate accelerator chip, or CPU instruction set extensions. Offload adds a driver and sometimes a firmware blob. If the accelerator handles keys, its key storage and update path are part of the security design.

The switch chip

Desktop and branch firewalls often have more front panel ports than the CPU has network controllers. A small Ethernet switch chip fans one or two CPU links out to several ports, with internal VLAN tags telling them apart. A misconfigured switch chip can bridge networks the firewall policy treats as separate. The sibling post on how a network switch is made covers switch silicon in depth.

TPM or secure element

Many appliances carry a TPM or a secure element to hold the device identity key, record boot measurements, and seal secrets (such as a configuration encryption key) so they are released only when the measured boot state matches. A TPM records and attests; it does not by itself stop a bad image from booting. Enforcement comes from the firmware's verification chain.

Storage

The first stage firmware lives in SPI flash; the operating system and logs live on eMMC, an M.2 SSD or a small disk. Well designed appliances keep the root file system read only, rotate logs on a separate partition, send logs off the box, and keep two slots or boot environments so a failed update can fall back.

Management port, console and out of band access

Most appliances have a dedicated management Ethernet port and a serial console, and larger models may have a baseboard management controller. BOD 23-02 states the intent plainly: most device management interfaces are designed to be reached from dedicated physical interfaces or management networks, not from the public internet. Some models also carry bypass relays on port pairs so traffic keeps flowing if power fails; that fail open choice is a security decision and should be documented.

How is a firewall appliance built?

Reference designs and ODMs

Few firewall brands design every board from scratch. Silicon suppliers publish reference designs showing how to wire their CPU or network processor to memory, flash, network controllers and power. An original design manufacturer adapts the reference for the brand's port count, case and thermal budget, and often builds the units too.

Two consequences follow. The firmware beneath the brand's operating system (UEFI or U-Boot, network controller firmware, any BMC) often comes from the silicon supplier and the ODM, not the brand. And a weakness in a shared reference component can reach several product lines at once. Ask suppliers which firmware components they build and which they inherit.

Board bring-up

Bring-up is when prototype boards are first powered. Engineers check voltage rails and clocks, get first stage firmware running from SPI flash, train DRAM, then bring up the console, storage, network controllers and finally the operating system. JTAG and UART debug ports are essential here and a risk later, so production units usually have them locked, fused off, or at least behind physical access with tamper evidence.

Firmware flashing

On the production line a programming station writes first stage firmware to SPI flash (sometimes before the chip is soldered) and the operating system image to boot storage. A good line verifies each image against a known hash and records it against the serial number, which becomes the source of truth if anyone later needs to know what shipped on a unit.

Factory provisioning of keys and certificates

Provisioning turns a generic board into a specific device:

1. Write the serial number and MAC address range.
2. Enrol the secure boot public keys or key hashes the firmware will trust; on some platforms, blow fuses so they cannot change.
3. Generate a device identity key pair, ideally inside the TPM or secure element so the private key never leaves it.
4. Have the brand's manufacturing certificate authority sign a device certificate, which the device later uses to prove it is genuine when activating licences or joining a management service.
5. Record the public key, certificate serial and firmware hashes in the brand's database.

The weak point is the provisioning station. If it generates keys and copies them in, or will sign any request it receives, it is a high value target. Generating keys on device and letting the station relay only a certificate signing request limits that.

Test and shipping

Units go through functional test of every port, fan and power supply, often a heat soak burn-in, then sealed packaging. Tamper evident seals and recorded serials let a buyer confirm that what arrived is what left.

What software runs on a firewall appliance?

The base operating system

Almost every appliance runs a trimmed, hardened Linux or BSD derived system. OPNsense, an open source firewall distribution, is a public example: its architecture documentation describes the core as "an almost standard FreeBSD system" extended with packages, with source split into the FreeBSD base, a ports collection, the core GUI and configuration parts, and build tools. Hardening on an appliance usually means no general shell for administrators (or a restricted one), no compilers, kernel module signing enforced, and services bound only to the interfaces that need them.

The packet filter and policy engine

In open source systems you can read exactly how policy is evaluated. OpenBSD's pf.conf manual says pf filters statefully by default and that, for filter rules, the last matching rule decides the action unless a rule carries the quick option, which makes it the last matching rule and stops evaluation. On Linux, netfilter is the kernel framework and nftables its current interface; the nftables wiki says it is available in kernels from 3.13, ships the nft tool with a syntax different from iptables, and includes a compatibility layer so iptables commands can run over the nftables kernel framework.

Commercial appliances put their own model on top (zones, objects, users, applications) and compile it into whatever the data plane understands.

The data plane

The data plane touches every packet. In a kernel design it is the network stack and packet filter; in a user space design it is a DPDK or AF_XDP application with its own flow table; in a hardware assisted design it is network processor or ASIC microcode plus the driver that programs it. It parses untrusted packets at line rate, so memory safety bugs here are among the most serious an appliance can have.

The control plane

The control plane builds what the data plane needs: routing tables from static and dynamic routing, neighbour tables, state synchronisation between high availability pairs (often over a dedicated link), VPN security associations, DHCP leases and the compiled policy. These daemons run on the host CPU.

The management plane

The management plane is how an administrator or tool changes the box: web UI, REST or XML API, SSH CLI, SNMP, serial console, and often a connector to central or cloud management. OPNsense documents a split worth copying: a PHP frontend on the Phalcon framework, a backend service in Python, communication over a Unix domain socket, and a daemon called configd that starts and stops services and generates configuration files. The web layer asks a narrower backend to perform specific actions instead of running everything with full privilege.

VPN daemons

IPsec with IKEv2 is the long running standard for site to site tunnels; strongSwan's documentation explains how IKEv2 establishes security associations and supports options such as EAP and multiple authentication rounds. WireGuard's project site says it aims to be faster, simpler and leaner than IPsec and to be small enough to be reviewed by a single person. Many appliances also offer a TLS based remote access VPN with a web portal where users log in and download a client.

That portal is a second internet facing web application on the box. It is public by design, because remote users need it, so it needs the care of any public web app: fewer features exposed, prompt patches and strong authentication.

IPS engines and content updates

Intrusion prevention and application identification engines inspect traffic against signatures and protocol parsers. Suricata is the best documented open source example. Its documentation calls suricata-update the official way to update and manage rules: it downloads rule sets, merges them by default into a single suricata.rules file, lets you enable or disable rules through enable.conf and disable.conf, and recommends updating rules frequently, then restarting Suricata.

Commercial engines follow the same pattern. The engine is firmware; signatures, application definitions, URL categories and threat feeds are content on their own schedule. Content can still trigger a bug or block legitimate traffic, so it needs integrity checks and rollback like firmware.

How do secure boot and signed images work on appliances?

The chain of trust

Each stage verifies the next before handing over control:

1. Immutable root. Boot ROM in the CPU or SoC holds or references a public key (often a hash fused into silicon) and verifies the first stage firmware. The post on Intel Boot Guard and AMD Platform Secure Boot explains how x86 platforms do this before UEFI runs.
2. Firmware. UEFI or U-Boot verifies the bootloader or kernel signature against keys enrolled at the factory.
3. Kernel. The kernel verifies loadable modules. The Linux kernel's module signing facility signs modules at install time and checks the signature on load, so unsigned modules or modules signed with an invalid key can be refused.
4. Root file system. A read only root, often protected by a hash tree so a changed block is detected when read.
5. Packages and updates. The update client verifies a signature before installing. OpenBSD's signify is a clear public example: its manual shows signify -C verifying a signed checksum list (SHA256.sig) against a public key and then checking each file's checksum.

Measured boot runs alongside: each stage's hash is recorded in the TPM so the device or a remote verifier can later prove which code ran.

What NIST SP 800-193 adds

NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018), describes mechanisms for protecting the platform against unauthorised changes, detecting unauthorised changes that occur, and recovering rapidly and securely. On an appliance that means signed updates and write protected flash, verified and measured boot, and a golden image or second slot to recover to. The abstract also notes that a successful firmware attack could leave a system inoperable or needing reprogramming by the original manufacturer.

Signing keys and the release process

Image signing is only as strong as the private key. Keep signing keys in a hardware security module, separate engineering and production keys, require more than one person to approve a production signing, and publish release hashes on a channel separate from the download. If a key is exposed, revocation needs firmware that supports more than one trusted key or a key update path.

Why integrity checking tools matter after an incident

When an appliance is suspected of compromise, the first question is whether the code running on it is still the code that shipped. Several makers publish integrity checking tools or procedures for this. Conceptually they compare files, processes and images on the device against a known good manifest of hashes for that exact release, and look for files that should not be there.

Limits to keep in mind:

• A compromised device can lie about itself. A check run inside the box is evidence, not proof. Prefer manifests signed by the maker and, where possible, checks that read storage from outside the running system.
• Re-imaging is not always enough. If an attacker reached firmware below the OS, or took credentials, keys or the configuration, a rebuild does not undo that. Rotate every credential and key the device held.
• Collect before you clean. Preserve logs, running configuration, process and connection lists and integrity check output before a reboot or re-image, because some evidence lives only in memory.
• Integrity tools are product and version specific. Follow the maker's and your national CERT's guidance for the exact product.

Why is the management plane the main risk?

What BOD 23-02 requires

CISA issued Binding Operational Directive 23-02, Mitigating the Risk from Internet-Exposed Management Interfaces, on 13 June 2023. It observes that threat actors have used certain classes of network devices to gain unrestricted access to organisational networks, and that the risk grows when management interfaces are reachable from the internet.

Its scope covers routers, switches, firewalls, VPN concentrators, proxies, load balancers and out of band server management interfaces, over protocols including HTTP, HTTPS, FTP, SNMP, Telnet, TFTP, RDP, rlogin, RSH, SSH, SMB, VNC and X11. Within 14 days of CISA notification or the agency's own discovery, an agency must either make the interface reachable only from an internal enterprise network (CISA recommends an isolated management network), or deploy zero trust capabilities that enforce access through a policy enforcement point separate from the interface itself, which the directive calls the preferred action.

BOD 23-02 binds US federal civilian executive branch agencies only. CISA's directives page lists it alongside BOD 26-04 (10 June 2026) on prioritising security updates based on risk; BOD 22-01 is shown as revoked and is history now.

Why attackers aim at the management plane

• It is a web application. Admin UIs and VPN portals parse untrusted HTTP, handle sessions and uploads, and call system functions.
• It runs with high privilege. The code behind the UI can change policy, create users and often run system commands.
• It sits at the edge. If the management service listens on the outside interface, the attack surface is global.
• It is hard to watch. Few organisations run endpoint tooling on appliances, and many keep logs only on the device.
• It holds secrets. Configurations carry VPN keys, certificate private keys, directory bind credentials and password hashes. The post on edge devices as initial access covers how stored credentials turn one box into a foothold, and VPN edge appliance zero days covers the remote access portal side.

What the edge device guidance says

The Canadian Centre for Cyber Security's Security considerations for edge devices (ITSM.80.101, February 2025) recommends that network management interfaces not be directly exposed to the internet, and lists practical controls: enable centralised, off device logging at detailed levels; use strong, phishing resistant MFA for all administrative access; manage devices only from an out of band management network or an administrative workstation physically separated from the data network, using a hardened host; keep an inventory of edge devices and their support timelines; manage end of life devices, since any vulnerability found on them stays unpatched; and keep a baseline configuration that disables unneeded services and changes default credentials.

CISA's Enhanced Visibility and Hardening Guidance for Communications Infrastructure (4 December 2024), written with US and allied agencies, goes further for network devices: an out of band management network physically separate from operational traffic, a strict default deny ACL strategy with denied traffic logged, secure centralised logging with log traffic encrypted in transit, SNMPv3 only with encryption and authentication, disabling plaintext and unused services (Telnet, FTP, TFTP, SSH v1, HTTP servers, SNMP v1 and v2c), disabling unused VPN features and algorithms, investigating configuration changes made outside change management, and scanning your own internet facing infrastructure for exposed services.

What Secure by Design asks of appliance makers

CISA's Secure by Design pledge is voluntary and aimed at enterprise software makers, with seven goals. Several map onto appliance management planes: increase MFA use, reduce default passwords (for example with random, instance unique initial passwords or physical access for first setup), cut whole vulnerability classes such as injection and memory safety bugs, make patches easier to install and communicate end of life clearly, and give customers evidence of intrusions such as logs at no extra cost.

How do firmware and content updates, rollback and long term support trains work?

Release trains

Appliance software runs on trains: a major release, then maintenance releases until end of support. OPNsense publishes a clear, open example. Its documentation says there are two major releases a year, each receiving minor updates about every two weeks, named by year and month (25.1 is the January 2025 release; 25.1.3 is its third update). It warns that major upgrades install offline with no web or SSH server running, and recommends doing them from a VGA display or serial console so you can revert to a snapshot or repair if something fails.

Commercial appliances often run a feature train and one or more long term support trains that only receive fixes for longer. Long term trains reduce change risk but must be watched for their end dates.

Rollback

• A and B slots. The update writes the inactive slot; the bootloader tries it and falls back if it fails to boot or fails a health check.
• Boot environments or snapshots. A snapshot taken before an update lets you boot the previous state.
• Configuration history. A bad policy push can be undone separately from firmware.

Rollback has a security tension. If an attacker can roll a device back to an old, vulnerable but validly signed image, signatures alone do not help. Platforms counter this with anti rollback counters, a monotonic version in fuses or the TPM below which the bootloader refuses to go.

Content updates

IPS signatures, application definitions, URL categories and threat feeds update far more often than firmware. They should be signed and verified, staged where possible, and rolled back when a bad update blocks business traffic. The Suricata flow (fetch, merge, apply local enable and disable lists, restart) is a good mental model even for closed engines.

End of support

Every train and hardware model has an end of support date, after which no fixes arrive, including for the management plane. The edge device guidance above treats tracking support timelines as a core control. An appliance past its date on the network edge is the clearest replacement priority you have.

Comparing fast path designs

Component, failure mode, control

How is a firewall evaluated before purchase?

NIST SP 800-41 Rev. 1

NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy (September 2009), is old but still a useful frame. It covers packet filtering, stateful inspection, application firewalls, application proxy gateways, dedicated proxy servers and web application firewalls, recommends deny by default policies for incoming traffic, and sets out five phases: plan, configure, test, deploy and manage.

Common Criteria protection profiles

Government buyers in the US and allied markets often look for Common Criteria evaluations. The Common Criteria portal groups the relevant documents under boundary protection devices and systems, including PP-Modules for intrusion prevention systems, VPN gateways and TLS inspection proxies that are used together with the collaborative Protection Profile for Network Devices (NDcPP); the portal lists, for example, a certified PP-Configuration combining NDcPP with IPS, firewall and VPN gateway modules. An evaluation covers the versions, hardware and settings named in the security target, so check that what you deploy matches what was evaluated.

Step by step: inventory, lock down and verify your firewall appliances

These steps are generic. Use your product's documentation for exact menus, test changes in a maintenance window, and keep console access available, because a mistake in management access rules can lock you out.

1. Inventory firmware, OS and content versions

For each appliance record model, serial, firmware or OS version, IPS content version, licence expiry and the maker's end of support date for that model and train. On open source and Linux or BSD based systems you can read versions directly:

# OPNsense
opnsense-version

# FreeBSD based: installed kernel, running kernel, installed userland
freebsd-version -kru

# Linux based
cat /etc/os-release
uname -r

# Suricata engine
suricata -V

For closed appliances use the maker's CLI or API, or SNMPv3 from your monitoring host only:

snmpget -v3 -l authPriv -u monitor -a SHA -A "$AUTH" -x AES -X "$PRIV" \
  10.20.0.1 SNMPv2-MIB::sysDescr.0

Keep the results in version control or your asset system, with the end of support date on each line.

2. Remove management access from the WAN side

First see what is listening on the box:

# FreeBSD based
sockstat -4 -6 -l

# Linux based
ss -tulpn

Then, from an outside host you control, check your own public addresses for the management ports you use. Bind management services to the management interface only and drop management traffic everywhere else. A pf fragment for a BSD based system:

# pf.conf fragment: management only from the isolated management network
mgmt_if  = "igb2"
mgmt_net = "10.20.0.0/24"

set skip on lo
block in log all
pass in quick on $mgmt_if proto tcp from $mgmt_net to ($mgmt_if) port { 22 443 } keep state

The same idea in nftables on a Linux based system:

table inet mgmt {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    iifname "mgmt0" ip saddr 10.20.0.0/24 tcp dport { 22, 443 } accept
  }
}

These fragments show only the management part of a ruleset; a real one also needs your forwarding policy. Apply them with a console session open and confirm you can still log in from the management network before closing it.

If administrators must work remotely, bring them in through a VPN or access proxy that terminates on a separate device or interface, enforce phishing resistant MFA there, and let only that path reach the management network. That matches BOD 23-02's preferred policy enforcement point separate from the interface.

3. Send logs to an external collector

Forward system, authentication, configuration change, VPN and firewall logs to a collector the appliance cannot administer. Syslog over TLS is defined in RFC 5425, which allocates TCP port 6514 as its default. An rsyslog example using the omfwd module on a Linux based system:

# /etc/rsyslog.d/50-forward.conf
global(DefaultNetstreamDriverCAFile="/etc/rsyslog.d/ca.pem")

action(type="omfwd" target="logs.example.internal" port="6514" protocol="tcp"
       StreamDriver="gtls" StreamDriverMode="1"
       StreamDriverAuthMode="x509/name"
       StreamDriverPermittedPeers="logs.example.internal")

On GUI appliances use the remote logging settings and choose TLS where offered. Alert on administrator logins from unexpected sources, new administrator accounts, configuration exports, firmware changes and changes made outside change management.

4. Verify image hashes and signatures before every update

Download firmware only from the maker's official portal and compare its hash with the published value, ideally fetched over a separate channel:

sha256sum firewall-image.img
# compare with the maker's published SHA-256 for that exact file

Where a signed checksum list is published, verify the signature, not just the hash. OpenBSD's flow is a public example:

signify -C -p /etc/signify/openbsd-81-base.pub -x SHA256.sig

After the update, confirm the running version, run the maker's integrity check if one exists, and record the result in your inventory.

5. Turn the edge device guidance into a recurring review

Each quarter, check: management reachable only from the management network; phishing resistant MFA on administrative and VPN access; no default or shared local accounts; break glass password vaulted and rotated; plaintext and unused services off; SNMPv3 only; firmware and content within support; logs off box with alerts; backups encrypted; and a written, practised plan for a suspected compromise.

Common mistakes

• Management interfaces on the internet. The web UI, SSH or SNMP listening on the WAN side, often because a temporary rule was never removed.
• Local admin accounts never rotated. One shared admin password unchanged since installation, known to former staff and contractors.
• Logs kept only on the box. The evidence sits on the device you no longer trust and may vanish on reboot.
• Updates deferred past the support date. A train or model reaches end of support and keeps running at the edge.
• Trusting a re-image after compromise. Rebuilding without rotating the credentials, keys and VPN secrets the device held.
• Watching firmware but not content, or the reverse.
• Assuming the evaluated configuration. Buying on a Common Criteria certificate but running a different version or mode.
• Skipping hash checks. Uploading firmware from a mirror or shared drive without checking the published hash.

FAQ

What is inside a firewall appliance?

A general purpose x86 or Arm CPU, memory, SPI flash for firmware, an SSD or eMMC for the operating system and logs, network controllers and often a small switch chip. Many models add network processors, FPGAs or ASICs for the fast path, crypto accelerators, a TPM, a dedicated management port and a serial console.

Is a firewall just a Linux or BSD computer?

Mostly, with hardware and software tuned for packets. Most appliances run a hardened Linux or BSD derived OS for the control and management planes. The difference is the data plane, which may be kernel code, a user space framework or dedicated silicon.

What is the difference between the data plane, control plane and management plane?

The data plane filters and forwards each packet. The control plane builds routes, state tables and VPN keys for it. The management plane is how administrators and tools configure and monitor the device through a web UI, API, SSH or SNMP.

Why should the firewall management interface not be on the internet?

Because it is a privileged web application that parses untrusted input, and a flaw in it can hand over the device and the network behind it. CISA BOD 23-02 requires federal agencies to take such interfaces off the internet or put a separate policy enforcement point in front of them.

What is BOD 23-02?

A CISA Binding Operational Directive issued on 13 June 2023 requiring US federal civilian agencies, within 14 days of discovery or notification, to remove internet exposed management interfaces of routers, switches, firewalls, VPN concentrators, proxies, load balancers and out of band server management, or protect them with zero trust access control.

How does secure boot work on a firewall?

An immutable root of trust verifies the first firmware, which verifies the bootloader and kernel, which verifies modules and updates. Each stage checks a signature before running the next, and a TPM can record measurements so the boot state can be proven later.

How do I verify firewall firmware before installing it?

Download it from the maker's official portal, compare its SHA-256 hash with the published value, verify a signature if one is provided, and confirm the version after installing.

What happens when a firewall reaches end of support?

The maker stops shipping fixes, including security fixes. The box may keep working, but any new vulnerability stays open, so plan replacement before the published date.

Can I check whether my firewall has been tampered with?

Use the maker's integrity checking tool or procedure if one exists, review the logs you shipped off the device, and contact the maker and your national CERT. A check run on a compromised device is evidence, not proof.

Where Safeguard fits, honestly

Safeguard does not build, test or certify firewall appliances, scan appliance firmware images, monitor network devices, manage device fleets or generate hardware bills of materials. Nothing here should be read as Safeguard securing a firewall.

The overlap is the software your teams write around the edge: automation that pushes firewall policy, internal portals and APIs that read firewall logs, and any appliance software you build yourself on Linux or BSD. If that code lives in repositories or container images, Safeguard can scan it (for example safeguard scan --dir . on a checkout or safeguard scan --image followed by an image name), match components against vulnerability databases, rank findings with reachability analysis, evaluate policies and gates, and open fix pull requests when you switch autonomous remediation on.

Supply chain hygiene still matters at the edge: every appliance ships open source components in its kernel, VPN daemons, web stack and inspection engines, and the automation around it pulls dependencies like any other project. For the parts you build and ship yourself, the options below help close the gap between a fix existing and that fix running.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow fits a JavaScript dashboard or automation service your team maintains for firewall policy and logs.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Network teams that keep automation repositories inside the management network can scan them locally the same way.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A team asking an assistant about its network automation code can limit it to the read and scan tools it needs.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• CISA, BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces (13 June 2023)
• CISA, Enhanced Visibility and Hardening Guidance for Communications Infrastructure (4 December 2024)
• Canadian Centre for Cyber Security, Security considerations for edge devices (ITSM.80.101, February 2025)
• CISA, Secure by Design
• CISA, Secure by Design Pledge
• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy (September 2009)
• NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018)
• Common Criteria portal, Collaborative and other protection profiles
• OpenBSD, pf.conf(5)
• OpenBSD, signify(1)
• nftables wiki, What is nftables?
• DPDK
• DPDK Programmer's Guide, Overview
• Linux kernel documentation, AF_XDP
• Linux kernel documentation, Kernel module signing facility
• OPNsense documentation, Updates
• OPNsense documentation, Architecture
• FreeBSD manual, freebsd-version(1)
• Suricata documentation, Rule Management with Suricata-Update
• strongSwan documentation, Introduction
• WireGuard
• RFC 5425, TLS Transport Mapping for Syslog
• rsyslog documentation, omfwd: syslog forwarding output module

Last reviewed: 26 October 2026.