Listen to Patrick McBride, Chief Marketing Officer at Beyond Identity, talk about how Beyond Identity came to be and the different products offered. 

Transcript

Tony

Okay, well, we do have our guest joining us now. So we'll just do a round of introductions to all the guests who've made it to this rescheduled session. Thank you very much. I do apologize on behalf of all the idiots that voted for Brexit, and meant that we can't deliver beer on time. Thankfully, we've managed to get the session back up and running. So thanks for the guys at IEVA for working so hard to get those deliveries out to you. 

We have a special guest on the call today, a change to our presenter slot. We were originally going to have the head of EMEA do the presentation to you guys. But we've actually been lucky enough to get Patrick McBride, who is our CMO, and has been with the company since the very beginning. Patrick's previously actually been an analyst and an engineer, so has a great depth of knowledge about the subject and also a real passion for it. 

So Patrick will be running us through what we do shortly. Of course, during that session, if you have any questions, please, put them in the chat. Or we can actually do them live after Patrick's presentation. If you do put them in the chat, then myself and two of my colleagues, Gary Strong, and Juha Hakava, who respectively cover the UK, Middle East, and the Nordic region can take care of those questions for you. 

So I think all it leaves me to do now is let Patrick introduce himself and give you a brief run-through of what we're going to do. Then we'll quickly hand over to Ryan who will let us know which beer we'll all be sipping as Patrick presents, and then we'll be able to kick off. So, Patrick, over to you. 

Patrick

Yeah, that's fine. So, you know, I'll throw a slide up to kind of show some of the background just so you guys understand kind of how I come to the subject. By the way, as far as Q&A with a small group, just interrupt. I mean, raise your hand or speak up. This is super simple. There's no pretense here for it. So be happy to answer stuff. 

Certainly, throw them in the chat room and, or either or is fine, or both, and we'll get to them. You know, by way of intro, I've been kind of at this cybersecurity thing for, I can say, nearly 30 years now. If I say 30 years, I'm coming up on that anniversary, then it just makes me feel even older than I am. But as Tony mentioned, I've kind of sat at most of the seats in the table. 

I've done a CIO and CISO role in the past, I did an analyst role. I was an analyst for a long time at a company called META Security Group that Gartner bought. We got big enough and pissed Gartner off enough that they finally bought us and, you know, took enough business away that it hurt. 

So I like to call myself a reformed analyst. But from a security perspective, I founded a company that did early security program development and pen testing. This is my second stint in more the identity-centric, you know, space and we'll talk a little bit about that. But I've spent some time in threat intel space with iSIGHT Partners and ZeroFOX. And one of the other cool stints was I spent a couple of years helping launch an industrial cybersecurity company called Claroty which was a hell of a lot of fun. 

For me, it was drinking from the, you know, the fire hose because I had to learn about a lot of industrial network protocols and things like that, that I didn't have any access. I came out of school writing code. So, you know, I'm a tech guy or a tech meanie. I mean that, you know, with affection. You know, at the root, I know where I fall off the end of the cliff. 

I know what I know, know what I don't know. So if you ask me a question I know, I'm going to answer it. If I don't know, we'll get you an answer to it that's a correct one. Although my title says marketing, I'm a little bit of an oddball kind of marketing guy. Being around cybersecurity for a long time, I know for a fact that the folks that we're talking to, CISOs kind of all over the place, actually care about getting truthful answers and actually want to know how stuff works and not just a bunch of marketing fluff. 

So that's kind of the way I come at it. And, you know, hopefully, that'll give you a bit of a background of how I come at some of the subjects that we'll cover today. Oh, by the way, the background unless we need to change, I figured it felt, it's post beer o'clock for you guys. 

I'm in New York City, so it's a little early to be sipping beers but Tony has said that despite Brexit, he's been able to ship me a glass and some good beer so, Ryan, if you would, let us know what beer we're going to try first and impart some of your knowledge, that'd be awesome. 

Ryan

Absolutely. So yeah, hi, guys. My name is Ryan. We'll be talking through the beers this evening. We'll keep it quite light-hearted and go through them. So all the beers we're trying today are from a brewery in Northeast London called Signature Brew. They're all about good quality beers to be paired with great music. 

So two of our main passions. A lot of the brewers that come together to collaborate with bands in the development over time to the core range. To start you off with the most refreshing and most popular style, I'm going to go with the studio lager which is the orange style can. 

So, yeah, it might link to, sort of, the Pilsner style that you'd find in the Czech Republic in Germany, light, fresh, crisp. At the end of the day, for anyone in the UK, then that's probably the one that's going to perk you up and get you through and nice to sip through the presentation. I'll go into a little bit more detail afterwards, and then we'll chat through the rest on the different styles and how they differ. 

Patrick 

I am going to throw this in presentation mode. Somebody's going to have to enable me to do a screen share here. Oh, there we go. Well, look at that. Oh, everybody see that all right?

All right, and we'll throw it in. So I'm a little bit of a giveaway, you know, with my surname, it's probably not hard to figure out what beer I might be, have a little preference for. So, I'm sharing the right screen, we got a nice glass of Guinness, you know, slowly entering. 

