Zscaler, Inc. (ZS) Earnings Call Transcript & Summary

Great, thank you very much. My name is Alex Henderson. I am the security analyst at Needham. It's a pleasure to have Zscaler here, one of my favorite companies and one of my favorite management teams too. So it's really going to be a fun 40 minutes. Just for reminder, if you have a question and want to ask it, just there's a dialogue box. Just type it in and I'll relay it to management. And with that, welcome, guys.

Thank you.

Thank you, Alex.

So I am convinced that we are at the cusp of the largest transition in network architecture that's happened in -- since I started in the business in 1986. And I don't think The Street quite grasp just how big a transition this is and how much wood there is behind the arrowhead driving that transition. So with your technology, you take the user off the enterprise network and there's really no reason why that user should be on there with microservices, Kubernetes, CI/CD pipelining, code as infrastructure, we are driving enormous change in how applications are written that is driving enormous impact on how companies think about those applications. Those applications that are inside a container with the workload infrastructure needed to run them sit on top of a runtime environment and are separate from that runtime environment. So they simply become points in the cloud where the API gateway is exposed and says, "Hello world. In that world, we have an architecture where applications and users are simply points in the cloud, and we need to connect them and secure them. Is that where we're going? Because I think if it is, you guys are perfectly positioned to drive that connectivity and that security. Can you talk about the change in enterprise architecture and how important that is to your story and to securing the world as we move forward?

Alex, absolutely yes. I mean the point you made was actually even that offers further opportunities. First of all, applications are moving to the cloud. They're no longer sitting contained. They're going to many cloud availability zones and agents. Then they are becoming microservices and are getting pushed to the edge. That means applications will be everywhere. You can't be extending your network everywhere to say, this is my perimeter, this is my -- as you said, they become points. I'd like to call them islands. They should be islands out there. There is no pathway that always interconnects them. You go through a Zero Trust Exchange, which is like a switchboard to connect the right entity to right entity. That entity could be a user going to application. It could be workload going to workload. I'm going to use a couple of slides to set the stage because visually it's easier to understand. Otherwise, everything sounds and looks like the same. So let me talk to the network change we are talking about, which drives the security change. The last mega change that happened in networking happened in about 1990s when IBM era ended, if you are old enough to recall SNA network. Cisco was born to build the modern network. And with that switching and routing technology of Cisco, they said, look, if you have various branches, I will extend your network to every branch office. If users get on the network, they can access applications. That's wonderful. Then we said, "Wow, but we want to work from home." Let's invent VPN. So we can extend our corporate network to every household, which is what we have been doing. Then we said we want to embrace public cloud, let's extend our network to every cloud providers every region because applications and users must be on the same network very basic principle. That's how we have done things for 30 years. And then we said we don't like to buy appliances. We want cloud. So network security vendors try to say, "I got virtual firewalls in the cloud and I'm a cloud service, okay. But they won't tell you that firewall and VPNs are network devices and IP devices. They extend your network wherever they are. So this gold color line is all becomes a corporate network. And the more location you break out at the more you are attack surface. So first, they find you. Bad guys find you based on your attack surface. Anything that resolves to open Internet is your attack surface. Firewall, VPN, any apps, number one. Number two, they want to compromise. Once they find you, they come after you. Every bad thing comes on the Internet when your users interact with Internet, they can get infected from phishing and zero-day attacks and whatnot. Once they infect something out there that becomes a feature and they want to move laterally so they can find high-value target. That's what happened to Maersk, a mega shipping company. That's what happened at Colonial Pipeline when they stole VPN credentials, got on the network and moved laterally to find billings as the high-value application. It's like getting on U.S. highway in San Fran on I-80, I can reach New York, Miami or Chicago without hitting a single light, okay? That's the good news. That's a bad news. And then they want to steal your data. And all that data gets sent to the Internet. Hence, you need to make sure you protect it. So our philosophy in this new world is not around building a perimeter on everything. It's making sure they can find you, your attack surface goes away. They can compromise you with proper inspection. They can move laterally so they're not on the network and they can steal your data. That's really what led us to really build the service, whereby the old world is like allowing a visitor unescorted in your building, so they can wander around and go to any room and every room while they're supposed to go to say Room #22. In fact, buildings that are adjacent are interconnected, they all become risky, just like your branch offices with the data center. The right approach is, your buildings will have no names. They go dark. No knows what they are. Interconnectivity goes away. They become islands and reception moves far away from your headquarters. They still check my ID, if I want to come and see you, they give me a badge, but they'll say, Jay, stop, you'll be blindfolded and escorted to room 22 where your meeting is. Once your meeting happens, you got blindfolded and escorted out. That is like think of this, a building is like your data center or Azure, a room is like your application and that's what we need to connect. So with that in mind, the last comment I'll make on this slide are your applications of use at destination, there could be microservices. They could be full-blown applications, external, one kind, internal, your own. You go through an exchange, which does 2 things. One, they make a policy decision should this person or should this entity be allowed to connect; two, then they enforce policy by sitting in line. What are the policy decisions, this identity trust? Is this entity trusted. This is a device trust, can we trust this device. And the security trust or status is this something malicious? Just like you don't want dangerous luggage to get on the plane, you don't want malicious content to come in and infect you guys. And then you look at anomalous behavior for risk, you decide which application you can go to. It's like allowing you to say, you can go to Room 22, 24 and 26 and nowhere else, and then you actually establish the connection by sitting in line. This is for external, internal, is pretty similar with one difference that with the connector technology, you open an inside-out connection, so no outside-in connections allowed. With that, we eliminate your attack surface and applications are hidden behind us. They could be sitting in 100 locations, 200, doesn't matter. We find them, we connect the right user essentially connected only applications, There's no lateral movement. It's like going to Room 22 and 22 only. And besides that, this is the opposite of firewalls and VPN architecture. You can't bolt on these things on top of legacy technology. And then, of course, preventing compromise, but cyber inspection and DLP becomes fundamental. So this is the technology we built whereas you never own the network, you don't need to extend the perimeter and it's a multi-tenant Zero Trust architecture. This is the architecture that will happen is happening. It's the biggest change in networking since IBM era ended 30 years ago. Sorry, Alex, took a little bit longer. I hope it helped.

