Skip to content

Zscaler BYOIP Integration Overview

BYOIP SUPPORTER
ASN AS22616
IPv4 support
IPv6 support
LOA support
ROA support
Process Semi-automatic
Locations supported
Other: India, Japan, Philippines, South Korea, Turkey, United Arab Emirates, Taiwan, France, Germany, Greece, Ireland, United Kingdom, Canada, Mexico, United States, Argentina, Brazil, Chile, Colombia, Peru, Australia

This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) concepts with Zscaler Internet Access (ZIA) and the Zscaler Zero Trust Exchange. Zscaler does not operate like an IaaS provider that directly hosts customer prefixes on virtual NICs; instead, it offers Dedicated IP and Source IP Anchoring (SIPA) capabilities that allow you to use stable, sometimes customer-owned, public IP addresses for egress traffic. In practice, BYOIP with Zscaler is achieved through two complementary models: (1) Zscaler-managed dedicated IPs — including customer-owned prefixes that Zscaler now originates as Zscaler Managed Dedicated IPs on the Zero Trust Exchange (formal BYOIP feature), and (2) customer-managed dedicated IPs via Source IP Anchoring, where your own network or cloud edge NATs traffic using your IP ranges while still leveraging Zscaler inspection.

Provider Details

FieldInformation
Provider NameZscaler (Zscaler Internet Access)
Website Announcing the ability to Bring Your Own Dedicated IP (BYOIP) on the Zscaler Zero Trust Exchange | Global Access, Local Control: Breaking Geo Restrictions (Dedicated IPs & BYOIP) | Source IP Anchoring (SIPA) overview | Using Dedicated IP (ZIA) | Self-provisioning Static IPs
ASN(s) Regional Zscaler cloud ASNs used for BYOIP and dedicated egress:
Americas: AS22616 (ZSCALER, INC.)
EMEA: AS62044
APAC: AS53813
These ASNs are used by Zscaler to originate customer-owned prefixes (BYOIP) and Zscaler-owned dedicated IP ranges from the Zero Trust Exchange.
Regions Supported Zscaler Internet Access is delivered from a large, globally distributed cloud (hundreds of data centers worldwide). Dedicated IP and BYOIP features are tied to ZIA public service edges and scoped by region-specific ASNs (Americas, EMEA, APAC). BYOIP deployments are anchored to a chosen region by creating a ROA that authorizes the corresponding Zscaler ASN. Practical use cases include:
– Regional egress IPs for SaaS allowlists and geographic compliance (country-based geolocation).
– In-country egress and logging for data/content sovereignty.
– Keeping a consistent, customer-owned egress identity while leveraging Zero Trust Exchange inspection.
Support Contact Zscaler Help Portal (support tickets & documentation) | Customer Success Center (requires login) | Account team / partner channel for design and commercial enablement.
Tech Article & Date Announcing the ability to Bring Your Own Dedicated IP (BYOIP) on the Zscaler Zero Trust Exchange — formal announcement of customer-owned Dedicated IPs (BYOIP) on the Zero Trust Exchange, including ROA/x.509 validation model and regional ASNs.
Global Access, Local Control: Breaking Geo Restrictions with ZIA — earlier blog introducing Dedicated IPs, Zscaler-managed dedicated IPs, and Bring Your Own IP (BYOIP) as part of geolocation and sovereignty controls.
Techzine: Zscaler introduces BYOIP for Zero Trust architectures — independent overview highlighting how BYOIP on the Zero Trust Exchange preserves network identity within a Zero Trust design.
Supporting collateral: Transform Source IP-Address-Based Application Access, Professional Services: Source IP Anchoring (SIPA).
BYOIP Scope Zscaler’s BYOIP capability is focused on dedicated egress addresses for SaaS / internet access, not on attaching prefixes to virtual machines:
1) Zscaler-managed Dedicated IPs (Hosted BYOIP): Dedicated IPs hosted and routed by Zscaler’s cloud, reserved for a single customer. With the BYOIP feature, you can bring an IPv4 prefix you own; Zscaler validates your authorization (via ROA and a signed BYOIP message), then originates that prefix from the designated region and exposes addresses as Zscaler Managed Dedicated IPs for policy and egress. This is the primary provider-announced BYOIP model.
2) Customer-managed Dedicated IPs via Source IP Anchoring (SIPA): Zscaler forwards selected traffic (after inspection) back to your network or cloud edge through ZPA App Connectors; your own firewalls/NAT gateways then egress this traffic using your own public IP addresses. This is functionally BYOIP for IP allowlisting and reputation, while Zscaler remains in-path for security and policy enforcement.
Supported Versions BYOIP and dedicated IPs use public IPv4 addresses today. The BYOIP feature explicitly supports customer-owned IPv4 prefixes (minimum /24) registered with ARIN, RIPE, or APNIC and originated by a regional Zscaler ASN. IPv6 BYOIP is on the roadmap with a minimum /48 prefix size; availability and timelines must be confirmed with Zscaler. Dedicated IPs can be single addresses or small ranges carved from these prefixes, depending on design and licensing.
Supported Services BYOIP concepts apply to Zscaler Internet Access (ZIA) for outbound web/SaaS traffic running on the Zscaler Zero Trust Exchange. Source IP Anchoring additionally requires Zscaler Private Access (ZPA) and ZPA App Connectors deployed where your own public IP ranges are reachable (on-prem DC, colo, or public cloud). The BYOIP/dedicated IP feature set is used to:
– Provide stable, dedicated egress IPs (Zscaler- or customer-owned) for SaaS allowlists and partner networks.
– Localize egress (country-based IP geolocation and logging).
– Maintain existing IP-based trust relationships and regulatory approvals during migrations to Zero Trust.