The advantage of a really nice lager is you can kind of sip on it right away. The disadvantage of a nice Guinness is, you know, the bartenders and particularly the ones in Ireland make a nice game out of it. They'll, you know, they'll pour a little bit of it, pour a little bit more, pull a little bit more, and then let it sit at you. 

So you got to, you know, wait and anticipate your beer for some period of time before you actually get there. So, you know, I wish I was enjoying the lager first. Like I said, I will also partake. I got to figure out what music pairings. Maybe we ought to come back with some questions, you know, as well about, like, what would you pair this with music-wise? 

After you guys take some notes, if you want to throw that in the chat room, I'd be interested to, like, what I should be listening to now that you guys have tasted the lager, and we're going to do a band pairing as well. I've got a little Grateful Dead going in my background. All right, I think we hit most of this. Like I said, I'm a reformed analyst, but, you know, it's kind of once an analyst, always an analyst. So I think of myself more from that, you know, perspective than, you know, kind of a natural marketing guy. 

All that's, you know, kind of learned stuff. What I thought I'd do today, you know, is just take you basically on a bit of a tour of the company and kind of where we came about, how we came about. So kind of give you the backstory, you know, on the organization and share a little bit, you know, where we are today and then talk a bit about the tech. So the original tech that now underpins our set of products we started working on back in early 2019, actually in 2018. 

And we really got going in earnest in 2019. So, the backstory is this Jim Clark who may have, some of you guys may recognize that name, Jim founded a pretty storied company in the Silicon Valley area called Silicon Graphics. So at the time, it was kind of the big graphics processing thing. 

He had some really innovative tech that he put forward to that. And, you know, if you don't know Silicon Graphics, you probably know some of the output from it. So most of the, or all the early Disney Pixar movies and the animations and stuff were done on that equipment. So they had, you know, they migrated the company, they bought a couple of other risk-based computing companies out there. 

So MIPS computer, they bought the, you know, some supercomputing companies, you know, as well over time. So they became a pretty big deal in the, not just the digital, you know, processing piece of it, but also just, like, traditional server kind of computing. And, you know, they fought, if some of you guys remember the RISC-CISC battles from the old days. 

Well, all right, so our CEO, TJ, ran the business for him. Jim was chairman, he founded, he was operationally involved or design involved in the beginning, but he stepped back and brought in some other folks. And TJ came as an engineer over from Bell Labs and ended up becoming the president of the company and running it. 

So those guys have been working together for quite a few years, working and investing. After the Silicon Graphics run, they, you know, took their company public. And when they both decided to hang up the spurs on that one, Jim kind of famously hired a couple guys from the University of Illinois Urbana-Champaign in the States and moved them all out to Silicon Valley and started another little company called Netscape. 

So Netscape, you know, it was the original commercial browser. TJ helped a little bit on that. But then he went off and did another company called At Home Network that ended up being acquired by AT&T. So At Home Networks did kind of the first broadband over cable. So they kind of, you know, built the technology that a lot of the cable providers then went on to implement to give broadband access to the home. 

So without any kind of hyperbole, you can say these guys were really a big piece of the early commercial internet. A lot of folks think about Netscape first as like, oh, the Netscape browser. But they invented a lot of other stuff. They had some really cool server technology, but along the way, they invented something that we're all still using today. 

At the time, it was called SSL or, you know, secure socket layer. And now it's TLS, you know, as we know, or the lock in your browser. And, you know, the backstory there is Jim hired a couple of guys to come in and, you know, create a way to basically identify that the server that you're talking to is actually the server you want to be talking to and to be able to set up the secure link. 

And so they invented SSL. So a couple of folks here, actually one of them, Taher Elgamal, the guy that kind of perfected it is actually on our advisory board. So it's kind of cool to get to talk to guys that are, you know, tech heroes effectively. And we've leveraged a lot of that. So I tell that part of the backstory because we've leveraged some of those fundamental techniques. 

SSL or TLS now uses asymmetric cryptography relies, as many of you guys know is, on a public certificate authority, a known certificate authority, and then public private key technology and X.509 certificates to do the binding. So we've leveraged a lot of that technology, but we did it in a way that, you know, is pretty innovative. 

So we'll talk a little bit about that in a second. So they got going in 2009 on this new thing. Jim had started, it actually started, and not many people know this part of the story, inside of another company that Jim was kind of messing around with for, kind of, home automation. He ended up hating that business. But he was pretty convinced that nobody, if you were going to do home automation, writ large, from light switches, to cameras, to your stereo equipment, to whatever, the HVAC and all that stuff, if you're going to do that, nobody would want to enter a password to change the temperature or turn on the lights, etc. 

So, you know, he wanted to do that in a completely passwordless way, and they got going with it and that's where some of the innovation... So when they decided not to end up doing that company, this other idea, leveraging, kind of the asymmetric crypto and X.509 certificates was something that they wanted to use. So our stealth name when we were doing it was ZeroPW. 