No, that's a great explanation. I want to stress the importance of the policy differential there. So when I think about policy implementation in the traditional architecture, you have a firewall and the traffic comes in and hits that firewall and you say, what is this traffic? Well, this traffic is e-mail. We'll send it over here, we'll decrypt it or not. And if there's something execution, we will send it to a sandbox. Conversely, if it's a voice over IP call probably don't have anything embedded in it, put it through port 40 directly. It's on a per flow basis. Now when we look at the architecture, you just described, that policy implementation is radically different.

Very different.

It's actually driven off of a policy on a per user and a per application and understanding that is, I think, a key differential.

And it's more than application, it's perception. And that's -- and why can this be done? Because this Zero Trust is a proxy architecture. Proxy says stop, who are you? I need to figure out before you go. A firewall is a pass-through. You don't terminate connection. You let the connection go while you're trying to decide, aren't they supposed to go here and there and whatnot. That's why proxy has always been the best architecture. When you need to inspect content, when you need to redirect content and whatnot, so proxy, multi-tenancy, ability to scale and then if you look at the policy in the firewall, typical policy is going from this source to this destination, that's the most common thing. Then they say, yes, we can do app ID, app based. As TLS1.3 is coming around, even that failed, you can even look in the header. Here, you need to make work with identity vendors to check identity. While a firewall may check basic identity but the SAML attributes that need to be obtained for conditional excellent line, that's not really designed for a firewall-based architecture. So there are multiple things. We figure out some of the things in our Zero Trust Exchange. We integrate with vendors like Microsoft and CrowdStrike to get some of the other stuff.

It's, I think, a big difference. If I were to look at the traditional firewalls taking a single-tenant architecture and pushing it to the cloud and saying it's a cloud native or scalable in the cloud. It may be scalable, but it certainly not solving that policy problem in any way because the policy hasn't articulated. And it puts the customer in a bad situation where they have to decide, are we going to do multiple policy architectures which I think is a real problem. One of the questions I think is really important is where are we in this process of change. I mean I think when you came public, we talked about hairpinning of traffic and people were like, what's that? Now that's become cauterized as cloud direct. And everybody knows what cloud direct means seemingly. But where are the CIO, CTO, CISOs, the Chief Financial Officer and Chief Executive Officers and even the Board of Directors on understanding this architectural change? And are any of them even thinking about eliminating that unnecessary and, in fact, poorly constructed network backbone?

