Cloudflare Access — Identity-Based Policies

Cloudflare Access policies define who can reach your applications based on identity, device posture, location, and authentication method, enforcing Zero Trust access at the edge.

What You Will Learn

You will learn how to build Access policy building blocks using include, exclude, and require selectors, understand policy evaluation order, and create practical policies for common team structures.

Why It Matters

Traditional IP-based allowlists are brittle and insecure. Identity-based policies let you grant access based on who the user is rather than where they connect from, enabling secure remote access without a VPN.

Real-World Use Case

A 300-person product company uses Access policies to segment internal tools: engineering gets GitHub and Jenkins, marketing gets HubSpot and Canva, finance gets QuickBooks. Each policy checks Okta group membership, WARP device posture, and requires MFA.

Policy Architecture

Access policies use a three-part selector system: include (who is allowed), exclude (who is denied), and require (what conditions must be met).

flowchart TD
    A[User Request] --> B{Include Rules}
    B -->|Matches| C{Require Rules}
    B -->|No Match| D[Deny]
    C -->|All Met| E{Exclude Rules}
    C -->|Any Missing| D
    E -->|Not Excluded| F[Allow]
    E -->|Excluded| D

Policy Building Blocks

Every Access policy consists of three selector types that work together:

Creating a Basic Policy via API

Create a policy that allows anyone from your company domain with MFA.

curl -s -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Company Access",
    "decision": "allow",
    "include": [{"email_domain": {"domain": "company.com"}}],
    "require": [{"auth_method": {"auth_method": "mfa"}}],
    "exclude": []
  }' | jq '.result.name, .result.id'

Expected output:

"Company Access"
"abc-123-def-456"

Group-Based Policy for Team Access

Use Access groups to manage team-level permissions centrally.

# Create an Access group for engineering
curl -s -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/groups" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Engineering Team",
    "include": [
      {"okta": {"name": "Engineering", "id": "okta-group-id"}},
      {"email_domain": {"domain": "engineering.company.com"}}
    ],
    "require": [{"auth_method": {"auth_method": "mfa"}}]
  }' | jq '.success'

Expected output:

true

Now reference this group in policies instead of repeating individual rules.

Device Posture Policy

Require specific device posture checks before granting access.

curl -s -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
  -H "Authorization: Bearer $API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Device Compliant Access",
    "decision": "allow",
    "include": [{"email_domain": {"domain": "company.com"}}],
    "require": [
      {"auth_method": {"auth_method": "mfa"}},
      {"device_posture": {"integration_uid": "int-abc", "require_disk_encryption": true}}
    ]
  }' | jq '.success'

Expected output:

true

Common Mistakes

Practice Questions

1. What is the difference between include and require selectors in an Access policy?
2. How do Access groups simplify policy management across multiple applications?
3. Why should exclude rules be used alongside include rules rather than as a replacement?

Challenge

Create three Access policies for a company with engineering, sales, and admin teams. Engineering and sales each have their own Okta group. Admins need access to everything. Each policy must require MFA and device posture Compliance. Verify each policy with a test API call.

Real-World Task

Your organisation has five internal applications: a CRM, a source code Repository, a documentation wiki, a monitoring dashboard, and an HR portal. Create Access policies that grant access based on department membership using Azure AD groups. Engineering gets the repo and monitoring. Sales gets the CRM. Everyone gets the wiki and HR portal. Require MFA for all applications and device posture for the source code Repository.

FAQ

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro — security-first tools for the modern web.