[ZT] ZTWA learning path updates (phase 1)

public/__redirects

@@ -716,7 +716,10 @@
 /learning-paths/cybersafe/concepts/what-is-area1/ /learning-paths/cybersafe/concepts/what-is-email-security/ 301
 /learning-paths/cybersafe/area1-onboarding/ /learning-paths/cybersafe/email-security-onboarding/ 301
 
-
+## zero-trust-web access / clientless-access
+/learning-paths/zero-trust-web-access/concepts/reverse-proxy-server/ https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/ 301
+/zero-trust-web-access/concepts/zero-trust/ https://www.cloudflare.com/learning/security/glossary/what-is-zero-trust/ 301
+/learning-paths/zero-trust-web-access/concepts/zero-trust-web-access/ /learning-paths/clientless-access/concepts/what-is-clientless-access/ 301
 
 ## dns-filtering / secure-internet-traffic
 /learning-paths/dns-filtering/ /learning-paths/secure-internet-traffic/ 301
@@ -743,7 +746,7 @@
 /learning-paths/secure-internet-traffic/ /learning-paths/secure-internet-traffic/concepts/ 301
 /learning-paths/secure-o365-email/ /learning-paths/secure-o365-email/concepts/ 301
 /learning-paths/workers/ /learning-paths/workers/concepts/ 301
-/learning-paths/zero-trust-web-access/ /learning-paths/zero-trust-web-access/concepts/ 301
+/learning-paths/clientless-access/ /learning-paths/clientless-access/concepts/ 301
 /learning-paths/application-security/default-traffic-security/security-level/ /learning-paths/application-security/default-traffic-security/browser-integrity/ 301
 
 # more redirects in the /dynamic/ section
