replace instances of ZTWA

ranbel · ranbel · commit 5aceb70516ed · 2025-04-09T15:18:58.000-04:00
diff --git a/src/content/docs/cloudflare-one/implementation-guides/index.mdx b/src/content/docs/cloudflare-one/implementation-guides/index.mdx
@@ -31,7 +31,7 @@ Implementation guides cover deployment steps and best practices for specific Clo
 </LinkTitleCard>
 
 <LinkTitleCard
-	title="Deploy Clientless Access"
+	title="Deploy clientless access"
 	href="/learning-paths/zero-trust-web-access/concepts/"
 	icon="laptop"
 >
diff --git a/src/content/docs/cloudflare-one/implementation-guides/zero-trust-web-access.mdx b/src/content/docs/cloudflare-one/implementation-guides/zero-trust-web-access.mdx
@@ -1,6 +1,6 @@
 ---
 pcx_content_type: navigation
-title: Deploy Clientless Access
+title: Deploy clientless access
 external_link: /learning-paths/zero-trust-web-access/concepts/
 sidebar:
   order: 3
diff --git a/src/content/docs/learning-paths/replace-vpn/get-started/index.mdx b/src/content/docs/learning-paths/replace-vpn/get-started/index.mdx
@@ -16,7 +16,7 @@ This guide will highlight best practices to follow and other decisions to consid
 
 :::note
 
-This learning path focuses on client-based remote access to internal services. If you are looking for clientless or Zero Trust Web Access functionality, refer to our [Deploy Zero Trust Web Access](/learning-paths/zero-trust-web-access/concepts/) learning path.
+This learning path focuses on client-based remote access to internal services. If you are looking for clientless or browser-based functionality, refer to our [Deploy clientless access](/learning-paths/zero-trust-web-access/concepts/) learning path.
 :::
 
 ## Objectives
diff --git a/src/content/docs/learning-paths/secure-internet-traffic/build-http-policies/browser-isolation.mdx b/src/content/docs/learning-paths/secure-internet-traffic/build-http-policies/browser-isolation.mdx
@@ -9,7 +9,7 @@ import { GlossaryDefinition, TabItem, Tabs } from "~/components";
 
 <GlossaryDefinition term="Cloudflare Browser Isolation" />
 
-Browser Isolation provides unique and transparent protection for your users using methods that surpass the capabilities of a traditional secure web gateway. This section focuses primarily on Browser Isolation for external services, assuming that most traffic from a device or a network is being forwarded to Cloudflare. For other applications of Browser Isolation, refer to the [Zero Trust Web Access (ZTWA) learning path](/learning-paths/zero-trust-web-access/concepts/).
+Browser Isolation provides unique and transparent protection for your users using methods that surpass the capabilities of a traditional secure web gateway. This section focuses primarily on Browser Isolation for external services, assuming that most traffic from a device or a network is being forwarded to Cloudflare. For other applications of Browser Isolation, refer to the [Deploy clientless access](/learning-paths/zero-trust-web-access/concepts/) guide.
 
 As a note, Cloudflare's Browser Isolation technology was built to be used for 100% of your user's daily browsing. These recommendations do not suggest that you should limit or be cautious with your use of Browser Isolation, but instead help identify practical outcomes that balance technology with actualized security benefits.
 
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/access-application/best-practices.mdx b/src/content/docs/learning-paths/zero-trust-web-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.
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/index.mdx b/src/content/docs/learning-paths/zero-trust-web-access/advanced-workflows/index.mdx
@@ -1,5 +1,5 @@
 ---
-title: Advanced ZTWA workflows
+title: Advanced workflows
 pcx_content_type: overview
 sidebar:
   order: 7
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/clientless-rbi.mdx b/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/clientless-rbi.mdx
@@ -19,7 +19,7 @@ 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
 
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/index.mdx b/src/content/docs/learning-paths/zero-trust-web-access/alternative-onramps/index.mdx
@@ -1,5 +1,5 @@
 ---
-title: Alternative ZTWA on-ramps
+title: Alternative on-ramps
 pcx_content_type: overview
 sidebar:
   order: 8
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/connect-private-applications/best-practices.mdx b/src/content/docs/learning-paths/zero-trust-web-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
 
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/add-site.mdx b/src/content/docs/learning-paths/zero-trust-web-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.
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/index.mdx b/src/content/docs/learning-paths/zero-trust-web-access/initial-setup/index.mdx
@@ -6,7 +6,7 @@ sidebar:
 
 ---
 
