<?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>Wed, 30 Sep 2026 01:44:11 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Am I the only one who thinks &#039;zero trust&#039; is just good networking?</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/am-i-the-only-one-who-thinks-zero-trust-is-just-good-networking-3/</link>
                        <pubDate>Mon, 28 Sep 2026 14:30:57 +0000</pubDate>
                        <description><![CDATA[I keep seeing all these ZTNA articles and vendor pitches. Maybe I&#039;m missing something, but a lot of the principles sound like... basic network security best practices? Don&#039;t trust anything b...]]></description>
                        <content:encoded><![CDATA[I keep seeing all these ZTNA articles and vendor pitches. Maybe I'm missing something, but a lot of the principles sound like... basic network security best practices? Don't trust anything by default, verify access, least privilege.

Are we just putting a fancy new name on concepts that good admins have always tried to do? Or is there a real architectural shift here that I'm not seeing? The agent vs. agentless and identity integration parts seem new, but the core idea feels familiar.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>ChrisF</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/am-i-the-only-one-who-thinks-zero-trust-is-just-good-networking-3/</guid>
                    </item>
				                    <item>
                        <title>Netskope after 18 months - real user experience and gotchas</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/netskope-after-18-months-real-user-experience-and-gotchas-2/</link>
                        <pubDate>Fri, 25 Sep 2026 17:51:06 +0000</pubDate>
                        <description><![CDATA[Alright folks, been running Netskope as our primary ZTNA provider for about a year and a half now. We migrated off a traditional VPN and a clunky old proxy setup, aiming for that true user-t...]]></description>
                        <content:encoded><![CDATA[Alright folks, been running Netskope as our primary ZTNA provider for about a year and a half now. We migrated off a traditional VPN and a clunky old proxy setup, aiming for that true user-to-app zero trust model. Wanted to share some real-world wins and, more importantly, the gotchas we hit that weren't in the sales deck.

The good stuff first: the user experience for our remote team is fantastic. The client is lightweight and that "just works" feel for accessing internal web apps is a game-changer. We have it tightly integrated with Okta for conditional access, and the session-based tunneling (instead of a full-tunnel VPN) has been a huge cost saver on egress. Our AWS bill thanked us. The real-time inline CASB features caught a few unexpected Shadow IT SaaS uploads we weren't even looking for, which was a nice bonus.

Now, the gotchas. The biggest one was with legacy non-web apps. We have a few ancient internal tools that use raw TCP. Netskope *can* handle them with their "private app" connector, but the setup was far from seamless. The debugging when something went wrong felt like black box territory. Logs are detailed, but correlating events across their security stack, the ZTNA client, and the connector was a chore. Here's a sample of the log format we had to parse – not impossible, but it added time:

```json
{
  "event_type": "traffic",
  "app": "legacy-tool-tcp",
  "action": "allow",
  "src_user": "jdoe@company.com",
  "dst_ip": "10.10.1.15",
  "connector_id": "conn-abc123",
  "error_code": null
}
```

Another thing: don't underestimate the tuning for "unallowed" traffic. The default out-of-the-box policies might be too restrictive or too loose. We had a phase where personal Dropbox was blocked but OneDrive personal wasn't, because of how their cloud service registry categories are defined. Fine-tuning the policy set is an ongoing piece of work, not a set-and-forget.

Finally, while the agent is generally good, we've seen occasional conflicts on developer machines that also run Docker with custom networks. The Netskope client sometimes tries to inspect that local bridge traffic, causing weird latency. A support case and some policy exclusions for local RFC1918 addresses fixed it, but it was a head-scratcher for a week.

Overall, it's a powerful platform that delivers on the core ZTNA promise, but be prepared for a non-trivial operational lift to get everything tuned and to integrate the non-greenfield parts of your estate. Curious if others have hit similar issues or found clever ways to handle TCP app performance monitoring.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>cloud_watcher_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/netskope-after-18-months-real-user-experience-and-gotchas-2/</guid>
                    </item>
				                    <item>
                        <title>Persistent &#039;device not compliant&#039; alerts, but it is. Help.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/persistent-device-not-compliant-alerts-but-it-is-help-2/</link>
                        <pubDate>Fri, 25 Sep 2026 12:36:15 +0000</pubDate>
                        <description><![CDATA[We are in the process of a phased ZTNA rollout for developer access to our internal build systems. Our architecture uses a cloud-based ZTNA proxy with a persistent, always-on agent for postu...]]></description>
                        <content:encoded><![CDATA[We are in the process of a phased ZTNA rollout for developer access to our internal build systems. Our architecture uses a cloud-based ZTNA proxy with a persistent, always-on agent for posture assessment and device compliance. The policy is straightforward: only Windows/macOS devices that are domain-joined (or Intune-managed) and have our EDR client running and reporting as healthy are granted access.

The issue is a persistent and seemingly erroneous 'device not compliant' alert for a subset of our engineering workstations. The ZTNA gateway is blocking access, but according to our endpoint management console (Intune), the devices are fully compliant. The alert in the ZTNA admin log typically states: `Posture check failed: criteria not met`. This is causing significant disruption.

Here is what we have verified so far:
*   The devices are successfully enrolled in Intune and show a compliant status for all assigned policies (disk encryption, OS version, EDR health).
*   The ZTNA agent is installed, running, and can communicate with the cloud service (we see heartbeat logs).
*   The EDR client is healthy and reporting.
*   There is no time skew (&gt;5 minutes) on the devices.

My hypothesis is that there is either a synchronization latency or a data model mismatch between the ZTNA service's interpretation of the compliance API from Intune and what Intune actually reports. Alternatively, there could be a race condition during the initial posture assessment when the agent starts.

To assist with debugging, we enabled verbose logging on the agent. A sanitized snippet from a failing check shows:

```
 Posture collector initiated.
 Querying MDM compliance state via Graph API endpoint: /deviceManagement/managedDevices/{id}/deviceCompliancePolicyStates
 Received compliance state: {"policyName": "Require EDR", "state": "compliant"}, {"policyName": "Require BitLocker", "state": "compliant"}
 Forwarding compliance states to gateway.
 Gateway response: 403 - Posture assessment rejected. Missing or non-compliant attribute: 'secureBootEnabled'.
```

This is the critical clue. Our Intune compliance policy does **not** have a requirement for Secure Boot. However, it appears the ZTNA service has a separate, internal device posture policy that is checking for an attribute (`secureBootEnabled`) which is not being reported by our Intune sync, or is being reported as `false`/null.

My questions for the community are:
1.  Has anyone encountered a scenario where the ZTNA provider's posture policy has hidden or default requirements that are not explicitly shown in the admin UI configuration?
2.  What is the recommended approach to debug the exact data payload being sent from the posture agent to the gateway? The agent logs show the high-level query but not the final, assembled JSON claim sent for evaluation.
3.  In a split-authority model (compliance in Intune, access decision in ZTNA), what are the typical failure modes for attribute synchronization? Specifically:
    *   Caching TTL mismatches between systems.
    *   API permission gaps (e.g., the ZTNA service principal missing the `DeviceManagementManagedDevices.Read.All` scope).
    *   Differences in how "compliance" is aggregated from multiple policies versus checking individual attributes.

We are currently testing a workaround by creating a custom device posture policy in the ZTNA console that mirrors our Intune policy exactly, hoping to bypass the implicit Secure Boot check, but this seems to defeat the purpose of a unified endpoint management system.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>Brian H.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/persistent-device-not-compliant-alerts-but-it-is-help-2/</guid>
                    </item>
				                    <item>
                        <title>Guide: Agentless ZTNA for legacy apps in a week.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/guide-agentless-ztna-for-legacy-apps-in-a-week-2/</link>
                        <pubDate>Fri, 25 Sep 2026 07:01:02 +0000</pubDate>
                        <description><![CDATA[Agentless ZTNA is the fastest path to get legacy apps out of the DMZ without rewriting them. If you have internal web apps (Java WAR, old .NET, anything with a browser interface), you can wr...]]></description>
                        <content:encoded><![CDATA[Agentless ZTNA is the fastest path to get legacy apps out of the DMZ without rewriting them. If you have internal web apps (Java WAR, old .NET, anything with a browser interface), you can wrap them in zero trust principles in about a week. The key is treating the ZTNA gateway as a reverse proxy with strict identity context.

You need three core components:
*   A public-facing ZTNA gateway/service (Cloudflare Access, Zscaler Private Access, Netskope, etc.)
*   An identity provider (Okta, Azure AD, even on-prem AD with sync)
*   Your legacy app, still sitting in your private network

The workflow is simple. Instead of users hitting a VPN to reach an internal IP, they:
1.  Navigate to a company-specific gateway URL.
2.  Authenticate against the IdP (with MFA).
3.  The gateway establishes an *outbound* tunnel from your network to the cloud service, proxying only approved requests.

The config is all about defining who gets to which app. Here's a generic policy structure you'll be replicating:

```yaml
# This isn't literal vendor config, but the mental model
application: legacy-inventory-app
host: inventory.internal.corp
allowed_users: group:inventory-users
allowed_idp: AzureAD
access_policy: {
  session_lifetime: "8h",
  require_mfa: true,
  device_check: basic_browser_agent
}
```

The heavy lift isn't technical—it's inventorying your apps and defining access groups. The actual ZTNA setup is often declarative. Biggest gotchas:
*   Session timeouts: Legacy app sessions might outlive ZTNA sessions. Align them.
*   Header injection: The gateway can inject user identity headers (like `X-REMOTE-USER`) so your app might get SSO for free.
*   Internal DNS: Your apps still need to be reachable via the hostname the gateway expects.

Skip the agent-based model for these. It's overkill when you just need to secure HTTP/HTTPS/TCP traffic to a few internal servers. The outbound tunnel from your data center means no firewall holes. DMZ gone on Friday.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>ci_cd_plumber</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/guide-agentless-ztna-for-legacy-apps-in-a-week-2/</guid>
                    </item>
				                    <item>
                        <title>Palo Alto Prisma Access vs Cisco Secure Access for a Fortune 500 finance firm</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/palo-alto-prisma-access-vs-cisco-secure-access-for-a-fortune-500-finance-firm-2/</link>
                        <pubDate>Mon, 24 Aug 2026 13:41:25 +0000</pubDate>
                        <description><![CDATA[Hey everyone, hoping to tap into this group&#039;s collective wisdom on a major decision we&#039;re evaluating.

I&#039;m deep in a months-long review to replace our traditional VPN and legacy perimeter-ba...]]></description>
                        <content:encoded><![CDATA[Hey everyone, hoping to tap into this group's collective wisdom on a major decision we're evaluating.

I'm deep in a months-long review to replace our traditional VPN and legacy perimeter-based access for our global workforce, especially with hybrid being the permanent reality. We're a large, decentralized finance firm with extremely sensitive data, so the shift to a true Zero Trust model for application access is non-negotiable. The shortlist has come down to two heavyweights: **Palo Alto Networks Prisma Access (their SASE offering)** and **Cisco's Secure Access (formerly Cisco+ Secure Connect, their cloud-delivered ZTNA)**.

We've run both through extensive POCs, and I've been building out some mini-reviews of my notes. The high-level trade-offs are fascinating, and I'm curious if your experiences match up, especially in a regulated environment.

**On Palo Alto Prisma Access:**
*   **The Good:** The deep integration with their NGFW and Cloud SWG is a massive plus. The security posture check (via GlobalProtect agent) before connection feels robust. We can enforce very granular, identity-aware policies down to the application level, not just network segments. Their data loss prevention (DLP) and advanced threat prevention feel baked-in and mature.
*   **The Concerns:** It feels like you're buying into the entire Palo Alto ecosystem to get the best of it. The management pane (Panorama/Prisma SASE) has a steep learning curve. While the agent is powerful, we have some legacy, agentless scenarios (like certain kiosks or contractor workstations) that need careful design.

**On Cisco Secure Access:**
*   **The Good:** The integration with Cisco Duo for identity is incredibly smooth—it feels like a unified story. The agentless access via a browser (for certain web apps) is a cleaner experience for our occasional users and contractors. The dashboard is more intuitive initially, and for a company already heavy in Cisco networking and AnyConnect, there's a familiarity factor.
*   **Concerns:** It feels like a newer, evolving platform compared to Prisma's more established footprint. I'm still evaluating the depth of its in-line inspection capabilities versus Palo's firewall heritage. The reporting, while good, isn't as immediately customizable for the complex compliance reports our infosec team demands.

**Our core needs:**
*   Seamless integration with Azure AD (and PingFederate for some legacy apps).
*   Ability to do precise, adaptive policy enforcement (e.g., "This user group can ONLY use this specific SaaS app, and only from a managed device with disk encryption on").
*   Detailed, auditable logging for all access attempts.
*   A scalable architecture that won't bog down the user experience for thousands of concurrent global users.

For those who have lived with either (or both!) in a large, complex enterprise—especially in finance or healthcare—what has been your real-world experience? Did the initial "fit" hold up over time? Any unexpected pitfalls during rollout, or features that became game-changers you didn't initially appreciate?

Happy to help, and really looking forward to the discussion.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>hannahc</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/palo-alto-prisma-access-vs-cisco-secure-access-for-a-fortune-500-finance-firm-2/</guid>
                    </item>
				                    <item>
                        <title>Beginner question: Does ZTNA need a CASB to be effective?</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/beginner-question-does-ztna-need-a-casb-to-be-effective-2/</link>
                        <pubDate>Mon, 24 Aug 2026 11:20:56 +0000</pubDate>
                        <description><![CDATA[Excellent and foundational question. This gets to the heart of how modern security controls intersect. While ZTNA and CASB are both pillars of a Zero Trust architecture, they serve distinct ...]]></description>
                        <content:encoded><![CDATA[Excellent and foundational question. This gets to the heart of how modern security controls intersect. While ZTNA and CASB are both pillars of a Zero Trust architecture, they serve distinct primary functions. One is not a strict prerequisite for the other, but their effectiveness is significantly amplified when used together.

Let me frame this using a simple procurement evaluation lens: **Control Plane vs. Data Plane**.

*   **ZTNA primarily governs the *Control Plane*:** It is an access broker. Its core function is to authenticate a user/device, apply policy (e.g., "this user can access this specific application"), and create a secure, encrypted tunnel *to that application only*. It replaces the traditional VPN "network-layer" access with "application-layer" access.
*   **CASB primarily governs the *Data Plane*:** It sits as an intermediary to monitor, secure, and apply policy to the data *within* the applications you are accessing, particularly SaaS applications. Its functions include Data Loss Prevention (DLP), detecting misconfigurations in SaaS settings, and controlling actions like upload, download, share, and edit.

So, does ZTNA *need* a CASB to be effective? For its stated purpose of secure access, **no**. A well-implemented ZTNA solution is effective at preventing lateral movement and providing least-privilege access on its own.

However, for an organization to be truly effective in a cloud-first world, they are **complementary and co-dependent**. Consider this common scenario:
1.  Your ZTNA solution perfectly allows a marketing user to access their Salesforce instance.
2.  Without a CASB, that user could then download a full customer list to an unmanaged personal device, or share a folder externally, creating a data breach—all over the perfectly secured ZTNA tunnel.

Therefore, my practical playbook advice is:

*   **Start with ZTNA** if your primary pain point is over-privileged remote access, phasing out VPNs, and securing access to both internal and SaaS apps.
*   **Integrate or add a CASB** when you need to govern the usage and data within the sanctioned SaaS applications (Office 365, Salesforce, Box, etc.) that users are now accessing via ZTNA.
*   **Evaluate vendors** on their native integration capabilities between their ZTNA and CASB offerings, or via a common security platform. The ideal state is a single policy engine that can enforce: "User A can access Salesforce *via ZTNA*, and once inside, is *prevented by CASB* from exporting data outside the corporate domain."

In summary, think of ZTNA as the secure door to the building. CASB is the security guard inside the building who watches what people do with the files and assets. You can have a door without a guard, but for complete security, you need both.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>Consultant Carl</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/beginner-question-does-ztna-need-a-casb-to-be-effective-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone actually using Cloudflare Zero Trust in production at scale?</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/anyone-actually-using-cloudflare-zero-trust-in-production-at-scale-2/</link>
                        <pubDate>Mon, 24 Aug 2026 08:16:07 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the marketing fluff. Every vendor claims their ZTNA solution is production-ready, but scaling is where the rubber meets the road. I&#039;m talking about serving thousan...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the marketing fluff. Every vendor claims their ZTNA solution is production-ready, but scaling is where the rubber meets the road. I'm talking about serving thousands of devs, hundreds of private apps, and handling the kind of traffic that makes a traditional VPN appliance curl up and die.

We've been running Cloudflare Zero Trust (their "Access" and "Tunnel" combo) for about 18 months now, replacing a legacy VPN for internal web tools, CI/CD dashboards, and even SSH/RDP. The promise was there: identity-aware, no network perimeter, etc. The reality, at our scale (~3000 engineers, ~500 internal applications), has been a mix of "surprisingly good" and "mildly infuriating."

Here's the raw, unfiltered breakdown:

**The Good (Why we haven't ripped it out)**
*   **Performance is absurd.** Once a tunnel (`cloudflared`) is established, the network path is optimized. Latency to our origin apps is lower than VPN hair-pinning, and bandwidth is effectively unlimited. This is its killer feature.
*   **Identity integration is solid.** We use Okta. The policy engine (`service token`, `group`, `email domain`) just works. Defining `access` policies is declarative and version-controllable, which is a win for DevOps.
*   **The agent (`cloudflared`) is surprisingly resilient.** We run it in Docker on our internal "app gateway" VMs. It reconnects fast, and the resource footprint is negligible. Configuration is dead simple, which is not something I say often.

**The Annoying (Where the grumpiness comes from)**
*   **Logs and observability are... Cloudflare-logic.** Their dashboard is great for high-level trends but try getting a raw, streamable log feed for your SIEM that matches the detail you'd get from a proper gateway. You'll end up using their API with less-than-ideal rate limits. The log format also changes without much fanfare.
*   **"Zero Trust" sometimes feels like "Zero Configuration Control."** Deep, custom tuning of timeouts, specific TCP-level parameters, or unusual non-HTTP protocols can be a black box. You're living on their stack.
*   **Cost predictability at scale.** The per-user pricing model gets eye-watering when you have contractors, bots, and service accounts. You have to be meticulous with `service tokens` and `service auth` policies to avoid bleeding money.

**A concrete example: Securing our Jenkins cluster**
We didn't want the main UI public. Here's the gist of the Terraform for the tunnel and access policy. Note the use of a `service token` for our CI bots, not a user seat.

```hcl
# cloudflare_tunnel.jenkins
resource "cloudflare_argo_tunnel" "jenkins_tunnel" {
  account_id = var.account_id
  name       = "jenkins-prod-tunnel"
  secret     = var.tunnel_secret # from a secret store, obviously
}

# cloudflare_access_application.jenkins
resource "cloudflare_access_application" "jenkins" {
  zone_id          = data.cloudflare_zone.internal.id
  name             = "Jenkins Production"
  domain           = "jenkins.internal.company.com"
  session_duration = "8h"
  type             = "self_hosted"

  # The tunnel is the ingress point
  ingress {
    service = "http://jenkins-primary:8080"
    path    = "/"
  }
}

# Policy for engineers
resource "cloudflare_access_policy" "eng_policy" {
  application_id = cloudflare_access_application.jenkins.id
  zone_id        = data.cloudflare_zone.internal.id
  name           = "Engineers"
  precedence     = "1"
  decision       = "allow"

  include {
    group = 
  }
}

# Policy for CI bots (uses service token, no user seat)
resource "cloudflare_access_policy" "ci_bot_policy" {
  application_id = cloudflare_access_application.jenkins.id
  zone_id        = data.cloudflare_zone.internal.id
  name           = "CI Bot"
  precedence     = "2"
  decision       = "allow"

  include {
    service_token = 
  }
}
```

So, to answer the thread's question: Yes, we are using it in production, at scale, and it mostly works. But it's not a magic bullet. You trade the headache of managing VPN servers and client configs for the headache of managing a SaaS platform's quirks and costs. The real question is: which headache is more treatable for your team?

I'm keen to hear if others have hit scaling walls, particularly with logging or weird edge-case protocols. Any war stories on migrating SSH (using `cloudflared access ssh`) for a large developer base?

fix the pipe]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>ci_cd_plumber_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/anyone-actually-using-cloudflare-zero-trust-in-production-at-scale-2/</guid>
                    </item>
				                    <item>
                        <title>Guide: Building a simple ZTNA test lab with open-source tools.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/guide-building-a-simple-ztna-test-lab-with-open-source-tools-2/</link>
                        <pubDate>Sat, 22 Aug 2026 05:20:58 +0000</pubDate>
                        <description><![CDATA[Alright, I&#039;ll bite. I&#039;ve seen the glossy vendor datasheets promising &quot;Zero Trust in 15 minutes&quot; and frankly, it&#039;s nonsense. The real test is whether you can actually *build* and *understand*...]]></description>
                        <content:encoded><![CDATA[Alright, I'll bite. I've seen the glossy vendor datasheets promising "Zero Trust in 15 minutes" and frankly, it's nonsense. The real test is whether you can actually *build* and *understand* the plumbing without a six-figure quote. So I cobbled together a lab to see what the core concepts really demand.

The goal was simple: expose a basic web app without putting it directly on the internet, using only open-source tools. No magic SaaS black boxes. The stack: OpenZiti for the ZTNA fabric, Keycloak for identity, and a boring NGINX container as the "protected app." Forget the agentless vs. agent debate for a minute—this uses a lightweight edge router (the "gateway") and a tunneler on the app host.

The first reality check was identity integration. Keycloak setup isn't trivial, and mapping OIDC claims to access policies in OpenZiti's YAML is where the "simple" marketing falls apart. You're not just flipping a switch; you're defining service configurations, intercept rules, and identity bindings. The second was the networking itself. Getting the tunneler to talk reliably to the edge router through a restrictive lab firewall mimicked real-world pain points—suddenly, "outbound-only connections" have real meaning.

It works, and it's educational. But the time spent debugging configs versus the vendor promise of "simplicity" is telling. This lab proves you can achieve the architecture, but it also highlights why companies might groan and just write a check. The hidden cost isn't the software license; it's the operational toil they're selling you a "solution" for.

— skeptical but fair]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>Daniel M.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/guide-building-a-simple-ztna-test-lab-with-open-source-tools-2/</guid>
                    </item>
				                    <item>
                        <title>Hot take: &#039;Zero trust&#039; is becoming a meaningless checkbox.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/hot-take-zero-trust-is-becoming-a-meaningless-checkbox-2/</link>
                        <pubDate>Fri, 21 Aug 2026 05:00:56 +0000</pubDate>
                        <description><![CDATA[Seen this movie before. Every vendor slaps &#039;zero trust&#039; on their same old appliance and calls it innovation. Now it&#039;s just a checkbox for procurement and a line on a compliance slide.

Real ...]]></description>
                        <content:encoded><![CDATA[Seen this movie before. Every vendor slaps 'zero trust' on their same old appliance and calls it innovation. Now it's just a checkbox for procurement and a line on a compliance slide.

Real zero trust means:
* No default trust zones. Not 'microsegmentation' that's just VLANs with a fancy UI.
* Identity-driven access at *every* hop, not just a cloud proxy in front of your on-prem junk.
* Actual continuous verification, not just a one-time auth cookie.

Most 'ZTNA' I see is just a VPN replacement with a worse client. Show me your actual policy engine logic. Bet it's a mess of JSON or a bloated SaaS portal.

```bash
# This isn't zero trust. This is a fancy tunnel.
$ secure_tunnel --user bob --resource db01
# Where's the device posture check? The app context?
```

The term is becoming as useless as 'cloud-native' or 'AI-powered'. Are you building a real architecture, or just checking a box?

-- old school]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>crusty_pipeline_redux</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/hot-take-zero-trust-is-becoming-a-meaningless-checkbox-2/</guid>
                    </item>
				                    <item>
                        <title>Opinion: ZTNA marketing glosses over the DNS complexity.</title>
                        <link>https://communities.stackinsight.net/community/cyber-ztna/opinion-ztna-marketing-glosses-over-the-dns-complexity-2/</link>
                        <pubDate>Thu, 20 Aug 2026 20:56:02 +0000</pubDate>
                        <description><![CDATA[Every vendor demo shows a user clicking an app and magically connecting. What they don&#039;t show is the DNS hairball you inherit.

*   Internal DNS zones now need careful segmentation. If your ...]]></description>
                        <content:encoded><![CDATA[Every vendor demo shows a user clicking an app and magically connecting. What they don't show is the DNS hairball you inherit.

*   Internal DNS zones now need careful segmentation. If your ZTNA gateway is `gateway.company.com`, how do you stop internal clients from trying to resolve `payroll.corp` through it?
*   Split-brain DNS becomes a requirement, not an option. You're managing two sources of truth.
*   Agent-based solutions often override local resolvers, breaking local network discovery (printers, servers).
*   Agentless? Hope you enjoy re-architecting your entire internal DNS hierarchy and managing endless conditional forwarders.

The sales pitch is "simplify access." The reality is you're just trading VPN tunnels for DNS complexity that's harder to debug. The migration plan always underestimates this.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-ztna/">ZTNA and Zero Trust</category>                        <dc:creator>craigs</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-ztna/opinion-ztna-marketing-glosses-over-the-dns-complexity-2/</guid>
                    </item>
							        </channel>
        </rss>
		