Your ZTNA Strategy Has a Blind Spot — External Users Need a Different Approach

Zero Trust Network Access is supposed to replace VPN for good. But most ZTNA evaluations focus exclusively on internal employees — and completely miss the external user problem. This post breaks down why, and shows a hybrid AWS architecture that handles both.

The Problem

Enterprise VPN replacement projects typically start with a clear goal: move from perimeter-based security to zero-trust, application-level access. AWS Verified Access does this well — it validates identity and device posture on every request, grants access per-application instead of per-network, and scales elastically without VPN concentrators.

But here’s the blind spot. Most large enterprises don’t just have internal employees accessing critical applications like SAP ECC. They also have external users — contractors, suppliers, logistics partners, auditors — who need the same application access from devices the enterprise doesn’t own or manage.

For external users, ZTNA solutions like Verified Access hit three walls:

• Device posture is unenforceable. You can’t install CrowdStrike or Okta Verify on a contractor’s personal laptop. Without device posture checks, you lose half the zero-trust value. The “trust” in zero trust depends on verifying both who you are and what you’re connecting from.
• Client deployment is impractical. Verified Access TCP endpoints (needed for thick-client protocols like SAP GUI’s DIAG) require a lightweight connectivity client. Getting external partners to install software on machines you don’t control is a hard sell — and a support nightmare.
• Data reaches the endpoint. With Verified Access, application data flows to the user’s device. For internal managed devices with disk encryption and EDR, that’s acceptable. For an unmanaged contractor laptop? That’s a compliance gap.

The result: most ZTNA rollouts either exclude external users entirely (leaving them on legacy VPN) or grant them the same access path as internal employees with weaker security guarantees. Neither is good.

The Solution

The fix is straightforward — stop trying to force external users through an access path designed for managed devices. Instead, use a two-track architecture:

• Track 1: AWS Verified Access for internal employees on managed devices (identity + device posture + application-level access)
• Track 2: Amazon AppStream 2.0 for external users on unmanaged devices (application streaming — data never leaves AWS)

The key insight: with AppStream, the application session runs on a managed fleet inside your VPC. The external user’s device is just a screen. No data on the endpoint. No agent to install. No device posture to enforce — because the “device” accessing SAP is an AWS-managed instance you fully control.

How It Works

Track 1: AWS Verified Access for Internal Users

Verified Access is a cloud-native, fully managed ZTNA service. It sits at the edge of your AWS infrastructure and validates every access request against two signals: identity (who is this user?) and device posture (is their device compliant?).

The core components:

Component	Purpose
Verified Access Instance	Central configuration — trust providers, groups, policies
Trust Provider	IdP integration via OIDC or IAM Identity Center
HTTP Endpoints	Web application access (fronted by ALB)
TCP Endpoints	Non-HTTP protocol access like SAP GUI DIAG (fronted by NLB)
Connectivity Connector	Lightweight agent for hybrid access to on-premises resources

For SAP environments specifically, this means:

• SAP Fiori / WebGUI → HTTP endpoints through an ALB. Users access via browser, no client needed.
• SAP GUI Desktop → TCP endpoints through an NLB. The DIAG protocol (binary over TCP, port 3200+) flows through a Verified Access TCP endpoint. Users need the lightweight VA connectivity client.
• SAP Web Dispatcher / Router → HTTP or TCP endpoints depending on configuration.

Device posture integrates with CrowdStrike or Okta — the endpoint agent reports OS version, disk encryption status, antivirus state, and more. Verified Access evaluates this on every request, not just at login.

One important nuance with OIDC providers like Google Workspace: the JWT token does not include group membership claims by default. If your access policies depend on group-based rules (e.g., “only users in SAP-Finance-LATAM can access this endpoint”), you’ll need either custom claim mapping or a sync path through IAM Identity Center.

Track 2: Amazon AppStream 2.0 for External Users

AppStream 2.0 is an application streaming service. You install applications (like SAP GUI) on a fleet of managed instances, and users access them through a browser. The application runs on AWS — the user sees pixels, not data.

Why this solves the external user problem:

Challenge	How AppStream Solves It
No device posture agent	Not needed — the application runs on an AWS-managed instance
Can’t install TCP client	Not needed — everything streams through the browser via HTTPS
Data leakage risk	Data never reaches the endpoint. Clipboard, file transfer, and printing can be disabled per policy
Compliance/audit	Built-in session recording and watermarking. Every action is captured
Identity federation	SAML 2.0 federation with partner IdPs or guest accounts

For SAP GUI specifically, AppStream streams the full desktop application in the browser. The user gets the same SAP GUI experience — transactions, reports, ALV grids, downloads — but the DIAG traffic stays entirely within your VPC. The external user’s browser receives only a video stream.

DLP controls are granular:

• Clipboard: disable copy/paste between local device and streamed session
• File transfer: disable upload/download
• Printing: disable or redirect to virtual printers
• Watermarking: overlay user identity on the stream for screenshot deterrence
• Session recording: capture full session video for audit and compliance