But as we really explored that and looked at it, it was pretty clear to us that there was a whole lot of opportunities beyond just, you know, improving things by eliminating passwords, improving security, and reducing friction. There was a lot of other stuff that needed to go. So we didn't want to be anchored just in that whole, just password listing. So we went on, you know, beyond that and came up with that name over a lot of wine at Jim's place. 

And it's really nice to have a multibillionaire's wine budget, by the way. I will say that and with a smile. We get to drink really good wine on the occasion that we go over to Jim's house. So they went on and we launched, you know, Jim started funding ZeroPW, then we raised outside money. Jim put more money in, then we raised outside money from, you know, well-known Silicon Valley venture capitalists so... 

A company called NEA, which is one of the top three companies in the Valley, and has been for years, and then Koch Disruptive Technologies, part of the Koch, K-O-C-H, empire. We didn't publicly launch the company because we, you know, spent a lot of time perfecting this until April 14th. We were going to launch in March and then the pandemic hit. And then we all looked around and said, you know, "Is this going to last? Is it not going to last? Is the news cycle going to change?" 

We'd rather not, like, launch, publicly launch a company with... At the time, the only thing that anybody was talking about in the news was the pandemic, stupid things our president said on occasion or daily or tweeted or whatever, and then the economy. So, you know, was not exactly the time that you'd like to launch a company, but we decided that, that was probably going to go on for a while, let's just get out there and get going. 

We've raised 105 million, you know, to date, we've got 171 employees including a big chunk of a team in EMEA. So we're not trying to, you know, service, our EMEA clients, you know, kind of across the pond. We've got the combination of sales, sales engineering, engineering. As we've tried to really grow our engineering and support teams, we found some, you know, really good folks. 

Particularly, we've done a lot of hiring on the continent, actually, there as well. So, you know, nice team in Europe, you know, to support the EMEA and I suspect, when we expand into Asia, we'll do the same thing. So what we do. You know, the thing that we're really known for is strong, you know, super-strong, frictionless MFA, but adding some things to it. 

So let me go through that and I'll come back to it. We've got three separate different use cases that we actually support. So, you know, there's authentication kind of things that, you know, have to do with your workforce. So, kind of, the traditional providence of the CISO or, and the CIO making sure we're protecting the access to the data and applications, our sensitive data and applications, whether we're regulated or not. 

On the other end of the spectrum, we also have a solution, that's one platform, you know, but we've got a solution that is optimized for the customer use case. So anything from bank, financial banking, financial services on one end, obviously very security conscious, worried about account takeovers and the like to retail establishments on the other end. 

So, you know, whether it's a pizza delivery, or a shoe company, or, you know, stereos, or whatever you might buy online and everything in between. In fact, I, interesting, our early customers in that space happened to be in the surprisingly, by the way, in the travel and hospitality business, given the ding that those guys all kind of took during COVID. 

But there seems to be a lot of interest from that industry as well. In the middle, we've got the DevOps solution, too. And this was interesting because, and it'll make more sense when we go into it, but this was actually one of our existing customers, gave us this idea basically said, hey, they had bought us to use us to protect their workforce. And he said, "Hey, wait a minute, with the tech that you've got, the way you did it, you could solve one of my other problems." 

And the specific problem, there was two, but that he wanted us to solve in the DevOps area to better protect our codebase. By the way, the customer, and this is public is, I'm not sharing any secrets that we, you know, haven't already been allowed to share, because I'm always very sensitive to that, even being the marketing guy having lived on the other side of the desk there. It's Snowflake, the big, you know, data analytics, cloud-based data analytics platform that, you know, I think it's still the number one software IPO in history. 

I know they IPO'd sometime last year. And so Snowflake bought us to protect and lock down their workforce, you know, who had access to, you know, their platform and stuff. But he says, "Listen, my developers pose a really unique challenge. And the first thing I'd like you to solve, and you can use the same tech to do it, is we're starting to have them sign the source code that they put into our repos. But the problem is, you know, first of all, a lot of them weren't signing it. So we're going to force that. That's something that Git and other repos kind of support. But if they sign it, there's no way for me to tie their identity, you know, in Git to their corporate identity." 

And so the idea of making sure that not only are all the code pieces that go into the repo that end up becoming the binaries that run their platform, and actually the stuff that builds their infrastructure. So we've got so much these days, you know, infrastructure as code. So they've got, really, kind of two codebases, the actual application codebase, and the codebase that spins up their infrastructure which all runs on AWS as many organizations do. 

So you've got to protect access to that. And then you also want to protect and make sure that, that code is actually signed so that you can trace who did exactly what change when. So you've got really provenance of every little piece of source code. There's a lot of talk here in the States, you know, given the fact with some of these supply chain kinds of hacks about software provenance or about supply chain, protecting the supply chain and stuff. 

And one of the things that comes up is this idea of a software bill of materials, right? Hey, what's all the stuff that went into the software that we're buying or that we happen to be using? Snowflake's a platform that runs in the cloud, and SolarWinds happened to be a platform that got installed in corporate networks, two scenarios that you have to protect against. 

By the way, when Snowflake was talking to us about this was before the SolarWinds attacks. It was really interesting. He came out of the same cloth as I did. He was an old pen testing guy. So he kind of tends to think about, like, how would I attack this? And he was like, "Man, I don't know, you know, who's putting stuff in there, and the software bill of materials isn't going to help me." 

