Policies

Cloudflare Access determines who can reach your application by applying the Access policies you configure.

Every Access policy has four building blocks:

• Actions: What happens when a user matches the policy (Allow, Block, Bypass, or Service Auth)
• Rule types: How criteria are combined (Include, Require, or Exclude)
• Selectors: The attributes being checked (for example, email domain, country, or device posture)
• Values: The specific values to match against (for example, @example.com)

Actions

Actions let you grant or deny permission to a certain user or user group. You can set only one action per policy.

Allow

The Allow action allows users that meet certain criteria to reach an application behind Access.

The following example lets any user with an @example.com email address, as validated against an IdP, reach the application:

Action	Rule type	Selector	Value
Allow	Include	Emails Ending In:	@example.com

You can add a Require rule in the same policy action to enforce additional checks. Finally, if the policy contains an Exclude rule, users meeting that definition are prevented from reaching the application.

For example, this second configuration lets any user from Portugal with a @team.com email address, as validated against an IdP, reach the application, except for user-1 and user-2:

Action	Rule type	Selector	Value
Allow	Include	Country	Portugal
	Require	Emails Ending In	@team.com
	Exclude	Email	user-1@team.com, user-2@team.com

Block

The Block action prevents users who meet certain critera from reaching an application behind Access. For example, the following policy blocks requests from Russian source IPs that are not on your list of approved IPs.

Action	Rule type	Selector	Value
Block	Include	Country	Russian Federation
	Exclude	IP list	Corporate IP allowlist

Block policies are best used in conjunction with Allow policies as a way to carve out exceptions in those Allow policies. Since Access is deny by default, users who do not match a Block policy will still be denied access unless they explicitly match an Allow policy.

Bypass

Warning

Bypass does not enforce any Access security controls and requests are not logged. Bypass policies should be tested before deploying to production. Consider using Service Auth if you would like to enforce policies and maintain logging without requiring user authentication.

As Bypass does not enforce Access security controls, Bypass policies do not support identity-based rule types. When making Bypass policies, you will not be able to apply certain identity-based selectors (such as email).

The Bypass action disables any Access enforcement for traffic that meets the defined rule criteria. Bypass is typically used to enable applications that require specific endpoints to be public.

For example, some applications have an endpoint under the /admin route that must be publicly routable. In this situation, you could create an Access application for the domain test.example.com/admin/<your-url> and add the following Bypass policy:

Action	Rule type	Selector	Value
Bypass	Include	Everyone	Everyone

As part of implementing a Zero Trust security model, Cloudflare does not recommend using Bypass to grant direct permanent access to your internal applications. To enable seamless and secure access for on-network employees, use Cloudflare Tunnel to connect your private network and have users connect through the Cloudflare One Client.

Note

When applying a Bypass action, security settings revert to the defaults configured for the zone and any configured Page Rules. If Always use HTTPS is enabled for the site, then traffic to the bypassed destination continues in HTTPS. If Always use HTTPS is disabled, traffic is HTTP.

Product compatibility

Bypass policies which contain device posture check rules will not function when Zaraz is enabled for the zone protected by Access, or if a Worker intercepts the request. To work around this limitation and bypass Access, change the policy action to Service Auth.

Service Auth

Service Auth rules enforce authentication flows that do not require an identity provider IdP login, such as service tokens and mutual TLS.

Action	Rule type	Selector
Service Auth	Include	Valid certificate

Rule types

Rule types determine how your criteria are combined to evaluate a user. All Access policies must contain at least one Include rule. This Include rule defines the initial pool of eligible users who can access an application. You can then add Exclude and Require rules to narrow the scope.

Rule type	Logic	Effect
Include	OR	User must match at least one Include rule.
Exclude	NOT	User matching any Exclude criterion is denied access, even if they match an Include rule.
Require	AND	User must match all Require criteria in addition to matching an Include rule.

Require rules with OR operators

By default, multiple values in a Require rule are joined with AND logic. This can produce unexpected results.

Example problem: You want to allow employees and contractors in Portugal or the United States. If you configure:

Action	Rule type	Selector	Value
Allow	Require	Country	United States, Portugal
	Require	Emails ending in	@cloudflare.com, @contractors.com

This policy requires the user to be in the United States AND Portugal simultaneously, and have an email ending in both @cloudflare.com AND @contractors.com. No user can satisfy all conditions, so nobody gets access.

Solution: Use a rule group to convert AND logic to OR logic within a Require rule.

1. Create a rule group called Country requirements that includes users in Portugal OR the United States:

   Rule type	Selector	Value
   Include	Country	United States, Portugal

