[Secure Web Gateway] Added updates for SWG (#30578)

* Added updates for SWG

* Fixing broken links

Author: dcpena

src/content/docs/cloudflare-one/traffic-policies/egress-policies/index.mdx

@@ -54,6 +54,17 @@ The following egress policy configures all traffic destined for a third-party ne
 	product="cloudflare-one"
 />
 
+### Secure access to SaaS applications
+
+Many SaaS providers (for example, Microsoft 365, Salesforce, or Workday) allow you to restrict access to connections from specific IP addresses. You can use dedicated egress IPs with Gateway to enforce this restriction:
+
+1. **Obtain dedicated egress IPs** from your account team and note the assigned IPv4 and IPv6 addresses.
+2. **Create an egress policy** that routes traffic destined for the SaaS provider through your dedicated egress IP. Use the Destination IP selector with the provider's published IP ranges, or the Application selector (Beta) to match the provider by name.
+3. **Add the egress IPs to the SaaS provider's allowlist** so the provider only accepts connections from your organization's IPs.
+4. **Pair with HTTP policies** to add deeper controls — for example, block file uploads to personal accounts, enforce DLP profiles to prevent sensitive data from leaving the organization, or require [device posture checks](/cloudflare-one/reusable-components/posture-checks/) before allowing access.
+
+This pattern ensures that access to the SaaS application is limited to traffic that passes through Gateway, where your security policies are enforced, and that the SaaS provider can verify traffic originates from your organization.
+
 ### Catch-all policy
 
 Without a catch-all policy, any traffic that does not match an explicit egress policy will attempt to use the closest dedicated egress IP location. To avoid unexpected IP assignments and maintain the best performance, create a catch-all policy that routes remaining traffic through the default Zero Trust IP range:

src/content/docs/cloudflare-one/traffic-policies/get-started/index.mdx

@@ -22,3 +22,54 @@ For each type of policy, we recommend the following workflow:
 2. Verify that Gateway is successfully proxying traffic from your devices.
 3. Set up basic security and compatibility policies (recommended for most use cases).
 4. Customize your configuration to the unique needs of your organization.
+
+## Recommended deployment phases
+
+Most organizations roll out Gateway in phases, starting with the lowest-effort, highest-impact policy type and adding deeper inspection over time.
+
+### Phase 1: DNS filtering
+
+DNS filtering requires the least deployment effort and provides immediate protection.
+
+- Point your network DNS to Gateway's resolver addresses, or deploy the Cloudflare One Client in DNS-only mode.
+- Block all [security threat categories](/cloudflare-one/traffic-policies/domain-categories/#security-categories) (malware, phishing, command and control).
+- Block [content categories](/cloudflare-one/traffic-policies/domain-categories/#content-categories) that violate your acceptable use policy.
+- Review [DNS logs](/cloudflare-one/insights/logs/dashboard-logs/gateway-logs/) to gain visibility into Internet usage across your organization.
+
+For setup instructions, refer to [Set up DNS filtering](/cloudflare-one/traffic-policies/get-started/dns/).
+
+### Phase 2: Network policies
+
+After DNS filtering is in place, add network-level controls for non-HTTP traffic.
+
+- Deploy the [Cloudflare One Client](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/) and enable the [Gateway proxy](/cloudflare-one/traffic-policies/proxy/) for TCP.
+- Block traffic to high-risk IP ranges or restrict which ports and protocols users can access.
+- Use [protocol detection](/cloudflare-one/traffic-policies/network-policies/protocol-detection/) to identify applications by traffic pattern rather than port number.
+- Enable network session logging for audit trails.
+
+For setup instructions, refer to [Set up network filtering](/cloudflare-one/traffic-policies/get-started/network/).
+
+### Phase 3: HTTP inspection
+
+HTTP inspection provides the deepest visibility and the most granular controls, but it requires additional setup.
+
+- Install the [Cloudflare root certificate](/cloudflare-one/team-and-resources/devices/user-side-certificates/) on user devices.
+- Enable [TLS decryption](/cloudflare-one/traffic-policies/http-policies/tls-decryption/) to inspect HTTPS traffic.
+- Create [Do Not Inspect](/cloudflare-one/traffic-policies/http-policies/#do-not-inspect) policies for applications that use certificate pinning.
+- Block risky file types, enable [anti-virus scanning](/cloudflare-one/traffic-policies/http-policies/antivirus-scanning/), and configure [DLP profiles](/cloudflare-one/data-loss-prevention/) to detect sensitive data.
+- Use [Browser Isolation](/cloudflare-one/remote-browser-isolation/) to render high-risk sites in a remote browser.
+
+For setup instructions, refer to [Set up HTTP filtering](/cloudflare-one/traffic-policies/get-started/http/).
+
+### Phase 4: Egress control and full integration
+
+With all policy layers active, extend Gateway to cover your full network and integrate with other Cloudflare One services.
+
+- Connect branch offices and data centers with [network tunnels](/cloudflare-one/networks/) (IPsec/GRE via Magic WAN).
+- Configure [dedicated egress IPs](/cloudflare-one/traffic-policies/egress-policies/) so third-party services can identify your organization's traffic.
+- Set up [resolver policies](/cloudflare-one/traffic-policies/resolver-policies/) to route internal DNS queries to your private DNS servers.
+- Monitor SaaS application usage with [CASB](/cloudflare-one/cloud-and-saas-findings/).
+
+:::note
+You do not need to complete every phase. Choose the phases that match your organization's security requirements and deployment timeline.
+:::

src/content/docs/cloudflare-one/traffic-policies/index.mdx

@@ -13,9 +13,41 @@ tags:
 
 import { Details, Stream } from "~/components";
 
+A Secure Web Gateway (SWG) is a security service that sits between an organization's users and the Internet. It inspects outbound traffic to enforce security policies, block threats, and prevent data loss. Core SWG capabilities include:
+
+- **URL and domain filtering** – Controls which websites users can access.
+- **Anti-malware scanning** – Inspects files in transit for malicious code.
+- **Application control** – Manages which applications users can reach and what actions they can perform.
+- **Data Loss Prevention (DLP)** – Detects and blocks sensitive data before it leaves the network.
+- **Traffic inspection** – Decrypts and examines encrypted (HTTPS) traffic for hidden threats.
+
+## The need for an SWG
+
+Traditional network security relied on hardware firewalls at the perimeter of a corporate network. That model assumed users, applications, and data all lived inside the same network boundary. Modern organizations face a different reality:
+
+- **Distributed workforce** – Employees connect from home networks, public Wi-Fi, and mobile devices, outside any corporate perimeter.
+- **Cloud and SaaS adoption** – Business-critical applications and data have moved to cloud platforms like Microsoft 365, Google Workspace, and Salesforce.
+- **Expanding threat surface** – Phishing, ransomware, command-and-control botnets, and data exfiltration attempts target users regardless of their location.
+
+Without an SWG, organizations lose visibility into what websites and applications users access, what threats reach user devices, and what data leaves the organization. An SWG restores that visibility and control by inspecting traffic in the cloud, close to users, rather than forcing all traffic through a central data center.
+
+Cloudflare Gateway is Cloudflare's SWG, built into the [Cloudflare One](https://www.cloudflare.com/learning/access-management/what-is-a-secure-web-gateway/) SASE platform. It inspects and filters traffic at the DNS, network (Layer 4), and HTTP (Layer 7) layers. 
+
+For more information on how SWGs work, refer to the [Cloudflare Learning Center](https://www.cloudflare.com/learning/access-management/what-is-a-secure-web-gateway/).
+
+## Traffic policy types
+
 Every organization needs a way to control what users can reach on the Internet — blocking malware sites, restricting risky applications, and deciding how traffic exits the corporate network. Think of traffic policies as a set of security checkpoints, each inspecting a different layer of your traffic before it is allowed through.
 
-Cloudflare Gateway, a [Secure Web Gateway](https://www.cloudflare.com/learning/access-management/what-is-a-secure-web-gateway/) (a cloud service that sits between your users and the Internet to enforce security rules), allows you to set up policies that inspect and filter your organization's Internet traffic. Traffic policies control which websites, applications, and services your users can access — and how that traffic leaves your network.
+### How Gateway relates to traditional firewalls
+
+If you are familiar with traditional network security, Gateway's policy layers map to familiar firewall functions:
+
+- **DNS policies** correspond to DNS-layer filtering (blocking domains before connections are established).
+- **Network policies** correspond to a Layer 4 stateful firewall, sometimes called Firewall-as-a-Service (FWaaS), filtering by IP address, port, and protocol.
+- **HTTP policies** correspond to a Layer 7 application firewall (forward proxy with TLS decryption and deep packet inspection).
+
+Unlike hardware firewalls that sit at a single network perimeter, Gateway enforces these policies across Cloudflare's global network, protecting 
 
 Gateway supports several policy types because network traffic can be inspected at different layers — from raw packets up to full HTTP requests. Each policy type gives you control at a specific layer:
 
@@ -49,7 +81,7 @@ Use network policies to block access to specific ports or non-HTTP services such
 
 **[HTTP policies](/cloudflare-one/traffic-policies/http-policies/)** inspect the full content of web requests — including URLs, headers, and uploaded or downloaded files. Gateway decrypts HTTPS traffic so it can examine what DNS and network policies cannot see. This requires installing a [Cloudflare root certificate](/cloudflare-one/team-and-resources/devices/user-side-certificates/) on user devices.
 
-Use HTTP policies to block specific URLs, scan file uploads for sensitive data, block malware in downloads, and control which accounts users can sign in to — for example, allow your company Google Workspace account but block personal Gmail.
+Use HTTP policies to block specific URLs, scan file uploads for sensitive data, block malware in downloads, [quarantine suspicious files](/cloudflare-one/traffic-policies/http-policies/file-sandboxing/) for sandbox analysis, and control which accounts users can sign in to. For example, allow your company Google Workspace account but block personal Gmail.
 
 </Details>
 
@@ -69,6 +101,19 @@ Use resolver policies to resolve private hostnames on your internal network, rou
 
 </Details>
 
+### Identity and device context
+
+Gateway policies can go beyond network attributes (domains, IPs, ports) and incorporate user identity and device health into every decision.
+
+When users connect through the [Cloudflare One Client](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/), Gateway can evaluate:
+
+- **User identity** – Email address, group membership, and authentication method from your [identity provider](/cloudflare-one/integrations/identity-providers/) (for example, Okta, Microsoft Entra ID, or Google Workspace).
+- **Device posture** – Signals such as operating system version, disk encryption status, firewall state, and whether the device serial number matches a managed device list. For the full list of available checks, refer to [Device posture](/cloudflare-one/reusable-components/posture-checks/).
+
+These signals can be combined with traffic selectors to create context-aware policies. For example, you can create an HTTP policy that allows access to a sensitive SaaS application only when the user belongs to a specific group **and** the device has disk encryption turned on.
+
+For details on building policies with identity selectors, refer to [Identity-based policies](/cloudflare-one/traffic-policies/identity-selectors/).
+
 :::note
 When creating or editing policies, it may take up to 60 seconds for that policy to be updated across all of Cloudflare's data centers.
 :::
@@ -108,6 +153,51 @@ The following table maps common traffic-filtering goals to the best Cloudflare G
 
 After you choose a Cloudflare Gateway policy type, continue with the matching setup guide to create the policy that fits your traffic-filtering goal.
 
+### Choose a connection method
+
+The connection method (on-ramp) you use determines which policy types Gateway can enforce. The following table summarizes each method:
+
+| Connection method | DNS policies | Network policies | HTTP policies | Best for |
+| --- | --- | --- | --- | --- |
+| [Cloudflare One Client](/cloudflare-one/team-and-resources/devices/cloudflare-one-client/) (WARP) | Yes | Yes | Yes | Roaming users on managed devices (laptops, phones) |
+| [DNS resolver](/cloudflare-one/networks/resolvers-and-proxies/dns/locations/) configuration | Yes | No | No | Unmanaged devices, entire networks, or initial rollout |
+| [Proxy endpoint](/cloudflare-one/networks/resolvers-and-proxies/proxy-endpoints/) (PAC file) | No | No | Yes (browser only) | Browser-level HTTP filtering without a device agent |
+| [Network tunnel](/cloudflare-one/networks/) (IPsec/GRE via Magic WAN) | Yes | Yes | Yes | Branch offices, data centers, and site-level connectivity |
+
+- The **Cloudflare One Client** provides the broadest coverage and is the recommended method for per-device deployments.
+- **DNS resolver** configuration is the easiest to deploy (change a DNS setting on your router or device) and provides immediate protection, but it only enforces DNS policies.
+- **Proxy endpoints** enable HTTP inspection through browser proxy configuration without installing an agent, but they are limited to browser traffic.
+- **Network tunnels** route all site traffic through Gateway and are best for protecting entire office locations or data centers.
+
+You can combine multiple on-ramps. For example, use the Cloudflare One Client for remote employees and network tunnels for branch offices.
+
+## How Gateway processes traffic
+
+When a user makes a request, Gateway inspects it at multiple layers before allowing the connection through. The following diagram shows the end-to-end flow:
+
+```mermaid
+flowchart LR
+    accTitle: Gateway traffic flow
+    accDescr: Diagram showing how traffic flows from user device through an on-ramp to Cloudflare Gateway for policy evaluation, then to the destination.
+
+    A["User device"] --> B["On-ramp"]
+    B --> C["Cloudflare edge<br/>(nearest location)"]
+    C --> D["Policy evaluation"]
+    D --> E["Destination<br/>server"]
+    E --> D
+    D --> C
+    C --> B
+    B --> A
+```
+
+1. The user's device sends a request (DNS query, TCP connection, or HTTP request).
+2. The request reaches Cloudflare through an **on-ramp** — the Cloudflare One Client, a DNS resolver configuration, a proxy endpoint, or a network tunnel.
+3. Cloudflare processes the request at the **nearest edge location**, not a centralized data center. This keeps latency low regardless of where the user connects from.
+4. Gateway evaluates the request against your configured policies in [order of enforcement](/cloudflare-one/traffic-policies/order-of-enforcement/): DNS policies first, then network policies, then HTTP policies.
+5. If policies allow the request, Gateway proxies it to the destination server and inspects the response on the return path.
+
+For details on how Gateway proxies traffic and establishes connections, refer to [Proxy](/cloudflare-one/traffic-policies/proxy/).
+
 ## Troubleshoot Cloudflare Gateway policies
 
 For help resolving common issues with Cloudflare Gateway policies, refer to [Troubleshooting](/cloudflare-one/traffic-policies/troubleshooting/).

src/content/partials/cloudflare-one/gateway/order-of-enforcement.mdx

@@ -168,6 +168,22 @@ Lastly, Gateway inspects the body of the HTTP request by evaluating it against D
 
 When [resolver policies](/cloudflare-one/traffic-policies/resolver-policies/) are present, Gateway first evaluates any DNS policies with pre-resolution selectors, then routes any DNS queries according to the [order of precedence](#order-of-precedence) of your resolver policies, and lastly evaluates any DNS policies with post-resolution selectors.
 
+### Default behavior when no policy matches
+
+If traffic does not match any explicit Allow or Block policy, Gateway applies the following defaults:
+
+| Policy type | Default action | Description |
+| --- | --- | --- |
+| DNS | Allow | DNS queries resolve normally through the configured resolver. |
+| Network | Allow | TCP and UDP connections are allowed through the Gateway proxy. |
+| HTTP | Allow | HTTP and HTTPS requests are allowed. However, if you have configured a default Block action in your [HTTP policy settings](/cloudflare-one/traffic-policies/http-policies/), unmatched traffic is blocked instead. |
+
+Because the default is to allow unmatched traffic, Gateway follows a permissive model. To switch to a restrictive model (block by default, allow by exception), create a catch-all Block policy at the lowest precedence in the relevant policy builder and add specific Allow policies above it.
+
+:::note
+Do Not Inspect policies are evaluated before all other HTTP policies. If traffic matches a Do Not Inspect policy, it bypasses all remaining HTTP policies and is allowed through Gateway. For details, refer to [HTTP policy priority](#http-policies).
+:::
+
 ### Order of precedence
 
 Order of precedence refers to the priority of individual policies within the DNS, network, or HTTP policy builder. Gateway evaluates policies in ascending order beginning with the lowest value.