The Decision Logic

The routing decision is simple and can be implemented at the identity layer:

IF user.device_managed == true
   AND device.posture_compliant == true
   → Route to AWS Verified Access (direct application access)

ELSE
   → Route to Amazon AppStream 2.0 (streamed application access)

In practice, this maps to your IdP group membership. Internal employees in the “Managed-Devices” group get Verified Access endpoints. External contractors in the “Partner-Access” group get AppStream portal URLs. No user-facing decision needed.

Amazon WorkSpaces Web is a lighter alternative for external users who only need web-based SAP access (Fiori, WebGUI). At ~$7/user/month, it’s cheaper than AppStream but doesn’t support thick-client applications like SAP GUI desktop.

Cost Comparison

Here’s what the numbers look like for an enterprise with 45,000 internal users and 1,000 external users:

Component	Scope	Monthly Cost	Annual Cost
Verified Access (HTTP + TCP)	10 apps, 5 TCP endpoints, internal users	~$3,100	~$37K
AppStream 2.0 (SAP GUI streaming)	~1,000 external users, on-demand	~$25,000-$40,000	~$300K-$480K
Hybrid Total			~$337K-$517K

Compare that to pure ZTNA alternatives that struggle with the external user problem:

Solution	Annual Cost (45K users)	External User Story
Zscaler ZPA	$180-270K	Per-user licensing, still needs agent
Palo Alto Prisma	$200-400K	Clientless for web only, no SAP GUI
Cloudflare Access	$90-150K	HTTP only, no TCP/SAP GUI support
AWS Hybrid (VA + AppStream)	$337-517K	Full coverage, both user types

The hybrid approach costs more than Verified Access alone, but it’s the only option that actually solves the external user problem for thick-client applications like SAP GUI. And the AppStream component scales linearly — 500 external users instead of 1,000 cuts that cost in half.

SAP-Specific Gotchas

A few things to watch for when applying this architecture to SAP environments:

• DIAG is stateful. SAP GUI sessions maintain persistent connections. Long idle sessions (>24 hours) may be terminated by the Verified Access edge. Configure SAP keep-alive parameters (rdisp/conn_cache_timeout) to prevent drops.
• Latency matters for SAP GUI. Verified Access adds ~10-20ms at the edge. SAP GUI users expect sub-100ms response. Always validate with a PoC before committing.
• AppStream fleet sizing for SAP. SAP GUI is memory-intensive. Use stream.standard.medium instances minimum. Budget for 1 instance per 2-3 concurrent users to account for SAP’s memory footprint.
• Double encryption. Verified Access terminates TLS, then forwards to the load balancer. If SAP GUI encryption (snc/enable) is also active, you’re double-encrypting. Consider disabling SAP-level encryption when traffic already flows through VA’s TLS tunnel.
• Session timeout mismatch. SAP’s default idle timeout is 15 minutes (rdisp/max_conn_idle_time). Verified Access and AppStream have their own session timeouts. Align these to avoid users getting disconnected mid-transaction.

What I Learned

• ZTNA evaluations that only consider internal users are incomplete. The external user segment is smaller but architecturally harder — and it’s where most ZTNA solutions fall short. Device posture enforcement, the cornerstone of zero trust, simply doesn’t work when you don’t control the device.
• Application streaming is the correct abstraction for unmanaged devices. Instead of trying to secure an endpoint you can’t control, remove the endpoint from the equation entirely. AppStream turns the access problem into a display problem — the user sees pixels, not data.
• Hybrid architectures beat single-vendor purity. Using two AWS services (Verified Access + AppStream) for two different user profiles is better than forcing one tool to handle both. The routing decision is simple, the security model is clean, and each track is optimized for its use case.

Do It Yourself

Key takeaways:

• ZTNA breaks down for external users on unmanaged devices — Device posture enforcement, the cornerstone of zero trust, simply doesn’t work when you don’t control the device. Trying to force external contractors through the same access path as internal employees creates security gaps.
• Application streaming removes the endpoint from the equation — With AppStream, the application runs on AWS-managed instances you fully control. The external user’s device is just a screen receiving pixels — no data reaches the endpoint, no agent to install, no posture to enforce.
• Hybrid beats single-vendor purity — Using Verified Access for internal users (identity + device posture) and AppStream for external users (streamed access) gives you the right security model for each user type. The routing decision is simple and happens at the IdP layer.

Try it now:

1. Test Verified Access with a web app — Follow the Verified Access getting started guide to set up an HTTP endpoint fronting an ALB with a simple web application. Configure trust provider integration with your IdP.
2. Deploy an AppStream 2.0 fleet with SAP GUI — Use the AppStream deployment guide to create a small on-demand fleet, install SAP GUI (or any thick-client app), and test streaming access through a browser. Configure DLP controls (clipboard, file transfer) to validate data protection.
3. Map your external user requirements — List all external users (contractors, partners, auditors) and the applications they need access to. Identify which are web-based (Verified Access candidates) vs. thick-client (AppStream candidates) to size your hybrid architecture.