NewFirebreak is now available: server segmentation at the host

Know what connects.
Control what should.

Access gets decided in two places: the firewalls across your network, and the servers themselves. Fireweave Technologies builds one product for each. FireWeave proves what your network actually does. Firebreak enforces what every server may talk to.

Self-hosted · Evidence behind every decision · Adopt either product on its own

Our products

Two products. Two layers of the same question.

“Can this talk to that?” has a network answer and a server answer. Each product owns one, stands on its own, and shows you the evidence behind every answer.

? can web-01 reach api-03 on tcp/443
1

10.20.4.15

web-01

2

PA-DC1

Panorama

3

sg-app-tier

AWS

4

10.40.8.12

api-03 :443

FireWeave

Firewall policy & path analysis · Across the network

Prove what your network actually does.

Ask whether two endpoints can talk. FireWeave walks every firewall and cloud control between them and returns the verdict, the exact rule behind it, and the evidence.

  • Palo Alto, Check Point, Fortinet, AWS, Azure and GCP
  • Governed change with rollback on six enforcement planes
  • AI that drafts changes and can't deploy them

Policy · default deny

role: web→role: apptcp/443
role: app→role: datatcp/5432
Anything elseDENY

Signed per host · canary first

Committed on host

web-01

canary…

web-02

pending

app-01

pending

app-02

pending

db-01

pending

db-02

pending

Firebreak

New

Host-based server segmentation · At the workload

Stop lateral movement at the host.

See every connection between your servers, allow only what runs your applications, and verify that each host actually enforces it, on Linux and Windows.

  • Observation mode first, with impact previewed against real traffic
  • Enforced in each host's own firewall: nftables or WFP
  • Signed policy, canary rollouts and one-step restore

A wider view of access

The network has layers. Your controls should too.

Firewall policy answers part of the access question, and server policy answers the rest. An attacker who lands on one server shouldn’t inherit everything that server’s subnet can reach. Each layer gets a product built for the team that runs it.

At the workload: Firebreak

Server-to-server policy enforced in each host's own firewall. Lateral connections no rule allows are dropped by the server that receives them.

Across the network: FireWeave

Firewalls, cloud security groups and routing in one model. Every path explained, every change governed and reversible.

data centercloud vpc

Your estate · data center + cloud

FireWeave · firewalls, cloud policy, routing

Firebreak · host policy on every server

How we build

Different jobs. The same engineering discipline.

Evidence, not assertions

FireWeave returns the rule and the evidence behind every verdict. Firebreak reports what each host actually committed, not just that a change was sent.

Change you can undo

FireWeave governs changes and can roll them back. Firebreak pilots on one host, rolls out canary-first, and restores the previous policy in one step.

Self-hosted by design

Both products run in your environment, under your control. Firebreak brings its own certificate authority and signing keys, and its controller needs no internet access.

Deterministic where it counts

FireWeave's AI can draft a change but can't deploy one. Firebreak's enforcement runs on signed, deterministic policy, with no model in the packet path.

Let’s start with your environment.

Bring a firewall problem, a segmentation project, or both. You’ll talk with the people who build the products.