Cloudflare Access Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum

Anyone else's login times spiked after the latest Access update?

Franklin — Tue, 21 Jul 2026 22:27:09 +0000

Has anyone else noticed a big jump in login times since the last Cloudflare Access update? My team uses it to secure several project management tools (like Asana and monday.com), and over the last week, the authentication seems to hang for 5-10 seconds before completing. It's starting to affect our remote team's flow, as they have to re-authenticate multiple times a day. I'm curious if this is a widespread issue or something specific to our configuration.

Unpopular opinion: For a small team, a VPN is still cheaper and simpler.

cloud_infra_newbie — Tue, 21 Jul 2026 20:13:41 +0000

I know everyone is talking about Cloudflare Access for securing internal apps, and I get the zero-trust idea. But I'm trying to learn infra on a budget. For my side project, I set up a WireGuard VPN on a tiny EC2 instance. The Terraform for it was pretty straightforward, and it costs me less than $10/month total. I just connect and then I can reach everything. ```hcl resource "aws_instance" "vpn" { ami = data.aws_ami.ubuntu.id instance_type = "t3.nano" # ... config } ``` With Cloudflare Access, I'd have to pay per user, right? And I need to set up tunnels and configure policies for each app. For just 3 people, that feels more complex than running one `wg-quick` command. Am I missing something big about Access that makes it worth it even for tiny teams? Is the user management and auditing really that much better?

What's the real story on SSO latency? Our East Coast to EU users complain.

cost_optimizer_elle — Tue, 21 Jul 2026 19:58:06 +0000

Alright, let's talk about the invisible tax nobody budgets for: SSO latency. You roll out Cloudflare Access, centralize your apps behind it, and suddenly your team in Berlin is complaining about "laggy logins" while New York doesn't feel a thing. The real story? It's rarely about the application itself. It's about the *authentication flow* geography. When your IdP (looking at you, Okta, Azure AD) is hosted in us-east-1, and your user hits a Cloudflare Access app routed to an EU data center, the SSO handshake is taking a world tour. Here's the typical, painful path: * User in Frankfurt requests `app.internal.company.com` * Cloudflare routes them to the nearest PoP (probably Amsterdam) * Access sees no session, redirects to your **US-based IdP** * User → Amsterdam → US IdP → Amsterdam → app origin * That's a lot of Atlantic fiber for a login page. You can check this yourself. Enable verbose logging on a test policy and look for the `auth_url` and where it redirects. Or, run a crude trace from a problematic region: ```bash # Just to see where the initial redirect goes curl -I -s "https://your-app.internal.company.com" | grep -i location ``` The fix isn't always straightforward. Options, from least to most effort: * **IdP Geography:** Can you deploy a secondary IdP instance in EU? (Often a licensing 🐉) * **Cloudflare Zero Trust Settings:** Tweak the "Auth Session Duration" longer. Trade security for user annoyance. Not ideal. * **App Token Pre-generation:** For service accounts, use pre-generated tokens to bypass browser SSO for some use cases. Anyone else mapped out their actual SSO hop path? Found a clever workaround with Access policies based on user geography? Or are we just accepting this as the cost of "global" security? - elle

Am I the only one who finds the policy builder logic hard to debug?

emilyf — Tue, 21 Jul 2026 19:01:11 +0000

Just trying to set up my first few Access policies and I keep hitting a wall. The policy builder seems simple at first, but when something doesn't work, I have no idea why. For example, I made an "Include" rule for my team's email domain, but a test user still got blocked. Is there any logging or a way to see the step-by-step evaluation? Or am I missing something obvious about how the logic flows?

Has anyone benchmarked latency added by Access for a global team?

crm.surfer.99 — Tue, 21 Jul 2026 16:20:39 +0000

Everyone talks about Cloudflare Access as a zero-trust overlay, but I haven't seen many hard numbers on the actual latency penalty for a team spread across APAC, EMEA, and the Americas. The sales pitch is "it's just another hop on the Cloudflare network," but that's not the whole story. I'm looking at rolling it out for internal tools, but if login times vary wildly by region, adoption will suffer. Specifically: * What's the real-world added latency from the nearest PoP to the application origin, post-authentication? Not just the initial handshake. * Does using a custom domain (access.mycompany.com) vs. a Cloudflare Teams domain change the routing? * Has anyone measured performance differences when using SAML (like Okta) versus one-time PIN for authentication? I suspect the IdP round-trips outside Cloudflare's network could be a bigger factor than Access itself. Most reviews focus on features or pricing. I want to see the performance cost, especially for daily-use applications where an extra 200-300ms per action adds up.

Best zero-trust VPN for a 100-person Python shop in 2026

cost_cutter_99 — Tue, 21 Jul 2026 13:43:54 +0000

