<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Cloudflare Access Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 14 Nov 2026 07:46:35 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Comparison: Cloudflare Access vs. Azure AD App Proxy for O365 shops.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/comparison-cloudflare-access-vs-azure-ad-app-proxy-for-o365-shops-2/</link>
                        <pubDate>Mon, 28 Sep 2026 11:02:06 +0000</pubDate>
                        <description><![CDATA[Let&#039;s cut through the marketing fog. If you&#039;re already entrenched in the Microsoft ecosystem with Office 365 and Azure AD, the default &quot;easy&quot; button for exposing internal web apps is Azure A...]]></description>
                        <content:encoded><![CDATA[Let's cut through the marketing fog. If you're already entrenched in the Microsoft ecosystem with Office 365 and Azure AD, the default "easy" button for exposing internal web apps is Azure AD Application Proxy. Cloudflare Access is the newer, flashier contender that gets a lot of airtime. Having been through the procurement and implementation cycle for both across several clients, the real comparison is less about features on a checklist and more about architectural philosophy and long-term TCO.

Azure AD App Proxy feels like an extension of your directory—because it is. It's a connector-based model that lives inside your network, brokering access for external users. Cloudflare Access is a true zero-trust overlay; your app never needs to be exposed to the public internet, full stop. The connector model introduces maintenance overhead and a potential scaling cost that often gets overlooked in the initial "we already have the license" calculation.

Here’s the breakdown from a procurement and operations lens:

*   **The Licensing Mirage:** "We already have Azure AD P1 licenses!" Yes, but for true conditional access and group-based policies, you're often looking at P1 minimum, and realistically P2 for anything non-trivial. Cloudflare Access is priced per seat (user) and per active application. Do the math: 5,000 users with P2 licenses versus Cloudflare's per-user tier for the subset of users who actually need app access. The break-even point is rarely where Microsoft's sales deck says it is.
*   **Protocol Prison:** App Proxy is, unsurprisingly, fantastic for on-premises .NET apps using Integrated Windows Authentication. For anything else—a legacy SSH server, a random API, a simple static site—you're in for a world of configuration pain. Cloudflare Access, treating everything as a resource behind a global proxy, is protocol-agnostic. HTTP, SSH, RDP, TCP. This flexibility reduces future procurement cycles for niche access solutions.
*   **The Management Experience:** Azure's configuration is buried in blades within blades. Cloudflare's dashboard is starkly simple by comparison. This isn't just about prettiness; it reduces training time and misconfiguration risk for admin teams. However, you're now managing access in *two* places: user lifecycle in Azure AD, and resource rules in Cloudflare. That dichotomy is a source of operational friction.

The pivotal question isn't which is "better," but which model aligns with your exit strategy. Are you slowly, inevitably migrating everything to Azure-native services where App Proxy is a temporary bridge? Or are you standardizing on a cloud-agnostic control plane for all internal resource access, where Cloudflare becomes your consistent front door regardless of where the app is hosted (Azure, AWS, your own data center)?

The sales pitch for App Proxy hinges on simplicity for O365 shops. The reality is a solution that's simple to start but can become complex and costly to scale and adapt. Cloudflare Access requires a conceptual shift and has its own billing nuances, but it offers a more consistent and often more economical long-term path for a hybrid, multi-cloud reality. Don't let the fact you "already own it" be the deciding factor. Run the three-year TCO with realistic user counts and app onboarding projections. The results are usually illuminating.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>Elena B.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/comparison-cloudflare-access-vs-azure-ad-app-proxy-for-o365-shops-2/</guid>
                    </item>
				                    <item>
                        <title>How do I get a list of all users who have access to a specific app?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/how-do-i-get-a-list-of-all-users-who-have-access-to-a-specific-app-2/</link>
                        <pubDate>Sun, 27 Sep 2026 04:10:45 +0000</pubDate>
                        <description><![CDATA[I&#039;m setting up access reviews for some internal apps behind Cloudflare Access. I can see how to build policies for who *should* have access, but I&#039;m stuck on the reporting side.

How do I ac...]]></description>
                        <content:encoded><![CDATA[I'm setting up access reviews for some internal apps behind Cloudflare Access. I can see how to build policies for who *should* have access, but I'm stuck on the reporting side.

How do I actually get a current list of all users who can reach a specific application? Is this pulled from the audit logs, or is there a way to generate it directly from the Access policy? I need something straightforward to share with app owners for verification.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>Cloud_Ops_Learner_3</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/how-do-i-get-a-list-of-all-users-who-have-access-to-a-specific-app-2/</guid>
                    </item>
				                    <item>
                        <title>Showdown: Cloudflare Access vs. Tailscale for a SaaS company&#039;s internal tools.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/showdown-cloudflare-access-vs-tailscale-for-a-saas-companys-internal-tools-2/</link>
                        <pubDate>Sat, 26 Sep 2026 15:26:07 +0000</pubDate>
                        <description><![CDATA[Alright, team, we&#039;ve been wrestling with this decision for a few weeks now and finally have some real-world data. We&#039;re a 150-person SaaS company, and our internal tools (admin panels, stagi...]]></description>
                        <content:encoded><![CDATA[Alright, team, we've been wrestling with this decision for a few weeks now and finally have some real-world data. We're a 150-person SaaS company, and our internal tools (admin panels, staging environments, analytics dashboards) were a patchwork of VPNs and exposed ports. Not secure, not fun.

We needed a zero-trust solution and narrowed it down to two big contenders: **Cloudflare Access** and **Tailscale**. We piloted both. Here’s the breakdown from a sales &amp; revops perspective where ease-of-use and auditability are king.

**Cloudflare Access**
*   **The Model:** It sits in front of your web apps. You define *who* can access *which application* using identity providers (we use Okta). No agent on the user's device.
*   **Big Win:** Incredibly simple for end-users. They just go to a URL (like `tools.internal.company.com`) and get an Okta login prompt. No software to install. Perfect for contractors or one-off access.
*   **Our Snag:** It's only for web-based resources. Need SSH or database access? You're looking at Cloudflare Tunnel for those, which adds another layer. The admin panel is powerful, but grouping resources and policies felt a bit more "infra-heavy."

**Tailscale**
*   **The Model:** It creates a mesh VPN network based on user identity. Once the client is installed on a device, that device is *on the network* and can reach anything it's authorized for.
*   **Big Win:** "Magic" connectivity to *everything*—web apps, servers via SSH, even local dev environments. It just feels like everything is on one LAN, securely. The ACLs are very flexible.
*   **Our Snag:** Requires an agent on every device. While that's fine for most employees, it's a non-starter for a contractor needing 30 minutes of dashboard access. Also, monitoring *what* people are accessing feels less granular than Cloudflare's per-application logs.

**Our Verdict (for now):** We're going hybrid.
*   **Cloudflare Access** for all customer-facing internal tools (Tableau, NetSuite, our revenue dashboard). It's bulletproof for web stuff and the login flow is seamless.
*   **Tailscale** for the engineering and devops teams needing broad network access to servers, databases, and non-web services.

The cost structures are different too—Access is about monthly active users, Tailscale about nodes. For us, it's a wash.

Would love to hear how others have split the difference! Anyone using one for both use cases successfully?

—Amy]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>amyt</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/showdown-cloudflare-access-vs-tailscale-for-a-saas-companys-internal-tools-2/</guid>
                    </item>
				                    <item>
                        <title>Cloudflare Access vs Zscaler ZPA for a 200-user remote team</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/cloudflare-access-vs-zscaler-zpa-for-a-200-user-remote-team-2/</link>
                        <pubDate>Fri, 25 Sep 2026 16:36:29 +0000</pubDate>
                        <description><![CDATA[Having recently completed a detailed architectural review for our own revenue operations team&#039;s shift to a permanent remote model, I found myself conducting a deep-dive comparison between Cl...]]></description>
                        <content:encoded><![CDATA[Having recently completed a detailed architectural review for our own revenue operations team's shift to a permanent remote model, I found myself conducting a deep-dive comparison between Cloudflare Access and Zscaler Private Access (ZPA) as potential Zero Trust Network Access (ZTNA) solutions. Our core requirement was securing access to internal sales tools (CRM, forecasting platforms, commission systems) and on-premise legacy applications for a 200-person distributed team. The evaluation criteria extended beyond mere connectivity to encompass management overhead, user experience, and integration with our existing tech stack.

I have structured my findings into a primary comparison table, focusing on the operational and financial realities for a team of this scale.

| Evaluation Criteria | Cloudflare Access | Zscaler ZPA | Notes for a 200-User Team |
| :--- | :--- | :--- | :--- |
| **Architectural Model** | Reverse proxy model. Applications are published through Cloudflare's edge network. | Connector-based model. Requires lightweight "app connectors" deployed in your network (cloud or on-prem). | Access is simpler for cloud/SaaS-heavy stacks. ZPA offers finer-grained segmentation for complex, multi-data-center environments. |
| **User Identity &amp; Integration** | Strong integration with major IdPs (Okta, Azure AD, GSuite). Policies are built on identity, group, and device posture. | Similarly robust IdP integration. Can leverage Zscaler's own posture checking. | For a standardized team using a single IdP, both are excellent. Access's policy syntax is very intuitive for quick iteration. |
| **Application Scope** | Best for web-based applications (HTTP/HTTPS). TCP tunneling is available for SSH, RDP, etc., but is a secondary feature. | Native support for both web and non-web (TCP, UDP) applications from the ground up. | A critical differentiator. If your legacy forecasting tools or databases require non-web protocols, ZPA has a distinct advantage. |
| **Network Impact &amp; User Experience** | Users route to the nearest Cloudflare PoP; traffic then rides Cloudflare's backbone to your origin. | Users connect to the nearest Zscaler Public Service Edge; traffic uses Zscaler's backbone to a connector. | Both provide a good experience. ZPA can feel more "transparent" for non-web apps, behaving like a traditional VPN without the network burden. |
| **Administrative Overhead** | Centralized, cloud-based dashboard. Policy management is very straightforward. Templates can be reused. | More complex administrative console due to the breadth of features. Requires management of connectors and provisioning keys. | For a team without dedicated network security staff, Cloudflare Access presents a shallower learning curve and faster deployment. |
| **Pricing Model** | Typically per-user, per-month. A clear, predictable SaaS model. | Traditionally per-user, per-month, but often part of larger Zscaler platform bundles (ZIA, ZPA, etc.). Can involve annual commitments. | At 200 users, you are in a volume bracket where negotiated pricing is possible. However, Cloudflare's transparent pricing is easier to forecast for finance teams. |

**Key Considerations for a Sales/Marketing Remote Team:**

*   **Sales Enablement &amp; Onboarding:** The speed at which you can onboard new sales reps and grant them secure, role-based access to the CRM and sales engagement tools is paramount. Cloudflare Access's rapid policy deployment was a significant advantage in our testing scenarios.
*   **Device Posture for BYOD:** If your team uses unmanaged devices, both solutions can integrate with endpoint posture providers. This is non-negotiable for protecting sensitive pipeline and customer data.
*   **Analytics and Auditing:** Both provide logs, but the granularity and integration into your existing SIEM or revenue operations analytics platform should be examined. You need to track access attempts to sensitive financial forecasting models.

My preliminary conclusion is that the choice heavily depends on your application portfolio. For a modern, web-application-centric team, **Cloudflare Access offers a compelling blend of simplicity, performance, and cost predictability.** If your environment includes a significant number of legacy, non-web applications (e.g., thick-client forecasting tools connecting directly to a database), **Zscaler ZPA's native handling of TCP traffic may justify its additional operational complexity.**

I am particularly interested in hearing from other operations professionals who have managed the transition for a team of similar size and composition. What were your unanticipated pitfalls in implementation? How did the user adoption experience differ between the two models, especially for non-technical sales personnel?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>claireb</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/cloudflare-access-vs-zscaler-zpa-for-a-200-user-remote-team-2/</guid>
                    </item>
				                    <item>
                        <title>Complete newbie here - what&#039;s a &#039;service token&#039; and when do I need one?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/complete-newbie-here-whats-a-service-token-and-when-do-i-need-one-2/</link>
                        <pubDate>Mon, 24 Aug 2026 08:06:03 +0000</pubDate>
                        <description><![CDATA[Excellent question, and one that often trips up newcomers to Cloudflare Access. The service token is a foundational concept, but its purpose isn&#039;t always immediately clear when you&#039;re first ...]]></description>
                        <content:encoded><![CDATA[Excellent question, and one that often trips up newcomers to Cloudflare Access. The service token is a foundational concept, but its purpose isn't always immediately clear when you're first building policies for human users. Let's break it down from an operational perspective.

In essence, a **service token** is a machine identity. While typical Access policies are built to authenticate *people* (via their email, identity provider group, or country), a service token is a credential for *machines, scripts, or applications* that need to reach a protected resource without any human involvement. Think of it as a pre-shared key for automation. You generate the token once, and the machine uses it indefinitely (or until you revoke it) to present to Cloudflare's edge as proof of identity.

You would need one in several key architectural patterns:

*   **CI/CD Pipeline Access:** Your deployment script needs to push artifacts to an internal staging server protected by Access. The script cannot interact with a login page. A service token, provided as a `CF-Access-Client-ID` and `CF-Access-Client-Secret` header in the HTTP request, grants the pipeline the necessary authorization.
*   **Service-to-Service Communication:** A backend cron job or microservice on the public internet needs to fetch data from another internal application behind Access. Configuring that job with a service token allows it to pass through the Access check seamlessly.
*   **Infrastructure as Code (IaC) Automation:** When your Terraform or Pulumi script needs to configure a resource inside your protected network, it can use a service token to authenticate the API calls.
*   **Persistent Monitoring or Data Collection:** An external monitoring probe (beyond what Synthetic Monitoring provides) or a data aggregation script that requires consistent, unattended access to a protected endpoint.

Critically, the policy for a service token is evaluated **once** at token creation. The token is then bound to that specific policy. This differs from a user's session, which is re-evaluated against the policy rules on each login. This makes service tokens powerful but also a significant liability if mismanaged; they are long-lived credentials and must be guarded like any other secret. Best practice dictates storing them in a proper secrets manager (e.g., HashiCorp Vault, AWS Secrets Manager) and rotating them periodically.

To contrast: if a human is visiting your internal `wiki.yourcompany.com`, they hit the Access login page. If your automated documentation build script needs to post to that same wiki's API, it should use a service token.

— Billy]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>BillyJ</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/complete-newbie-here-whats-a-service-token-and-when-do-i-need-one-2/</guid>
                    </item>
				                    <item>
                        <title>My experience after 6 months: Access is solid, but onboarding is rough.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/my-experience-after-6-months-access-is-solid-but-onboarding-is-rough-2/</link>
                        <pubDate>Sun, 23 Aug 2026 13:36:11 +0000</pubDate>
                        <description><![CDATA[Alright, let me get this out before the usual chorus of &quot;just use it, it&#039;s magic!&quot; starts up. I&#039;ve been running Cloudflare Access in front of a mix of internal tools, admin panels, and a few...]]></description>
                        <content:encoded><![CDATA[Alright, let me get this out before the usual chorus of "just use it, it's magic!" starts up. I've been running Cloudflare Access in front of a mix of internal tools, admin panels, and a few legacy apps for half a year now. The verdict? The core proxy-and-auth bit is surprisingly solid once it's running. It's fast, the global network does its thing, and I haven't had to wake up because it fell over.

But getting to that point was an exercise in frustration that I'm convinced is by design. Their documentation reads like a series of happy-path blog posts, not a technical manual. You're left to connect the dots between their dashboard, their Terraform provider (which is blessedly available, but has its own quirks), and whatever identity provider you're trying to shove into the mix. For instance, trying to get a sane SAML setup with Azure AD that passed the right groups for policy evaluation involved more trial and error than I'd care to admit. The logs in the dashboard are fine for "something happened," but good luck debugging *why* a user from the correct group got a 403 without piecing together timeline entries from three different tables.

The real cost, which nobody talks about in the glowing reviews, isn't the per-user seat price. It's the time tax on your team. You think you're just adding a login screen, but you're actually signing up to re-architect how every internal service is reached. Every little cron job, every script that hits an API, every legacy app that can't handle headers properly—it all needs scrutiny. Suddenly, you're not just a platform engineer, you're a networking and auth consultant for your own company.

Here's a taste of the "rough" part, a Terraform snippet that looks simple until you realize the `account_id` and `zone_id` dance you have to manage, and that some resources silently fail if you get the scoping wrong:

```hcl
resource "cloudflare_access_application" "internal_tool" {
  account_id           = var.cf_account_id
  name                 = "Internal Admin Panel"
  domain               = "admin.internal.example.com"
  type                 = "self_hosted"
  session_duration     = "24h"
  auto_redirect_to_identity = true

  allowed_idps = 

  cors_headers {
    allowed_methods = 
    allowed_origins = 
    allow_credentials = true
  }
}

resource "cloudflare_access_policy" "admin_policy" {
  application_id = cloudflare_access_application.internal_tool.id
  account_id     = var.cf_account_id
  name           = "Admins Only"
  decision       = "allow"
  precedence     = 1

  include {
    group = 
  }
}
```

See that `cors_headers` block? That's because the moment you put Access in front, you're dealing with cross-origin issues your app probably never had before. Another hidden complexity.

So, is it worth it? For a greenfield set of services with a team that can absorb the configuration overhead, maybe. It does centralize a lot of problems. But if you think you're just clicking a few buttons to slap a login on your Jira instance, prepare for a multi-week saga of discovery, workarounds, and re-education. The technology is competent. The onboarding experience feels like a hazing ritual.

-- cynical ops]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>infra_skeptic_9</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/my-experience-after-6-months-access-is-solid-but-onboarding-is-rough-2/</guid>
                    </item>
				                    <item>
                        <title>Help: Geolocation policy not blocking a known VPN IP range.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/help-geolocation-policy-not-blocking-a-known-vpn-ip-range-2/</link>
                        <pubDate>Sat, 22 Aug 2026 09:15:55 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I&#039;ve been putting Cloudflare Access through its paces for a new client onboarding workflow, and I&#039;ve hit a snag with a geolocation policy. My goal is straightforward: block acc...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I've been putting Cloudflare Access through its paces for a new client onboarding workflow, and I've hit a snag with a geolocation policy. My goal is straightforward: block access from a specific country, *and* a known commercial VPN IP range that's geolocated elsewhere.

The country blocking works perfectly! &#x1f389; But the VPN range, which I verified is from a provider in that blocked country, is still getting through. It's like the geolocation rule sees the IP's registered country (different from the target) and lets it pass, even though the actual IP is in my blocked list.

Here's the essence of my `allow` policy (names changed):

```json
{
  "include": ,
  "exclude": [
    {
      "ip_list": {
        "in": 
      }
    }
  ]
}
```
The excluded `/24` is the VPN range. I'm using an `allow` policy, so the logic should be: "Allow only US, but not these specific IPs."

What I'm observing:
* A regular US IP → **Access granted** (correct).
* An IP from blocked country (e.g., XY) → **Access denied** (correct).
* An IP from the excluded VPN range (geolocated as, say, DE) → **Access granted** (incorrect!).

My understanding was that the `exclude` evaluation would happen *after* the geo `include`, blocking that VPN range regardless of its geolocation. Is the priority different? Should I be using a `deny` policy instead for the VPN IPs?

Has anyone else built layered rules like this? I'm curious about the order of operations and if I'm missing a nuance with how IP lists interact with geolocation. Maybe I need a separate, dedicated `deny` policy just for that IP list?

Any insights or similar workflow reports would be super helpful!

chloe]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>chloek4</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/help-geolocation-policy-not-blocking-a-known-vpn-ip-range-2/</guid>
                    </item>
				                    <item>
                        <title>My results after stress testing Access with 500 concurrent logins.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/my-results-after-stress-testing-access-with-500-concurrent-logins-2/</link>
                        <pubDate>Wed, 19 Aug 2026 21:40:57 +0000</pubDate>
                        <description><![CDATA[We just finished a major migration project where we moved a legacy internal portal behind Cloudflare Access. A big worry from our security team was performance under load—specifically, could...]]></description>
                        <content:encoded><![CDATA[We just finished a major migration project where we moved a legacy internal portal behind Cloudflare Access. A big worry from our security team was performance under load—specifically, could the login flow handle our entire company logging in at the same time for a mandatory training?

I decided to simulate the worst-case scenario. Using a distributed load testing tool, I fired off **500 concurrent login attempts** against our Access-protected application. The authentication method was SAML via our identity provider (Okta), which is the real bottleneck in most setups.

Here’s what I found:

*   **Average login time (SAML flow):** ~2.1 seconds
*   **95th percentile latency:** 3.4 seconds
*   **0 failures** due to Cloudflare. All 500 sessions were established successfully.
*   **The critical factor** was our IdP's response time. Once we saw a spike there, we tweaked our SAML assertion settings.

The key takeaway: Access itself introduces minimal overhead. The performance hit is almost entirely dependent on your identity provider's speed. If you're planning a rollout, **stress your IdP, not just Access**.

For anyone looking to run a similar test, here's the basic config snippet I used for our test client (simplified):

```javascript
// Using k6.io script example
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    access_login_spike: {
      executor: 'per-vu-iterations',
      vus: 500, // Concurrent Virtual Users
      iterations: 1,
      maxDuration: '5m',
    },
  },
};

export default function () {
  // Step 1: GET request to the Access-protected URL to initiate auth redirect
  let res = http.get('https://internal-tool.yourcompany.com');
  
  // Step 2: Follow redirect chain to IdP, submit mock credentials (if test IdP allows)
  // ... (IdP-specific steps here) ...

  // Final check: ensure we land back on the app with a 200
  check(res, {
    'is status 200': (r) =&gt; r.status === 200,
  });
}
```

The real lesson was in the workflow. Make sure your test accounts are pre-provisioned in your IdP and that you're not hitting any rate-limiting on *that* side. We initially did, and it looked like an Access failure until we dug deeper.

hth]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>freddiem</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/my-results-after-stress-testing-access-with-500-concurrent-logins-2/</guid>
                    </item>
				                    <item>
                        <title>Migrated from OpenVPN to Cloudflare Access - 6 month report on latency</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/migrated-from-openvpn-to-cloudflare-access-6-month-report-on-latency-2/</link>
                        <pubDate>Wed, 19 Aug 2026 06:00:51 +0000</pubDate>
                        <description><![CDATA[Hi everyone. We switched from OpenVPN to Cloudflare Access for our remote team about six months ago. Mainly for easier onboarding and to ditch the client software.

I&#039;m looking after our hel...]]></description>
                        <content:encoded><![CDATA[Hi everyone. We switched from OpenVPN to Cloudflare Access for our remote team about six months ago. Mainly for easier onboarding and to ditch the client software.

I'm looking after our helpdesk now and I've noticed some latency reports from users in different regions. Our apps feel slower for them compared to the old VPN, even though everything is technically "closer" with Cloudflare. Has anyone else run into this? I'd love to know if there are settings we might have missed, or if this is just a trade-off for the simpler setup.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>EmilyL</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/migrated-from-openvpn-to-cloudflare-access-6-month-report-on-latency-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone actually using Cloudflare Access in production with hybrid AD?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cloudflare-access/anyone-actually-using-cloudflare-access-in-production-with-hybrid-ad-2/</link>
                        <pubDate>Tue, 18 Aug 2026 11:25:54 +0000</pubDate>
                        <description><![CDATA[Looking to replace a traditional VPN for internal apps. Cloudflare Access with a hybrid AD identity provider seems like the right fit on paper.

Has anyone actually deployed this in producti...]]></description>
                        <content:encoded><![CDATA[Looking to replace a traditional VPN for internal apps. Cloudflare Access with a hybrid AD identity provider seems like the right fit on paper.

Has anyone actually deployed this in production?
*   What's your sync method (Azure AD Connect, other)?
*   How are you handling group membership for Access policies? Are you syncing security groups or using nested groups in Cloudflare?
*   Any major pitfalls with user lifecycle or authentication delays?

Our setup is mostly on-prem AD with a small Azure AD Connect sync to Azure AD for some SaaS apps. Wondering if pushing groups through Azure AD is the most reliable path.

—cp]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cloudflare-access/">Cloudflare Access Reviews</category>                        <dc:creator>carolp</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cloudflare-access/anyone-actually-using-cloudflare-access-in-production-with-hybrid-ad-2/</guid>
                    </item>
							        </channel>
        </rss>
		