-In this guide, you will learn how to deliver Zero Trust Web 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/).
+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/zero-trust-web-access/concepts/).
 
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/index.mdx b/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/index.mdx
@@ -10,7 +10,7 @@ Publish internal applications that users currently access from a traditional cor
 
 :::note
 
-The remaining modules (Modules 6-9) discuss special considerations and setup options for enterprise environments. If you are only looking to configure a basic ZTWA setup, feel free to skip them.
+The remaining modules (Modules 6-9) discuss special considerations and setup options for enterprise environments. If you are only looking to configure a basic clientless access setup, feel free to skip them.
 :::
 
 ## Objectives
diff --git a/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso.mdx b/src/content/docs/learning-paths/zero-trust-web-access/migrate-applications/integrated-sso.mdx
@@ -6,7 +6,7 @@ sidebar:
 
 ---
 
-Many organizations in the past few years have recognized the importance of source-of-truth identity and have directly integrated their SSO provider with their internal applications. The SSO provider is only aware of the internal domain on which the application exists (via the configured ACS URL), which means the user must be connected to the local network in order to access the application. This security architecture makes sense for a traditional network perimeter, but it presents challenges for Zero Trust adoption. In the ZTWA model, the user's device has no concept of an internal corporate network, only the specific, scoped applications to which they have access. The problem is summarized in the following diagram:
+Many organizations in the past few years have recognized the importance of source-of-truth identity and have directly integrated their SSO provider with their internal applications. The SSO provider is only aware of the internal domain on which the application exists (via the configured ACS URL), which means the user must be connected to the local network in order to access the application. This security architecture makes sense for a traditional network perimeter, but it presents challenges for Zero Trust adoption. In the clientless access model, the user's device has no concept of an internal corporate network, only the specific, scoped applications to which they have access. The problem is summarized in the following diagram:
 
 ```mermaid
 flowchart LR
diff --git a/src/content/docs/reference-architecture/by-solution.mdx b/src/content/docs/reference-architecture/by-solution.mdx
@@ -59,7 +59,7 @@ Architecture documentation related to using Cloudflare for Zero Trust, SSE and S
 
 - [Secure your Internet traffic and SaaS apps](/learning-paths/secure-internet-traffic/concepts/)
 - [Replace your VPN](/learning-paths/replace-vpn/concepts/)
-- [Deploy Zero Trust Web Access](/learning-paths/zero-trust-web-access/concepts/)
+- [Deploy clientless access](/learning-paths/zero-trust-web-access/concepts/)
 - [Secure Microsoft 365 email with Email Security](/learning-paths/secure-o365-email/concepts/)
 
 ### Networking
diff --git a/src/content/docs/reference-architecture/implementation-guides/zero-trust/ztna-web-access.mdx b/src/content/docs/reference-architecture/implementation-guides/zero-trust/ztna-web-access.mdx
@@ -1,6 +1,6 @@
 ---
 pcx_content_type: navigation
-title: Deploy Zero Trust Web Access
+title: Deploy clientless access
 external_link: /learning-paths/zero-trust-web-access/concepts/
 sidebar:
   order: 3
diff --git a/src/content/learning-paths/zero-trust-web-access.json b/src/content/learning-paths/zero-trust-web-access.json
@@ -1,5 +1,5 @@
 {
-	"title": "Deploy Clientless Access",
+	"title": "Deploy clientless access",
 	"path": "/learning-paths/zero-trust-web-access/concepts/",
 	"priority": 2,
 	"description": "Secure access to internal web applications without a device client.",

Original file line number	Diff line number	Diff line change
`@@ -31,7 +31,7 @@ Implementation guides cover deployment steps and best practices for specific Clo`
`31`	`31`	`</LinkTitleCard>`
`32`	`32`
`33`	`33`	`<LinkTitleCard`
`34`		`- title="Deploy Clientless Access"`
	`34`	`+ title="Deploy clientless access"`
`35`	`35`	`href="/learning-paths/zero-trust-web-access/concepts/"`
`36`	`36`	`icon="laptop"`
`37`	`37`	`>`