Technical Requirements

RequirementDetails
Prefix Size Zscaler formalizes BYOIP at the level of dedicated public IPs backed by customer-owned prefixes:
Zscaler-managed Dedicated IPs with BYOIP: Customer-owned IPv4 prefixes registered with ARIN/RIPE/APNIC, with a minimum size of /24 from a single Zscaler data center. Zscaler originates these prefixes via a regional ASN and exposes selected addresses as Zscaler Managed Dedicated IPs.
Customer-managed Dedicated IPs (SIPA): One or more public IPv4 addresses (or subnets) under your control at your egress point (data center or cloud). For SIPA, Zscaler does not originate your prefix in BGP; your own network/ISP does, so minimum prefix size is governed by your upstream routing policy, not Zscaler.
IPv6 roadmap: IPv6 BYOIP minimum is documented as /48 for planning purposes; check with Zscaler for current availability.
ASN Ownership Required No customer ASN is required for Zscaler-managed Dedicated IPs or BYOIP. Zscaler uses its own regional ASNs (AS22616, AS62044, AS53813) to originate customer-owned and Zscaler-owned dedicated IP ranges from its cloud.
For customer-managed dedicated IPs via SIPA, your network edge is responsible for routing and NATing traffic using your IP ranges. If you egress to the internet using your own ASN, existing ISP/BGP arrangements continue unchanged; Zscaler sits logically in front of that egress as a security and policy layer.
IRR / Route Objects For BYOIP where Zscaler originates your prefixes:
– Your prefix must be correctly registered with a recognized RIR (ARIN, RIPE, APNIC) and have routing/IRR data that is consistent with Zscaler’s origin ASN for the chosen region.
– Zscaler relies primarily on RPKI ROAs and RIR records for validation; maintaining accurate IRR route objects remains a best practice for global routing hygiene.
For SIPA (customer-managed dedicated IP), Zscaler does not announce your prefixes; your ISP/BGP edge remains authoritative, so existing IRR and RPKI practices stay entirely in your domain.
ROA or LOA For the formal BYOIP feature (customer-owned Dedicated IPs on the Zero Trust Exchange):
– A valid RPKI ROA is required for your prefix in your RIR, authorizing the appropriate regional Zscaler ASN (Americas, EMEA, or APAC) to originate your route.
– You must generate an x.509 self-signed certificate pair and use it to sign a short BYOIP validation message that ties your prefix to your organization. Zscaler validates this signed message against public information you publish in your RIR records (for example, netblock remarks).
– Zscaler’s routing system performs ROA/RPKI checks before advertising your prefix and monitors ROA validity; if the ROA lapses, announcements may be withdrawn to maintain routing hygiene.
Traditional Letters of Authorization (LOA) or contract language may still be requested, but ROA + cryptographic attestation are the primary trust anchors for BYOIP. For SIPA-only scenarios (where Zscaler does not originate your space), ROAs remain your responsibility with your own ASN and ISPs.
RIR Limitations Customer-owned IP space used for BYOIP/SIPA must be globally routable public IPv4, correctly registered with a recognized RIR. The BYOIP feature is documented for prefixes in ARIN, RIPE, and APNIC. You must be able to:
– Prove control over the IPs (via RIR records and ROAs).
– Create ROAs that authorize the appropriate Zscaler ASN by region for BYOIP.
– Update your routing/IRR data as needed to support your egress design and any migration between regions.