Knowing, you know, being able to produce a bill of materials of everything that went in our software is like producing a bill of materials for your Wheaties box, you know. And, you know, if you got some poison that came into the wheat and you don't know which plant put the poison into the wheat, it's not helpful, right? So having a software bill of materials, it's all that you can trace back to a unique identity, I'm not going to spend any more time talking about the DevOps thing, but it was a pretty interesting outcome. 

And it's always nice when one of your customers says, "Hey, wait a minute. You've got something here that you can, you know, can tweak." So the signing keys are something we can attach to a corporate identity, and then the SSH keys that allow you to gain access to the repo are things you can... So it's kind of a not well-known vulnerability in the software development process or the DevSecOps process that we have. 

I'm going to do this really quickly. Like, this is going to be no new news to anybody on the phone. You know, you're all security folks. Obviously, our traditional network perimeter, you know, kind of evaporated. You know, I was developing security programs at the time when the security program was, you know, a firewall when firewall rules. 

So, you know, that was like step one. We used to joke M&M security, anybody who's been around, you know, hard on the outside, you know, at the network perimeter and softer on the inside. And then we realized soft on the inside's probably not good. So we need more controls inside and we started to layer our defenses up, etc. And then, you know, then all, you know, then all heck broke loose. 

Our users, you know, first of all, didn't all work inside the castle walls. They weren't always on the network. And that's more true today than ever, obviously. But a lot of the technology that we use isn't, you know, in behind the walls. It's SaaS, and PaaS, and infrastructure as a service or all the other asses as a service kinds of things. 

And so, you know, where our new world is one where we need kind of anywhere access to anything, whether it's on prem, you know, or in the cloud. So that kind of screws our old, keep the bad guys out, let the good guys in, kind of perimeter mentality. So, yeah, moved from the firewall in the DMZ as the real demark and it pushed out. And then, you know, so this truism now that again we kind of all understand that the identity, and the endpoint really become the new perimeter. 

If I can't know that it's Tony on the other end of a transaction or of an authentication transaction, then we're nowhere. I kind of extend that thinking. I think it's if I can't understand that if it's Tony and if I can't understand if it's a device that we've authorized Tony to use. 

And I'm going to pluck into that a little bit more. So one of the issues, just knowing Tony, is you need a higher trust way to do that. I'm telling anybody here that passwords are a particularly flawed authentication method in terms of a security perspective again, will be no news. You know, it's kind of the root of, you know, a lot of things, the root of all evil as we like to say. 

But beyond that, you need to be able to control the who and the what, you know, has access, regardless of where they are. And many organizations, I mean, I've seen widely different views. In fact, I'd love to get everybody's input. There's the no way BOYOD at all camp and there's, yeah, of course, we have to, implement BYOD if not for all of our users, for some subset of users, and if not for some subset of users, the executives are all pushing us to do it anyway. 

Is that the commonplace here? I'd love to even just stop there and get everybody's kind of, where are you on the BYOD ramp? No damn way or I need to figure out a way to do it, but, you know, do it securely? Any hand raisers on that, Mario, Rob, Matt? Were things in the... 

Mario

For us, the company line is still no BYOD. But guess what? There are exceptions and I'm rather unhappy with the exceptions. Ultimately, I'm less concerned about BYOD. I'm more concerned about where our data ends up, losing control of the data. So that is my problem. 

Device identification is very important to me. And I have been looking for years for something that beyond reasonable doubt allows me to identify a device, I can identify users beyond reasonable doubt at this point, but devices, I'm not so sure. That might open the door for BYOD if I can do this. 

But as I said, where's my data going to end up, right? [crosstalk] branch services, we have some secrets we don't want to share, and we have GDPR regulations. 

Patrick

Yep. Exactly, exactly. By the way, not surprising to you, but that tracks very well with a lot of my other Pfizer, you know, clients. So in places where they still have the BYOD restriction, in some cases, they've gone, it's pretty heavy-handed in a pretty expensive way, is just all VDI. Even if it's my work-issued device, you're still not doing anything on the work-issued device. 

Pretty expensive proposition way to go. But, you know, it doesn't eliminate the device security thing. I mean, obviously, that could still be an issue or device, you know, knowing who it is, but it helped somewhat with the where's my data going, you know, controlling it through that so... Somewhat, because, you know, there's still a bunch of other controls, as you know, that you'd have to put in place even with EDI. 

Mario

You see there's a reasonable effort that needs to be made to secure the data and make sure it doesn't end up accidentally or on purpose in the wrong hands. But a few years ago, we have run a contest internally, for a document to be leaked and to then tell us how they did it to test our controls and to test how much of that we could actually see. 

And it is unbelievable what people come up with. And I'm not talking about taking photos of screens, really exfiltrating a Word document. You see if people want to find a way, they'll find a way. If you are too restrictive in your approach, people will find workarounds. 

You will never plug that completely. 

Patrick

