Skip to content

Cloudflare Access access control & privilege security checks

Admin roles, standing privileges, permission scopes and policy enforcement — the settings that decide how much damage one compromised account can do.

On Cloudflare Access, Black Cat runs 14 checks in this area on every scan. Each one below lists its severity, how to fix it, and the compliance controls it satisfies where a control applies. See what access the Cloudflare Access connector needs.

Checks (14)

severity: critical Application Without Policies fix difficulty: easy #

Assign at least one access policy to every Cloudflare Access application

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Applications
  3. Click the application name to open its settings
  4. Select the "Policies" tab
  5. Click "Add a policy" and configure an allow rule targeting specific users, groups, or identity providers
  6. Save the policy and verify the application now shows at least one active policy

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Bypass Decision Policy fix difficulty: medium #

Replace the bypass decision policy with an allow or block policy to enforce authentication

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Applications
  3. Click the application that contains the bypass policy
  4. Select the "Policies" tab and click the bypass policy to edit it
  5. Change the "Decision" from "Bypass" to "Allow" and configure appropriate include rules
  6. Save the policy and verify users are now required to authenticate

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Policy Allows Everyone fix difficulty: medium #

Remove the Everyone include rule and restrict access to specific users or groups

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Applications
  3. Click the application containing the policy and open the "Policies" tab
  4. Edit the policy that includes an "Everyone" rule
  5. Delete the "Everyone" include entry
  6. Add specific include rules targeting users by email, identity provider group, or Access Group
  7. Save and verify only intended users can authenticate

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: low No Purpose Justification fix difficulty: easy #

Enable purpose justification on the Access policy to require users to state a reason for access

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Applications
  3. Click the application and open the "Policies" tab
  4. Edit the relevant policy
  5. Expand the "Additional settings" section and enable "Purpose justification"
  6. Optionally set a custom justification prompt
  7. Save the policy

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: high Group Includes Everyone fix difficulty: medium #

Remove the Everyone rule from the Access group and scope membership to specific identities

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Groups
  3. Click the group to open its settings
  4. Locate the "Everyone" include rule and remove it
  5. Add specific include rules such as email domains, individual users, or IdP groups
  6. Save the group and review any applications that rely on this group to confirm intended access

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Group With Empty Include Rules fix difficulty: easy #

Add at least one include rule to the Access group to define its membership

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Groups
  3. Click the group with no include rules
  4. Under "Include" add at least one rule (e.g., email, email domain, or identity provider group)
  5. Save the group
  6. Verify the group is correctly referenced in the intended Access policies

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Single Identity Provider fix difficulty: hard #

Configure a second identity provider in Cloudflare Access to eliminate a single point of failure

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Settings > Authentication (or Access > Identity Providers)
  3. Click "Add new" to add a second identity provider
  4. Select the provider type (e.g., SAML, OIDC, or a directory provider) and complete the configuration
  5. Test the new identity provider to confirm it authenticates users successfully
  6. Update Access policies to include the new provider as an allowed authentication method

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Application Allows All IdPs fix difficulty: easy #

Restrict the application to specific identity providers via allowed_idps to prevent weaker IdPs (e.g., OTP) from authenticating users

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Applications and select the affected application
  3. Open the Authentication tab and review which identity providers are configured
  4. Under "Identity providers", uncheck "Accept all available identity providers"
  5. Explicitly select the SSO IdP(s) that should authenticate users for this application
  6. Save the change and verify the application enforces the new restriction

Vendor docs ↗

Satisfies: ISO 27001:2022 A.5.15 SOC 2 Type II CC6.1 CIS Controls v8 CIS-06.1 NIST CSF 2.0 PR.AA-05 GDPR (SaaS Security) GDPR-25.2 HIPAA (SaaS Security) HIPAA-312.a NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Application No Auto-Redirect to IdP fix difficulty: easy #

Enable auto-redirect to the identity provider so users cannot choose a weaker authentication method

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Applications and select the affected application
  3. Open the Authentication tab
  4. Enable "Instant Auth" or "Auto-redirect to identity provider"
  5. Save the change and verify users are redirected to the correct IdP automatically

Vendor docs ↗

Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Policy Without Require Rules fix difficulty: medium #

Add require rules to the Access policy to enforce additional authentication conditions such as MFA

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Applications and select the application
  3. Open the "Policies" tab and edit the policy without require rules
  4. Under "Require", add a rule such as "Authentication Method - mfa" or a specific IdP group
  5. Save the policy and verify users must satisfy the require condition to access the application

Vendor docs ↗

Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Group Without Require Rules fix difficulty: medium #

Add require rules to the Access group to enforce additional authentication conditions for group members

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Groups and select the group
  3. Under "Require", add a rule such as "Authentication Method - mfa" or a device posture check
  4. Save the group and verify policies referencing this group now enforce the new conditions

Vendor docs ↗

Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Service Token Over One Year Old fix difficulty: medium #

Rotate or revoke the Cloudflare Access service token that is over one year old

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Access > Service Auth > Service Tokens
  3. Locate the service token over 365 days old
  4. Click "Refresh" to generate a new client secret
  5. Update all services using this token with the new credentials
  6. Set a calendar reminder to rotate again before the next annual mark

Vendor docs ↗

Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: medium Seat Expiration Not Configured fix difficulty: easy #

Enable automatic seat expiration to reclaim inactive Zero Trust user seats

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Navigate to Settings > Account (or Team and resources > Users)
  3. Enable "Automatically remove users after a period of inactivity"
  4. Set an inactivity threshold (minimum 1 month)
  5. Save the configuration

Vendor docs ↗

Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

severity: low Dashboard Not Read-Only fix difficulty: medium #

Set the Zero Trust dashboard to API/Terraform read-only mode to enforce change control

  1. Sign in to the Cloudflare Zero Trust dashboard at one.dash.cloudflare.com
  2. Confirm your Zero Trust configuration is managed via API or Terraform
  3. Navigate to Settings and enable API/Terraform read-only mode
  4. Verify that dashboard edits are now blocked outside of the API/Terraform workflow

Vendor docs ↗

Satisfies: NIS2 Directive NIS2-21.i.1 DORA (SaaS Security) DORA-9.2

More Cloudflare Access checks

The information on this page is provided for general informational purposes and is believed to be accurate as of its most recent update. Product names, logos, and trademarks are the property of their respective owners and are used for identification purposes only; their use does not imply any affiliation with or endorsement by those owners. Descriptions of third-party applications and of compliance frameworks are based on publicly available documentation and may change over time.

See these checks run on your stack

Start a free 14-day trial — no credit card required.

Start Free Trial