Firebreak · Architecture & security

Built like the control it is.

A segmentation product holds the keys to every server’s firewall. Here is how Firebreak is put together, how it earns that trust, and where its guarantees stop.

firebreak controller · self-hostedlinux serverwindows server:443ssoexport:18444 mTLS:18443 enrollapplication traffic · never via controllerEngineersbrowser · CLI · APIIdentity providerOIDC · SAML · SCIMYour toolsSIEM · ServiceNow · Jira · Slack · TeamsGatewaynginx · TLSController APIpolicy · signing · CAWorkerpreviews · rollouts · retentionPostgreSQLdedicatedAgentunprivileged · local bufferHelpersigned, constrained ops onlynftables / WFPAgentunprivilegedHelperconstrained opsnftables / WFPSigned policy flows down. Committed state and observations flow up.Only the helper may change the firewall, and only Firebreak's own table or provider.

Security model

Trust is established, never assumed.

01

Enrollment

  • One-time pairing file that expires after 15 minutes
  • Each agent generates its private key on the host. Keys never travel.
  • Its certificate is bound to that workload's identity

02

Control channel

  • Mutual TLS against your installation's own certificate authority
  • 30-day agent certificates, renewed automatically
  • Separate ports for the console, enrollment and agent traffic

03

Policy delivery

  • Ed25519-signed per host, with a sequence number against replay and an expiry
  • Trial apply, then kernel read-back, then a second signed confirmation before commit
  • Automatic local rollback when the confirmation never arrives

04

On the host

  • The agent runs unprivileged
  • A separate helper is the only component that changes the firewall, through constrained, signed operations with no shell
  • Linux services are sandboxed by systemd. On Windows: a virtual service account, an ACL-restricted pipe and boot-time WFP guards.

05

Keys & data at rest

  • Controller keys sealed with systemd credentials, bound to the TPM when present
  • Nightly backups encrypted with ChaCha20-Poly1305 and signed
  • Release artifacts signed with a separate key, and every file verified at install

06

People & sessions

  • OIDC, SAML 2.0 (SP-initiated only, signature-wrapping and replay protections) and SCIM 2.0
  • Argon2id for local passwords. CSRF and origin checks on every session.
  • SCIM tokens stored only as hashes. Ticketing and SIEM credentials are never returned by the API.

Where the guarantees stop

What we’re precise about.

No single control is the whole defense. Here is where Firebreak’s responsibility ends, so you can plan around it.

Company security & disclosure policy

mTLS protects the control channel, not your application traffic.

Firebreak decides which connections are allowed. It does not encrypt server-to-server traffic.

A host owned at root can lie about itself.

Host enforcement is strong against lateral movement from other machines. An attacker with root on a server can alter that server's own firewall and reports, so treat endpoint integrity as a separate control.

Standby promotion is a deliberate act.

A warm standby controller is supported, and promoting it is a command you run, never automatic.

Start with one application.

We’ll walk through its real communication, the access policy it needs, and enforcement on its hosts, in your environment, with the engineers who build Firebreak.