Step-by-Step BYOIP Process

Estimated Setup Time: Highly dependent on commercial enablement and network design. For most enterprises, expect several weeks from initial design to production rollout, including SaaS allowlist changes, ROA approval/propagation, and testing.

Tested By Us: Not yet

A) Zscaler-managed Dedicated IPs (Hosted Dedicated / BYOIP option)

  • Engage your Zscaler account team to scope the use cases: SaaS allowlists, geo-restricted apps, data sovereignty requirements, and traffic volumes per region, and confirm whether you will use Zscaler-assigned Dedicated IPs, customer-owned BYOIP prefixes, or a mix of both.
  • Decide between standard Zscaler-managed Dedicated IPs (Zscaler-owned IPs) and BYOIP-style Dedicated IPs where the dedicated addresses come from your own IPv4 prefix, originated by a regional Zscaler ASN as Zscaler Managed Dedicated IPs.
  • For BYOIP, ensure your IPv4 prefix (minimum /24) is registered with ARIN/RIPE/APNIC and create an RPKI ROA that includes the prefix and authorizes the correct Zscaler ASN for the target region (Americas AS22616, EMEA AS62044, APAC AS53813).
  • Generate an x.509 self-signed certificate pair, prepare and sign the BYOIP validation message provided by Zscaler, and publish the relevant public certificate details in your RIR/netblock remarks as requested. Open a Zscaler support ticket to initiate BYOIP onboarding.
  • Zscaler validates your ROA and signed BYOIP message, provisions dedicated IP pools in the selected ZIA locations, associates them with your tenant, and begins originating the prefix from the designated region. Configure policy so traffic from your users/locations egresses using these Dedicated IPs instead of shared pool addresses.
  • Coordinate with SaaS providers, partners, and regulators to update their IP allowlists to include the new dedicated (and where applicable, customer-owned) egress IPs. Validate access to all critical apps, monitor logs and geolocation behavior, and gradually migrate traffic and retire legacy VPNs or on-premises proxies previously used solely for source IP allowlisting.

B) Customer-managed Dedicated IPs via Source IP Anchoring (SIPA)

  • Ensure you are licensed for both Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA), and that you can deploy ZPA App Connectors near your existing egress environment (on-prem DC, colo, or cloud VPC/VNet).
  • Identify one or more egress points (firewalls/NAT gateways) that will use your public IP ranges for outbound connections to critical SaaS or external services; verify capacity and redundancy at those egress points.
  • Deploy ZPA App Connectors in the chosen network segment and configure them so they can reach both Zscaler public service edges (for incoming traffic) and your NAT gateway/firewall (for egress to the internet).
  • In the ZIA admin portal, create Source IP Anchoring policies that match the applications or destinations requiring your own source IPs, and point those flows to the appropriate SIPA connector group / location.
  • Configure routing and NAT at your egress so that traffic arriving from the App Connectors is translated to your chosen public IP address(es). Test flows end-to-end to confirm that application logs see your BYOIP address, while traffic is still inspected by ZIA/ZPA.
  • Update external allowlists and regulatory documentation to reference your BYOIP egress IPs. Continue monitoring for performance and reliability, and expand SIPA policies as more applications are migrated from traditional site-to-site VPN or proxy-based egress.

