Modern enterprises don’t run on a defined perimeter anymore. Users connect from everywhere, applications live across SaaS and public cloud, and attackers ever increasingly hide in encrypted traffic. In this environment, security teams need more than “IP + port” controls—they need application-aware enforcement and always-on threat inspection that follows users and traffic wherever it goes.Zscaler Zero Trust Firewall is designed for exactly that: cloud-delivered protection for web and non-web traffic, centralized policy, and deep visibility—without the operational drag of appliance sprawl. Two new capabilities that significantly improve this security outcomes are:Custom Application Service Groups (Custom App Services) for precise, reusable application/service controlsCustom IPS Signature Rules (Cloud Custom IPS) for organization-specific threat detections enforced through IPS ControlThis post focuses on what they do, why they matter, and how customers can put them into practice quickly.Why application and threat detection needs a zero trust approachLegacy firewalls were built for a world where:applications stayed in the data center,“Inside the perimeter” was trusted,and deep inspection (especially SSL/TLS) was optional.Today, that model breaks down:SSL/TLS is the default, and turning on TLS inspection at scale can be painful in appliance architectures.Attackers don’t just attack servers—they target users, endpoints, and “normal” protocols.Policy sprawl grows fast when you try to emulate zero trust through endless network segments and distributed rulebases.A Zero Trust Firewall addresses these challenges by enforcing in the cloud and adding richer context for decisions such as identity, application/service constructs, and integrated IPS.What Zero Trust Firewall (ZTFW) deliversCustomer outcomes typically map to three capabilities:Consistent protection everywhere: The same security posture for users at HQ, branches, and remote.Better precision than “network-only” controls: Policies can incorporate user context and (where licensed) process-level awareness via Endpoint App Control.Inline inspection + visibility: Built-in security services (including IPS) and centralized logging/insights so security teams can investigate and respond faster.That foundation is what makes Custom App Services and Custom IPS signatures so impactful: they become building blocks you can reuse and scale across your environment. Custom Application Service Groups: enforce policy on application services, not just IPsApplication Service Groups are policy objects you can use as criteria in Firewall Filtering and Forwarding rules. They’re defined using service metadata such as:IP addresses (single IP, subnet, or range)FQDNs and wildcard FQDNs (e.g., *.example.com)TCP/UDP destination portsZscaler provides both:Predefined application service groups (AU / “Authoritative”): These are application service groups for popular SaaS and cloud providers based on their metadata; broadly applicable; updated over time.Custom application service groups (CU) : Created by you, in your tenant, for your specific service definitions and policy needs. Predefined Application Service GroupsZscaler maintains and updates a list of predefined application services based on information published by the respective providers. These predefined services help customers:Reduce operational overhead: less manual IP-list maintenance as providers evolve.Write cleaner firewall policy: rules read like business intent (“Allow Microsoft 365”) rather than brittle networking trivia.Improve accuracy: service identification is built to reflect provider-published metadata. Zscaler also continuously updates provider-published metadata for many predefined groups, reducing the effort of tracking SaaS IP changes over time. Custom Application Service Groups: add flexibility when predefined isn’t enoughPredefined services are intentionally generalized and provider-driven. But real customer environments often need something more specific, such as:a privately hosted API with known FQDNs and portsa partner integration endpoint seta SaaS app that isn’t in the predefined cataloga subset of destinations within a larger provider footprintThat’s where Custom Application Service Groups come in.A custom application service group can be built using combinations of:IP addresses (single IP / subnet / range)FQDN / wildcard FQDN (e.g., api.example.com or *.example.com)TCP/UDP destination portsThis gives you service-aware control for apps that are unique to your business, not just what’s common among all customers.Where custom services deliver the most valueModel your own apps like “first-class services” in firewall policy: Instead of falling back to generic destination IP groups and ports.Limit a large, predefined service footprint to only what you intend: Example: define a custom group representing only a narrow set of AWS-hosted endpoints your engineering org should reach.Create reusable objects: Use the same custom service group across Firewall Filtering, Forwarding rules, and (where applicable) IPS control targeting.Custom Application Service Groups help you:Reduce rule fragility: Instead of chasing shifting IPs and endpoints, define the service once and reuse it.Improve least privilege: Narrow access to exactly the destinations and ports that matter.Simplify operations: Build cleaner policies using reusable objects rather than repeating the same destinations in many rules.A key advantage: first-packet identificationA key benefit of application service groups is they can be used to identify applications on the first packet, which can allow policy action to apply immediately. Operationally, this also influences rule design: application service-based policies often belong higher in a higher priority rule than similar “network application” rules to ensure deterministic matching.Example use cases:Tight SaaS allowlisting: Allow Microsoft 365 or Zoom-related service traffic only for intended users and conditions.Controlled cloud access: Allow AWS/GCP service traffic, but only for specific departments (and ideally with multiple conditions).Partner/API segmentation: Create a custom service group for partner API hosts and required ports, then enforce strict allow + logging. IPS Control with Cloud Custom IPS: always-on threat prevention, inlineEven the “right” application traffic can carry threats. That’s why Zero Trust Firewall pairs application control with inline intrusion prevention.IPS Control in ZIA provides signature-based detection across web and non-web traffic (including HTTP/HTTPS/FTP/DNS/TCP/UDP and IP-based traffic) and supports granular policy conditions such as users/groups/departments/locations and more. It also supports actions such as:AllowBlock/DropBlock/ResetBypass IPSDefault threat signatures vs. Custom IPS signatures (what’s included vs. what you add)IPS Control policies can be configured to enforce signatures from two sources:Signatures available with IPS Control by default: Zscaler’s IPS Control uses IPS signature rules built and updated by Zscaler’s security research team (ThreatLabz), as well as signatures from industry-leading vendors. These signatures provide broad baseline coverage and are maintained by Zscaler.Custom IPS Signature Rules (customer-defined): In addition to the default signatures, you can create and deploy custom IPS signatures that are specific to your organization’s requirements without requiring any additional infrastructure, and inspect your traffic using these signatures. These custom signatures are authored by your team and remain specific to your tenant.In either scenario, with Zscaler Cloud IPS Control, you no longer have to hairpin the traffic back to the DC via VPNs. Instead, the traffic can go directly to the cloud, no matter where the user, device, or workload is globally. Custom IPS Signature Rules: tailor threat detection to your environmentCustom IPS Signature Rules let your security team define organization-specific detections using Snort-like syntax, deploy them in the Zscaler cloud (no additional infrastructure), and enforce them through IPS Control via an assigned Threat Category. Additionally, the signature only stays in your tenant, enabling you to comply with TLP:amber/red guidelines.This is especially valuable when:You have a unique internal application or API surfaceYou receive new threat intel and want to respond independent of Zscaler’s ThreatLabz.You need custom detections for compliance or for telemetry/signals into your SOC via Zscaler logging. Quick example: why you’d use a custom signature even when defaults existScenario: Your SecOps team receives threat intel about a pattern targeting your environment. That pattern may not exist in the default global signature set (yet), and you can’t wait for a broader industry signature release cycle.What you do:Keep default IPS signatures enabled (so you retain broad protection immediately).Create a Custom IPS signature that matches the environment-specific pattern.Assign it to a threat category and enforce it via an IPS Control rule scoped to the relevant users/locations/services (for example, the Application Service Group representing that app/service).Choose the IPS Control action (e.g., block/drop for high-confidence attempts) and activate the policy.Outcome: You get the best of both:continuously updated default coverage from Zscaler, andfast, precise, tenant-specific detection when your environment needs something unique—without deploying additional IPS infrastructure.In practice: write signatures that are specific, testable, and scoped (then monitor hits and adjust). ConclusionA Zero Trust Firewall isn’t just “a firewall in the cloud.” The real advantage comes from higher-fidelity policy objects and embedded threat prevention that move at the speed of modern environments.Custom Application Service Groups reduce policy fragility and increase enforcement precision by modeling services the way the business uses them.Custom IPS Signature Rules close detection gaps by letting you encode organization-specific threat intelligence and enforce it through IPS Control—without deploying separate IPS infrastructure.Together, they turn firewall policy from a static ruleset into a living control plane for application-aware access and threat detection in a zero trust architecture. Join an upcoming hands-on Zero Trust Firewall workshop where Zscaler experts walk you through building real policies for non-web traffic including IPS rules, DNS controls, and application-aware enforcement in a live, interactive environment.Reserve your spotSeats are limited and sessions fill quickly so register early.
[#item_full_content] Modern enterprises don’t run on a defined perimeter anymore. Users connect from everywhere, applications live across SaaS and public cloud, and attackers ever increasingly hide in encrypted traffic. In this environment, security teams need more than “IP + port” controls—they need application-aware enforcement and always-on threat inspection that follows users and traffic wherever it goes.Zscaler Zero Trust Firewall is designed for exactly that: cloud-delivered protection for web and non-web traffic, centralized policy, and deep visibility—without the operational drag of appliance sprawl. Two new capabilities that significantly improve this security outcomes are:Custom Application Service Groups (Custom App Services) for precise, reusable application/service controlsCustom IPS Signature Rules (Cloud Custom IPS) for organization-specific threat detections enforced through IPS ControlThis post focuses on what they do, why they matter, and how customers can put them into practice quickly.Why application and threat detection needs a zero trust approachLegacy firewalls were built for a world where:applications stayed in the data center,“Inside the perimeter” was trusted,and deep inspection (especially SSL/TLS) was optional.Today, that model breaks down:SSL/TLS is the default, and turning on TLS inspection at scale can be painful in appliance architectures.Attackers don’t just attack servers—they target users, endpoints, and “normal” protocols.Policy sprawl grows fast when you try to emulate zero trust through endless network segments and distributed rulebases.A Zero Trust Firewall addresses these challenges by enforcing in the cloud and adding richer context for decisions such as identity, application/service constructs, and integrated IPS.What Zero Trust Firewall (ZTFW) deliversCustomer outcomes typically map to three capabilities:Consistent protection everywhere: The same security posture for users at HQ, branches, and remote.Better precision than “network-only” controls: Policies can incorporate user context and (where licensed) process-level awareness via Endpoint App Control.Inline inspection + visibility: Built-in security services (including IPS) and centralized logging/insights so security teams can investigate and respond faster.That foundation is what makes Custom App Services and Custom IPS signatures so impactful: they become building blocks you can reuse and scale across your environment. Custom Application Service Groups: enforce policy on application services, not just IPsApplication Service Groups are policy objects you can use as criteria in Firewall Filtering and Forwarding rules. They’re defined using service metadata such as:IP addresses (single IP, subnet, or range)FQDNs and wildcard FQDNs (e.g., *.example.com)TCP/UDP destination portsZscaler provides both:Predefined application service groups (AU / “Authoritative”): These are application service groups for popular SaaS and cloud providers based on their metadata; broadly applicable; updated over time.Custom application service groups (CU) : Created by you, in your tenant, for your specific service definitions and policy needs. Predefined Application Service GroupsZscaler maintains and updates a list of predefined application services based on information published by the respective providers. These predefined services help customers:Reduce operational overhead: less manual IP-list maintenance as providers evolve.Write cleaner firewall policy: rules read like business intent (“Allow Microsoft 365”) rather than brittle networking trivia.Improve accuracy: service identification is built to reflect provider-published metadata. Zscaler also continuously updates provider-published metadata for many predefined groups, reducing the effort of tracking SaaS IP changes over time. Custom Application Service Groups: add flexibility when predefined isn’t enoughPredefined services are intentionally generalized and provider-driven. But real customer environments often need something more specific, such as:a privately hosted API with known FQDNs and portsa partner integration endpoint seta SaaS app that isn’t in the predefined cataloga subset of destinations within a larger provider footprintThat’s where Custom Application Service Groups come in.A custom application service group can be built using combinations of:IP addresses (single IP / subnet / range)FQDN / wildcard FQDN (e.g., api.example.com or *.example.com)TCP/UDP destination portsThis gives you service-aware control for apps that are unique to your business, not just what’s common among all customers.Where custom services deliver the most valueModel your own apps like “first-class services” in firewall policy: Instead of falling back to generic destination IP groups and ports.Limit a large, predefined service footprint to only what you intend: Example: define a custom group representing only a narrow set of AWS-hosted endpoints your engineering org should reach.Create reusable objects: Use the same custom service group across Firewall Filtering, Forwarding rules, and (where applicable) IPS control targeting.Custom Application Service Groups help you:Reduce rule fragility: Instead of chasing shifting IPs and endpoints, define the service once and reuse it.Improve least privilege: Narrow access to exactly the destinations and ports that matter.Simplify operations: Build cleaner policies using reusable objects rather than repeating the same destinations in many rules.A key advantage: first-packet identificationA key benefit of application service groups is they can be used to identify applications on the first packet, which can allow policy action to apply immediately. Operationally, this also influences rule design: application service-based policies often belong higher in a higher priority rule than similar “network application” rules to ensure deterministic matching.Example use cases:Tight SaaS allowlisting: Allow Microsoft 365 or Zoom-related service traffic only for intended users and conditions.Controlled cloud access: Allow AWS/GCP service traffic, but only for specific departments (and ideally with multiple conditions).Partner/API segmentation: Create a custom service group for partner API hosts and required ports, then enforce strict allow + logging. IPS Control with Cloud Custom IPS: always-on threat prevention, inlineEven the “right” application traffic can carry threats. That’s why Zero Trust Firewall pairs application control with inline intrusion prevention.IPS Control in ZIA provides signature-based detection across web and non-web traffic (including HTTP/HTTPS/FTP/DNS/TCP/UDP and IP-based traffic) and supports granular policy conditions such as users/groups/departments/locations and more. It also supports actions such as:AllowBlock/DropBlock/ResetBypass IPSDefault threat signatures vs. Custom IPS signatures (what’s included vs. what you add)IPS Control policies can be configured to enforce signatures from two sources:Signatures available with IPS Control by default: Zscaler’s IPS Control uses IPS signature rules built and updated by Zscaler’s security research team (ThreatLabz), as well as signatures from industry-leading vendors. These signatures provide broad baseline coverage and are maintained by Zscaler.Custom IPS Signature Rules (customer-defined): In addition to the default signatures, you can create and deploy custom IPS signatures that are specific to your organization’s requirements without requiring any additional infrastructure, and inspect your traffic using these signatures. These custom signatures are authored by your team and remain specific to your tenant.In either scenario, with Zscaler Cloud IPS Control, you no longer have to hairpin the traffic back to the DC via VPNs. Instead, the traffic can go directly to the cloud, no matter where the user, device, or workload is globally. Custom IPS Signature Rules: tailor threat detection to your environmentCustom IPS Signature Rules let your security team define organization-specific detections using Snort-like syntax, deploy them in the Zscaler cloud (no additional infrastructure), and enforce them through IPS Control via an assigned Threat Category. Additionally, the signature only stays in your tenant, enabling you to comply with TLP:amber/red guidelines.This is especially valuable when:You have a unique internal application or API surfaceYou receive new threat intel and want to respond independent of Zscaler’s ThreatLabz.You need custom detections for compliance or for telemetry/signals into your SOC via Zscaler logging. Quick example: why you’d use a custom signature even when defaults existScenario: Your SecOps team receives threat intel about a pattern targeting your environment. That pattern may not exist in the default global signature set (yet), and you can’t wait for a broader industry signature release cycle.What you do:Keep default IPS signatures enabled (so you retain broad protection immediately).Create a Custom IPS signature that matches the environment-specific pattern.Assign it to a threat category and enforce it via an IPS Control rule scoped to the relevant users/locations/services (for example, the Application Service Group representing that app/service).Choose the IPS Control action (e.g., block/drop for high-confidence attempts) and activate the policy.Outcome: You get the best of both:continuously updated default coverage from Zscaler, andfast, precise, tenant-specific detection when your environment needs something unique—without deploying additional IPS infrastructure.In practice: write signatures that are specific, testable, and scoped (then monitor hits and adjust). ConclusionA Zero Trust Firewall isn’t just “a firewall in the cloud.” The real advantage comes from higher-fidelity policy objects and embedded threat prevention that move at the speed of modern environments.Custom Application Service Groups reduce policy fragility and increase enforcement precision by modeling services the way the business uses them.Custom IPS Signature Rules close detection gaps by letting you encode organization-specific threat intelligence and enforce it through IPS Control—without deploying separate IPS infrastructure.Together, they turn firewall policy from a static ruleset into a living control plane for application-aware access and threat detection in a zero trust architecture. Join an upcoming hands-on Zero Trust Firewall workshop where Zscaler experts walk you through building real policies for non-web traffic including IPS rules, DNS controls, and application-aware enforcement in a live, interactive environment.Reserve your spotSeats are limited and sessions fill quickly so register early.
