Policies
A Policy is the rule that grants access in Firezone. Each Policy connects a single Group to a single Resource: every Actor in the Group may reach that Resource, and no one outside it can.
Firezone is default-deny. A Resource is unreachable until a Policy grants access to it, so access is purely additive — you open up exactly what each Group needs and nothing more. There are no "deny" rules to reason about; to revoke access, you remove or disable the Policy that granted it.
How overlapping policies combine
Access is evaluated on a boolean OR basis: when more than one Policy applies to the same Actor–Resource pair, access is allowed if any of them evaluates to true. Adding a Policy can only ever widen access, never narrow it, so the least-restrictive matching Policy wins.
This matters most when a Policy carries conditions. As an example, consider the following policies:
| Policy | Group | Resource | Condition |
|---|---|---|---|
A | Engineering | Production DB | Time of Day: 08:00-17:00 |
B | DevOps | Production DB | None |
If an Actor is a member of both the Engineering and DevOps groups, they will be
able to access the Production DB at any time of day since Policy B will always
evaluate to true.
Conditional access
On Team and Enterprise plans, a Policy can carry conditions that further restrict when and from where access is allowed — by client location, IP range, authentication provider, verified device, or time of day. Conditions are how Firezone expresses zero-trust controls beyond simple Group membership. The condition types below are available.
Client Location
Restricts access to Clients connecting from specific countries. The Client's IP
address is used to look up the country of origin. Supports is in (allow the
listed countries) and is not in (block them); accepts one or more countries.
IP Range
Restricts access to a specific IP address or range of Client IP addresses.
Supports is in CIDR and is not in CIDR; accepts one or more IPv4/IPv6
addresses or CIDR ranges.
Authentication Provider
Restricts access based on the authentication provider that was used to
authenticate the Client. Useful when you want to apply a stricter set of
authentication requirements for certain Groups or Resources using a separate SSO
app in your identity provider. Supports is in and is not in over the list of
configured providers.
Require Verified Client
Restricts access to verified Clients only. When this condition is present, any Client used by Actors in the group cannot access the Resource unless it has been explicitly marked as verified in the admin portal.
Adding the condition is itself the enablement — there is no extra toggle inside the card. Remove the condition to lift the requirement.
The Client is identified for verification by their unique device IDs, which are retrieved from the following sources depending on the platform:
| Platform | Source | Notes |
|---|---|---|
| macOS | Hardware ID | Matches the hardware ID found in the system report |
| macOS | Hardware serial | Matches the hardware serial found in the system report |
| iOS | App installation ID | A unique UUIDv4 generated by the system upon app installation. Note: This ID will be reset if the app is uninstalled and reinstalled. |
| Android | App installation ID | A unique UUIDv4 generated by the system upon app installation. Note: This ID will be reset if the app is uninstalled and reinstalled. |
| Windows, Linux | Device ID | The BIOS UUID retried from SMBIOS |
| Windows, Linux | Motherboard serial | The mainboard serial retried from SMBIOS |
This feature acts as a lightweight device management solution, ideal for organizations looking to enforce device policies (e.g., preventing mobile device access to production databases) without requiring a full-fledged MDM system to be in place.
Client verification is a lightweight mechanism designed to prevent outside attackers from impersonating an Actor's device using only a stolen credential. It is not a substitute for strong device identity authentication: the device IDs above are read from sources that an attacker with local access to an already-verified device can copy to another machine. Stronger device identity guarantees are planned in firezone/firezone#8369.
Time of Day
Restricts access to certain time windows throughout the week based on the 24hr
time and specified time zone. Each day of the week takes one or more
HH:MM-HH:MM windows during which access is allowed.
The time zone determines the offset used when determining whether to allow
access for a particular Client. For example, if you specify a time window of
08:00-17:00 and time zone of Eastern, Clients in the Pacific timezone 3
hours behind will be allowed access from 05:00-14:00 Eastern time.
Ready to grant access? See Manage access for the workflow to create a Policy and apply conditions.
Need help? See all support options.