diff --git a/src/content/docs/dns/proxy-status/use-cases.mdx b/src/content/docs/dns/proxy-status/use-cases.mdx
index 280523c48c7..c952e4d05d0 100644
--- a/src/content/docs/dns/proxy-status/use-cases.mdx
+++ b/src/content/docs/dns/proxy-status/use-cases.mdx
@@ -26,10 +26,12 @@ When traffic is proxied through Cloudflare, the following behaviors apply. You m
 
 ### Source IP changes
 
-Your origin server sees Cloudflare IP addresses as the source of all requests instead of the end-user's IP address. Applications that rely on the source IP for authentication, rate limiting, or geolocation will not function as expected without additional configuration.
+Your origin server sees Cloudflare IP addresses as the source of all requests instead of the end-user's IP address. Applications that use source IPs for access restrictions, rate limiting, or geolocation need additional configuration.
 
 Cloudflare includes the original visitor IP address in the [`CF-Connecting-IP`](/fundamentals/reference/http-headers/) and `X-Forwarded-For` request headers. Configure your origin server to read the visitor IP from these headers. For more information, refer to [Restoring original visitor IPs](/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips/).
 
+Do not use these headers as proof of a user's or client's identity. Before using their values for IP-based access restrictions or rate limiting, [authenticate traffic reaching your origin](/fundamentals/reference/http-headers/#trust-visitor-ip-headers). Allowlisting Cloudflare IP ranges alone does not identify your zone. [Worker subrequests](/fundamentals/reference/http-headers/#cf-connecting-ip-in-worker-subrequests) can also change visitor IP header values, depending on their destination.
+
 ### Client certificate (mTLS) validation
 
 When a record is proxied, TLS terminates at Cloudflare's global network. Cloudflare establishes a separate TLS connection to your origin server. This means the origin never receives the end-user's client certificate during the TLS handshake. You can achieve mTLS through the following:
diff --git a/src/content/docs/fundamentals/concepts/cloudflare-ip-addresses.mdx b/src/content/docs/fundamentals/concepts/cloudflare-ip-addresses.mdx
index a33c727c198..1a84ebdc799 100644
--- a/src/content/docs/fundamentals/concepts/cloudflare-ip-addresses.mdx
+++ b/src/content/docs/fundamentals/concepts/cloudflare-ip-addresses.mdx
@@ -50,7 +50,9 @@ For more specific guidance, contact your hosting provider or website administrat
 
 ### Block other IP addresses (recommended)
 
-If someone discovers your origin server's IP address — for example, through historical DNS records or mail server configuration — they could send traffic directly to your server, bypassing Cloudflare's security protections entirely. To prevent this, block all traffic that does not come from Cloudflare IP addresses or the IP addresses of your trusted partners, vendors, or applications.
+If someone discovers your origin server's IP address — for example, through historical DNS records or mail server configuration — they could send traffic directly to your server, bypassing Cloudflare's security protections entirely. To restrict direct access, block all traffic that does not come from Cloudflare IP addresses or the IP addresses of your trusted partners, vendors, or applications.
+
+Cloudflare IP ranges are shared across customers. Allowlisting them does not prove that a request passed through your zone or its security rules. Combine this network filter with [origin authentication](/fundamentals/reference/http-headers/#trust-visitor-ip-headers), especially before trusting visitor IP headers for security decisions.
 
 For example, you might [update your iptables](https://www.linode.com/docs/guides/control-network-traffic-with-iptables/#block-or-allow-traffic-by-port-number-to-create-an-iptables-firewall) with the following commands:
 
diff --git a/src/content/docs/fundamentals/reference/http-headers.mdx b/src/content/docs/fundamentals/reference/http-headers.mdx
index ae6f33a90b1..111673eba57 100644
--- a/src/content/docs/fundamentals/reference/http-headers.mdx
+++ b/src/content/docs/fundamentals/reference/http-headers.mdx
@@ -22,8 +22,7 @@ For incoming requests, the value of this header will always be set to `accept-en
 
 ### CF-Connecting-IP
 
-`CF-Connecting-IP` provides the client IP address connecting to Cloudflare to the origin web server.
-This header will only be sent on the traffic from Cloudflare's edge to your origin web server.
+`CF-Connecting-IP` provides the client IP address connecting to Cloudflare to the origin web server. For requests made by Workers, the value depends on the subrequest destination. Refer to [CF-Connecting-IP in Worker subrequests](#cf-connecting-ip-in-worker-subrequests).
 
 For guidance on logging your visitor's original IP address, refer to [Restoring original visitor IPs](/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips/).
 
@@ -35,12 +34,26 @@ In same-zone Worker subrequests, the value of `CF-Connecting-IP` reflects the va
 
 In cross-zone subrequests from one Cloudflare zone to another Cloudflare zone, the `CF-Connecting-IP` value will be set to the Worker client IP address `'2a06:98c0:3600::103'` for security reasons.
 
-For Worker subrequests destined for a non-Cloudflare customer zone, the Worker script controls the client IP headers: both `CF-Connecting-IP` and `x-real-ip` can be altered by the Worker. If the subrequest forwards the original request's headers unchanged, both headers reflect the client's IP address.
-
-To authenticate that traffic originates from your own zone, use zone-level or per-hostname [Authenticated Origin Pulls](/ssl/origin-configuration/authenticated-origin-pull/) with your own certificate, or [Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/).
+For Worker subrequests to destinations not proxied by Cloudflare, the Worker can set or overwrite `CF-Connecting-IP`. The destination can therefore receive a value chosen by the Worker. `x-real-ip` is an internal Cloudflare header and is stripped before delivery to these destinations.
 
 When no Worker subrequest is triggered, `cf-connecting-ip` reflects the client's IP address and the `x-real-ip` header is stripped.
 
+#### Trust visitor IP headers
+
+:::caution[Protect the Cloudflare-to-origin connection]
+Visitor IP headers are not authentication credentials for users or clients. An IP address can be shared by multiple users.
+
+A connection from a [Cloudflare IP address](/fundamentals/concepts/cloudflare-ip-addresses/) does not prove that a request passed through your zone or its security rules. Cloudflare IP ranges are shared across customers.
+
+Before using `CF-Connecting-IP`, `True-Client-IP`, or `X-Forwarded-For` for IP-based access restrictions or rate limiting, authenticate the Cloudflare-to-origin connection.
+
+For public HTTPS origins, we recommend mutual TLS (mTLS) using [zone-level](/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/) or [per-hostname Authenticated Origin Pulls](/ssl/origin-configuration/authenticated-origin-pull/set-up/per-hostname/). Use a certificate dedicated to your zone or hostname, and configure your origin to require and verify client certificates. Reject requests with missing or untrusted certificates. Global AOP uses a shared certificate and does not identify your zone.
+
+Alternatively, use [Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/) and block direct public access to your origin.
+
+Your own Workers must also preserve or set visitor IP headers according to your application's trust requirements.
+:::
+
 ### CF-Connecting-IPv6
 
 Cloudflare provides [free IPv6 support](/network/ipv6-compatibility/) to all domains without requiring additional configuration or hardware. To support migrating to IPv6, Cloudflare's [Pseudo IPv4](/network/pseudo-ipv4/) provides an IPv6 to IPv4 translation service for all Cloudflare domains.
@@ -61,6 +74,8 @@ If [Pseudo IPv4](/network/pseudo-ipv4/) is set to `Add Header` - Cloudflare auto
 
 There is no difference between the `True-Client-IP` and `CF-Connecting-IP` headers besides the name of the header. Some Enterprise customers with legacy devices need `True-Client-IP` to avoid updating firewalls or load-balancers to read a custom header name.
 
+`True-Client-IP` does not provide additional authentication. The same [visitor IP header trust requirements](#trust-visitor-ip-headers) apply.
+
 To add a `True-Client-IP` HTTP header to requests, [enable the **Add "True-Client-IP" header** Managed Transform](/rules/transform/managed-transforms/configure/).
 
 Alternatively, if you do not wish to receive the `True-Client-IP` header or any HTTP header that may contain the visitor's IP address, [enable the **Remove visitor IP headers** Managed Transform](/rules/transform/managed-transforms/configure/).
@@ -83,6 +98,8 @@ Using the previous example where a request was proxied twice (proxies A and B) b
 
 :::note
 To restore the original visitor IP address at your origin web server, Cloudflare recommends that your logs or applications look at `CF-Connecting-IP` or `True-Client-IP` instead of `X-Forwarded-For`. `CF-Connecting-IP` and `True-Client-IP` both have a consistent format containing only one IP address.
+
+Before relying on these values for security decisions, follow the [visitor IP header trust requirements](#trust-visitor-ip-headers).
 :::
 
 ### X-Forwarded-Proto
diff --git a/src/content/docs/network/true-client-ip-header.mdx b/src/content/docs/network/true-client-ip-header.mdx
index 4222a14cb97..79cec5264b9 100644
--- a/src/content/docs/network/true-client-ip-header.mdx
+++ b/src/content/docs/network/true-client-ip-header.mdx
@@ -9,6 +9,8 @@ products:
 
 Enabling the True-Client-IP Header adds the [`True-Client-IP` header](/fundamentals/reference/http-headers/#true-client-ip-enterprise-plan-only) to all requests to your origin server, which includes the end user's IP address.
 
+Do not use `True-Client-IP` to authenticate users or clients. Follow the [visitor IP header trust requirements](/fundamentals/reference/http-headers/#trust-visitor-ip-headers) before using its value for IP-based access restrictions or rate limiting.
+
 ## Availability
 
 |  | Free | Pro | Business | Enterprise |
@@ -20,7 +22,7 @@ Enabling the True-Client-IP Header adds the [`True-Client-IP` header](/fundament
 The recommended procedure to access client IP information is to [enable the **Add "True-Client-IP" header** Managed Transform](/rules/transform/managed-transforms/reference/#add-true-client-ip-header).
 
 :::note
-To use this data, you will need to then retrieve it from the [`True-Client-IP` header](/fundamentals/reference/http-headers/#cf-ipcountry).
+To use this data, you will need to then retrieve it from the [`True-Client-IP` header](/fundamentals/reference/http-headers/#true-client-ip-enterprise-plan-only).
 :::
 
 ## Additional resources
diff --git a/src/content/docs/rules/transform/request-header-modification/index.mdx b/src/content/docs/rules/transform/request-header-modification/index.mdx
index c85401eefc9..449dc3f07f3 100644
--- a/src/content/docs/rules/transform/request-header-modification/index.mdx
+++ b/src/content/docs/rules/transform/request-header-modification/index.mdx
@@ -59,7 +59,9 @@ You can create a request header transform rule [in the dashboard](/rules/transfo
 
 - Due to protocol compliance reasons, modifying or removing request headers with [forbidden header names](https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name) (such as `Accept-Encoding`) is generally not allowed in Request Header Transform Rules.
 
-- You cannot modify the value of any header commonly used to identify the website visitor's IP address or initial protocol, such as `x-forwarded-for`, `true-client-ip`, `x-real-ip`, or `x-forwarded-proto`. If your origin needs a custom value in a header like `x-real-ip` on requests reaching your origin server, use [Cloudflare Snippets](/rules/snippets/) or [Cloudflare Workers](/workers/) and set the header on a `fetch()` subrequest. The value must be a syntactically valid IP address. This workaround does not work for cross-zone subrequests, where Cloudflare unconditionally replaces the value with an internal Cloudflare address to prevent IP spoofing.
+- You cannot modify the value of any header commonly used to identify the website visitor's IP address or initial protocol, such as `x-forwarded-for`, `true-client-ip`, `x-real-ip`, or `x-forwarded-proto`.
+
+- For custom visitor IP values in [Worker subrequests](/fundamentals/reference/http-headers/#cf-connecting-ip-in-worker-subrequests), behavior depends on the destination. In same-zone subrequests, setting `x-real-ip` to a valid IP address changes `CF-Connecting-IP`. Cross-zone subrequests to another Cloudflare zone use a fixed Worker IP address. For destinations not proxied by Cloudflare, a Worker can set `CF-Connecting-IP`, but `x-real-ip` is stripped before delivery.
 
 - Although you can remove the `x-forwarded-for` header in a Request Header Transform Rule, Cloudflare's backend proxy re-adds it (with the visitor's IP address) before the request reaches your origin server, because the proxy runs after all rule phases. The same applies to [Managed Transforms](/rules/transform/managed-transforms/). However, if the request is handled by Cloudflare Workers — which [run before the cache](/workers/reference/how-the-cache-works/) — the `x-forwarded-for` request header will be absent because the proxy has not yet re-added it.
 
diff --git a/src/content/docs/ssl/origin-configuration/authenticated-origin-pull/index.mdx b/src/content/docs/ssl/origin-configuration/authenticated-origin-pull/index.mdx
index 3fdb6ffe9f0..5258cd9e3ff 100644
--- a/src/content/docs/ssl/origin-configuration/authenticated-origin-pull/index.mdx
+++ b/src/content/docs/ssl/origin-configuration/authenticated-origin-pull/index.mdx
@@ -19,7 +19,13 @@ Authenticated Origin Pulls (AOP) helps ensure requests to your origin server com
 Authenticated Origin Pulls does not apply when your [SSL/TLS encryption mode](/ssl/origin-configuration/ssl-modes/) is set to **Off** or **Flexible**.
 :::
 
-Without AOP, anyone who discovers your origin server's IP address can send requests directly, bypassing Cloudflare and all its protections. When you combine AOP with the [Cloudflare Web Application Firewall (WAF)](/waf/), your origin only accepts requests that have passed through Cloudflare, which means every request is evaluated by the WAF before reaching your server.
+If your origin accepts unauthenticated public connections, anyone who discovers its IP address can send requests directly, bypassing Cloudflare and its protections. AOP lets your origin require a client certificate from Cloudflare.
+
+:::caution[Use your own certificate to identify your zone]
+For public HTTPS origins that rely on visitor IP headers for IP-based access restrictions or rate limiting, we recommend mutual TLS (mTLS) using zone-level or per-hostname AOP with [your own certificate](#when-to-use-your-own-certificate). Use a certificate dedicated to your zone or hostname, and configure your origin to require and verify client certificates. Reject requests with missing or untrusted certificates.
+
+Global AOP uses a certificate shared across Cloudflare accounts. When your origin validates it, it authenticates Cloudflare's network but does not identify your account or zone. Enabling AOP in Cloudflare alone does not enforce certificate validation at your origin.
+:::
 
 :::note[Not compatible with Cloudflare Tunnel]
 AOP is not compatible with origins connected through [Cloudflare Tunnel](/cloudflare-one/networks/connectors/cloudflare-tunnel/). Tunnel uses outbound-only connections from your origin, so there is no inbound listener for Cloudflare to present a client certificate to. If your origin is reachable through Cloudflare Tunnel, origin traffic is already authenticated using the tunnel's connector credentials, and AOP settings have no effect on that hostname.
@@ -48,7 +54,7 @@ AOP has three independent configuration levels. Each uses its own certificate an
 
 ## When to use your own certificate
 
-Global AOP uses a Cloudflare-provided certificate shared across all accounts, so it only proves a request came from the Cloudflare network — not from your account specifically. If you need to guarantee requests come from your account, set up [zone-level](/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/) or [per-hostname](/ssl/origin-configuration/authenticated-origin-pull/set-up/per-hostname/) AOP with your own certificate.
+Global AOP uses a Cloudflare-provided certificate shared across all accounts. Validating this certificate authenticates the Cloudflare network but does not identify your account or zone. To distinguish traffic for your zone or hostname, set up [zone-level](/ssl/origin-configuration/authenticated-origin-pull/set-up/zone-level/) or [per-hostname](/ssl/origin-configuration/authenticated-origin-pull/set-up/per-hostname/) AOP with a dedicated certificate, and enforce client certificate validation at your origin.
 
 Using your own certificate is also required for [FIPS](https://en.wikipedia.org/wiki/Federal_Information_Processing_Standards) compliance. For broader origin protection guidance, refer to [Protect your origin server](/fundamentals/security/protect-your-origin-server/).
 
diff --git a/src/content/docs/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips.mdx b/src/content/docs/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips.mdx
index dd9d3148e61..e9a196f855e 100644
--- a/src/content/docs/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips.mdx
+++ b/src/content/docs/support/troubleshooting/restoring-visitor-ips/restoring-original-visitor-ips.mdx
@@ -7,12 +7,20 @@ products:
   - support
 ---
 
-import { Render } from "~/components";
+import { Render, Steps } from "~/components";
 
 When your [website traffic is routed through the Cloudflare network](/fundamentals/concepts/how-cloudflare-works/), we act as a reverse proxy. This allows Cloudflare to speed up page load time by routing packets more efficiently and caching static resources (images, JavaScript, CSS, etc.). As a result, when responding to requests and logging them, your origin server returns a [Cloudflare IP address](https://www.cloudflare.com/ips/).
 
 For example, if you install applications that depend on the incoming IP address of the original visitor, a Cloudflare IP address is logged by default. The original visitor IP address appears in an appended HTTP header called [`CF-Connecting-IP`](/fundamentals/reference/http-headers/#cf-connecting-ip). By following our [web server instructions](#web-server-instructions), you can log the original visitor IP address at your origin server. If this HTTP header is not available when requests reach your origin server, check your [Transform Rules](/rules/transform/) and [Managed Transforms](/rules/transform/managed-transforms/) configuration.
 
+:::caution[Protect the Cloudflare-to-origin connection]
+The visitor IP restoration configurations restore IP values for logs and applications. They do not authenticate users or clients, or verify that traffic passed through your zone. Before using those values for IP-based access restrictions or rate limiting, follow the [visitor IP header trust requirements](/fundamentals/reference/http-headers/#trust-visitor-ip-headers).
+
+For public HTTPS origins, we recommend mutual TLS (mTLS) using [zone-level or per-hostname Authenticated Origin Pulls](/ssl/origin-configuration/authenticated-origin-pull/#when-to-use-your-own-certificate) with a certificate dedicated to your zone or hostname. Configure your origin to require and verify client certificates, rejecting requests with missing or untrusted certificates. Alternatively, use Cloudflare Tunnel with direct public access blocked.
+
+Allowlisting Cloudflare IP ranges or using global AOP alone does not identify your zone: both use credentials or infrastructure shared across customers. [Worker subrequests](/fundamentals/reference/http-headers/#cf-connecting-ip-in-worker-subrequests) can also change visitor IP header values, depending on the destination.
+:::
+
 :::note
 
 <Render file="pseudo-ipv4-warning" product="fundamentals" />
@@ -256,28 +264,27 @@ codebase](https://github.com/cloudflare/mod_cloudflare) from GitHub.
 
 ### Lighttpd
 
-To have Lighttpd automatically rewrite the server IP for the access logs and for your application, you can follow one of the two solutions below.
+Use `mod_extforward` to restore visitor IPs in Lighttpd. Use Lighttpd 1.4.70 or later when your proxy reuses HTTP/2 connections for different visitors, as described in the [Lighttpd documentation](https://redmine.lighttpd.net/projects/lighttpd/wiki/Mod_extforward).
 
-1. Open your **lighttpd.conf** file and add *mod_extforward* to the *server.modules* list. It must come **after** *mod_accesslog* to show the real IP in the access logs
-2. Add the following code block anywhere in the **lighttpd.conf** file after the server modules list and then restart Lighttpd
+<Steps>
 
-```
-$HTTP["remoteip"] == "192.2.0.1 (example IP address)"
-{
-extforward.forwarder = ( "all" => "trust" )
-extforward.headers = ("CF-Connecting-IP")
-}
-```
+1. Open `lighttpd.conf` and add `mod_extforward` to the `server.modules` list. Place it after `mod_accesslog` to restore visitor IPs in access logs.
 
-:::note
+2. Configure `extforward.forwarder` with all current [Cloudflare IPv4 and IPv6 ranges](https://www.cloudflare.com/ips/), and set `extforward.headers` to `CF-Connecting-IP`. The following example shows one range of each type. Add all remaining Cloudflare ranges before using it:
 
-If your origin connects to the Internet with IPv6,
-**$HTTP\["remoteip"]**, which is required for matching the remote IP
-ranges does not work when IPv6 is enabled. Using the above method will
-not work when trying to forward IP ranges. Add the following lines to
-lighttpd.conf as an alternative solution:
-`extforward.forwarder = ( "all" => "trust" ) extforward.headers = ("CF-Connecting-IP")`
-:::
+   ```txt
+   extforward.forwarder = (
+       "173.245.48.0/20" => "trust",
+       "2400:cb00::/32" => "trust"
+   )
+   extforward.headers = ("CF-Connecting-IP")
+   ```
+
+3. Restart Lighttpd after updating its configuration.
+
+</Steps>
+
+Do not use `"all" => "trust"` to work around IPv6 configuration issues. Trust only your configured proxy ranges and [authenticate the path to your origin](/fundamentals/reference/http-headers/#trust-visitor-ip-headers). For a complete example, refer to [Lighttpd's Cloudflare configuration guide](https://redmine.lighttpd.net/projects/lighttpd/wiki/Restoring_original_visitor_IPs_Logging_visitor_IP_addresses_with_mod_extforward).
 
 ### LiteSpeed server
 
@@ -432,7 +439,7 @@ An outside developer has created a module to restore visitor IP called [node_cl
 
 ### HAProxy
 
-In order to extract the original client IP in the X_FORWARDED_FOR header, you need to use the following configuration in HAProxy:
+After [authenticating traffic reaching your origin](/fundamentals/reference/http-headers/#trust-visitor-ip-headers), use the following HAProxy configuration to copy `CF-Connecting-IP` into `X-Forwarded-For`. The `from_cf` source IP check is an additional network filter and does not identify your zone:
 
 1. Create a text file `CF_ips.lst` containing all IP ranges from [https://www.cloudflare.com/en-gb/ips/](https://www.cloudflare.com/en-gb/ips/)
 2. Ensure to disable `option forwardfor` in HAProxy
@@ -456,13 +463,17 @@ clientIPDetection:
         failClosed: true
 ```
 
+`failClosed: true` rejects requests when the header is missing or does not contain a valid IP address. It does not authenticate the header's sender. [Authenticate traffic reaching your gateway](/fundamentals/reference/http-headers/#trust-visitor-ip-headers) before trusting this value.
+
 For more details, refer to [Custom header original IP detection extension](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/original_ip_detection/custom_header/v3/custom_header.proto).
 
 ### Caddy
 
 If you are running an application behind [Caddy](https://caddyserver.com/) that relies on the `X-Forwarded-For` header, you can configure Caddy to override the header with Cloudflare's [CF-Connecting-IP header](/fundamentals/reference/http-headers/#cf-connecting-ip).
 
-It is advised that you also only accept traffic from [Cloudflare's IP addresses](https://www.cloudflare.com/ips/); otherwise, the header could be spoofed. That's why, in the second example, we handle this as part of the Caddy configuration. Alternatively, you can handle this at the firewall level, which is usually easier to automate. If you already have a firewall or other measure in place to ensure this, your Caddyfile could look like this:
+Before using `CF-Connecting-IP` for IP-based access restrictions or rate limiting, [verify that requests reach your origin through your Cloudflare zone](/fundamentals/reference/http-headers/#trust-visitor-ip-headers). If you use Authenticated Origin Pulls (AOP), configure Caddy to [require and verify client certificates](https://caddyserver.com/docs/caddyfile/directives/tls) using a dedicated CA for your zone-level or per-hostname AOP certificate.
+
+For direct connections from Cloudflare to Caddy, also restrict incoming connections to [Cloudflare's IP addresses](https://www.cloudflare.com/ips/) as an additional network filter. Cloudflare IP ranges are shared, so this restriction alone does not prevent another Cloudflare customer from sending requests with a chosen `CF-Connecting-IP` value. With origin protection configured separately, your Caddyfile can copy the header as follows:
 ```txt title="Caddyfile"
 https://example.com {
     reverse_proxy localhost:8080 {
@@ -472,7 +483,7 @@ https://example.com {
 }
 ```
 
-If you want Caddy to handle only accepting traffic from [Cloudflare's IP addresses](https://www.cloudflare.com/ips/), you can use a configuration like this one:
+The following example adds the network filter in Caddy for direct connections from Cloudflare. These examples do not configure client certificate validation. The source IP matcher does not identify your account or zone:
 ```txt title="Caddyfile"
 https://example.com {
     # Restrict access to Cloudflare IPs (https://www.cloudflare.com/ips/)
diff --git a/src/content/docs/workers/runtime-apis/headers.mdx b/src/content/docs/workers/runtime-apis/headers.mdx
index 5fd387aafea..51315a94a92 100644
--- a/src/content/docs/workers/runtime-apis/headers.mdx
+++ b/src/content/docs/workers/runtime-apis/headers.mdx
@@ -68,7 +68,9 @@ Cloudflare sets a number of its own custom headers on incoming requests and outg
 
 For a list of documented Cloudflare request headers, refer to [Cloudflare HTTP headers](/fundamentals/reference/http-headers/).
 
+Visitor IP headers depend on the destination of a `fetch()` subrequest. Refer to [CF-Connecting-IP in Worker subrequests](/fundamentals/reference/http-headers/#cf-connecting-ip-in-worker-subrequests) for same-zone, cross-zone, and external destination behavior, and the [trust requirements](/fundamentals/reference/http-headers/#trust-visitor-ip-headers) for using these headers in security decisions.
+
 ## Related resources
 
 * [Logging headers to console](/workers/examples/logging-headers/) - Review how to log headers in the console.
-* [Cloudflare HTTP headers](/fundamentals/reference/http-headers/) - Contains a list of specific headers that Cloudflare adds.
\ No newline at end of file
+* [Cloudflare HTTP headers](/fundamentals/reference/http-headers/) - Contains a list of specific headers that Cloudflare adds.
diff --git a/src/content/partials/learning-paths/limit-external-connections-network.mdx b/src/content/partials/learning-paths/limit-external-connections-network.mdx
index 04e70a8581e..72c6fca3a38 100644
--- a/src/content/partials/learning-paths/limit-external-connections-network.mdx
+++ b/src/content/partials/learning-paths/limit-external-connections-network.mdx
@@ -10,11 +10,13 @@ import { Details } from "~/components"
 
 Explicitly block all traffic that does not come from [Cloudflare IP addresses](/fundamentals/concepts/cloudflare-ip-addresses/) (or the IP addresses of your trusted partners, vendors, or applications).
 
+Cloudflare IP ranges are shared across customers. Combine this filter with [origin authentication](/fundamentals/reference/http-headers/#trust-visitor-ip-headers) to identify traffic for your account or zone.
+
 * **Security**: Moderately secure.
 * **Availability**: All customers.
 * **Challenges**:
   * Requires allowlisting Cloudflare IP ranges at your origin server.
-  * Vulnerable to IP spoofing.
+  * Allows connections from other Cloudflare customers. A Cloudflare source IP does not prove that your zone's security rules ran.
 
 
 </Details>
diff --git a/src/content/partials/learning-paths/limit-external-connections-transport.mdx b/src/content/partials/learning-paths/limit-external-connections-transport.mdx
index 6ad27fa7542..07384e52337 100644
--- a/src/content/partials/learning-paths/limit-external-connections-transport.mdx
+++ b/src/content/partials/learning-paths/limit-external-connections-transport.mdx
@@ -10,12 +10,14 @@ import { Details, Render } from "~/components"
 
 [Authenticated Origin Pulls](/ssl/origin-configuration/authenticated-origin-pull/) helps ensure requests to your origin server come from the Cloudflare network.
 
+To identify traffic for your account or zone, use your own certificate with [zone-level or per-hostname AOP](/ssl/origin-configuration/authenticated-origin-pull/#when-to-use-your-own-certificate). Configure your origin to reject requests without the expected client certificate.
+
 * **Security**: Very secure.
 * **Availability**: All customers.
 * **Challenges**:
   * Requires [Full](/ssl/origin-configuration/ssl-modes/full/) or [Full (strict)](/ssl/origin-configuration/ssl-modes/full-strict/) encryption modes.
   * Requires more configuration efforts for application and server, such as uploading a certificate and configuring the server to use it.
-  * For more strict security, you should upload your own certificate. Although Cloudflare provides you a certificate for easy configuration, this certificate only guarantees that a request is coming from the Cloudflare network.
+  * Global AOP uses a certificate shared across Cloudflare accounts. It authenticates the Cloudflare network, but does not identify your account or zone.
   * Not scalable for large numbers of origin servers.