Amen. I was just on a tour with one of my colleagues where we did, I guess it was like 24 or 25 meetings, it was primarily CISOs, and almost exclusively CISOs. And I did another one earlier last year. And in both of those cases, I heard some stuff come up that I've just never heard. You know, I'm pretty old school. 

I'm not old school in my thinking but, you know, I've been around for a while. And, you know, back in the day, the old school CISO was like, you know, my way or the highway, we'll do it whatever way you want. But all these guys are starting to talk about, and worry about, and be concerned about user experience for two reasons. If you don't give them a good one, they'll figure out ways to work around it. But also just from a, you know, we can't continue to be the bad guys, you know? 

So that's come up, any other ones, any other comments on how people are, you know, thinking about BYOD or not? I'll just take a breath for a second. 

Robert

It's Rob here. Sorry. I mean, we are still not moving in that route. But we are finding more and more requirements to have apps installed on people's phones and mobile devices because we travel quite a lot around the world. So, you know, the guys recently have gone out to Qatar, Abu Dhabi, and Saudi Arabia. 

And there's lots of, like, the COVID tracking apps that they need to install on their own personal phones and things like this, and they're not too happy about those types of requirements. So I think in the end, it's the way we're going to have to sort of manage that type of, you know, work requirement in those environments. 

You know, from an individual point of view, they don't want to do it, but they're being forced to do it on their own personal devices because of their work. So, yeah, that's a little bit of a problem we're trying to think through at the moment, which is an interesting one, I think because not everybody has a corporate, you know, a corporate mobile phone and/or device like that. 

They obviously got laptops and endpoints for that sort but not from a phone type or tablet. So, you know, running the apps is quite difficult in that respect, and it actually just aligned with the entry requirements for some of these other countries. 

Patrick

Got it. Anybody else want to jump in or...? That's still super helpful. It opens up a lot of, you know, lot of room for some of the discussion that I wanted to go. Just in case anybody was playing bingo along and you thought you'd get through a presentation from a security company without some breaches, if these weren't on your bingo card, now you can, checked off. 

But, no, I bring this up for two points. One is the common denominator here is all these, the original attack vector, you know, for all of these breaches was a compromised password. So, kind of, not surprisingly, solarwinds123, the password that apparently the intern put in place, definitely not the excuse you want to use. 

But anyway, that's a whole different discussion on the PR side of it. But interesting, like, people don't know, if anybody's read the full report on there, it started with the solarwinds123 access to get a footprint. But they were actually able to get, you know, move laterally and get into the core of the system. And then effectively, you know, I'm not going to knock a particular MFA company. But they were able to get to the MFA thing and mint themselves an MFA token that they could reuse, you know, over and over, a reusable token so that they could get in, you know, and allow them to continue to move laterally around the network and get to where they needed to get to for the codebase and stuff like that. 

So pretty interesting. That's a particularly, that's a state-level attack granted, but there's a lot of other things that come up with MFA that people are bringing up. Our government is as is, and I know that the UK governor's considering some stuff as well in terms of not all MFA is created equal. You know, some of it's stronger than others, just to put it in Orwellian terms, you know. 

So anyway, that was interesting, but this point that you guys brought up, this is one of the things it seemed like back in the old day, it's like everything we tend to put in place to... Particularly with authentication, passwords themselves were a pain in the ass, especially when we figured out that they were the soft white underbody that the bad guys were going to go attack, steal passwords and things like that. 

So then we went to the whole longer and stronger password which, you know, I kind of laugh at now. If the method is cracking a password, a longer or stronger password helps. But most of the methods that people are using to get passwords are phishing or stealing from the database and, you know, and they're just lightly, you know, salted or not, and so they're easy to kind of crack. 

So it only works in a narrow case. Most of the passwords are stolen because there's a malware, you know, on the desktop or something or a phishing site that you're ushering people to or some combination thereof. So, you know, malware doesn't care if it's four characters, or 400 characters, or 4,000 characters. It's more than happy to steal it and pass it along to the bad guy. But that was one. 

And then the frequency changing them, you know, which is still relevant. If it's stolen and you change it in between, that's fine, but it's, with the frequency that they get stolen these days, it becomes hard, and that's one of those, again, one of those trade-offs, like, is it every 30 days, or every year, or every six months, etc. Password managers were a good way to make sure that, and I'm raising my hand here, I'm a LastPass user, have been for a decade because I've got a bunch of stuff, a bunch of consumer apps that I still have to get to that I haven't been able to take go passwordless on. 

And so they were a great way to make sure that we, you know, got different passwords for all of our accounts and didn't reuse the same ones. You know, so that was a nice Band-Aid for that. But if anybody's ever used one, you know, myself, it's sometimes like playing pinball. You know, all of us probably are tech support for our family, you know, if anybody's done that. 

So when I installed a password manager for my mom and tried to get her to use it, you know, every time it broke or didn't, you know, didn't put it in the right place, it just was confusing. They've gotten better. The UX has gotten better, but still, you know, not ideal. VPN was actually one way that people used to control the, to the device to your guy's point earlier. You know, if I've got a VPN that has some controls on a device, and we'll go into that. 

