Firezone connects users to private resources through a control plane, gateways, clients, and policies. Its architecture separates the management portal from the data-plane gateways. That split is useful for security design, but it complicates internet exposure counts. A public web portal, an API endpoint, and a gateway listener are not the same asset and should not share one product count.

A ZoomEye count-only probe on 2026-11-11 at 22:43 UTC returned 0 for app="Firezone" and 1,764 for title="Firezone". The probe used page 1, page size 1, and sub_type="all" [1]. The title count is a broad candidate set. It does not establish that 1,764 Firezone control planes are reachable, and the zero app count means a validated fingerprint was not present in this query.

The default-deny model

Firezone documents access as default-deny. A resource remains unreachable until a policy grants access to a group. The policy engine evaluates access when a client attempts to connect and when related configuration changes [2][3]. This design reduces accidental access, but it makes policy quality the central security question. An overly broad group or a service account placed in a powerful group can turn default-deny into broad allow.

Service accounts and API tokens are separate actor types. The documentation states that an API token cannot sign in to the Firezone client or admin portal and is not granted resource access through policies. A service account can be a regular actor and must be added to a group explicitly before a policy applies [4]. Those distinctions are important for investigation. A stolen API token and a stolen user session have different capabilities.

Inventory questions

Record the control-plane URL, account ID, identity provider, and gateway sites. Identify whether the public title belongs to a control plane, documentation site, client download page, or unrelated product. Verify the asset with its owner and configuration. Gateways may not expose an HTTP title at all, so a title search should not be used as the gateway inventory.

Review groups and policies. For each resource, list the groups that can reach it and the users or service accounts in those groups. Firezone's documentation describes a one-to-one mapping between a policy and a group-resource pair. If a broad group is attached to a sensitive resource, the policy may be technically valid but operationally excessive. Look for service accounts that were added to a group for convenience and never removed.

Identity and device trust

The control plane delegates user authentication to an identity provider. Review the issuer, client registration, redirect URI, and group claims. If Firezone maps an identity-provider group to a local group, a change in the identity provider can silently change access. Monitor group membership changes as security events.

Firezone also documents optional device trust using X.509 certificates issued by an MDM or enterprise PKI. This adds a second condition before access. It should not be treated as a replacement for user authorization. A compromised device with a valid certificate still needs a policy that limits which resources it can reach.

Monitoring and response

Monitor control-plane logins, policy changes, group changes, gateway enrollment, and resource configuration. Alert when a gateway appears from an unexpected site or when a policy grants a broad group access to a sensitive resource. Correlate a user login with the resources the user actually reached. A successful login is not the same as an authorized session.

If a token or session is suspected compromised, identify the actor type first. Revoke the API token or service account credential and remove the service account from affected groups. For a user, revoke sessions and re-evaluate group membership. Check whether the user's device certificate is still valid. Then inspect resource logs for access that occurred during the credential window.

Reporting the ZoomEye result

The correct count statement is narrow: app="Firezone" returned 0 and title="Firezone" returned 1,764 in the stated scope at the stated time. Do not translate the title result into a vulnerability count. Do not claim that every title match is self-hosted. Use the candidate list for ownership checks, then rely on control-plane configuration for the real inventory.

Hardening checklist

Keep the admin portal behind a strong identity provider and MFA. Use device trust where it fits the risk model. Review group membership and resource policies regularly. Separate service accounts by function and grant only the groups needed for their jobs. Protect API tokens and rotate them on a schedule. Monitor gateway enrollment and policy changes.

Firezone's default-deny design is a useful foundation. The exposure question is whether the control plane and its policies are managed with the same care as the network path they replace. A title-based external count can find candidates, but it cannot validate the policy. The security decision belongs in the configuration review.

References

[1] ZoomEye count-only observation, https://www.zoomeye.ai/searchResult?q=dGl0bGU9IkZpcmV6b25lIg==

[2] Firezone quickstart and default-deny policies, https://www.firezone.dev/kb/quickstart

[3] Firezone core components, https://www.firezone.dev/kb/architecture/core-components

[4] Firezone actor model, https://www.firezone.dev/kb/concepts/actors