Yes. So first of all, yes, 4 years ago, we still used to evangelize and talk about the need for going away from private MPLS networks and the like. And you used to think, are you guys crazy? Today, every CIO is looking at phasing out MPLS network. Now everyone is kind of saying, "I need to go...

Time out, time out, Jay. For people who may don't know what an MPLS network is and what role it plays, the MPLS network is multiprotocol label switching circuits that are set up by a service provider to connect a branch or a home office to a data center. And the typical company with 2,000-plus employees spends what, $25 million to $250 million a year on these circuits, it's a big chunk of change. So it's a very important point.

It's very true and maybe even further simplifying it. Think off before the U.S. interstate highway system was available. You could get private roads connecting your offices to your headquarters. I mean that's our private MPLS network state. So obviously, it's expensive. Now once the Internet highway is available, it's a lot cheaper, so you can actually use that to go up there securely. So they are going through changes. They're already making changes. This change didn't happen overnight. It's happening at a pace. Most enterprises now have done some degree of MPLS elimination. That's number one. The next fascinating thing that's happening at a faster pace is bringing Zero Trust in it. What does it mean? When you do SD-WAN, you're going over the Internet and you're saving money from MPLS network cost, but you're still a WAN. I showed the lateral movement, but you're still interconnected. In fact, our branch can still, in fact everything else. So the CIOs now are talking with us and say, how do I do Zero Trust SD-WAN? Okay. Where by my office becomes like Starbucks. My network is not extended to my office, and that's the next thing with Zero Trust is for the fueling and differentiating us and that's where we are still doing some level of evangelism in this area. That's -- but that's the next phase. And then the third phase comes is public workloads and cloud is not just moving from data center to the cloud. Cloud is giving enterprises flexibility. So if I'm a global company, I want some of my workloads to run in Singapore for local availability at high performance, some in Germany, some here and there. So your applications are spread. We'll be spreading on far more locations than they've ever been before, which really means in the traditional sense, they interconnect all these regions, my AWS east-based applications need to talk to AWS west-based application to AWS in U.K. and so on and so forth. They're building multipoint mesh network just like they build for the branch office. It's fascinating. That's what's going on today. And they are spinning some virtual firewalls and the like and then they say, our customers, Zscaler customers who have done Zero Trust with ZIA, ZPA, they kind of said, "Wow, I can do the same, the ZIA, ZPA for cloud workloads without building this multipoint network, that's not only costly. It facilitates lateral type movement, so in single in fact workload, in fact everything. So that's the next big phase we're seeing out there. So we are in very early stage with a massive opportunity in front of our security has lagged several years behind adoption of cloud applications.

So most of the focus that we've talked about so far is really focused on the user to the application connectivity. But increasingly, more and more of the traffic is actually application to application, domain to domain communication. Historically, applications running in the enterprise data centers were run on what I would describe as legacy appliance boxes that were specialized for certain purposes. Increasingly, those technologies are being bought by the coder and then put inside the container with the application, which is why you call it an application workload as opposed to calling it an application. That containerized application workload or code as infrastructure as it's called, is independent of the run time environment. So if that's the case, why won't enterprise private cloud data centers start to look like AWS, where the application is separate from the run time environment, the application workload securities responsibility of the design of the coder not the run time environment, this is the logical separation. And the run time environment is just an island that's running these application workloads. If that's the case, why would we even connect the data center to a branch or to a home office? And how big an opportunity is there for you to do to app to app, domain to domain Kubernetes orchestrated workloads?