And then mult-factor authentication was about giving higher trust in the user identity, you know, of course. And so, you know, if passwords are the issue then, you know, kind of, multi-factor is the answer. And I think the way we look at it is we a 100% agree. That's why we're doing multiple factors. 

We just think you need to do, as part of that authentication transaction, more than just that. And authentication really is directly relatable to zero trust, right? If you can't trust the identity, if I can't trust that it's Mario on the other side of the transaction and I can't trust the device he's using is one that I want him to use, or is secure enough, or whatever, then, we really don't have any, the base level of zero trust isn't there. 

You know, we've already redone it. And, you know, in some ways, and I'll talk about this, you know, we think passwords are so completely compromised, you can't have zero trust with passwords, certainly as passwords alone. This idea of transitive trust comes up as well, and I think it's one of the more important foundational things of zero trust is check every time, right? 

You don't want to grant somebody access, you know, to one thing, you know, and we know this, right? If I go into the office, I was just down in our new offices in New York, if I go into the lobby, I've got to badge in to get into the lobby, that doesn't automatically get me to the elevators. Now I've got to, in fact, in our case, I've got to go show my ID to the, you know, the guys in the front and sign in right now because we need some new official badges, and then we get on the elevator. 

When I get off the elevator, it doesn't mean I can get into the office. I need another one to get in. And then some of the offices inside, we're going to have badgeable, too, our data room, and our server room, and things like that. So, you know, just because I got into the building doesn't give me access to everything. But lots of things that we do and lots of the ways that we set up security controls these days, you know, we have this transit of trust. 

I'll come back to that point in a second. So we're, you know, we're trying to fix that, you know, trade-off as well. I'm trying to go through and go back to customers. So this is kind of our customer view, you know, folks that we've done work with and why they looked at us. 

And, you know, kind of why they changed the direction that they were on. And so wanted to share some of this. Traditional MFA is really designed, you know, to give you higher trust in the user, right? I know, it's Mario, I know, it's Juha, you know, I know, it's Ryan or whoever. But there's, you know, there's a lot of issues. 

A lot of the factors that we use are phishable to the point that like one-time codes over SMS, or onetime...actually, onetime anything, magic links, one-time codes, one-times passwords over anything that's part of the public telephony network is verboten now in the U.S. government, and it's being recommended against. 

And the simple reason is there's multiple ways to attack that. I can attack the telephony network itself, you know, and then get a man in the middle thing to grab the code. I can attack the device itself, get malware on the device, steal the code. The more common and more automated way today is I fake front whatever I'm logging into my bank, my whatever, I get a user, 'Hey, come change your password." I get their user ID, their password, and then the fake site, you know, sends that to the real site. 

The real site generates the MFA challenge, and the end user then types that code in, you know, and then, you know, into the fake site, and it gets it. And that's done at scale now. There's automation technologies that the financially motivated hackers are using for that at scale. So, you know, it certainly gives you higher trust than a password alone, but it doesn't give you the level of trust that a lot of people really need to be able to count on it. 

The other way is to, you know, so a push notification is definitely better than that, right? A push notification over a secure channel. What people are running into in terms of the issue with that is conditioning. We get back to putting the user in the equation and being able to get the user to do things that we, you know, that we didn't want them to do. 

So what they're doing is they'll send two or three different requests in a fairly, quick manner, and a lot of folks will just, I'm doing something other, and I'll just clear the request. Yeah, let me in. You know, there's training obviously, you can do to get around that, but it's certainly not foolproof when you put the user back in the seat, so to speak, with something that they can just... 

Particularly they're finding that with, we get so many notifications on our phones and things like that. It's over a new text message, a new Slack message, you know, that we're always having to clear. So we just are getting conditioned that way. Most of the customers that we talked to have adopted some form of MFA but, you know, very few of them haven't looked at anything although the adoption rates across the globe are actually way lower than stuff like firewalls and things like that. 

But there's two issues, you know? Most of them, like, particularly in the workforce, they're just putting an MFA challenge in front of their SSO or putting an MFA challenge in front of just a couple of important apps, like maybe my VPN or the externally facing applications. But, you know, in that case, then you run into trends that have trust issues. 

Just because I got in doesn't mean I necessarily should get to the next thing, you know, without validating that again. The other thing that people have done because the other people have found that if you did put MFA in front of all your applications, you get a revolt on your hands. It's like, wait a minute, you know, it's taken me 15 or 20 minutes, you know, to log in in the morning. 

And so what people have done for that is, okay, well, I'll set timers. I'll put my session timers up to a couple of days so you don't have to re-login, but, you know, then, you know, then we're playing around. You know, improve security, but, you know, reduced user friction. So we're playing around with that same chart. We're, you know, screwing around with security and making the experience better, but we're making the security less, etc. 

And the thing that's come up most often is just the last point. Listen, part of the authentication transaction ought to be able to check the device. So at the time that I'm letting somebody into something, whether it's Salesforce or some other range of SaaS-based applications or some platform, data analytics platform or even checking them into my single sign-on tool, I'd like to make sure that they're coming in from a device that I've authorized them to come in from. 