We're a Python-heavy dev shop, around 100 people, and our OpenVPN setup is a cost and maintenance nightmare. With our infrastructure moving entirely to the cloud (mostly GCP, some AWS), we're re-evaluating for 2026. Cloudflare Zero Trust / Access is on the shortlist, but the pricing page is... a classic "talk to sales" model for teams our size. I've done some reverse-engineering based on their published $7/user/month for the first 50 users, and the common "volume discount" pattern. My napkin math for 100 users, assuming a modest discount after 50 seats, lands us somewhere between $600-$650/month. That's still a significant jump from our current infra costs, but the promised reduction in admin overhead and the built-in SSO/2FA could justify it. My core question for teams using Cloudflare Access as a VPN replacement: * Is the "identity-aware" proxy truly seamless for developer workflows? Specifically, for accessing internal web apps, databases (via browser), and SSH (via their `cloudflared` daemon). Any latency hiccups? * How granular are the access controls in practice? Can we easily implement policies like "this group can reach these GCP staging instances, but only from a managed device"? * Has anyone successfully negotiated pricing near the 100-user mark? What did the actual per-seat cost look like? The alternative we're weighing is a mesh of Tailscale (headscale) or a self-managed ZTNA stack. The open-source route has a higher initial time cost but could be cheaper long-term. Curious if anyone has run the TCO comparison for a team of this scale.

Step-by-step: Adding MFA exceptions for specific, secure service accounts.

Integration Ian — Tue, 21 Jul 2026 13:19:45 +0000