So what you really described, Alex, if each workload sitting in a given region could be viewed as what you called a point, I call it sand islands, that's connected to the internet and users have access to Internet from their home or branch office wherever without you having to worry about having your special network, your simple internet access. And then the function of what I call a smart switchboard that who talks to who. There needs to be policy definition somewhere. And you couldn't be putting this policy in every container on its own. Otherwise, think of it. If all of the policy for security were to sit at everyone's PC, that doesn't scale. It doesn't work. So there are certain things that need to be put in at the endpoint of workload for security. There are certain things that need to be somewhat sitting in the cloud that figures out who talks to. It's a combination of those 2. Yes, there is a lot of discussion about developers being able to do secure, okay. There's a lot of discussion of security figuring on what to do, but here is what the reality is. When networking guys wanted to do security in the networking world, it never works because network leaders are focused on making sure the package flow without an interruption. Security tends to kind of get in the middle of it. So that's why there had to be cooperation between network and security, in the same way, developers have interest in making sure applications are built as fast as possible. They are not expert in security. So the CISO organization's role is evolving to work with these developers, not act as an overall cop and say, I will give it to you. But work as equal peers to figure out security gets done. Now workloads, you can put -- workload security is so confusing to everyone these days because 50 companies are born every 3 weeks. And everyone claims to do the same kind of stuff. You can put security of workloads in 2 buckets: Bucket #1, the workloads I'm building, are they safe from vulnerabilities. Because if the code, they're pulling in code like log forging, I mean, they're in trouble. So that needs to be sorted out when they are actually building the application. So workload scanning players are all there. Number two, are those have workloads configured properly? Configuration of workloads is like you have a massive hotel room. It has so many windows and doors and all these stuff. What should be closed? What should be open? It's based on how you use it. So that's the vulnerability -- sorry, configuration management. That's not in line. This is scanning. And then being able to scan and say, do right people have permission to access right workloads? This is like which guests can get to which room of the hotel room. Can they go to conference room or this room. So that's one part. That's where Gartner is coining a new term cloud-native application protection platform, CNAPP, which is a collection of a bunch of acronyms that are throwing at CSPM, CIEM and the like. That's one area. This is where it becomes close to a developer because when developers build the workloads, you can actually embed some of that stuff in it. Then this is the second point. Workload A needs to talk to workload B. There needs to be some central policy of switchboard that determines that. For that, you sit actually in line to figure out how do you get from A to B? The networking plays a role that today they build these point-to-point network. Tomorrow, with Zscaler approach, we are basically taking Zero Trust to workloads because workloads from communication point of view are like users. A user talks to Internet, a workload talks to Internet, user talks to workload, workloads talk to other workloads, who having that policy as a switchboard is the second part of workload security. While in the first part I explained, you have lots of vendors, the 100-plus vendors, they'll come and go. When it comes to sitting in line to enforce policy, our Zero Trust experience is actually very unique and it gives us a big, big barrier to entry. So we are focused on both areas. Our customers are moving to Zero Trust for workloads quickly because they understand Zero Trust because of user experience and then we expand to the rest.

So when I look at this architectural change, one of the things that I think is clear to me at least is that the adoption of microservices is a necessity for writing applications. Applications are what drives every enterprise sort of a ubiquitous need. Companies that are on legacy monolithic applications are inherently at a disadvantage to companies that use microservice based Kubernetes-driven applications because of the agility associated with continuously integrating, continuously deploying or CI/CD of those micro services out to running applications in the field, that happens 10 -- 5, 10x a day. So you're trying to get to run circles around any legacy product. Now there are roughly 750 million applications globally, and they're growing at a 30% clip. And penetrations of new applications with Kubernetes has gone from 15% to mid-20s currently and is expected to exceed 50% by '24. When I put those 2 numbers together, it implies a triple-digit growth rate on a huge base with an imperative around agility that makes it a necessity for any enterprise. Inherently that's the wood behind the arrowhead that forces this change in architecture. When you put those 2 together with what you're doing on the user front, this has to happen. Is this not absolutely clear dynamics?

Well, to forward thinkers and progressive company, it's pretty clear. A lot of others are just figuring it out. But think of the simple thing, in today's environment when you need to really get a network built from Point A to Point B, it takes weeks. It used to take months. Now it can take several weeks now in the dynamic environment you talked about. You're not going to wait for weeks. Literally, the motto is simply get connection to the Internet. It's a transport plumbing. And then the policy engine helps you figure out where you need to go. You move your workloads from Place A to Place B to Place C. You shouldn't have to work about re-networking, because each workload is simply a point or location and island and that gets connected, all you need is connectivity to the Internet. It's like -- as long as I have a connecting road to the highway system, I can get Point A to B proper inspection with checkposts in the middle.