You know, if it's a banking customer or consumer, you know, maybe you can or can't control that. I mean, you know, you may not be in a position to say, no. You might be able to warn them, hey, you're coming in from a device that, you know, may be authorized, you got an authenticator but maybe it's jailbroken. Hey, warn them. 

Do you really want to be, you know, getting to your banking app with a, you know, with a phone that's jailbroken? For example. There was no concept in traditional MFA of this idea of the, you know, device access control. So the ways that we had to do that, got pretty tough and pretty tough to implement and very difficult to control. 

So we set out to fix that. Similar things. VPN was one of the ways that people would use to control and get some level of trust in the device, that you said, Mario. Many of the VPN things will use, they'll get some device signals or some device posture data, a couple of quick checks, others will use a certificate on the device. 

That certificate happens to be on the hard drive. So as our Snowflake CISO told me, it's like, "Patrick, half of my company's engineers, all of them know how to move the certificate from the device that I issued them at work, and it's running my MDM and my SDR or EDR tool. They know how to move that over to their machine at home, their cool water-cooled computer that they built at home, and then get to all of our infrastructures." 

So it's not a very good way of actually controlling access to an authorized and well-managed device so... And it's got some other things, it's expensive, it's certainly probably the only good way to get into on prem from external, but do you really want to take, I'm stealing another line directly from a client's, do I really want to have my CEO log into the VPN, you know, and go through all the challenges there, to have them, to trombone traffic, come back out to go to Salesforce to see some reports? 

It's a SaaS-based application. It's all HTTPS. So it's a secure tunnel, you know. So the only thing that, that buys me is frustration for my CEO, you know, as well so... We already talked about you can move the cert around. Some of the alternatives that they were looking at, at the time, didn't seem to work. 

Here's how we net it out, like, what would an ideal solution look like? It would look something like, but not exactly like, so you're going to laugh when I say that. I promise you, you will laugh because nobody has ever said ideal and airport in the same sentence, ever. 

Going through the airport authentication process is a giant pain for all of us so... But hear me out here. In terms of the things that you would want to do, it does make sense. You would want to have, you know, a good ID a really strong, you know, identification. In fact, we're going through a whole process here in the States because we didn't do it. Our driver's licenses are what we use to be able to get on a plane to go, you know, if we're domestic travel, we don't need anything more. 

But our driver's license were easily spoofed, basically, you know, by bad guys. It was not hard to get one. And there were two issues, the identity proofing wasn't very good for many of the states. Like, they didn't check a lot of records to make sure I've got a state citizen that should be getting a license, and then the license, the piece of plastic itself was easy to tamper with or spoof. 

So, A, you want a strong identification method and you want to check it, but then you want to confidently authenticate that it's Mario that's coming, you know, through, but then we don't let Mario go down to the plane. We're putting him through the full body scanner or at least a magnetometer to make sure he doesn't, you know, have a gun, or some knife, or other metal on him. And then we're putting his bag, if he's bringing a carry-on bag or anything or his jacket, we're putting that through the scanner, making sure he doesn't have it. 

And that's kind of the thing. You know, before we grant you access to where you're going, let's check everything and make sure. Now nobody in the world would say, the why you'd laugh, is it would say that that's a frictionless experience. But we can do better in the digital environment, you know? They don't violate transitive trust. And having been a victim of this myself, I wear glasses. 

I might have gone to the bar out in the lobby area, before I went through, you know, into the other thing. I might have had a couple of beers and I might have forgotten my glasses at the bar. So I go through this whole ugly, you know, this whole rigmarole process, and then I have to go get my glasses. I have to go back out, go grab my glasses, and go back in. 

Well, they don't wave you back through, right? It's not like, oh, come in. We saw you. You're going through the full set of checks again. There's no idea of, you know, just because we checked you a little while ago, we'll still let you through. You're going to go through it. So this idea of transitive trust ends up being important. 

So that's what we do. I'll net it out this way. We've used that same technology, you know, certificates, public private-key cryptography, but we built this stuff in a way that you don't have to run a certificate authority, anybody that's ever had to do that, build a PKI infrastructure, you don't have to do. 

You don't have to run or manage a certificate authority. We don't either, I'll tell you why. It's all, you know, part and parcel of the applications. But we can use strong, cryptographic asymmetric cryptography to do that. Why? Well, modern devices have a couple of things. Modern devices have really nice initial authentication methods, either a PIN code where the PIN is stored on the device in a trusted piece of hardware, the TPM or the enclave. 

You know, it's not like a password that, you know, is stored in a database on the other end. It's literally stored in the device, but not on the hard drive where a bad guy can get to it. It's forwarded and... That's one piece. But those TPMs are also really useful. A PIN code or a biometric is what I was for... So to identify myself to the device, I've got, you know, a really strong way to do it. 

We know it's pretty strong because our FBI keeps asking Apple to break into it for them and, you know, Apple's response is we wouldn't if we could, and we can't anyway. So, you know, go away. They're asking them for, you know, good reasons. You know, I won't get on my privacy soapbox here. But, you know, we know we've got strong authentication factors in the endpoints these days. 

