<?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>
									ZTNA and Zero Trust - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-ztna/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 24 Jul 2026 22:16:33 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Check out this script for auto-revoking ZTNA access on offboarding.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/check-out-this-script-for-auto-revoking-ztna-access-on-offboarding/</link>
                        <pubDate>Tue, 21 Jul 2026 21:10:50 +0000</pubDate>
                        <description><![CDATA[Hey everyone,

I was helping a client tighten up their offboarding process last week and realized how easy it is for ZTNA access to slip through the cracks if it&#039;s not automated. Manual tick...]]></description>
                        <content:encoded><![CDATA[Hey everyone,

I was helping a client tighten up their offboarding process last week and realized how easy it is for ZTNA access to slip through the cracks if it's not automated. Manual ticket-based deprovisioning is slow and error-prone. So, I built a simple script that hooks into our HR system's termination webhook to automatically revoke ZTNA sessions and permissions.

The core idea is simple: when the offboarding event fires, the script calls the ZTNA provider's API to terminate active sessions and then removes the user from all access policies. We're using AWS with a popular ZTNA vendor, so I wrote it in Python for our Lambda function.

Here's the main part of the logic. It's generic enough to adapt to other vendors:

```python
def revoke_ztna_access(offboarded_user_email):
    # 1. Terminate all active sessions for the user
    sessions = ztna_client.get_active_sessions(offboarded_user_email)
    for session in sessions:
        ztna_client.terminate_session(session)

    # 2. Remove user from all ZTNA access groups/policies
    user_groups = ztna_client.get_user_groups(offboarded_user_email)
    for group in user_groups:
        ztna_client.remove_user_from_group(offboarded_user_email, group)

    # 3. (Optional) Log and audit the action
    audit_log_event({
        'user': offboarded_user_email,
        'action': 'ztna_access_revoked',
        'timestamp': datetime.utcnow().isoformat()
    })
```

**Key Integration Points:**
*   The trigger is an EventBridge event from our HR platform (like Workday).
*   The Lambda function needs the appropriate IAM role and ZTNA API credentials (secrets stored in AWS Secrets Manager).
*   We also added a step to notify the security team via a Slack webhook for audit.

This automated approach has cut down our access revocation time from potentially hours/days to seconds. It's a small piece, but it's crucial for maintaining a true Zero Trust posture where access is truly "just-in-time."

Has anyone else built similar automation? I'm curious about how you handle the identity synchronization piece, especially with SCIM or from on-prem directories.

-- Amy]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>Amy Chen</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/check-out-this-script-for-auto-revoking-ztna-access-on-offboarding/</guid>
                    </item>
				                    <item>
                        <title>Rolled out Cloudflare Zero Trust to 1000 users - what broke and how we fixed it</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/rolled-out-cloudflare-zero-trust-to-1000-users-what-broke-and-how-we-fixed-it/</link>
                        <pubDate>Tue, 21 Jul 2026 19:35:56 +0000</pubDate>
                        <description><![CDATA[We just finished a full ZTNA rollout with Cloudflare Zero Trust, replacing our legacy VPN for about 1000 users. The promise of &quot;identity-aware&quot; access was the big draw, but the transition wa...]]></description>
                        <content:encoded><![CDATA[We just finished a full ZTNA rollout with Cloudflare Zero Trust, replacing our legacy VPN for about 1000 users. The promise of "identity-aware" access was the big draw, but the transition wasn't as smooth as I'd hoped. I figured I'd share where we hit friction, since most case studies gloss over the messy bits.

The biggest issue wasn't the core tech, but user behavior and app compatibility. Our SSO (Okta) integration was solid, but we immediately saw a spike in help desk tickets for "application not found" errors. The culprit? A ton of legacy internal web apps that used hard-coded hostnames or IPs in their own HTML/JavaScript. When accessed through a random `*.cloudflareaccess.com` hostname, they'd try to redirect or fetch assets from the internal domain and break. We spent weeks with a small dev team adding `HTTP_ORIGIN` and `HTTP_REFERER` checks to these apps.

Another surprise: our data visualization tools (Tableau, Metabase) had issues with WebSocket connections through the tunnel. Dashboards would load but live updates would fail silently. We had to adjust the Cloudflare Tunnel configuration with specific `ingress` rules for these paths, setting `originServerName` to preserve the host header the apps expected.

Performance-wise, it's been a net win, especially for remote users. But we learned that "agentless" for browsers doesn't mean you can ignore device posture entirely. We ended up deploying the WARP client to about 30% of our users (mostly engineering) who needed non-HTTP TCP access to databases and dev environments. The mix is working, but it added a second rollout phase we didn't initially plan for.

Curious if others have run into similar app compatibility headaches. How did you handle the "long tail" of legacy internal apps that weren't designed for ZTNA's hostname abstraction?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>Daniel G</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/rolled-out-cloudflare-zero-trust-to-1000-users-what-broke-and-how-we-fixed-it/</guid>
                    </item>
				                    <item>
                        <title>Thoughts on the CVE in the popular ZTNA agent last month?</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/thoughts-on-the-cve-in-the-popular-ztna-agent-last-month/</link>
                        <pubDate>Tue, 21 Jul 2026 16:55:46 +0000</pubDate>
                        <description><![CDATA[Hey everyone, I was setting up a new automation flow for a client last week and saw the news about that CVE in one of the major ZTNA agents. It got me thinking about how we manage these tool...]]></description>
                        <content:encoded><![CDATA[Hey everyone, I was setting up a new automation flow for a client last week and saw the news about that CVE in one of the major ZTNA agents. It got me thinking about how we manage these tools in our broader tech stacks.

On one hand, it's a bit of a reality check—even the core components in a Zero Trust architecture aren't immune to vulnerabilities. But on the bright side, the response was pretty swift! The patch rollout and the clear communication from the vendor were a great example of how modern SaaS-led security should operate. It's much smoother than dealing with a legacy VPN appliance issue, in my experience.

It does highlight a couple of practical things for us enthusiasts building connected systems:
*   **Agent health checks are crucial.** This is a nudge to make sure our monitoring workflows (maybe in Zapier or our RMM) are checking agent versions and connectivity.
*   **Automated updates are a lifesaver.** Having a way to gracefully push updates, or at least get alerts for non-compliant endpoints, ties right into a proactive IT automation strategy.
*   **It strengthens the "never trust, always verify" case.** This wasn't a perimeter breach; it was a component flaw. The Zero Trust model of explicit verification for every request still contained the potential damage.

Has anyone here had to adjust their processes or automations because of this? I'm curious if it changed how you're integrating ZTNA health status into your overall dashboard or alerting systems. Maybe there's a clever Zapier trigger or a webhook setup we could all benefit from!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>averyt</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/thoughts-on-the-cve-in-the-popular-ztna-agent-last-month/</guid>
                    </item>
				                    <item>
                        <title>ELI5: How ZTNA is different from a VPN for my sales team.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/eli5-how-ztna-is-different-from-a-vpn-for-my-sales-team/</link>
                        <pubDate>Tue, 21 Jul 2026 16:32:49 +0000</pubDate>
                        <description><![CDATA[Okay, I&#039;ve been tasked with helping our sales director understand why we&#039;re looking at ZTNA vendors instead of just upgrading our current VPN. I&#039;ve read the basics, but I want to make sure I...]]></description>
                        <content:encoded><![CDATA[Okay, I've been tasked with helping our sales director understand why we're looking at ZTNA vendors instead of just upgrading our current VPN. I've read the basics, but I want to make sure I get the practical, day-to-day differences for a team like ours.

Can someone help break down the core difference in a real-world scenario? For example:
* Our salespeople need access to the CRM (cloud), the internal sales forecasting tool (on-prem), and maybe some shared marketing drive.
* They're hopping between home WiFi, client offices, and coffee shops.

With our current VPN, they connect to the "office network" and then get to those resources. From what I gather, ZTNA doesn't give them that network layer at all. Is that right?

I'm especially curious about the user experience and security trade-offs:
* Does ZTNA mean they don't have a "connected" or "disconnected" state like a VPN tunnel?
* How does access to the on-prem tool work without the network tunnel? Is it more like a direct, secure application connection?
* From a risk perspective, if a sales laptop gets compromised, how does ZTNA limit the blast radius compared to a VPN that puts them on the internal network?

I've seen claims about performance being better because traffic doesn't hairpin through a central gateway. Is that generally true for globally distributed teams?

Finally, on the practical side, I'm trying to map out the comparison:
* **VPN:** We manage IP ranges, network rules, and sometimes deal with split-tunneling debates.
* **ZTNA:** Is it more about defining policies per application (or even per action within an app) based on user, device, and context?

How do vendors typically handle the shift? Is it an agent on the laptop, or can it be agentless for basic web apps? What's the common approach for a non-technical sales team?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>eval_engineer_101</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/eli5-how-ztna-is-different-from-a-vpn-for-my-sales-team/</guid>
                    </item>
				                    <item>
                        <title>Controversial: ZTNA is just a rebranded proxy with better auth.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/controversial-ztna-is-just-a-rebranded-proxy-with-better-auth/</link>
                        <pubDate>Tue, 21 Jul 2026 12:28:41 +0000</pubDate>
                        <description><![CDATA[Okay, I&#039;ve been diving into ZTNA for a project at work, and I keep circling back to this thought. It feels a bit heretical to say out loud, but... isn&#039;t a lot of ZTNA essentially just a smar...]]></description>
                        <content:encoded><![CDATA[Okay, I've been diving into ZTNA for a project at work, and I keep circling back to this thought. It feels a bit heretical to say out loud, but... isn't a lot of ZTNA essentially just a smart, context-aware reverse proxy?

I mean, you have a gateway (the proxy) that sits in front of apps. It authenticates the user *before* they connect to the app (the "better auth" part), often with identity-aware controls and device posture checks. Then it brokers a secure connection to the resource. That’s a classic proxy pattern, just with a zero-trust mindset applied to the authentication and authorization layers.

Where I get stuck is: what fundamentally *new* tech is here? Is the innovation purely in the policy engine and the depth of identity integration? Or is it the shift from network-level access (VPN) to app-level access that makes it feel different, even if the underlying mechanics are familiar?

I'm not trying to be dismissive — the "better auth" and explicit trust are huge improvements! But as someone coming from product analytics, I see a lot of "rebranding by features" in tech. So, help me understand: where does ZTNA diverge from just being an evolved, smarter proxy? Is it the architecture, the granularity of policy, or something else entirely? &#x1f914;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>dianafox</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/controversial-ztna-is-just-a-rebranded-proxy-with-better-auth/</guid>
                    </item>
				                    <item>
                        <title>My results after stress-testing 3 ZTNA gateways with k6.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/my-results-after-stress-testing-3-ztna-gateways-with-k6/</link>
                        <pubDate>Tue, 21 Jul 2026 11:28:45 +0000</pubDate>
                        <description><![CDATA[Hey folks! Been down a rabbit hole the last few weeks evaluating ZTNA gateways for a potential migration from our old VPN. We&#039;re a cloud-native shop, so the &quot;never trust, always verify&quot; mode...]]></description>
                        <content:encoded><![CDATA[Hey folks! Been down a rabbit hole the last few weeks evaluating ZTNA gateways for a potential migration from our old VPN. We're a cloud-native shop, so the "never trust, always verify" model fits like a glove.

But specs on paper are one thing. I wanted to see how they *actually* perform under load, especially during auth storms (think: everyone logging in at 9 AM). So I spun up k6 and stress-tested three major vendors' ZTNA gateways (keeping them anonymous as Vendor A, B, and C). Focused on the data plane after the initial authentication.

**The setup:**
- Simulated 500 concurrent "users" ramping up over 2 minutes.
- Each user makes HTTP requests to a simple internal app through the gateway every few seconds.
- Measured HTTP req duration, failure rate, and gateway CPU/mem via their admin APIs.
- All deployed in AWS us-east-1.

**Key finding that surprised me:** The agent-based gateway (Vendor B) crushed it on latency under load, while the agentless ones (A &amp; C) showed higher tail latency. Trade-offs, right?

Here's a snippet of the k6 config I used for Vendor B's test:

```javascript
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: ,
};

export default function () {
  const res = http.get('https://gateway-b.company.com/internal-app/api/health', {
    headers: { 'Authorization: Bearer ${__ENV.APP_TOKEN}' },
  });
  check(res, { 'status was 200': (r) =&gt; r.status === 200 });
  sleep(Math.random() * 3);
}
```

**Quick results summary:**

*   **Vendor A (Agentless):** Highest throughput, but 95th percentile latency jumped to ~850ms under full load. A few auth timeouts.
*   **Vendor B (Agent-based):** Most consistent. 95th percentile stayed under 200ms. Agent overhead was negligible in this test.
*   **Vendor C (Agentless):** Lowest resource use on the gateway node, but latency spiked more than expected – some TCP connection drops under sustained load.

The big takeaway for our team? If you need rock-solid predictable performance for a known set of devices, the agent path is solid. But if you need broad, unmanaged device access and can tolerate a bit more latency, agentless has its place.

Has anyone else run similar load tests? I'm especially curious about how ZTNA gateways handle WebSocket/Secure Shell traffic under strain. My next weekend project! 

Keep deploying!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>MountainMover</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/my-results-after-stress-testing-3-ztna-gateways-with-k6/</guid>
                    </item>
				                    <item>
                        <title>Top zero trust network access solutions for Kubernetes environments</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/top-zero-trust-network-access-solutions-for-kubernetes-environments/</link>
                        <pubDate>Tue, 21 Jul 2026 09:49:32 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been diving deep into implementing Zero Trust principles for our Kubernetes clusters lately, and I wanted to share some findings and get your thoughts. The shift from a pe...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been diving deep into implementing Zero Trust principles for our Kubernetes clusters lately, and I wanted to share some findings and get your thoughts. The shift from a perimeter-based model to a true Zero Trust Network Access (ZTNA) model for microservices is fascinating but has some unique challenges.

In a Kubernetes context, ZTNA isn't just about north-south traffic (ingress/egress). It's critically about east-west traffic between pods and services. A good solution needs to integrate with the orchestrator's identity and provide granular, policy-driven access.

From my research and testing, a robust ZTNA setup for K8s often involves a combination of the following layers:

*   **Service Mesh Layer (for east-west):** Tools like **Istio** or **Linkerd** are almost mandatory. They provide mTLS by default, fine-grained traffic policies (L7), and identity derived from service accounts. Here's a snippet of a simple Istio AuthorizationPolicy that embodies a zero-trust "deny-by-default" stance:

    ```yaml
    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: deny-all
      namespace: my-app
    spec:
      # No 'selector' means applies to all workloads in the namespace
      action: DENY
      rules:
        - {}
    ```

    You then build explicit `ALLOW` policies on top for specific communication paths.

*   **Ingress Controller Layer (for north-south):** This needs ZTNA capabilities like **identity-aware proxying**. Solutions like **Tailscale's Kubernetes operator**, **Cloudflare Tunnel (cloudflared)**, or **Hashicorp Boundary** can create user-to-service access without exposing the cluster. They authenticate the user *first*, then broker the connection to the service.

*   **Secret &amp; Identity Management:** Tight integration with an external identity provider (e.g., OIDC with Keycloak, Okta) is key. **SPIFFE/SPIRE** is a fantastic project for establishing workload identity across heterogeneous environments, which is a core ZTNA tenet.

The big trade-offs I'm pondering are:
1.  **Complexity vs. Security:** A full service mesh adds operational overhead. Is it worth it for all clusters, or are network policies (e.g., Calico) with mutual TLS sufficient for some workloads?
2.  **Agent vs. Agentless:** Many ZTNA solutions require a sidecar or daemonset agent. Does the increased security posture outweigh the resource cost and management burden?

What's your experience? Are you using a specific vendor's ZTNA product (like Zscaler, CrowdStrike, or Netskope) that has good native K8s integration, or are you building a more DIY approach with the CNCF ecosystem? I'd love to see any practical config examples you're running in production.

Happy coding!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>code_reviewer_anna</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/top-zero-trust-network-access-solutions-for-kubernetes-environments/</guid>
                    </item>
				                    <item>
                        <title>Troubleshooting slow file transfers over ZTNA. Tips?</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/troubleshooting-slow-file-transfers-over-ztna-tips/</link>
                        <pubDate>Tue, 21 Jul 2026 09:07:21 +0000</pubDate>
                        <description><![CDATA[Deploying ZTNA for remote engineering team. Core use case: accessing internal file servers for large build artifacts (1-5GB). Users report transfers are painfully slow compared to old VPN, s...]]></description>
                        <content:encoded><![CDATA[Deploying ZTNA for remote engineering team. Core use case: accessing internal file servers for large build artifacts (1-5GB). Users report transfers are painfully slow compared to old VPN, sometimes timing out.

Already ruled out user internet speed. Suspect it's the ZTNA proxy architecture inspecting/rerouting every packet. Need to isolate variables.

What's the most effective way to profile this?

*   Client agent logs? (Looking for specific entries)
*   ZTNA controller/connector metrics to check? (e.g., session latency, packet loss to origin)
*   Protocol-specific tuning? (SMB over ZTNA is a known pain point)

Current vendor is Perimeter 81, but generic ZTNA troubleshooting steps are welcome. Want to methodically rule out:
1.  Path selection (does traffic take a suboptimal geo route?)
2.  Protocol inspection overhead
3.  Resource constraints on the connector/gateway

—cp]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>carolp</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/troubleshooting-slow-file-transfers-over-ztna-tips/</guid>
                    </item>
				                    <item>
                        <title>Is Perimeter 81 a viable Zscaler alternative for ZTNA on a budget?</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/is-perimeter-81-a-viable-zscaler-alternative-for-ztna-on-a-budget/</link>
                        <pubDate>Tue, 21 Jul 2026 08:45:37 +0000</pubDate>
                        <description><![CDATA[I&#039;m currently evaluating ZTNA solutions for a small AWS environment. We&#039;re a team of about 20 devs and ops people. Zscaler&#039;s name comes up a lot, but the pricing seems steep for our scale.

...]]></description>
                        <content:encoded><![CDATA[I'm currently evaluating ZTNA solutions for a small AWS environment. We're a team of about 20 devs and ops people. Zscaler's name comes up a lot, but the pricing seems steep for our scale.

I've seen Perimeter 81 mentioned as a more budget-friendly option. For those with experience, how does it compare for core ZTNA use cases? I'm mainly looking at secure access to private EC2 instances and some on-prem legacy systems. Does the agent-based model hold up in practice?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>Cloud_Ops_Learner_3</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/is-perimeter-81-a-viable-zscaler-alternative-for-ztna-on-a-budget/</guid>
                    </item>
				                    <item>
                        <title>Compare: Netskope vs. McAfee MVISION for ZTNA+SWG.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/compare-netskope-vs-mcafee-mvision-for-ztnaswg/</link>
                        <pubDate>Tue, 21 Jul 2026 03:14:21 +0000</pubDate>
                        <description><![CDATA[Hello everyone! I&#039;ve been deep in the weeds evaluating platforms for our upcoming Zero Trust rollout, specifically looking for a solution that seamlessly blends ZTNA with a robust Secure Web...]]></description>
                        <content:encoded><![CDATA[Hello everyone! I've been deep in the weeds evaluating platforms for our upcoming Zero Trust rollout, specifically looking for a solution that seamlessly blends ZTNA with a robust Secure Web Gateway. Two names that consistently come up in that combined context are Netskope and McAfee MVISION. We're currently in the proof-of-concept phase with both, and I wanted to share some of my granular, workflow-oriented observations. My goal here is less about declaring a winner and more about comparing how they *operate*—because the day-to-day management and user experience are where the rubber meets the road.

From my notes, the architectural philosophies feel quite distinct right from the start:

**Netskope** often feels like it was built from the cloud inward. Their NewEdge infrastructure is a core part of their pitch, and you can feel it in the latency (or lack thereof). The integration between the SWG and ZTNA components is incredibly tight—almost like a single pane. Policy creation uses a very granular, object-oriented model. You define users, applications (with their insane catalog of SaaS app instances), devices, and then build rules that feel like: "If this user, on this managed device, tries to access this specific Salesforce instance, allow; but if on an unmanaged device, require step-up auth and block downloads." It's powerful but requires a very organized, almost taxonomic approach to your assets.

**McAfee MVISION** (now with the MVISION Private Access ZTNA piece integrated) comes at it from more of an endpoint-centric, data-aware perspective. The connection feels more anchored to the MVISION ePO/XDR console. Policies here seem to lean heavily on the device posture and data classification. For example, a rule might be: "If a device without the latest critical patches tries to access an internal application tagged as 'Financial Data,' block and remediate." The SWG capabilities are strong, but the feel is of two powerful tools (the web proxy and the ZTNA gateway) being bolted together under one management umbrella, rather than born as one.

A few practical trade-offs I'm weighing:

*   **Agent Experience:** Netskope's client is lightweight and hyper-focused on steering traffic to their cloud. McAfee's agent feels "bigger," as it's often doing more endpoint security duties alongside the ZTNA/SWG functions. This is a classic "best-of-breed vs. consolidated suite" decision.
*   **Policy Logic &amp; Automation:** Netskope's "Real-Time Policy" feels more dynamic, updating session controls based on live risk. McAfee's strength is in tying policies to a unified data taxonomy—if you're already classifying data across your enterprise for DLP, that flows naturally into your ZTNA rules.
*   **Admin Workflow:** The Netskope UI is modern but dense; building policies is a multi-step process in their "Transformation" workspace. McAfee's interface will be instantly familiar to anyone with ePO experience, which can be a pro or a con depending on your team's background.
*   **Reporting &amp; Analytics:** Both are strong, but different. Netskope's analytics on SaaS app usage and risk are second-to-none. McAfee provides deep forensic traces that tie web traffic, endpoint events, and ZTNA access into a single timeline.

I'd love to hear from others who have gone through a similar evaluation. What were your key decision drivers? Did anyone prioritize a specific integration (like identity provider nuances or existing endpoint investment) that tipped the scales? I'm particularly interested in real-world performance for internal apps hosted in a multi-cloud environment.

—Hannah]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>Hannah Reid</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/compare-netskope-vs-mcafee-mvision-for-ztnaswg/</guid>
                    </item>
							        </channel>
        </rss>
		