@@ -1899,6 +1902,8 @@
 /learning-paths/dns-filtering/create-policy/* /learning-paths/secure-internet-traffic/build-dns-policies/:splat 301
 ## Secure your Internet Traffic
 /learning-paths/secure-internet-traffic/connect-devices/* /learning-paths/secure-internet-traffic/connect-devices-networks/:splat 301
+## Zero Trust Web Access --> Clientless Access
+/learning-paths/zero-trust-web-access/* /learning-paths/clientless-access/:splat 301
 
 # Cloudflare for SaaS
 /ssl/ssl-for-saas/common-tasks/* /cloudflare-for-platforms/cloudflare-for-saas/ 301

src/content/docs/cloudflare-one/implementation-guides/clientless-access.mdx

@@ -0,0 +1,7 @@
+---
+pcx_content_type: navigation
+title: Deploy clientless access
+external_link: /learning-paths/clientless-access/concepts/
+sidebar:
+  order: 3
+---

src/content/docs/cloudflare-one/implementation-guides/index.mdx

@@ -31,8 +31,8 @@ Implementation guides cover deployment steps and best practices for specific Clo
 </LinkTitleCard>
 
 <LinkTitleCard
-	title="Deploy Zero Trust Web Access"
-	href="/learning-paths/zero-trust-web-access/concepts/"
+	title="Deploy clientless access"
+	href="/learning-paths/clientless-access/concepts/"
 	icon="laptop"
 >
 	Secure access to internal web applications without a device client.

src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx → src/content/docs/learning-paths/clientless-access/access-application/best-practices.mdx

@@ -20,6 +20,6 @@ Access applications have an inherently flexible and powerful domain structure ca
 
 ### Multiple domains in an application
 
-Many customers who have workflows designed around internal web applications, especially those that were built internally, often see challenges related to interdependencies on multiple internal services. Separately, there can be challenges related to SPAs (Single-Page Applications) that make onboarding to a Zero Trust Web Access service difficult. For example, an application may have iFrames or other embedded systems that rely on different internal and/or external addresses.
+Many customers who have workflows designed around internal web applications, especially those that were built internally, often see challenges related to interdependencies on multiple internal services. Separately, there can be challenges related to SPAs (Single-Page Applications) that make deploying clientless access difficult. For example, an application may have iFrames or other embedded systems that rely on different internal and/or external addresses.
 
-If your internal service operates in this way, we recommend specifying multiple top-level domains in a single Access application. Otherwise, if the goal of using multiple domains is to streamline or simplify policy creation, we recommend making one primary domain per application, and automating the rest of your deployment [using Terraform](/learning-paths/zero-trust-web-access/terraform/) or another Infrastructure as Code (IaC) service.
+If your internal service operates in this way, we recommend specifying multiple top-level domains in a single Access application. Otherwise, if the goal of using multiple domains is to streamline or simplify policy creation, we recommend making one primary domain per application, and automating the rest of your deployment [using Terraform](/learning-paths/clientless-access/terraform/) or another Infrastructure as Code (IaC) service.

src/content/docs/learning-paths/zero-trust-web-access/access-application/index.mdx → src/content/docs/learning-paths/clientless-access/access-application/index.mdx

@@ -6,7 +6,7 @@ sidebar:
 
 ---
 
-Now that you have [connected your private applications](/learning-paths/zero-trust-web-access/connect-private-applications/) to Cloudflare, secure those applications behind Cloudflare Access.
+Now that you have [connected your private applications](/learning-paths/clientless-access/connect-private-applications/) to Cloudflare, secure those applications behind Cloudflare Access.
 
 ## Objectives
 

src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/index.mdx → src/content/docs/learning-paths/clientless-access/advanced-workflows/index.mdx

@@ -1,5 +1,5 @@
 ---
-title: Advanced ZTWA workflows
+title: Advanced workflows
 pcx_content_type: overview
 sidebar:
   order: 7

src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/isolate-application.mdx → src/content/docs/learning-paths/clientless-access/advanced-workflows/isolate-application.mdx

@@ -230,7 +230,7 @@ Requires Data Loss Prevention add-on.
 
 Block users on unmanaged devices from downloading files that contain credit card numbers. This logic requires two policies:
 
-- **Policy 1: [Disable file downloads in isolated browser](/learning-paths/zero-trust-web-access/advanced-workflows/isolate-application/#disable-file-downloads-in-isolated-browser)**
+- **Policy 1: [Disable file downloads in isolated browser](/learning-paths/clientless-access/advanced-workflows/isolate-application/#disable-file-downloads-in-isolated-browser)**
 
 - **Policy 2: Block credit card numbers**
 

src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/clientless-rbi.mdx → src/content/docs/learning-paths/clientless-access/alternative-onramps/clientless-rbi.mdx

@@ -19,10 +19,10 @@ After the user authenticates to your IdP, Cloudflare will load the application i
 
 ## Setup
 
-To configure Clientless Web Isolation for Zero Trust Web Access, refer to [this tutorial](/cloudflare-one/tutorials/clientless-access-private-dns/).
+To configure Clientless Web Isolation to augment clientless access, refer to [this tutorial](/cloudflare-one/tutorials/clientless-access-private-dns/).
 
 ## Best practices
 
 * For guidance on building Gateway policies for private network applications, refer to [Secure your first application](/learning-paths/replace-vpn/build-policies/create-policy/).
 * If you already deployed the WARP client to some devices as part of a mixed-access methodology, ensure that your Gateway firewall policies do not rely on device posture checks. Because Clientless Web Isolation is not a machine in your fleet, it will not return any values for device posture checks.
-* You can standardize the user experience by making specific applications available in your App Launcher as [bookmarks](/learning-paths/zero-trust-web-access/customize-ux/bookmarks/). In this case, you would create a new bookmark for `https://<team-name>.cloudflareaccess.com/browser/https://internalresource.com`, which would take users directly to an isolated session with your application.
+* You can standardize the user experience by making specific applications available in your App Launcher as [bookmarks](/learning-paths/clientless-access/customize-ux/bookmarks/). In this case, you would create a new bookmark for `https://<team-name>.cloudflareaccess.com/browser/https://internalresource.com`, which would take users directly to an isolated session with your application.

src/content/docs/learning-paths/clientless-access/alternative-onramps/index.mdx

@@ -0,0 +1,15 @@
+---
+title: Alternative on-ramps
+pcx_content_type: overview
+sidebar:
+  order: 8
+
+---
+
+As discussed in the previous modules, almost everything you do with the Cloudflare reverse proxy requires [adding a site](/learning-paths/clientless-access/initial-setup/add-site/) to Cloudflare. That public DNS record (or its subdomains) becomes the domain on which your users access your private applications. This method is exceptionally secure and transparent; each domain and subdomain has access to the Cloudflare web security portfolio, are inherently DDoS protected, and receive an obfuscated origin IP. For these reasons, [public hostname routing](/learning-paths/clientless-access/connect-private-applications/) is the recommended method to onboard applications for clientless user access.  However, there may be times in which a public DNS record cannot be created, or other situations that prevent administrators from using this method.
+
+## Objectives
+
+By the end of this module, you will be able to:
+
+* Connect to private web applications using their private hostnames.

src/content/docs/learning-paths/clientless-access/concepts/index.mdx

@@ -0,0 +1,15 @@
+---
+title: Concepts
+pcx_content_type: overview
+sidebar:
+  order: 1
+
+---
+
+Review the concepts behind clientless access.
+
+## Objectives
+
+By the end of this module, you will be able to:
+
+- Understand the purpose and benefits of clientless access.

src/content/docs/learning-paths/clientless-access/concepts/what-is-clientless-access.mdx

@@ -0,0 +1,33 @@
+---
+title: What is clientless access?
+pcx_content_type: overview
+sidebar:
+  order: 1
+
+---
+
+Clientless access is a deployment option of a [Zero Trust Network Access (ZTNA)](https://www.cloudflare.com/learning/access-management/what-is-ztna/) service that provides secure access to internal applications without requiring end users to install any software. Users access corporate resources like intranet web apps, SSH terminals, and Windows servers through RDP from their web browser. Clientless access is commonly used to provide internal, [least-privilege access](https://www.cloudflare.com/learning/access-management/principle-of-least-privilege/) to users on unmanaged devices. Users may include third-party contractors, suppliers, and partners, or employees using personal mobile phones as part of an organization's bring-your-own-device (BYOD) policy.
+
+IT/security admins can decide how users authenticate, whether through their corporate identity provider, social media accounts, a PIN sent to their email, strong MFA, or a combination of options. Admins can also add inline services like Remote Browser Isolation (RBI) and Data Loss Prevention (DLP) to help prevent data exfiltration from unmanaged devices, still through a clientless implementation. Isolated apps can enforce broad data controls through the browser, such as  preventing uploads/downloads or copy/paste, or incorporating DLP policies.
+
+## Alternatives to clientless access
+
+### Device client
+
+A device client enables additional capabilities for a ZTNA deployment, like adding full device posture checks to policy evaluations or providing access to private network resources on private hostnames. However, when extending access to third-party or temporary workers, some organizations are reluctant to buy and ship company-managed devices or onboard clients to users' personal devices. Some IT or security teams may have rigorous device compatibility, interoperability, or other software audit processes that could delay user onboarding for a ZTNA rollout. Contractors may also not allow external company software to be installed on their personal devices, whether a legacy VPN or a more modern software client.
+
+### Identity provider workarounds
+
+Some organizations historically have created corporate identities for third-party users within their internal identity provider, or they have spent the time to integrate a third-party's external identity provider with their own. Time and complexity for this work aside, not all resources integrate directly with traditional identity and access management (IAM) products, so a tool like ZTNA can still be needed to aggregate access logistics more broadly across an organization's internal resources.
+
+### Enterprise browsers
+
+Enterprise browsers are another tool sparking interest in the industry for hybrid work and internal access use cases. They aim to consolidate security features and provide similar unified access and data protection to resources, all through a managed browser. However, some users may not want to disrupt their preferred workflows through their existing browser(s), and some third parties may still not wish to install any external software including the managed browser.
+
+## Why Cloudflare for clientless access
+
+One of the biggest challenges in delivering clientless, secure remote access is making it feel native for your end users. Solutions have existed for decades which operate in a way that breaks TLS on a firewall or creates a picture-in-a-picture to access an internal web service. These legacy solutions make it very difficult to apply traditional web security concepts to private apps.
+
+In contrast, Cloudflare is a leading [reverse proxy](https://www.cloudflare.com/learning/cdn/glossary/reverse-proxy/) provider for public-facing web assets, proxying approximately [20% of all websites](https://w3techs.com/technologies/overview/proxy). Together with our [SASE platform](/reference-architecture/architectures/sase/), this establishes a unique position for Cloudflare to deliver performant browser-based security for both public and private resources. There is no additional overhead in implementation, management, ongoing updates, or routing.
+
+Clientless access accelerates user onboarding for your admins, and it makes private apps feel just like SaaS apps for your end users. Many organizations roll out clientless access use cases toward the start of their larger SASE architecture journey as a “quick win” to develop momentum for a longer [VPN replacement](/learning-paths/replace-vpn/concepts/) project or security modernization initiative.

src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/best-practices.mdx → src/content/docs/learning-paths/clientless-access/connect-private-applications/best-practices.mdx

@@ -6,7 +6,7 @@ sidebar:
 
 ---
 
-We recommend following these best practices when you deploy Cloudflare Tunnel for Zero Trust Web Access.
+We recommend following these best practices when you deploy Cloudflare Tunnel for clientless access.
 
 ## Deploy another instance of cloudflared
 

src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/create-tunnel.mdx → src/content/docs/learning-paths/clientless-access/connect-private-applications/create-tunnel.mdx

@@ -24,7 +24,7 @@ To add a public hostname route to the tunnel:
 
 <Render file="tunnel/add-public-hostname" product="cloudflare-one" />
 
-All users on the Internet can now connect to this application via its public hostname. In [Module 4: Secure your applications](/learning-paths/zero-trust-web-access/access-application/), we will discuss how to restrict access to authorized users.
+All users on the Internet can now connect to this application via its public hostname. In [Module 4: Secure your applications](/learning-paths/clientless-access/access-application/), we will discuss how to restrict access to authorized users.
 
 :::note
 

src/content/docs/learning-paths/zero-trust-web-access/initial-setup/add-site.mdx → src/content/docs/learning-paths/clientless-access/initial-setup/add-site.mdx

@@ -8,7 +8,7 @@ sidebar:
 
 import { Render } from "~/components"
 
-In clientless ZTWA deployments, users connect to internal applications via public hostnames. You will need to own a domain, add it to Cloudflare, and configure Cloudflare as the [authoritative DNS provider](/dns/zone-setups/full-setup/setup/#update-your-nameservers) for that domain. Enterprise customers who cannot change their authoritative DNS provider have the option to configure a [partial (`CNAME`) setup](/dns/zone-setups/partial-setup/).
+In clientless access deployments, users connect to internal applications via public hostnames. You will need to own a domain, add it to Cloudflare, and configure Cloudflare as the [authoritative DNS provider](/dns/zone-setups/full-setup/setup/#update-your-nameservers) for that domain. Enterprise customers who cannot change their authoritative DNS provider have the option to configure a [partial (`CNAME`) setup](/dns/zone-setups/partial-setup/).
 
 You only need to add one domain to Cloudflare, since you can create an infinite number of subdomains to manage all of your private applications.
 
@@ -31,4 +31,4 @@ You only need to add one domain to Cloudflare, since you can create an infinite
 6. <Render file="update-nameservers" product="fundamentals" />
 7. (Optional) Follow the **Quick Start Guide** to configure security and performance settings.
 
-Registrars can take up to 24 hours to process nameserver changes. Your domain must be in an **Active** status before you can use it for Zero Trust Web Access.
+Registrars can take up to 24 hours to process nameserver changes. Your domain must be in an **Active** status before you can use it for clientless access.

src/content/docs/learning-paths/clientless-access/initial-setup/index.mdx

@@ -0,0 +1,20 @@
+---
+title: Initial setup
+pcx_content_type: overview
+sidebar:
+  order: 2
+
+---
+
+In this guide, you will learn how to deliver clientless access using the Cloudflare Zero Trust suite of products. This guide will focus on browser-based applications that do not require users to install a device client of any kind. It will discuss both common and complex scenarios, and should give you the tools to provide secure user access to internal web applications following a [Zero Trust model](https://www.cloudflare.com/learning/security/glossary/what-is-zero-trust/).
+
+If you need to deliver access to non-browser based applications, refer to our complementary guide for [replacing your VPN](/learning-paths/clientless-access/concepts/).
+
+## Objectives
+
+By the end of this module, you will be able to:
+
+* Set up a Cloudflare account.
+* Add your domain to Cloudflare.
+* Create a Zero Trust organization to manage applications and policies.
+* Configure an identity provider (IdP) for user authentication.