The other thing we have is that TPM. So we've got a really nice place to store a private key in a way that it can't be moved. It can't be moved off the device. The user has no access to it, our software has no access to it, actually. So what we do is we've got a piece of software, an authenticator, I'll show you really quickly in a second. 

And our authenticator has two jobs. One is, when you register to our service, I should say, I'll be very pedantic, it asks the TPM hardware, the specialized hardware on modern computers, and phones, and tablets, it asks it to create a private key and store it and then it asks it to sign, which we never see, and it's stored in the TPM, and it asks it to sign a X.509 certificate and send it through to us. 

Well, the X.509 certificate also has the public key, it's associated with it. We store that public key in our cloud. So we've got an authenticator in a cloud, the private key stays on the hardware at registration. Now we've done that cryptographic binding, we know that the MacBook Air that I'm working for is cryptographically bound to me, to my identity, and to the device. 

So it's me and my device all in one. So now when I log into the device, and you can't use the PKI or the public key in the background unless you've authenticated to the device, right? We don't have to have passwords. We don't have to have passwords in authentication flow. 

We don't have to have a password in any flow that's related to, you know, re-upping or if you lose a device or anything like that. So there isn't, you know, this idea of having to set passwords, or reset them, or revocate them or whatever. The way we've done that is authenticator really is kind of like a little private certificate authority. So it issues a certificate, you know, in the same way that a certificate authority would do it. 

And this was our patented innovation. Wait a minute, we can make every endpoint its own certificate authority, and we'll make the back end, the cloud, the holder of the public keys. So there's nothing of value to steal from our back end. We could open that up and publish it tomorrow. They couldn't do anything with it other than validate that the, you know, that certificates were signed, you know, with the key. 

It's nothing to steal that's of use, you know, for any bad guy. But we took advantage of the modern technology, the TPM and the strong, you know, biometric or PIN code authentication. And so you get multiple factors during each login. You get the possession of the device, you get the certificate exchange, you know, to prove my identity. 

So that's two. And the third one is we do a bunch of device checks. So I can say, with very, very, very high trust, that it's Juha coming in on a device that I've authorized him to use, and we can open up or close down that authorization based on, or you guys can, based on policy. Let's not assume that Juha's device is secure at the time of login. I can check all kinds of things that I want, dozens of policy checks or user-defined policy checks. 

You guys can write your own. And all those policy checks come natively. If you've got a BYOD device, we can still do them. If you happen to be on your work-issued devices, or running an MDM, or an EDR, we can integrate with those and get even more data about the, you know, this current state of security of the device when we let you log in. 

So when you log in, our gate is just like the airport gate. We're checking you, were checking, you know, that we're doing the scan, and we're scanning your device, you know, not scanning it for viruses or anything, but we're making sure that the security settings, is the firewall turned on? Is disk encryption turned on? 

Literally, at the time of login, you know, is the phone jailbroken or not? You know, a huge range of things. Or, hey, are there any alerts or issues, you know, with your EDR technology? Is your MDM up and running and using the policy that it was supposed to have, for example? So really, really strong assertions of identity, really, really strong assertions of the device, and really, really strong checks on whether the device is secure enough to get into whatever you want to let it get into. 

You know, I wasn't even going to do this under a picture is sometimes... Let me move this up. I'm going to leave you with this. Where are we? It won't let me... Okay. Here, I'll do a different share, then let's, I'll unshare and then reshare. 

I can work around this. And Zoom hides all kinds of stuff on your screen, you know, for you. Not nice. 

There we go. Okay, but now let's, I'm going to reshare a different screen. All right. So we're an Okta shop just to give you kind of a quick taste, a quick demo of what we do. 

We're an Okta shop. So I'll show you my little Beyond Identity. This is our authentication software. Runs across nearly any platform. It's easier to tell you where we don't run. Right now I don't have a solution for Google Chromebook. 

But other than that for any PC including, Linux, tablets, Linux, Windows, PCs, Mac, all the Mac ecosystem in terms of phones and tablets, all the Google ecosystem in terms of phones and tablets, etc. So we support all those. 

Like we said, we got to get a solution for Chromebook which actually one of our investors wants. So we should get on that. But so here's my identity in my authenticator. This one is running on my machine. You know, you can see that, you know, has some information about the machine, some of the device checks we can do, but I'm going to log out really quick. I'm running just to give you a quick...I've got a MacBook Air with a fingerprint reader, you know, on it. 

You know, this is logging into the front door of Okta looks like, you know, to us. As you can see, we've got a username, no password, and a Next button. So, of course, I've authenticated, you know, to my machine, I've authenticated into my machine already, and, you know, be careful, look, Mom, no hands kind of thing. You know, I don't have to do anything else except for, you know, by policy, we're doing a step-up authentication, in this case, to make sure that it's still me at the device. 

So I put my finger on the fingerprint reader and off we go. So I got multi-factor authentication, I got the device checks, my device clearly passed policy. If I went and, like, you know, turned my firewall off or did some other things I could get it to fail, you can take my word for that, or I'll let you guys dig in a little bit deeper. But that's where we're at now. 

We're, you know, strong multi-factor authentication that is, you know, we think the easiest to use in the industry.