Deploy firewalls, author L3/L4/L7 policy in a visual editor, and push it to many with a compliance check before it ships — across AWS, Azure and Google Cloud, in a single pane of glass. Stream live logs across firewalls and export them to your own SIEM. The GUI way to run Enforza.
Prefer policy-as-code? The same firewall runs through a GitHub pipeline too — same NVA, same engine.
Deploy, watch and steer your whole fleet from a single console — AWS, Azure and Google Cloud together. Author a policy once and push it to one firewall or a whole group, with a compliance check in front of every publish and every apply reporting back.
AWS, Azure and Google Cloud firewalls in a single pane of glass — a live map of locations, health counters, version and licence usage at a glance. No per-cloud console to flip between, no fleet spreadsheet to keep current.
Stand up a new firewall instance, register it and start enforcing in minutes — on any cloud, on a VM you already operate. The instance enrols itself over an outbound-only control plane; there is no inbound management port to open.
Write a policy once and publish it to one firewall or a whole group. Every push is a single, audited action with a compliance check in front of it — so the same vetted ruleset lands consistently across the fleet.
Each publish reports back to the console — success, or a parse / compile / apply error chip with the engine's own message inline. The silent-failure gap, where a rule validates centrally but rejects on the host, is closed.
A visual rule table with an object-aware picker. Set actions, reorder rules, reference named objects and toggle source-NAT — all in the GUI — then push with one click and a compliance check in front of it.
Compose L3/L4/L7 rules in an ordered table across the to-firewall, through-firewall and from-firewall sections, each with its own default action. Drag to reorder, set ACCEPT or DROP, toggle source-NAT per rule — all in the GUI.
Reference named network, port and hostname groups by name straight from the rule editor. The picker is opinionated about safety: cloud-imported groups appear in the destination picker only, so you author "egress to AWS S3", never "accept from all of AWS".
Allow or deny by destination domain (SNI / HTTP Host / DNS question name), TLS version, ALPN or upstream certificate — read from data already in clear text on the wire. No private CA to push to every endpoint, no custody of your TLS keys.
Publish a policy with a single click. Before it ships, it is checked against the frameworks you attached — advise to warn, or enforce to block the publish outright. Non-compliant rules never reach a firewall.
Write allow egress to AWS S3 in eu-west-2 and mean it.
The Object Manager pulls in cloud providers' own published IP-range
catalogues — AWS IP Ranges and Azure Service Tags — as named, reusable
network objects, kept current on a 48-hour change-detected refresh. The
rule editor picks from them by name, so you author against the service,
not a wall of CIDRs you chase every time the cloud changes.
Open any firewall and watch its traffic stream to your browser in real time. Select several and merge them into a single filterable feed — no agents, no forwarding pipeline, works through your own NAT.
Open a firewall and watch its traffic stream to your browser in real time — every flow, every action, every matched rule, as it happens. No agents to install, no forwarding pipeline to stand up; it works through your own NAT.
Select multiple firewalls and merge their streams into a single feed, then filter by source, destination, host, protocol or rule comment. Chase a problem across the fleet in one view instead of console-hopping cloud to cloud.
Each record carries who decided the packet and who enforces the rest of the flow, the matched rule, policy SHA, connection state, TLS version, ALPN and flow-close totals — so kernel-decided and engine-decided flows are equally auditable.
A separate log-shipping daemon ships traffic logs directly from the firewall instance to your destination, with your identity and your bill. The data plane never traverses Enforza's cloud — your logs stay yours.
The log-shipping daemon runs as its own hardened service, reading the firewall's local traffic logs and batching them straight to your destination using your own managed identity, instance role or token. We never sit in the path of your log data, and we pay nothing to move it — so there is no Enforza-side copy of your traffic to worry about.
Every sink reports a health heartbeat that renders as an inline chip on the firewall row — events written, last write, buffer depth, and the engine's own error string if a circuit opens. A plugin architecture means new sink kinds drop in without touching the core.
Logs Ingestion REST API with the VM's own managed identity.
Signed PutObject with the instance role; gzipped NDJSON batches.
HTTP Event Collector with a token held in your own cloud secrets.
The Cloud Controller is the workflow, not a different product. The same firewall NVA and the same single-pass packet classification and verdict engine run underneath whether you drive it from this console or from a GitHub pipeline — at the same flat per-firewall price.
GUI-driven, for network-operations teams who want to see and steer. Deploy, author policy in the visual editor, push to many and watch every flow stream back live — one pane of glass across the fleet.
Policy-as-code, for platform-engineering teams. Keep firewall policy in Git, reviewed in a pull request and gated by the same compliance checks before merge. Available now as a workflow — the same NVA enforces it.
No. The Cloud Controller and GitHub Pipeline Integration are two equal workflows over the same firewall NVA and the same single-pass packet classification and verdict engine, with equal billing. The Cloud Controller is the GUI way to run Enforza — deploy, author policy and watch logs in the console. GitOps is the policy-as-code way. The firewall enforcing your policy is identical either way; the only difference is how your team prefers to author and push.
AWS, Azure and Google Cloud — in a single pane of glass. A firewall instance runs on a standard Linux VM on any of them, and they all appear together in the fleet view with one map, one health board and one place to push policy.
No. The visual rule editor composes L3/L4/L7 policy in an ordered table with an object-aware picker — you set actions, reorder rules and reference named objects in the GUI, with no YAML to hand-write. Power users can still author advanced matchers directly, but it is not required to run the firewall from the console.
Your logs go to your own SIEM, never through Enforza's cloud. A separate log-shipping daemon streams traffic logs directly from the firewall instance to Azure Monitor / Microsoft Sentinel, AWS S3 or Splunk HEC, using your own managed identity, instance role or token — and your bill. The data plane never traverses Enforza's cloud. The live log stream you watch in the console runs over the same outbound control-plane connection; it is for operators viewing the fleet, not a copy of your logs that we retain.
Yes. Author a policy once and publish it to a single firewall or a whole group in one audited action. A compliance check runs in front of every publish — advise to warn or enforce to block — so the same vetted ruleset lands consistently across the fleet, and each apply reports its own success or error back to the console.
No. The firewall instance has no inbound management port and no admin UI to expose. Its control plane is outbound-only to the Enforza cloud — the instance manages up, never in — so there is no reachable management interface on the security device to find, harden or put behind a VPN, whichever workflow you drive it with.
Deploy, author policy in a visual editor, push to many with compliance gating, and stream live logs to your own SIEM — across AWS, Azure and Google Cloud. Start free, no card.