So CI/CD pipeline is a really interesting thing when I started thinking about distributed edge. The 5G world that we're moving towards has a real pronounced impact on where you're running your applications. It used to be -- we run a 1.5 miles long data center to corn field in Iowa, and I would just scale it up and it would go across the network. But now with 5G, the applications have to have extremely low latency. They are pushed out right to the edge and the same application could be running in 400, 500 locations globally as it's being updated with microservices consistently over the course of the day. And all of those microservice updates have to happen globally at the same time for continuity. Wow, that's an amazingly dynamic world we're talking about. And obviously, you become, in many respects, a 5G application enablement company in that respect.

Yes. And what you really just said is that enforcement of the policy will go from dozens or hundreds of locations to thousands and thousands of locations which really makes a case for having a proper distributor architecture, where I'm not trying to spin firewalls here, firewalls there. I need a proper Zero Trust exchange that automatically figures on what needs to happen, where and where not. In your example, actually, it's not just the same workload that get duplicated in each edge. Some of the application logic runs in the big data center, maybe some of the analytics on there and some of the logic run -- some of the microservices are running on the edge out there and the 2 work well together to make your job gets done. But the point you're making is applications need to be built and deployed and updated with agility, far, far more agility, that's beginning to happen more and more, that's driving the change for how networking and security is done.

The Log4j event was an interesting event because it was so ubiquitous. I think probably 40% to 50% of the companies are running application workloads with it in there. And most SaaS companies are using it. So that means most companies are exposed somehow. If I was using the full Zscaler platform, would it have been a risk to me?

So I'll tell you is it fascinating. So we were using Log4j in a few cases in our applications as well. So as soon as we learned, we figured out, we went to work. We made sure they all got passed. That was done very quickly. I got an e-mail towards end of the day from a CIO, it said, "Jay, thank you. My applications are hidden behind Zscaler Private Access." I actually -- yes, I need to patch Log4j but I'm not nervous to rush to it right away because my applications are not exposed to the Internet. If they -- the biggest issue with Log4j was that if you could find where the surfer is, you don't need to find any passport or anything. You simply send a command with certain characters, you are in with route access. Nothing could be more dangerous and more...

Very easy to take advantage of, very hard to patch.

So with the approach with Zero Trust, all these applications of our customers are sitting behind us, they're not exposed to the Internet. So that's the first thing. We're very proud of...

Just to remind people, the term for that is the application and the user on your network goes dark to the Internet.

Exactly. They can't be discovered from the Internet because if you saw my diagram earlier and it said, they find you, okay, how do they find you? They scan the internet.

Most applications, when they pop up that API gateway says, "Hello, world, that actually is what they say when they're introducing the application.

Exactly. So this was extremely effective and impressive. People start to appreciate the power of Zero Trust architecture. Now there's a lot of dialogue about Log4j and segmentation. Probably I should address that as more. Segmentation is a good thing, but it's not easy to do all this micro segmentation people talk about. Why do we need segmentation? Use my analogy of U.S. highway system. Right side get on in San Fran, I can reach anywhere without hitting a single light. Segmentation is like the U.S. turnpike system, these toll roads. You've get on certain places and you get off certain places. They're expensive to manage, run and build all that stuff. So segmentation is to say, gee, someone got inside my castle. They can go anywhere. I should build a wall here or wall here or wall here so they are restricted to move to only certain places. And then they said, but wait a second, but this user must be able to go here, too. This must be able to go here. This must be able to go here. And this one customer said, by the time we were able to finish our segmentation, we are, by and large, all to all policies, okay, any to any policy because without that, we were hitting so many bumps that certain users couldn't get to certain segments. It became useless. So that's where even segmentation needs to be based on identity, not on network segmentation. That's the old way of doing it and that's another area that's picking up momentum. And with Zero Trust architecture ZPA we are actually driving more and more app-to-app segmentation that user didn't have before.

Jay, one of the -- not -- and this probably goes to Remo as well, and we're running down to the last 7 minutes here. One of the questions that people are addressing right now is what goes on with interest rates rising and high-growth companies and profitability and the like. You guys are already profitable. You're clearly demonstrating leverage every quarter, but you're also investing at a high rate in sales capacity and driving significant productivity. Remo, can you talk a little bit about what your ARPU experience has been over the last couple 2, 3 quarters? And what your customer capture rate? What -- how many -- what user customer growth look like?

Yes. I mean, ARPU definitely is increasing. And we talked about 4 -- if you buy the user protection part, the ZIA, ZPA and ZDX, 4 users of 5,000 users or companies of 5,000 users we're seeing pricing in the $145 per user range. On the workload side with significant workload deployment...