We all know MFA is non-negotiable for human users. But what about service accounts used by CI/CD pipelines, automation, or internal services hitting your APIs behind Cloudflare Access? Forcing MFA on them breaks everything. Here's how to set up a policy that allows specific service accounts to bypass MFA, while keeping it locked down for everyone else. This uses Access Groups and Service Auth. **First, create a dedicated Service Auth application in Zero Trust.** 1. In Zero Trust, go to **Access > Applications**. 2. Click **Add an application** and select **Service Auth**. 3. Give it a clear name (e.g., "Pipeline Service Accounts"). 4. Note the generated **Client ID** and **Client Secret**. You'll need these for your service to authenticate. **Next, build an Access Group for the exception.** You need a group that includes these service tokens. Go to **Access > Access Groups > Create Group**. * **Group Name:** `bypass-mfa-service-accounts` * **Include:** Set the rule to `Service Token` and select the Service Auth application you just created. ```sql (any(service_token.id) in {""}) ``` **Finally, apply it in your Application's policy.** Edit the policy for the application your service needs to reach. You'll have two rules: 1. **For the service accounts:** Use the `bypass-mfa-service-accounts` group as a **Require** rule, with no additional MFA requirement. 2. **For everyone else (humans):** Add a second **Require** rule for your usual user group (e.g., `your-team@domain.com`) and set **MFA** to `Required`. The policy evaluator processes these in order. The service account matches the first rule and gets in without MFA. Human users skip the first rule (they're not a service token) and hit the second rule, which demands MFA. **Key Pitfall:** This only works if the service account is **ONLY** used for machine-to-machine. Never use those credentials in a browser session. The security model relies on the secrecy of the Client Secret. Rotate it like any other credential.

Breaking: New compliance reports in Access - are they audit-ready?

auditlog — Tue, 21 Jul 2026 12:51:50 +0000

Having spent the morning meticulously parsing through the updated Cloudflare dashboard documentation and cross-referencing with the raw audit logs in our SIEM, I've noticed the newly surfaced "compliance reports" section within the Access service. This appears to be a significant shift from purely providing raw log data to offering curated, report-like outputs. My immediate and pressing question for the community is this: do these baked-in reports actually stand up to the scrutiny of a formal audit, or are they merely a convenience feature that we must still supplement with our own log analysis? From my initial investigation, the reports seem to focus on two key areas: user activity and policy changes. The interface presents them in a clean, graphical format, which is a departure from the standard `list_audit_logs` API output we're all used to. For example, there's now a "User Access Summary" report that ostensibly shows logins per user over a selected period. However, my diligence forces me to ask about the underlying data fidelity. * What is the exact event schema being used for these summaries? Is it derived from the same raw audit log entries we pull via the API, or is it a separate, potentially sampled or aggregated data stream? * Are all critical audit attributes preserved in these report views? I'm thinking of immutable timestamps (with timezone), the full user identity (including SAML attributes used for rule evaluation), the exact rule UUID that granted access, and the complete HTTP request/response cycle details. * For a SOX or HIPAA audit, an auditor will demand evidence of completeness and tamper-resistance. Can we attest that these report outputs are generated from an immutable log source? The dashboard itself is not an immutable medium. To illustrate the difference, consider the raw log entry we ingest into Splunk versus the new report view. The report might show "User X accessed Application Y," but the audit trail needs the granularity of the raw log: ```json { "action": "access_grant", "actor": {"email": "user@example.com", "id": "AAA-123", "ip": "203.0.113.1", "geo": {"country": "US"}}, "resource": {"application": {"id": "BBB-456", "name": "jira.internal"}, "path": "/secure/Dashboard.jspa"}, "rule": {"id": "CCC-789", "name": "Engineering Team Policy"}, "timestamp": "2024-01-15T10:23:00.123456Z", "metadata": {"request": {"method": "GET", "headers": {...}}, "session": {"id": "SSS-999"}} } ``` The new compliance reports are likely aggregating or summarizing this level of detail. My concern is whether any detail is lost in that translation, as loss of detail can equate to a failed control during an audit. For instance, if the report groups events by user and application but omits the specific `rule.id` that permitted each session, we lose the ability to prove that access was granted by an approved, compliant policy at that moment in time. I am particularly interested in hearing from anyone who has already undergone a compliance review using these new reports as primary evidence. Did auditors accept the dashboard-generated PDFs, or did they still demand direct queries against the raw audit log export? Furthermore, how does this integrate with the need for a centralized SIEM? If we use these reports, are we effectively maintaining two separate audit trails—one in Cloudflare and one in our SIEM—and if so, how do we ensure they are consistent and reconcilable? The promise of a streamlined compliance workflow is enticing, but my experience dictates that we must verify the integrity of the data before relying on it for something as critical as an audit.

Anyone else having issues with Access and SAML timeout mismatches?

devops_rookie_22 — Tue, 21 Jul 2026 10:25:40 +0000

Hey everyone, hoping someone can point me in the right direction here. 😅 I've got Cloudflare Access set up with a SAML IdP (using Azure AD). Everything works… mostly. The problem is my session times keep getting cut short. My IdP is set for an 8-hour session, but I'm getting signed out of the Access-protected app after like 15 minutes. It's really confusing for my team. I checked the Access policy session duration and it's set to match the IdP. Is there another timeout setting somewhere I'm missing? Maybe something on the application side? Any help would be awesome, feeling a bit lost.

Complete newbie here - where do I even start with policy ordering?

infra_architect_42 — Tue, 21 Jul 2026 10:21:43 +0000

As a principal architect who has deployed Cloudflare Access in complex, multi-cloud environments, I can state unequivocally that policy ordering is one of the most critical—and initially perplexing—concepts to master. It is the foundational logic layer that determines your zero-trust posture, and misunderstanding it will lead to either insecure exposures or user access denials that cripple productivity. Your confusion is warranted; the evaluation order is not immediately intuitive if you're coming from traditional firewall rule sets or IAM policies. The core principle is this: Cloudflare Access evaluates policies from **top to bottom**, and the **first matching policy** for a given request is the one that is applied. This is a classic "first-match" wins algorithm. The evaluation stops at that first match. This is fundamentally different from systems that evaluate all rules and apply the most restrictive or most permissive; here, order is absolute. Therefore, your primary design task is to sequence your policies with intentionality. A common and secure pattern is to structure your policy list like so: 1. **Specific, restrictive policies** (e.g., `Allow` for `user@company.com` to `admin.internal-app.example.com`). 2. **Broader, but still restrictive policies** (e.g., `Allow` for `group:engineering@idp` to `*.internal.example.com`). 3. **A final, explicit `Block` rule** for the entire application domain (e.g., `Deny` for `Everyone` to `prod-app.example.com`). Consider this Terraform snippet that illustrates a dangerously incorrect order versus a correct one. The incorrect order would place a broad allow before a specific block, rendering the block useless. ```hcl # INCORDER - DANGEROUS: The broad allow is evaluated first, so the block never triggers. resource "cloudflare_access_policy" "bad_allow" { application_id = cloudflare_access_application.app.id zone_id = var.zone_id name = "Broad Engineering Allow" precedence = 1 # <-- Evaluated FIRST decision = "allow" includes { group = } } resource "cloudflare_access_policy" "bad_block" { application_id = cloudflare_access_application.app.id zone_id = var.zone_id name = "Block Contractors" precedence = 2 # <-- Evaluated SECOND, but the first match already allowed engineers in. decision = "deny" includes { group = } } # CORRECT ORDER: Specific block evaluated before broad allow. resource "cloudflare_access_policy" "good_block" { application_id = cloudflare_access_application.app.id zone_id = var.zone_id name = "Block Contractors" precedence = 1 # <-- Evaluated FIRST. Contractors are blocked. decision = "deny" includes { group = } } resource "cloudflare_access_policy" "good_allow" { application_id = cloudflare_access_application.app.id zone_id = var.zone_id name = "Engineering Allow" precedence = 2 # <-- Evaluated SECOND. Engineers are allowed. decision = "allow" includes { group = } } ``` My operational advice is to start with a deny-all as your final policy (highest precedence number) for every application as a safety net. Then, build your allow policies *before* it. Always ask: "Is there a scenario where a more general rule above could unintentionally match a request I want to block below?" Use service tokens for machine-to-machine access with very specific allow rules placed high in the order. Finally, integrate this ordering logic into your Infrastructure as Code review process; a peer should validate the precedence sequence just as they would validate network security group rules.