References: Zscaler blog on customer-owned Dedicated IPs (BYOIP), Global Access, Local Control blog, Source IP Anchoring overview, Source IP access whitepaper, SIPA Professional Services datasheet, Techzine BYOIP article.

Cost and Limitations

ItemDetails
Fees Zscaler does not publish a granular public price list for Dedicated IPs or BYOIP. In general:
– Dedicated IPs (including customer-owned BYOIP variants) are add-on features on top of ZIA subscriptions and are typically priced per IP or per region as part of your commercial agreement.
– Source IP Anchoring depends on licensing for both ZIA and ZPA and may involve Professional Services for design and rollout. All commercial terms are negotiated with Zscaler or partners.
Bundled or Standalone BYOIP in the Zscaler sense is not a standalone routing service; it is embedded within ZIA/ZPA and the Zero Trust Exchange:
– Zscaler-managed Dedicated IPs (including BYOIP prefixes): part of the ZIA platform’s egress options, integrated with all normal ZIA security controls.
– SIPA (customer-managed dedicated IPs): an advanced routing feature combining ZIA and ZPA to anchor traffic through your own egress infrastructure while keeping Zero Trust inspection in place.
Traffic/Peering Restrictions – Zscaler egress always traverses the Zscaler security cloud; you cannot simply “host” address space there without security policies.
– Zscaler-managed Dedicated IPs (including BYOIP prefixes) are tied to specific regions / public service edges; cross-region behavior and load balancing are controlled by Zscaler and your ROA/ASN choices.
– SIPA flows are limited to applications/destinations you select; not all traffic needs to be anchored. Capacity and redundancy of your own egress are your responsibility.
Other Limitations – BYOIP and SIPA features are typically available only in enterprise/advanced bundles, not entry-level SKUs.
– Zscaler-managed Dedicated IPs use Zscaler’s cloud architecture; certain complex routing/geolocation needs may require custom design.
– SIPA requires ZPA and App Connectors; it introduces additional paths and dependencies (App Connectors, connectors’ hosting environment, your firewalls/NATs).
– Exact technical and contractual limits (number of dedicated IPs, maximum anchored destinations, etc.) are set per-customer.
– ROA expiry or misconfiguration can cause withdrawal of BYOIP advertisements; customers must maintain ROAs and RIR data to avoid disruption.

Automation & Developer Access

  • API Access: Yes — Zscaler provides REST APIs for ZIA and ZPA to manage locations, policies, forwarding profiles, and ZPA App Connectors. Dedicated IP and SIPA policy configuration (including rules that steer traffic to BYOIP prefixes) can be automated via these APIs once the features are enabled on your tenant.
  • Terraform: Community and partner Terraform providers exist for ZIA and ZPA, enabling infrastructure-as-code workflows for Zscaler configuration, including policy objects used in BYOIP/SIPA designs.
  • SIEM / Logging: Zscaler logs (including logs tied to dedicated IP / anchored traffic and BYOIP prefixes) can be exported to SIEMs and logging platforms via Nanolog Streaming Service (NSS) or the Zscaler Log Streaming service, for monitoring IP-based access and troubleshooting.
  • Professional Services: Zscaler offers specific Professional Services packages for Source IP Anchoring (SIPA), including design, policy creation, and guided rollout in complex environments; account teams can also assist with BYOIP onboarding and validation steps.

