We'll start today with a short presentation by our CEO, Jay Chaudhry, on our newly announced fourth pillar of our platform, the Zscaler Cloud Protection or ZCP. Afterwards, we will be joined by Amit Sinha, President and CTO, and Patrick Foxhoven, EVP of Emerging Technologies and CIO. We will open the session for question and answer. All participants will be in listen-only mode until the Q&A begins. If you wish to ask a question, please make sure that your Zoom username is identifiable, and use the raise the hand feature in the bottom of the meeting window. When you're selected for a question, please prepare to turn on video and unmute your microphone. We will not be providing any financial updates today. Please be mindful of this during the Q&A session.
As noted on this slide, today's session may contain forward-looking statements, including but not limited to our view of the industry, product performance, product business outlook, and other statements that are not historical facts. These statements are not guarantees of future performance, but rather are subject to risk and uncertainty. With that, I will now hand over the call to Jay.
Bill, thank you. Let me start with a few slides to give you a big picture view of where we fit and the new pillar we launched yesterday, Zscaler Cloud Protection. By now, hopefully you're familiar with our Zero Trust Exchange platform and pillars ZIA, ZPA, and user experience. These three are focused on user protection and experience to make sure a user can get to any application a good experience. We have been building over time to make sure we have a strong story to expand our offering in the next area. That is, let's go beyond protecting users to being able to protect servers and workloads. The launch yesterday is of Zscaler Cloud Protection, which has multiple solutions in it.
The great thing it does is that it expands our market significantly because we're not just doing user protection, we're also getting into workload and server protection. Now, I'll give you a quick high-level view of it. Hopefully, some of you had a chance to listen to my keynote where I covered it at a 40,000-ft level, then Amit and Patrick, during their product innovations, brought it down to a lower level. This fourth pillar actually completes our overall offering. Now, why do we care about Zscaler Cloud Protection? If you look at the workloads moving to the cloud, they're distributed multi-cloud, they evolve, they change. Their configurations are pretty complex. They're dynamic. They come, they go, and DevOps moves faster than security. They're actually going ahead and doing things that aren't even secure.
Connectivity, trying to take your traditional network-based connectivity with all these ingress and egress routes is complicated. Traffic flow, east and west, very low controls. we looked at the problem in four key areas as we talked to our customers. Security posture workloads. When there's so many workloads are being deployed out there'll be millions and millions of workloads out there. What's configured properly? What's not configured properly? It is the biggest source of security risks. That's one problem customers are asking it to solve. Second, they need various applications or workloads to talk to each other within the same data center, from public cloud A to B to C, whatnot. That's the second thing. How do I do it securely? Third, within a cloud, risk of lateral movement. Typically, you connect the networks.
Once you're on this beautiful flat network, you can reach anything and everything, which is wonderful, but which is also dangerous at the same time. Fourth, probably the most important, you may have the secure stuff, but your employees and your B2B customers need to access those applications securely with great experience. Those are the things we looked at, and we have been hearing from our customers that they have been trying to do it in a traditional way with a network security way. It's not working. What do we have? It's a combination of some of the investments we made in-house, building upon the zero trust technology we built for ZIA, ZPA and the like, and some acquisitions, with focus being how do you protect multi-cloud workloads. Multi-cloud is important because you don't have hardly any customers who is dependent on one cloud.
Cloud Security Posture becomes important. Gartner calls this thing CSPM and its proper configuration and the like. It's a new revenue opportunity for us. We have started with Cloudneeti and are evolving and growing it. I'll dig a little bit deeper into it. Workload communication. The workloads or applications sitting in your public cloud on an island. They need to talk to each other. Communication needs to happen across cloud to cloud. Traffic goes from workload to the internet, and you got cloud to data center connectivity. All that has to be done. We built a very cool technology called Cloud Connector that powers this communication. Essentially, the ZIA, ZPA use case, which used to be for user protection, now it's getting expanded to workload protection.
The pricing will be workload-based, just like user-based and here workload-based, but it expands our TAM significantly. Third area is segmentation within a data center, within a public cloud. This is where customers have been trying some of these virtual firewalls, doing network segmentation or some of these new vendors, like Illumio of the world. Really, we haven't seen serious traction. Customers are still looking for better solutions, and we built and expanded upon Edgewise Networks acquisition we've done. At the end of the day, all of this is good only if the users can access the workloads. It actually requires ZPA to be able to go and access those applications directly without having to go to the data center. That's our overall positioning. Three major new areas of functionality, plus ZPA for users to access these applications.
If I give you a little bit deeper view of each, without getting too deep into it. CSPM is the term Gartner coined. All kinds of workloads being deployed across multiple clouds, including application like Office 365, that got to be configured properly with so many knobs out there. We've acquired this company, we're further enhancing it. We're making some serious investments to make sure our CSPM offering is the best in the market, but it starts with discovery of what assets do I have, how are they configured, being able to match against a lot of standard compliant configurations. Identify what's not compliant and then prioritize what's the risk of non-compliance and being able to do auto remediation alike. Important area. This market is ready out there, and we are beginning to sell this offering out there. That's one.
Two, this is probably the most exciting and very unique because here we are bringing zero trust to the data center or call it zero trust for public cloud. Almost all vendors out there are trying to do network-centric communication. You could throw firewalls here and there, all that type of stuff. In this approach, I got, say, a workload need to talk to the internet. Sitting in AWS, it needs to go to internet. Well, our Cloud Connector is very smart, figures out the traffic, can direct it to ZIA policy engine, and you can apply the same policy, same protection. What would you do without it? You'd try to buy some virtual firewalls. Well, how do you do a cyber threat inspection? How do you do SSL inspection? How do you do DLP inspection that you're used to? You miss it.
We bring all that rich functionality to the traffic that's non-user traffic, that's app traffic, to secure it. There's a cloud-to-cloud traffic. Probably Azure traffic needs to go to from Azure East to Azure West. Maybe AWS traffic needs to come and app in AWS need to talk to app in Azure. All that stuff flows through our Zero Trust Exchange powered by Cloud Connector. You also need the same thing, data center to cloud. Today, you typically have a dedicated site-to-site VPN. Expensive, and it's network extension, not really zero trust type. This is third area. Fourth, more and more businesses want to change the old way where they're trying to send larger data exchange and files between two companies through some kind of old convoluted system. With zero trust, we can do it in a much better fashion.
This is an exciting, highly differentiated use case. The third area, this is a diagram we picked up from the internet, how people try to do this kind of cloud protection with workloads. Firewalls, VPNs to go out, to come back in, VPN to data center, all that mess. For segmentation, we got a very cool approach where Edgewise gave us the very important IP. Being able to create identity of software, identity of workloads. Okay? That's the core IP we bought. Now within a public cloud, you can say, "This app can talk to this app, but this app can't talk to this app." All this is powered by a bunch of sophisticated machine learning models. Because when you have lots of workloads, lots of policies, you need automation, and ML is playing a big role. The segmentation policies are automatically generated.
Otherwise, operationally, it'll be very hard to do. It's great benefits in terms of operational benefits without a lot of overhead and the risk reduction. This is a younger market. It's going to take some time as customers are getting educated in this area. Fourth is really the overall benefit. Once you got your stuff in the cloud, just like I'm showing here, in the old world, you would be going back to the data center and going back site to site over. Now, with ZPA, all these workloads can be accessed directly through us. They could be in your data center, they could be in GCP, Azure, and AWS. This thing kind of rounds out the benefit customers are driving. In summary, public cloud is happening. We all know that traditional security is a problem in a public cloud. It doesn't work. The new approaches are needed.
Really, that's what we have built here, essentially extending zero trust to public cloud. That's number one point. Number two, think of the opportunity. Just like endpoints are looking at saying, "I want to take EDR to servers," here we're saying, "I need to take user-to-app communication, zero trust technology for app-to-app or workload-to-workload communication." It expands our TAM quite a bit. With those remarks, Bill.
Okay. Thank you. Now we'll start the Q&A session. As a reminder, please use the raise hand function if you want to ask a question. Our first question will come from Andy Nowinski from D.A. Davidson. Please go ahead with your question.
All right. Thank you, gentlemen. Very helpful. It was good to listen to a lot of the presentations yesterday as well. Maybe I'll start with a clarification. On the slide you just presented today, you said that ZPA is a cross-sell, but it does seem like it's maybe the opposite. Wouldn't they deploy ZCP first, or excuse me, they wouldn't deploy ZCP without first running ZPA. It seems like ZCP, the cloud platform, is actually your cross-sell that you'd sell into all your accounts that are running either ZIA or ZPA already, right?
It's a good question. First of all, when I use the word cross-sell, I said we already are selling ZPA for data center VPN replacement. It becomes one more opportunity to be able to go to public cloud. Okay, that's one. The second part is actually there's no proper sequence to embrace ZCP if you look at the three pieces of ZCP out there. We think CSPM, security posture management, and the second part where I said workload communication within a kind of cloud-to-cloud and cloud-to-internet, both of those products are being asked for by our customers today. So you can be starting, some of our customers are starting with the CSPM, some are starting with workload communication. ZPA will be needed by everyone. We believe that every customer of Zscaler eventually will have ZIA, ZPA, and ZDX.
Once you have those three things, you can access any application, internal, external, and with ZDX, you can know the performance. Security and user performance both get solved.
That makes sense, Jay. Thank you. Last question from me. Can you just give an example of an unprotected workload at one of a Zscaler customer? A Zscaler customer is already committed to transforming their network infrastructure. They're already running, presumably, a next-gen architecture. They're not running a legacy architecture. What are they using to protect. Presumably, they're already, some of the workloads are in the cloud as well already that are Zscaler customers. What have they been using, or have they just not been protecting these workloads in the past?
I'll start, and Amit, you can add to it. We have a tool called Internet Attack Surface. We point to a given company called acme.com, for example, and see what can I see out there without sending any active traffic. A lot of information sitting in Google and Shodan and the like. We see so many workloads that can be discovered, that can be attacked. In many cases, customer doesn't even know about it's being exposed. They need a tool like CSPM to identify it, for example. In many cases, they can fix the configuration. In many cases, then they will need , some will be exposed, they need to go through a tool like ZPA, so they don't expose them to the internet. There's a lack of education in some cases, and there's a lack of the right technologies on other cases.
Amit, you want to add things to what I said?
Yeah, absolutely. I think, Andrew, there's a lot of cloud sprawl that is happening. If you look at ZIA and ZPA predominantly, we have been protecting users accessing applications either in the internet, SaaS, or in private workloads that require a VPN. As applications are moving to the cloud, things are sprawling. You might be moving an SAP application, maybe the back end is sitting in your data center, the front end is moved to Azure. How is Azure talking to your data center, right? Those are the kind of use cases that are greenfield opportunities for us to expand into, right? Similarly, as more applications move to AWS, what is happening is people are bringing the traditional data center thinking into AWS, right? I had a firewall here, let me deploy firewalls. Let me do VLAN segmentations.
That architecture that Jay was sharing becomes hairy very quickly, right? Because now you're talking about this VPC talking to this VPC going through a transit gateway. Well, the internet access is available only from this transit gateway. All of these are sort of greenfield opportunities as we start getting into app-to-app communication because people are just still thinking of their legacy way of doing it in the data center, except now they are trying to move it to AWS and Azure. We believe that many of the zero trust concepts that we brought to secure user-to-app communication naturally extend into cloud workloads. It starts off with those three things. One, as I get into AWS and Azure and GCP, configuration management is the number one problem, right? Do I have an open S3 bucket?
Maybe I was doing some QA testing, took an entire customer database and put it in an S3 bucket somewhere, and it was left open, right? Those workloads have never traditionally been part of the Zscaler ecosystem, and cloud protection brings that into the fold.
Thank you.
Okay. Our next question will come from Hamza Fodderwala at Morgan Stanley.
Hey, guys. Thank you so much for taking my question, and thank you for doing this product presentation. Very clear. I wanted to get your early sense about what you see as a market opportunity here, right? Because you mentioned a few times, this really expands the TAM for you. Amit mentioned bringing you into a lot of greenfield spaces. I guess, for Jay, Amit, and even Bill, how are you thinking about framing that market opportunity as you move to a more workload model? Said another way, there's going to be roughly $100 billion or so in PaaS IaaS spend today. That's probably going to grow, let's say, by double over the next three to five years. What percentage of that do you think is going to be a workload protection solution like this?
The unit of opportunity for us is number of workloads.
Okay.
Yeah. The bigger the market, we will charge by workloads. Every workloads need to be how we charge for your security posture, how many workloads are we monitoring and really look in the posture. How many workloads are talking to each other. It's essentially based on that. That's how we see the opportunity. We think with public cloud, those workloads are going to keep on growing and growing, and then they'll need someone like us to protect it. Do we have an idea to quantify it? At this stage, it's probably too early. Do we get a sense that it's a pretty big TAM opportunity? Yes.
Yeah. CSPM, workload segmentation, and workload communication all will be priced on a per workload basis. We'll discuss the TAM at our Analyst Day, which will be in January. Okay. Next question will come from-
No. No.
Oh, thanks. Next question will come from Joshua Tilton at Berenberg.
Yeah. Hey, guys. Can you hear me?
Yes.
Just a quick one from me. I just wanted to touch on the workload segmentation feature. Just, I understand it's early, but who have you identified as your competition in this space? How much of a moat would you say do you really have around an identity-based segmentation strategy? In other words, why can't others come out and mirror this with their own identity-based approach?
I'm sure, Amit, you want to take it.
I can share some insights. Patrick has deeper insights. It's a good question, Joshua. In order to look at this space, again, the traditional thinking has been, "I know how to build a firewall. Let me bring virtual firewalls into my AWS or GCP workloads. I'm going to have static ports and protocol-based rules that says, 'Here's my UI server, and it's only allowed to talk to this database server over this port.'" We all know that that does not stop lateral propagation from happening, because once one workload is infected, malware knows how to exploit static rules and propagate laterally. We believe that traditional thinking, even the Illumio of the world, are thinking more around traditional network-based segmentation inside a modern cloud workload. The identity-based approach requires a complete re-architecture, right? When we say identity, we are looking at multiple attributes.
We are looking at, well, this is a UI process, and there is a lot of fingerprinting that is going on. What machine is it running on? What MAC address is it coming from? there's lists of attributes that go into asserting a strong identity for that particular process. Doing it at scale is a hard engineering problem, right? You're sitting right in the middle of a very high-speed communication that might be happening between one workload and another workload inside, say, AWS or Azure. doing it at scale is a hard engineering problem. It's not just a simple identity. It's multiple different attributes going into fingerprinting that identity. That's a tough problem. The third problem to solve is how do you simplify the deployment, right?
We use machine learning-based auto segmentation, where you click on a button and the workload segmentation will look at the topology of your application and say, "This is how it needs to communicate." That simplifies the DevOps cycle dramatically. You're not tinkering with manual rules. In a complex application, you could have thousands of different pathways. How do you automatically discover and say, "This is legit, this is not legit?" All of those are hard engineering problems that we've built IP on. Most people in this space are still traditionally thinking of static and a network-based isolation principles that just don't work. Patrick, do you want to add anything to that?
Oh, that was good. Maybe just to emphasize that point or pile on to that point that Amit was making. Almost every other solution in the space, like Amit was saying, is network-centric, meaning it's IP address, it's a traditional firewall or ACL-based approach. That's why projects like micro-segmentation have been so much of a failure. We rarely see customers have, they may have implemented micro-segmentation in one piece or part of their network, but not holistically, not across the organization. The approach that we have, like Amit was saying, is identity-based, and it's a much lower-level approach. It's not at the network level. It's at the process level. It's a lower level that gives us a much stronger form of identity that is just not possible if you're doing this at the network level.
Yeah. Our belief is that the traditional firewall network-centric approach won't work based on what we're seeing from the customers. It's an opportunity for us. I've talked to many customers, some of the forward thinkers who said, "We would love to do segmentation. We have tried product A, B, and C. It just doesn't work." We think our approach is very promising. Having said that, I'll say this is a younger market. It needs fair amount of education, but I would rather be in a younger market and educate the market than try to go later on and become a me-too.
Thanks, guys.
Okay, thank you. Our next question will come from Taz Koujalgi at Guggenheim. Please go ahead.
Hey, guys. Thanks for taking my question. Two questions. First one is, it looks like some of the functionality you have in ZCP will overlap with, I guess, native functionality you get from the cloud vendors, AWS, I guess security gateways, and Azure firewalls. How do you address the fact that you would be competing with the, I guess, the cloud vendors in some areas with the ZCP product?
Every cloud vendor will have some piece here and there. I mean, would Microsoft do some kind of firewall? Yes. okay, what does that firewall do? If you really look at what our CISOs are telling us, that every server, I shouldn't say every, most workloads talk to the internet from the public cloud. what do they need to protect? Number one, cyber threats. Number two, data loss. All those connections are SSL encrypted. Somebody needs a proxy architecture with a multi-tenancy, so simply send the traffic to some cloud and say, "Go." As our Fortune 500 Global 2000 customers had deployed ZIA, they basically say, "Huh, I can use ZIA technology for policy enforcement, for DLP, and cyber threats.
I had no way to really figure out and send the right traffic off a given cloud." With our cloud connector that's powering the technology, you could have the traffic coming from AWS, Azure, DLP, VMware, your own data center, same policy, same protection. It's very compelling. Will some of the firewall functionality from AWS or Microsoft get in the middle of it? We don't think so. Will those firewalls do some level of macro network segments? Probably, yes. That's fine. I think the opportunity is big for us, especially for large customers who understand the value of our platform.
That's very helpful. Just one follow-up. One thing we hear from CIOs is that the world is moving more towards a hybrid architecture, a more multi-cloud world. People are not going to be using just one cloud. We'll have people using AWS, Azure, and GCP.
Yep.
Will the ZCP product work across clouds and across on-prem and cloud, or will it be limited to just the workloads which are residing within a certain cloud?
Amit?
That's a great question. I mean, you answered your question yourself, Taz. We are designed for a hybrid cloud world. Cloud Connector works on Azure and AWS and GCP. It also works on your VMware-based data center, where have you. Since we're not living in the walled garden of AWS, you need a uniform approach that can allow any workload to talk to any workload regardless of the infrastructure it is hosted in. To some extent, firewalls have already existed in AWS and Azure. That's how VPCs are designed. I mean, my router has a built-in firewall. We need to up level and talk about how do we have workloads across multiple different infrastructures talk seamlessly through a common policy engine, through a common Zero Trust Exchange platform. That's really what we've built. Most organizations are not going to just bet on one cloud provider.
They will have scattered and distributed workloads, and they will need to have consistent policies across all of them. Cloud Connector enables that, definitely. does CSPMs and workload segmentation. They work regardless of the underlying infrastructure.
Just one follow-up, if I may. This would be a service. It's a SaaS. You're not deploying a software on a VM in AWS or Azure, correct?
Right. All three services are SaaS. The CSPM is a SaaS service. With APIs, you point to your cloud workload. We give you all the misconfigurations and auto remediation options. With Cloud Connector, you can auto magically provision and auto scale, whatever is needed based on your workload, regardless of, again, the infrastructure it is deployed in. It is all based on the same subscription model. Instead of users, we'll go more towards a workload-based subscription. It is all a SaaS service.
Thank you, guys. Very helpful. Thanks.
Okay. We'll take our next question from Alex Henderson at Needham. Please go ahead with your question.
Great. Thank you very much. I would hope to get some detail on a couple of elements. First off, do you need to sell this to the DevOps teams? Do you sell into the shift-left community? Is this primarily going to be sold to the IT administrator, the SecOps teams back at the corporate? When you define a workload, if I take an application and I deploy it across a-
Just hypothetically, Akamai's 4,000 locations. Is that considered a workload, or is that considered 4,000 workloads because it's running it in 4,000 different locations? The last piece I just wanted you to clarify is, obviously policy is critical here, policy management problems with the flow-based architectures of the Palo Altos of the world have been a huge impediment. I assume that this is a per user, per application policy implementation going forward, which I think is core to your architecture. Is that accurate? Thank you.
Let me start with the first one. You have a three-part question. The first one, who is the buyer? Okay. The buyer could come from DevOps side of it, or it could come from security operation, network operation side of it. Our primary buyer of Zscaler today has been starting with CIO to enable transformation, with head of infrastructure and head of security have been the primary three buyers. For example, the one thing our customers have been asking for a long time is, and this is being asked by the CISO and the CIO. My users go out to the internet through you. My workloads need to go through you with the same security, same data protection type of stuff. Yes, DevOps gets brought into the loop, but our primary starts from the production side of it, from the security operation side of it.
Over time, we'll get to both ways, but there are two decision makers. DevOps is an important player, but who runs the operation security and all is important as well. That's part number one. Part number two, Amit, you want to take that?
Yeah. What was the specific part two question?
The question is, if you're defining a definition of a workload here.
Yeah
People think about a monolithic application running on a single server as a workload, but obviously in a CI/CD pipelining world, they could be highly distributed and therefore implemented in thousands of locations.
Right. The concept of a workload is pretty well-defined in public cloud infrastructure, right? For example, when we do our CSPM scans, a typical organization might have a few thousand workloads. We're not counting instances like a CDN scenario where you have 4,000 copies of the same thing as a workload. However, if you have a VM, that's a clear workload. If you have a Kubernetes cluster with X number of running instances, that's a workload. Similarly, you might have a serverless workload, right? Those concepts are well understood within the AWS framework or the Azure framework because they bill you based on it, right? It's not an ambiguous concept, and we're going to piggyback on that.
There was a third part.
The last piece was on the policy.
Right. yeah, I guess your question was, we've traditionally been a user-to-app policy. How does that translate to a app-to-app world? How does that translate to a workload or process-to-process world? I'd say it translates quite naturally, right? When you're able to implement policies for an organization with 400,000 users talking to millions of applications, being able to translate that to a few thousand workloads, talking to a few other thousand workloads is relatively simple. The amount of traffic per workload goes up, but the complexity of the policy decision trees is actually getting simplified. We've done it at a bigger scale, and bringing it back to a more manageable scale is easy.
Right. Just to expand, just like today for user, we can do a specific user to whatever. Here we can do a specific workload-based policy, or you can have a group of workloads, either way.
Think of it this way, Alex, right? Today, for an organization like Siemens with 400,000 user, you can go to the Zscaler console and for every user have a specific user-level policy for every destination, and we'll support it, right? No organization wants to do it that way, but we have that kind of scalability built in. A workload is a little more static, right? You might have a server that needs to go to the internet to download the latest Linux patch update, right? So those are a little more manageable. Since we've done it at that user scale, the ability to translate it to a workload scale is easier for us.
Great. Thank you for taking my question.
Okay, great. Our next question will come from Brian Essex at Goldman Sachs. Please go ahead with your question.
Great. Thank you for taking the question. I appreciate it, and thank you for doing this. Maybe I was just wondering, kind of back to the competitive environment, you see a number of your different peers in the market approaching this from an endpoint perspective or platform perspective or a developer perspective, you guys from a network access perspective. How do you see yourself differentiating yourselves from some of those vendors, some of which are partners of yours, particularly maybe compared to like a CrowdStrike who's approaching the cloud workload protection market in a little bit of a different way, but with a different construct in that they can have contextual data around access and workloads?
Yeah. I think we think through the ecosystem in a pretty meaningful way. Yeah. What's endpoint vendors doing? Here's my EDR. Since there are lots of workloads, I should run the same thing on my workload to make sure nothing malicious is going on. It is just like the device protection, it's the workload security by running AV. Now, just because you got CrowdStrike or Microsoft or VMware endpoint, you still need Zscaler. We are the switchboard. We are sitting in between. If you talk about that stuff, you're talking about which workload can talk to which workload and under what policy. When my workload talks to internet, somebody has to sit in the middle.
It's like an international airport, who goes, "We are sitting in an ideal position to connect the right party to right party." Now, that doesn't eliminate the need for having a host endpoint software or say, workload software sitting for doing the kind of security endpoint does. It's complementary to us. We are in between communication from A to B. That's how we look at it differently. Now, the other one, who else did you mention? Endpoint to us is very complementary.
Mm-hmm. Okay. maybe just-
Also, Brian, one point I'd add there is, as you think of the way the world is evolving, it's moving more and more from my data center to VMs in AWS to serverless and Lambda functions and just as a service. I'm running BigQuery, I'm running Snowflake. all of these, where will you put your endpoint agents? Kind of the same concept that we thought about when we said, "Hey, how do you run this on your iPhone on a 5G network?" if you think forward, the firewall vendors will think of virtualizing firewalls and running it in the cloud. The endpoint vendors will think about virtualizing their endpoints and running it in a VM host. As you move to more kind of, there's the pure SaaS for which we do CASB, and then there is more and more just serverless computing.
That's where CSPM is very important. That's where the ability to do policy. This Lambda function can talk to that internet workload, but that's it. How do you do it without putting endpoints becomes an important criteria.
Right. We like our switchboard function. We are the switchboard. Who should talk to who based on the policy.
Okay, great. Maybe one just quick follow-up is, are you applicable to development as well as runtime?
Patrick?
Applicable to development and as well as runtime. When we come in line, we're coming in line as a process on the machine that is at runtime. It's not in the development CI/CD pipeline. We would be complementary to some of the things that would run there. We're an inline runtime agent.
Got it. Super helpful. Thank you very much.
Sure.
Okay, our next question will come from Matt Hedberg at RBC. Please go ahead with your question.
Hey, guys. Thanks for taking my question. Thanks for doing this. Just one from me. I wanted to come at the TAM opportunity from a little different perspective. Obviously, ZIA and ZPA are seat-based pricing. In some of your early conversations with some early adopters of ZCP, if they're spending a dollar on ZIA and a dollar on ZPA, any sense for could ZCP be 50 cents? Could it be a dollar, $1.50? Just even from a magnitude perspective, how do they think about the spend in this category relative to your other categories?
Early stage, we're collecting data. In fact, we are early pricing. We've got to learn from the customer. I think it'll be probably a little bit too early to give you some data points. Probably in a few months, we'll have much better data points. The data points are learning.
Maybe then just-
Purely learning point of view right now.
I guess maybe from those data points, from some customers that have looked at it early, maybe pilot phase customers, beta customers, what have they been most happy with so far?
I think it's a range. We are finding that some customers, we try to go and get them early on with very attractive price. Some have tried to pay pretty significant, so the gap is quite big. We'd rather narrow it down before we share the numbers with you, because that's how we'll finalize our price as well, based on what the market is looking for. Give us a few months. We'll have it. We'll share the data.
Great. Well, the event was great. Thanks again, guys.
Okay, thank you. Our next question will come from Brad Zelnick at Credit Suisse. Brad, go ahead with your question.
Hey, guys. Nice to see everybody, and thanks so much for hosting the event. Jay, or for yourself or Amit or Patrick even, how should we think about ZCP pairing with SD-WAN, as it seems like you're adding the application awareness that SD-WAN is based on? Maybe in context with your VMware partnership, which I know you've expanded recently, how should we think about the selling motion and how this could pair with what they're doing with NSX and network segmentation with the workload segmentation that you've announced?
Right. We look at Zscaler as independent of the network. We like to say that we have totally decoupled application access from network access. Even questions get asked to us and say, "What are you doing with SD-WANs?" Say, we can take traffic from SD-WAN or a router, it's the same thing to us. It really doesn't matter. I think when it comes to the market of segmentation, this market is relatively young out there at this stage. In fact, if you ask me how many customers have done network segmentation or any kind of app segmentation successfully, those numbers are very small.
Okay.
Do we have enough data on the approaches? We don't. Yes, are we aware of the network segmentation that VMware is doing? Yes. I think it remains to be seen where the market evolves, but we like the zero trust approach where we are totally independent of the network. Now, the three areas I talked to you about our functionality, I think CSPM is ready for prime time because customers who have already deployed hundreds of thousands of workload, they need security posture and policy configuration. The communication between the data center and public cloud, or public cloud to internet, or communication between Azure East and Azure West without connecting the network. There's a big need out there for that piece. the Cloud Connector is actually enabling and empowering that piece. that's actually that market is ready to go.
The third piece, if you talk on a micro-segmentation level, early stage, we're learning and figuring out, as I said, we'd rather educate the market upfront. To answer your questions, I would say, haven't seen enough data out there.
Fair enough. Jay, thank you for that, and it's always nice to see you pushing beyond limits.
Thank you.
Okay, thanks. Our next question will come from Walter Pritchard at Citi. Walter, please go ahead with your question.
Yep, thanks. Thanks, everybody. Just two things. One, just want to be clear on what actually has to be deployed in the customer's network to be able to or what you have to have access to be able to do the sort of three things you're talking about. That's just a clarification. I'm wondering, as you think about container serverless, I mean, everybody's coming at this from a different angle. You have the sort of traditional workload that's a VM. You have virtual firewalls. You have the sort of cutting-edge workloads that are not very deployed, but they're solutions today. I mean, all the providers seem like they're taking a different approach on these different workloads. I'm curious how you expect to see your cloud workload protection offerings adopted initially versus where we're seeing some of these others adopted.
Everybody's got a very small initial footprint.
Mm-hmm. Patrick, you want to start with that? Amit, you can add on.
Yeah, I can tackle the what you deploy, the first part of the question. The answer varies depending on which part of the suite or entire cloud protection bundle that you're deploying. If it's the security posture element, that's just an API integration. There's nothing you're really deploying. You're configuring APIs and enabling us to have access to what you're governing there. If it's the workload communication, that is a new component that we call a Cloud Connector, and that is something very similar to what customers already deploy when they run a VM or a piece of software from us in their environment. That's what the Cloud Connector is. That's the form factor. The workload segmentation, that's actually a piece of software that gets installed in the existing. It's not a VM or something on the side of the network.
It's installed on the existing machine or container that's running the workload, technically speaking, it's a kernel security module. It's a software process that goes onto where the workloads are already running. Hopefully, I touched on those are the three.
Yeah. That's actually very specific and helpful. Thank you.
Sure.
I'm just curious kind of how you think people will come, like, different If we hear success here in six months, where do you think we'll hear the initial success? What type of workloads? What scenarios? Because it seems like everybody has a bit of success in this market, but nobody really has any share today.
That's correct, because the markets are young, right?
Right.
Our installed customer base is all looking for CSPM.
Right.
That's number one, right? I think that second area, what we call workload communication, we are very unique in that area. I want my workloads to be able to talk to internet. Any Zscaler customer will say, "Huh, I know that with ZIA gives me such a great security and DLP. Now I can take it to my workloads," a new market for us. Being able to talk among workloads. I haven't seen anyone do zero trust-based communication among those things. We're seeing, like, what do customers do? My data center should be connected to my AWS, my data center to Azure, my data center this. They're actually extending the networks over.
We have seen situations where something got actually hacked in a public cloud because of bad configurations, and the malicious actor could actually traverse over to the data center because of the networks are connected with each other. We bring a unique benefit in that deployment. We expect our workload communication to actually have very good traction. The third area, I said before, it is really nascent, and customers are figuring out, and it's not easy, micro-segmentation at that level, and that market will probably take the longest time. The first two, we are feeling very good based on the traction we've seen.
Okay, great. Thank you.
Okay, thank you. Our next question will come from Sterling Auty at JPMorgan. Sterling, please go ahead.
Yeah, thanks, guys. Actually, that was a great segue. Thanks, Walter. I wanted to know what was deployed on the client side, but now let's go to the other side and understand where are you actually delivering the solution from in terms of Zscaler. Is this running out of your public cloud footprint or your private cloud, and is the entire ZCP available globally, or how are you thinking about rolling it out region by region?
Amit?
Yeah. The three components of ZCP, cloud security, posture management, it's a SaaS service. It's available today. As we mentioned earlier, all you need is to authorize us to scan your AWS tenant or Azure tenant. It discovers and tells you all the misconfigurations. Available globally. Nothing needs to be deployed on the customer's VPC, for example, right? The cloud connector piece, which is connecting workloads to the internet or workload to workload across data centers or across between two clouds, that does require a VM. That VM is 100% managed, orchestrated by the Zscaler cloud. The VM runs in your AWS VPC or in your Azure VPC. It dramatically simplifies your VPC design. You don't need to have complex gateways, transit, VPCs, and all that other stuff that traditionally goes into designing these. It is like other virtual components that customers deploy from Zscaler, right?
When they deploy ZIA, they might deploy a log streaming service, they might deploy a virtual ZEN or a Private Service Edge, which is extending onto their particular section, right? Again, that's available globally and
Hey, Amit, if I may, one comment to that before you move on to the next topic.
Right.
It's like a traffic cop. There's not a whole lot to it.
Right.
The difference is when you deploy a firewall, you're talking with a policies index stuff. This is a traffic cop that's really directing traffic where it needs to go. Hence, it's a much simpler deployment and ongoing operational stuff.
Think of it as, today users deploy a Zscaler Client Connector on their laptop. It's a lightweight traffic forwarding agent. This is, instead of a client connector, it's a Cloud Connector. It is sitting in your cloud where your workloads are and forwarding traffic either to other workloads or to the internet, right? That's available, again, globally. Nothing needed except deploying this particular small agent on your VPC. The third bit, for the workload segmentation, it's a nascent area that does require this little bit of a host type agent that is deployed on those workloads. Again, that's available. That customer has to do it on their inside their workload. It's available wherever customers want to try it.
All right. Sounds good. Thank you.
Folks, I need to jump and host a CISO panel.
No worries. Yeah.
Thank you.
Thank you, Amit. Okay, our next question will come from Roger Boyd at UBS. Roger, go ahead with your question.
Can you hear me?
Yes.
Very good. Thanks. On for Fatima this afternoon. I guess thinking about with the addition of ZCP and CSPM finding a home there, does that change how you're thinking about, I guess, the modular add-on approach around ZIA in the past? maybe if we'll see some new bundles around more of the converged CASB, secure web gateway, DLP, that seems to resonate well.
I think it's too early for us to make the decision. We'd like to get some traction, see the degree of traction, then eventually over time, we create bundles. Right now, we are individually selling ZCP solutions being presented, and based on the customer interest, we're selling it. over time, you can expect us to bundle it in certain things.
Perfect. I guess going back to the DevOps pipeline, given the fact that you're focused on runtime and not being sort of into the pre-deployment phase, how are you thinking about areas to maybe partner integrate with the toolset that is in the CI/CD pipeline?
Patrick.
We're actually very complementary or almost agnostic to what's being done in the development pipeline. We're not a firewall. We're saying it's a much better approach, but just like a firewall is non-intrusive to that pipeline and is completely out of the picture, the same is true for what we're doing as well.
Okay. Thank you very much.
Okay. Thank you. Our next question will come from Walter Price at Allianz. Walter, please ask your question.
Sure. Thanks. I don't know if you can hear me.
Yes, we can hear you.
My question is, in the cloud, the most famous breaches have been the Capital One, AWS, and then recently this FireEye breach yesterday, where people steal identity and then go into a workload that they shouldn't have access to, either tangentially in the case of Capital One or in the case of FireEye, they misrepresented themselves as a customer. I think that's probably a really common way that nation states attack workloads that they want to get. How does your solution solve that problem?
See, at the highest level, if you think about most threats come because someone gets on your network and can laterally move left and right, discover other services. If they're not patched properly, get into them. The whole trust of zero trust is a switchboard approach. You connect someone to a particular application or service, don't put them on the network. That's what we have been trying to do with users. Now we are taking the same zero trust approach to servers. I think as more and more companies do this, the notion of you're on my network, inside, outside, if that starts disappearing, life will get much better. Now, would I say there won't ever be any security hacks? Not really. I think security posture will get much, much better. The zero trust approach, our customers are swearing by it.
Thank you.
Okay.
If I could- Oh, sorry.
I'm sorry, go ahead, Patrick. Did you have anything to say?
I was just going to add, just Capital One breach is very well-known and dissected. There was multiple places where we could have helped in that. The first place was, it was a misconfigured service in AWS, and that is core to what CSPM is meant to help discover and remediate. Obviously, that was then used to do subsequent malicious activity, and that's where, Jay, the workload protection and being in line in the runtime protection is what helps then solve that if they're already in as well. We kind of tackle it in the Capital One scenario in a couple different places.
Okay. Thank you, Patrick. We have time for one more question, and our last question will come from Michael Turits at KeyBanc Capital Markets. Michael, please ask your question. Michael, you will have to unmute.
That should do it. You guys got me? Thanks.
We can hear you.
Great. Congratulations on this. It does look like a big expansion to TAM, as you said, and a real broadening of what you're doing, from a really strong architecture and platform. My question is this, what you've done to date has largely been a networking service. You've protected users from applications and workloads. When you move into the cloud, whether you're doing posture management or looking at the connections between quote workloads, those workloads are based on very distributed applications. It requires a level of knowledge to understanding mapping of all those applications that wasn't really necessary for the prior types of security that you delivered. How have you built that expertise? I know you've made acquisitions. In that sense, this is somewhat of a new area for you.
I'll start, and Patrick, you can add. The core technology we are leveraging is our Zero Trust Exchange. What we have built over the past several years with ZPA, for example, and as some of the same principles apply to ZIA as well, but with ZPA especially, a switchboard approach. A user comes to us, we validate who you are, we look in the policy, we connect you to a particular application or service. A switchboard is not just meant for users. It's meant to say a known entity to known entity, and we connect you if the policy says yes. We needed to know the identity of workloads. In the case of micro-segmentation type of stuff, Edgewise Networks brought it to us. In the case of others, Patrick, maybe you can expand the second area, because we're seeing easy traction of workload communication from our customers.
Why do you think it's easy for us to take over the workload communication market? There are three, four use cases we talk about. Workload to internet, cloud to cloud, data center to cloud, independent of the network. That market is made for us. Maybe expand upon that a little bit.
Yeah, I would add to that saying that it's actually not as big of a leap as I think was being characterized from the standpoint that if you look at our customer base, we have many customers already on our ZIA offering that is not, they're not just sending us user traffic. They're taking their workloads that they've deployed in these environments, and they're actually forcing it via a network tunnel to go through our ZIA security stack, so that we can help secure that already. We're already in line to workload traffic already, even to the point that that's a SKU now that we've been charging customers for years for. We also, on the ZPA side, a core fundamental component of ZPA is to define named applications, which is workload environments.
in ZPA, we've already had to figure out how to discover applications that exist, i.e. workloads, map them, understand the context of why they are in scope, because it's never just an IP address or just a name of a host. It's much wider and broader than that, so we had to build application segments and all the hierarchy around that as well. I'd say it's not that big of a leap. We're already in this space already.
Great. Thanks a lot, I think really congratulations on this broadening.
Thank you.
Thank you.
I want to thank you all for your questions. If you have any questions remaining, please send those to ir@zscaler.com, and we will respond promptly. We will also have today's presentation available for download on our IR website very soon. We're excited about our additional opportunity to disrupt the data center, just as we are doing for enterprise perimeter. We want to thank you for your interest in Zscaler. This concludes our innovation briefing. Speak with you soon.