2. Create a policy that requires the rule group and includes users with either email domain:

   Action	Rule type	Selector	Value
   Allow	Require	Rule group	Country requirements
   	Include	Emails ending in	@cloudflare.com, @contractors.com

Selectors

When you add a rule to your policy, you will be asked to specify the criteria/attributes you want users to meet. These attributes are available for all Access application types, including SaaS, self-hosted, and non-HTTP applications.

Non-identity attributes are polled continuously, meaning they are evaluated with each new HTTP request for changes during the user session. If you have configured SCIM provisioning, you can force a user to re-attest all attributes with Access whenever you revoke the user in the IdP or update their IdP group membership.

Selector	Description	Checked at login	Checked continuously1	Identity-based selector?
Emails	you@company.com	✅	❌	✅
Emails ending in	@company.com	✅	❌	✅
External Evaluation	Allows or denies access based on custom logic in an external API.	✅	❌	✅
IP ranges	192.168.100.1/24 (supports IPv4/IPv6 addresses and CIDR ranges)	✅	✅	❌
Country	Uses the IP address to determine country.	✅	✅	❌
Everyone	Allows, denies, or bypasses access to everyone.	✅	❌	❌
Common Name	The request will need to present a valid certificate with an expected common name.	✅	✅	❌
Valid Certificate	The request will need to present any valid client certificate.	✅	✅	❌
Service Token	The request will need to present the correct service token headers configured for the specific application. Requires the Service Auth action.	✅	✅	❌
Any Access Service Token	The request will need to present the headers for any service token created for this account. Requires the Service Auth action.	✅	✅	❌
User Risk Score	The user's current risk score (Low, Medium, or High). Acts as a threshold — users with a score at or below the specified level pass the check. This selector only displays for Enterprise plans.	✅	✅	✅
Linked App Token	Checks for a valid OAuth access token issued to a specific Access for SaaS application. Requires the Service Auth action.	✅	✅	❌
Login Methods	Checks the identity provider used at the time of login.	✅	❌	✅
Authentication Method	Checks the multifactor authentication method used by the user, if supported by the identity provider.	✅	❌	✅
Identity provider group	Checks the user groups configured with your identity provider (IdP). This selector only displays if you use Microsoft Entra ID, GitHub, Google, Okta, or an IdP that provisions groups with SCIM.	✅	❌	✅
SAML Group	Checks a SAML attribute name / value pair. This selector only displays if you use a generic SAML identity provider.	✅	❌	✅
OIDC Claim	Checks an OIDC claim name / value pair. This selector only displays if you use a generic OIDC identity provider.	✅	❌	✅
Device posture	Checks device posture signals from the Cloudflare One Client or a third-party service provider. This selector only displays after you create a device posture check.	✅	✅	❌
Warp	Checks that the device is connected to the Cloudflare One Client, including the consumer version. This selector only displays after you enable the WARP posture check.	✅	✅	❌
Gateway	Checks that the device is connected to your Zero Trust instance through the Cloudflare One Client. This selector only displays after you enable the Gateway posture check.	✅	✅	❌

¹ For SaaS applications, Access can only enforce policies at the time of initial sign on and when reissuing the SaaS session. Once the user has authenticated to the SaaS app, session management falls solely within the purview of the SaaS app.

Connection context

Connection context settings allow you to control how users interact with an application after they have been granted access. While selectors determine who can access an application, connection context settings determine what actions users can take during their session.

Connection context is configured per policy, allowing you to grant different permissions to different groups of users. For example, you could allow full-time employees to copy data from a remote RDP session while restricting contractors to read-only access.

The available connection context settings depend on the application type:

Application type	Available settings
Infrastructure (SSH)	Allowed UNIX usernames
Browser-based RDP	Clipboard controls (copy/paste restrictions)

Order of execution

Policies are not evaluated strictly in the order they appear in the UI. Instead, Access groups policies by action type and evaluates them in two phases:

1. Phase 1 — All Bypass and Service Auth policies are evaluated first, from top to bottom.
2. Phase 2 — All Allow and Block policies are evaluated in order, from top to bottom. Once a user matches an Allow or Block policy, evaluation stops and no subsequent policies can override the decision.

For example, if you have policies arranged as follows:

• Allow A
• Block B
• Service Auth C
• Bypass D
• Allow E

The actual evaluation order is: Service Auth C > Bypass D > Allow A > Block B > Allow E.

Common misconfigurations

If you add any of the following rules to an Allow policy, anyone will be able to access your application.

Include everyone

Rule type	Selector	Value
Include	Everyone	Everyone

Include all valid emails

Rule type	Selector	Value
Include	Login Methods	One-time PIN

Additional resources

• API and Terraform provide programmatic ways to manage your Access policies and configurations.