Abuse & Reputation Management

  • When you use Zscaler-managed Dedicated IPs (Zscaler-owned addresses), Zscaler is responsible for overall hygiene of those ranges, but you must still comply with Zscaler’s acceptable use policies and respond to abuse/security incidents generated by your traffic.
  • For BYOIP/SIPA scenarios using your own IP ranges, you remain responsible for the long-term reputation and blacklist status of your addresses. Zscaler’s logging and threat protection features help detect abuse, but delisting and communication with external RBL operators remains a customer task; ROA and RIR records must also be kept accurate to prevent unintended routing or hijack risk.

Zscaler Homepage
Announcing the ability to Bring Your Own Dedicated IP (BYOIP) on the Zscaler Zero Trust Exchange
Global Access, Local Control: Breaking Geo Restrictions (Dedicated IPs & BYOIP)
Techzine: Zscaler introduces BYOIP for Zero Trust architectures
Source IP Anchoring (SIPA) overview
Using Dedicated IP (ZIA)
Self-provisioning Static IP Addresses
Transform Source IP-Address-Based Application Access (whitepaper)
Zscaler Professional Services: Source IP Anchoring (SIPA)
Zscaler Help Portal
Customer Success Center

FAQ

BYOIP, or Bring Your Own IP, is a service that enables organizations to bring their own public IP addresses—whether owned outright or leased from an IP provider—into a service provider’s network infrastructure. Instead of relying on IP addresses assigned by the provider, BYOIP allows businesses to retain control over their IP resources. This ensures continuity, particularly for organizations with established IP-based reputations, branding, or dependencies on specific address blocks. IP providers can assist in streamlining this process, making it easy to integrate your IPs into the desired network environment.

BYOIP offers several compelling advantages. By using your own IPs, you can maintain continuity in your network’s identity, reduce the risk of disruptions to email deliverability or service recognition, and avoid reputational concerns associated with shared IPs. Additionally, BYOIP provides enhanced flexibility and control over your IP resources.

BYOIP is ideal for organizations that either own public IP addresses or lease them from a trusted IP provider with explicit BYOIP support. This includes enterprises, cloud providers, content delivery networks (CDNs), and businesses with compliance requirements or IP reputation needs. Working with a reputable IP provider ensures that leased IPs can be seamlessly integrated into another provider’s infrastructure without ownership concerns.

You must either legally own the IP addresses or have explicit authorization from a leasing IP provider to route and manage them. IP providers who offer BYOIP-ready IP addresses simplify this process, providing documentation and support to ensure compliance with regional internet registry (RIR) policies and service provider requirements. This collaboration ensures smooth implementation without any legal or operational issues.

To use BYOIP, you’ll typically need to present documentation verifying your authority over the IP block. This can include official records from a regional internet registry (RIR) such as ARIN, RIPE NCC, or APNIC. If you are leasing IPs, the IP provider should supply proof of their ownership and grant you permission for BYOIP. Providers that specialize in IP leasing often handle this paperwork for you, reducing administrative burden and ensuring compliance.

Yes, BYOIP is designed to be a secure and reliable solution. Reputable service providers and IP providers implement robust safeguards to prevent unauthorized use or hijacking of IP addresses. Security measures include BGP filtering, route validation, and advanced protocols like Resource Public Key Infrastructure (RPKI). By collaborating with a trusted IP provider, businesses can benefit from additional layers of protection, ensuring that only authorized traffic is routed through their IP blocks.

The setup process for BYOIP varies by provider, typically taking anywhere from a few hours to a few days. Factors include the complexity of your network, the verification process for IP ownership or authorization, and the time needed for global BGP route propagation. IP providers often expedite the preparation and validation stages, ensuring a smooth and timely integration into the desired infrastructure.

Absolutely. Many providers, in partnership with IP providers, support routing IPs across multiple data centers or geographic regions. This feature optimizes performance for global businesses by reducing latency and improving service availability. When working with an IP provider, you can also ensure that your leased or owned IPs are aligned with your geographic requirements for compliance and efficiency.

If you choose to discontinue BYOIP with a provider, your IP addresses will be released from their network, and routing will cease. You can then reallocate these IPs for use with a different service provider or project.