Where would that have been, say, a year or 2 years ago?

A lot lower. I mean we didn't have ZDX, for example. I mean, if you break it out, ZIA is $45, ZIA by the transformation, by the full transformation. The ZIA add-ons, which is a browser isolation DLP, CASB out-of-band which we don't have -- which we didn't have a couple of years ago, generally, it was $30. ZPA is $45, ZDX is $25. But as we're becoming more mature as a company, pricing is going up. So we are building -- continue to build our platform, build our products. So pricing is just naturally increasing. The workload protection, $155 per workload. So that is for a significant workload deployments. The growth in users, basically the size of the -- we have companies of greater than $1 million ARR. We had 224 companies. Last year, we had 120. Growth rate 87%. So we're seeing the company size is increasing. So what we're seeing basically is that, as Jay talked about, the world is becoming to recognize that the structures, the Internet or the infrastructures for security and networking of 30 years ago, hub and spoke aren't working today. So we are seeing that uptick larger customer deployments, faster customer deployments, selling the platform, the broader platform and ARPU increasing.

Right. So given those characteristics, I would think that inherently, that provides natural leverage to your business model?

It does. And one of the things when we took a look at for what customers bought for ZIA and ZPA and you look at our ARR for ZIA and ZPA, there's still a 6x opportunity if they bought everything for ZIA and ZPA in our existing customer base. So when you take a look at the size of this market, $72 billion serviceable addressable market, which is what our addressable market is for companies of greater than 2,000 employees, $72 billion, when you take the user side and the workload side, that market will continue to increase. And it will also expand -- as we expand into other areas, which we're doing, IoT, B2B, B2C, 5G that we talked about. As these become more mainstream, it's just -- when I take a look at Zscaler versus other companies I have been at, a lot of companies kind of get walls basically of innovation. Zscaler basically is a -- it's a technology company. It's core is basically was built in technology. And Jay's vision in building the company 12 years ago to address the needs of the world, which are very prevalent today. Jay is also thinking about where the world is going 10 years from now and building basically the structure for us to continue to grow as a company to really take advantage of the platform, the Zero Trust Exchange, which has developed 12 years ago.

We've got 2 minutes left. Jay, in a minute, literally a minute because I want to put a sentence in the last minute, what are the 3 takeaways that you want people to take?

When I think about the Zscaler business overall, I start with how big is the opportunity, okay? And is the market ready? Five years ago, there were their questions about it, 4 years ago there were questions about it. Today, the market is coming to us at a rapid pace, not just for users and branches, but also workloads and all that stuff that's growing very rapidly. That's Point #1. Point #2, you've got to have the real architecture for this kind of stuff. When mega change happens every 20, 30 years, you can't retrofit on the same stuff. So this is a big shift with Zero Trust architecture where policy engine drives everything. The engine must scale to build a cloud and run a cloud is very different than taking your existing products and spend them in the cloud. We're very, very well positioned there. The number of the transaction you start seeing $200 billion transactions a day kind of stuff happening today, the cloud scales true to the name Zscaler. So 3, our customers, our growth, Remo talked about the numbers. We are very excited about the acceleration of the growth that we are seeing out there, not only a large customer base, which we had dominated quite a bit, but coming down market to enterprise customers, global presence around the world, and we are not -- we're unique to have 50% business outside the U.S. for us. And our customers being happy, our NPS score off the chart as compared to others. So I think when I talk to my management team and figuring out what to do, I'd say, I'm less worried about external forces. We need to stay focused on execution, heads down, don't be complacent, don't be arrogant, keep on innovating and selling.

Well, let me wrap there. Zscaler remains a strong buy-rated stock at Needham. We have a $418 target price, which is a significant upside from here. We have never lowered our estimates or our target price on the company or have changed our rating since the IPO. We strongly believe this is a stock you want to own for the next 5 to 10 years and probably longer. Jay, thank you so much for joining us. Remo, it's a pleasure to see again. Didn't get to talk to Bill, but he's lurking there in the background. And to the operators, thank you so much for managing the connectivity. Thanks, all. And I also -- for the over 100 people who are dialed into the Zoom, thanks for joining us.

Alex, thank you. I appreciate it.

Thank you. Take care. Bye.