Passwords have been used for authentication for decades and continue to proliferate. Yet we know they create friction for users, slow down business productivity, and are a weak form of user authentication. Users are always forgetting them or use weak passwords that are easily cracked by hackers. Many organizations would love to lessen reliance on passwords but many passwordless solutions only provide a partial solution and do not solve the inherent weakness of passwords. Modern enterprises cannot cover the myriad of access use cases today with a passwordless solution alone.
Just some housekeeping for today's webinar. You, the listeners are muted centrally, so you don't need to mute or unmute yourself. We will be recording this and in course, recording all the slides, the webcast we've made available quite quickly. And they're also, you can download the slide decks. If you wish to question answers, we will be taking Q and a at the end of the webinar, but you can enter questions anytime. So if something pops into your mind and you wanna ask either myself or Wolf, then please just drop it into the box in the control panel that you should see on your right, send it, and then we'll pick it up at the end.
So the agenda for this afternoon, I'm gonna be talking a little bit about sort of the history of passwords, why we, after thousands of years, we're still using them and why they still present a security risk to companies and organizations around the world. Then Wolfgang will talk a lot more in depth about how passwordless authentication is possible and why it's a key building block to enable zero trust for the workforce and why passwordless is possible right now. So we're looking forward to hearing more about that from Wolf. And then as I said, we have Q and a at the end.
So I'm just gonna, as I said, take a fairly high level, look at the history of passwords and how they have been used down the ages. I say down the ages actually were started off in biblical times. It will take a fairly rapid jump to the 20th century after that. But when I doing some research for, for this webinar, I found that what possibly is the first known incident or incident of a use of a password could be traced back to the 12th chapter. As it says here, the biblical book of judges, which is apparently around 1200 BC and in a battle between the, the, in that time, what we now call modern Israel were split up into, I think it's something like seven or eight different tribes and regions. And, and as today as was then the middle east, unfortunately saw a lot of tribal difficulties.
And there was a battle between the tribes of Gilead and Afra and the way that the Gilead soldiers decided to find out if any of their enemies was amongst them, was get, get them to pronounce the word. She now, the Gileads pronounced. It Shiff was an H they knew that the EF mites couldn't actually say that they, for some reason, they could only say Siff. So if they captured someone or they were suspected someone, then they would ask them to pronounce their, that word. And if they got it wrong, unfortunately the part, the penalty was death. And as it says, there, they were SL or slain at the Fords of the Jordan, which the river Jordan ran just east of Aran in those days. Now this probably is, got some truth to it, but it's, it's an example of how passwords even in the most primitive form were not the most reliable. It doesn't account for the fact that some of the GI ads might have cotton under this and would train themselves to pronounce the word correctly and vice versa. Some poor innocence may have accidentally pronounced it wrong and also found themselves slain at the fors of the Jordan. So that's a slightly, a high level look at what happened many centuries ago, but the concept that we, we be talking about this afternoon, hasn't really changed that much from then you type in a password. If it's not correct, you can't come in.
So zooming right up into the 20th century and right into the computer age, we see what is possibly or is it's not to be the first use of passwords in a computer system, MIT, which is the Massachusetts Institute of technology, a very fine institution, which is known around the world for many, many innovations in computer sciences, many other in other areas of science, it's believed that they were the first people to think that perhaps they, they should have some kind of authentication method so that when users logged onto the computer systems at MIT, they kind of knew who they were or that they knew that they were who they said they were. However, the first known computer breach occurred when a researcher simply printed out all the passwords, because they were in the clear, they weren't even encrypted and then gave 'em to the others.
So they could all log in willynilly as each other. Which of course, probably wasn't a huge problem when you, there was no internet, of course, in those days. And these were closed systems and those that accessed the computer were pretty much trustworthy. However, there was a software bug that someone created that made the passwords available to anyone who logged in. And whilst that again, was probably seen as a hack in the original and sort of good term meaning of, of, of playing with a computer system to, to, to get a result. It wasn't the result of any criminal activity, but the guy was kind of set even in 1961, a password was pretty much useless. If, if all you had to do was look on the system, find all the passwords, print them out, give them to other people. So there was no protection of password. It was kind of just a, just a gesture, a gesture really of, of security.
We move onto something, which was probably whilst passwords being printed out. That MIT was not the most serious of things. It's come to light that during the cold war, the us United States had what they call the minute man, nuclear missiles. Now these missiles were housed in silos, right across parts of the United States in the Midwest, across farmland, even, even rather strangely, sometimes next to people's houses. Now in 1962, the president, there was a presidential order that all these missiles should be protected against a rogue missile launch, which sounds like a fairly fundamental thing to do that. You shouldn't just be able to push a button that, that be had some kind of what we might call today to factor, or you would hope multifactor so that more than one person gets to launch a missile, but the codes were installed under the direction of the then secretary of defense, Robert McNamara.
However, the scary part is that once he left office, the strategic air defense commanders, who didn't like him for some reason and were more concerned about being able to launch the missiles quickly, I guess, because they thought if they didn't launch 'em quickly, then the Russians as was then the perceived enemy would be able to launch theirs before they'd even got theirs off the ground. So rather bizarrely, they just set the launch codes to eight digits of zero. So, which was basically useless piece of security. Wouldn't be so scary if it wasn't for the fact of what a nuclear missile would do, if it was launched, not so much by mistake by perhaps by a rogue operator. And that picture on the right that you can see is a, actually an archive picture of a town in United States with one of those or some of two of those missiles on, on sort of public display and curiously in the background, there is five zeros. So which I've just noticed, which perhaps was for something else, but strange, strange times. Anyway, those, those missiles are long since been decommissioned. I believe
Moving much further up to date and with the company that is quite often in the news or various privacy issues or concerns that it doesn't use the data that it holds about millions of people as wisely as it should a Facebook engineer. And again, this is, this is a, a report, so it's not verified, but the engineer claimed that at any one time, employees could log into any Facebook profile using a master passcode, which was simply a variant on the words, Chuck and Norris, which Chuck Norris is in case you don't know a famous action hero actor in many movies. And they simply replaced some of the letters with symbols and numbers, which, which is again, are hardly secure and wouldn't stop many people determined hackers from hacking that she said that she used it and knew of two other users had used it to log in and then manipulate other users' data.
And they were subsequently fired. Well, that's good. However, she also said the password no longer worked. It didn't really matter because it was placed by tool, which let Facebook, Facebook employees log in as another user with a click of a button. So some of that is, might not be true, but I believe possibly the first part is. And again, the point is that password is only as strong as you make it. And a password that is stolen is useless as a piece of protection or as a security device. So that's some a quick whi through just some fairly, not lighthearted, but interesting examples of the weakness of passwords in themselves.
So with that, I just want to look quickly at where we are now and how this, this, this dependence of passwords, which we've had for decades and is still with us virtually every device, every endpoint that we use, our mobile phones still heavily dependent on passwords, virtually every website that we log onto regularly, we use a username and password, all of that. As I said, back in the days of MIT, wasn't too much of a problem because you had a closed systems. You had infrastructures that were behind. Well, they, they were closed systems. You couldn't get into 'em unless you were on the inside in the first place. But today we, we live in a world of massive, massive complexity. And even the smallest of businesses will be using some of the business technology that I've listed here. So we all know the cloud is, is, is very much taking over the way.
Most of the world does business and the way that we use computer resources, we're having virtual machines. And then we have hybrid architectures. We have things like DevOps, which is a world away from again, from what MIT was doing, but we have people creating software in a continuous development and creating products, continuous development, continuous integration. We have containerization, which is related to that automation, AI machine learning IOT. We have then a situation where users and users, employees, vendors, third party actors, or all at some point wanting access to systems and networks that are bound up in all those various parts of business technology. And then the business processes again have changed fundamentally, particularly in the last 10 years or so. We've seen the rise of mobile working we've seen, and I'm sure Wolf will be mentioning this as well. That in the recent COVID period everybody's been working at home and everybody is now wanting to log onto systems from home using not necessarily wholly secure devices. And a lot of those people will be using passwords and usernames to get onto what the systems that they were used to using at work compliance has made everything harder as well.
It, if you lose passwords and then that results in a data breach, then the company will be fined significantly in Europe and increasingly so in the United States, customers are now getting access to infrastructure, which is extraordinary situation. If you think about it, but companies want their customers closer because of social media, et cetera. And they feel that if customers are brought into the organization, they can respond better and produce better products and services that they need. Agile development and collaborative working. Again, collaborative working is, is, is, is changing the way we work and is changing the way that we produce projects. And again, that's being done increasingly from end points that are not actually in what we might call a traditional office, all that then needs to work with security integrations. So we have security instance event management, analytics, multifactor access, which of course is key to this single sign on customer integration, identity, access, and management and privilege access management.
And that's just seven products or solutions that we have now come up with all of which at some point may still require a password to access. Even, even the security tools that we use surprisingly might only be accessed by a password. So we really are sort of wedded to this way of thinking, but it can change. And finally security processes that we need to think about are instant response, security management, forensics, auditing, and risk management and risk management passwords. If you use passwords, that's always going to increase risk. So just finally then to give you the kind of schematic of what I've just been talking about. Everything is connected, distributed, heterogeneous and complex, right up from connected vehicles to the, what we might have called the mainframe. At some point, the connected vehicle may be connected to the mainframe, which is what those guys in I MIT were playing with.
So all of this happening, all of this means that anyone or anything at some point needs access to our modern infrastructures. And with frankly, we need a better way of securing that access we've come a long way. We do have things like privilege, access management and identity access management, but we still lose passwords. And every, every week we virtual, we hear of another company that has been breached. And the first thing that anyone says is that so many thousands or millions of passwords were stolen from that company. So there's millions of passwords out there and we need to talk about them. So I'll now hand over to Wolfgang for the second part of this webinar.
And yes, my name is Wolf gang Golic, and I am an advisory CSO with duo where I'm primarily focused on the zero trust and, and pass less conversations. And, and I like that historic look back. I, I felt that really framed the situation very well. One of my favorite anecdotes about the history of passwords comes from the 1980s. So 1980s, the BSD project, early eighties, where they're, they're building out the systems that would become, you know, the, the foundation for the cloud, for containers, for everything else. And, and recently a couple folks as their want to do, worked to crack some of these early passwords and the, the answers, the, the passwords that were there were using reminds me of kind of the fun it exists when you enter your first password, right? When you, when you make that first shared secret with the machine, it, it can be something witty.
It can be inside joke. It, it can be a loved one. So Ken Thompson, for example, used a, a chess move for his password. Eric Schmidt now of Google back then, and during the BSD days, he named his wife, his wife was his password. And I love that. Right? You get a little bit of affection. You, if you think about what you wanna be remembering, every time you, you get to work, maybe it's it's your wife or a loved one. One of my first passwords, I was thinking about this, putting together the deck was, was a play in the word askie. I was, I was a kid who had a little bit too much time in his hands, and I just memorized 127 bit askie table. And I'm like, yes, long passwords capitalization, I'm secure. And, and this is, this is a bit of fun. What, it's your first, first system, your first account?
It, it can be, you know, a bit of LARC when you got 3, 4, 5 passwords, but of course, eventually we reach too many, but even the, the venerable password on a sticky note is, is almost went the way of Shibboleth, right? Because who does that anymore? I, I used to lead assessment practices before coming to, to Cisco, and we never would find people with passwords on sticky notes. We always heard about it. We never found it. We'd find 'em in, in, in spreadsheets or text files to be sure, but not passwords. And I've got a theory as to why that is, it has to do with the fact that a typical employee has 191 passwords. This is data from the end of twenty nineteen, a hundred ninety one passwords. Think about that is effectively one wall in the home office covered with sticky notes. We have, we have sucked the joy outta these passwords, and we've made it untenable for a typical user to maintain it.
So I wanna look at where we can go next, moving away from passwords and how to simplify the user experience. I'm gonna provide a path that organizations can follow. If you are working on a roadmap for passwordless. And I'm gonna start by looking at where passive less fits in the broader security initiatives. So I would place it very strongly in the center of the zero trust for workforce journey. So if you think about zero trust, it's effectively not trusting someone based on their credentials. It's not trusting someone based on where they're at the network. It's not releasing that authentication to the users. So the user can use the privileges that hopefully we defined with, you know, good, our back, good role based access control, good, you know, identity access management practices for onboarding offer. Hopefully we have a whole slew of access management technology on the back end.
It's that front end, that very initial moment where we decide if we're gonna trust somebody to move forward. Now, the problem is so many security officers are just now shedding the legacy of the department of no. And yet we're going to go and build a business case on saying, oh, we don't, we don't trust you. And that, that can be, that can be a significant challenge, but we know we have to implement this. If we're going to support remote work and have a good assurances about our identities. So for the organizations that are, are building business cases for zero trust today, which is in the us about, you know, 59% of organizations I find passive less is, is very appealing. Why? Because a strong authentication is, is critical towards strong trust and strong assurance that all the other principles of zero trust, hang on, which I'll get to in just a moment, B more importantly, when we think about a business case for zero trust, when we think about what's in it for the users, when we think about how to enable agility in our organizations that move away from the password is, is so powerful and so strong of a, of a gift to the end users, right?
How often do we get to make the end users' lives easier? And so by doing that at the same time where establishing stronger factors and putting in place zero trust controls, I think has a significant amount of promise for our business case and all the downstream fundamentals plug into it. Things like making sure that we've got that authenticated identity, certainly good visibility and ensuring that a perimeter is any place that we make an access control decision. So adaptive access, conditional and contextual controls, things like who is this user? What device are they on? Is the device healthy? Is the user behavior normal, all those sort of controls allow us to establish trust to let the user go in and use the privileges we've already assigned to them at the same time, reducing user friction on the front end. So let's look at passive less now from the lens of the users, from the lens of the people who are trying to get the work done, the, the usability aspect is so front and center in my mind, ever since we've, we've implemented passwords, we've asked more and more of users in order to protect these.
And this goes all the way back to that MIT story, Paul, that you were, you were sharing in the beginning, right? In the, in the early sixties, MIT establishes passwords in 1966, they establish the first encrypted password. So they're clear text for the, for the beginning. And at that moment, at that that point in time at the Friday evening in 1966, we established two effective moves for protecting credentials. One was invisible to the users, better algorithms, better hashing, better storage, better protections, and secure enclaves. The second was very visible, very friction inducing on the users, things like password complexity, password rotation, you have to have 191 unique passwords, password length, those sort of things. And, and right away, we see the, the split between what security controls we add on that are invisible and don't affect user experience and what security controls do. And so now we've got effectively 60 years of user friction that we built up to reduce and remove, and it's across all the devices we use it's on, on our phones, of course, on our desktops, on the apps, on both of those platforms.
And of course, on, on web apps. And a lot of work has been done by various manufacturers in various authentication platforms, such as touch ID and face ID on the iPhone fingerprint API on the, the Android device windows. Hello, of course for our windows desktops, but we still got a lot of, of work to do to move forward on this. And one of the main drivers are those phones, right? One of the main drivers are the consumer world and in the consumer space, we've really pushed forward in terms of providing a seamless experience. Most users are, are using touch or face ID, and it was a fantastic leap forward when it came out. As a matter of fact, if you, if you think about it, it's a prime example of increased usability leading to increased security because before, before most people who had the iPhones were not locking the device, I think the, the numbers were somewhere in the teens before touch ID came out.
And I remember, as my users were, were abandoning my, my Blackberry with my hardened policies and everything and bringing in iPhones, it was very frustrating. I'm like, you gotta lock your voice, but they didn't want to. They wanted the ease and convenience. And there was even a, a famous Steve jobs rant. Oh, there's always a famous Steve jobs ran, but there's a famous Steve jobs rant about how, why would you ever lock your phone? We want, we want people to get in and, you know, change the world and experience. So what does, what does apple do? They watch how people use their phone. They pick up the phone, hit the home screen and go. And they watched that and they worked with that and they worked with the designers. And of course they integrated in touch ID, right under that home screen button. So the minute you pick up your phone, you hit the home screen, you're authenticating.
And that combined with smart defaults and combined with the speed of authentication, that meant within one year of the touch ID being shipped, that the percentages of people with these new phones locking their screens, went from teens into the 80 percentile. So massive shift in terms of security. Why, why driven by improvements in usability? But anyways, so today we pick up our phone, we lock in to our home screen. We open up our apps and we're not prompted every single time for our password. Very rarely do we have to enter in credentials, it's reliant upon device, trust, device level authentication. You contrast that to your office experience, which is oftentimes getting in your desktop and every single app, you, you open every single website you're prompted for another password and, and prompted to get into your authenticated applications. And again, oftentimes those are separate passwords that you need to remember and type in the right one.
And it really creates two things. One, a lot of friction, again, 60 years of friction, we've inherited to that in the corporate environment, but two, a, a very disparate experience between the workforce and the consumer technology experiences. And I think that's really been driving a lot of the passwordless use cases. So let's take a, a look at those use cases. Now, starting out for those device use cases. Again, you pick up your device, you log in, you go this, this has proven very effective to get into a number of desktops and, and phones. And what's unique about this and what I really like the way they've set it up. And what enables that device trust and device level authentication is that those credentials are stored within the device. So I don't have to worry about my fingerprint leaving my phone. I don't need to worry about my face leaving my, my windows.
Hello box. They're stored securely in the computer. What's also unique about this is back to what we saw in the sixties. A lot of changes have been made and a lot of battles have been fought with adversaries around secure password storage. And so in, in the case of, you know, iOS, those biometrics are stored in a secure enclave within the devices, encrypted, protected in the case of windows, hello, that biometric information is stored on the TPM secured, protected so that it can't be stolen. It's not used for authentication. It's actually the, the device itself that then uses key material to authenticate to other other areas. So there's a lot of advantages coming out of these device use cases and a lot of advantages coming out of a platform approach for pass authentication. Couple caveats here, couple caveats here for early adopters. One is this, this naturally is predicated on a one to one relationship with users and devices.
Now, we all know that just about everyone on this webinar. I can guarantee as two or more devices, 90 in light last year, a study found that your power users, one in five users, your power users in the workforce have six or more devices. So when you consider a one to one starting point that breaks down, if you have six different devices that need to be enrolled, protected, secured, offering different experiences and different levels of quality. So we, we have a breakdown on the one user to many devices. We also have some concerns around the opposite, many devices or many users to one device. So if you have many users to one device, think medical floor, I think call centers think anywhere where there's shared equipment. We have a situation where passwordless today is not necessarily ideal for those situations. You don't wanna enroll like your 10 people's fingerprints all on, on one computer. So there's some scaling issues and some broader ways of thinking about passwordless that need to happen above and beyond these device use cases.
Then we've got our web app use cases. Now a lot of web apps have moved to SAML and O IDC. That's the modern authentication stack. That is fantastic because in the, the beginning of a passwordless journey, we can have less passwords. What I mean by that is grammatical weirdness aside. We can offer a experience of fewer authentications to our end users using things like single Sinai. Now, the downside of course, is there still is a shared secret. And in many cases in pastoral solutions today, there will still have to be a shared secret while we, while we transition towards a pastor's future, which is who reliant upon authentication protocols that shared secret can still pose a risk. If users are aware of it are entering it, have to remember. It can definitely still pose a risk. If adversaries can capture it can BR force it can get in.
So the, the first aspect of, of SAMO ADC is very intriguing because it simplifies the user experience. It starts us down that journey of moving away from passwords, but there are still some risks. The other area that we're watching very closely is the pH oh two standard of course, pH oh two is composed of web then, and CTAP, which were formally accepted as standards in the beginning of last year, Google and Microsoft early adopters. Apple is joined the 5 0 2 Alliance the beginning of this year. So we're, we're looking forward to seeing a lot of the device use cases integrating in with a, a 5 0 2 standard to provide that pass or less experience. And that's also an area where Duo's been very active. We've been part of the Fido Alliance since the beginning, and we're one of the, the first to support UTF and one of the first to support fi oh two.
Now that also sounds great. Hey, we'll, we'll have our devices and have our web apps and, and life will be good. We'll eventually be able to get rid of passwords. However, there, there is certainly a caveat in that most organizations are still in a, a hybrid environment, even, even talking with IDAs providers, we have a partner that does identity as a service, and they were telling us that still effectively, 70 of their clients, 70% of their clients are in a hybrid environment. So using identity in the cloud, having a cloud first approach, but still having a majority of their customers being hybrid. And in the dual world, we see something very comparable in any given month around 64% of our authentication is still with legacy protocols. So radius L D cetera, whereas the, the remainder, the small, but very growing percentage is modern off oh, ADC SAML 5 0 2.
So when thinking about pass list and thinking about the journey to it, there are pieces that we can plug in and snap in today very easily with device based authentication, looking at modern web off that supports either Sam for a less passwordless single sign-on approach, or 5 0 2 for a pass, no shared secret approach, but there's also a number of pieces that we're gonna have to think about very carefully and snap in, in the right approach at the right time, which means that a good pass, less plan, a good pass solution has to be geared towards incrementalism has to be geared towards sprints over roadmaps. That means things like supporting a per person per user approach to shifting people onto this authentication per application approach. And of course, supporting phased methodologies like enrollment campaigns and so on. So incrementalism and backwards compatibility is going to be hugely important for the next few years, as we deal with a long tail of legacy technology. The next thing to, to consider is stopping the adversaries.
Now, so many attacks trace back to credential theft, right? 81%, according to Verizon. And that could be things like passive reuse week passwords, those types of areas that we demand users do better, but it can also be things like credential, stuffing and fishing, where we're setting up points, where the attackers can take passwords from other sites and reuse them against us. This is a problem when we start thinking about those legacy protocols, because credential stuffing is stopped 100% of the time when you put in place multifactor, however, the criminals don't just give up, what do they do? They go ahead and, and use legacy protocols like IMAP and pop and other things that might be exposed. So we, we need to think very carefully, not only about stopping these, but also stopping what the adversaries will do next. And I think that that concept is, is so vital with authentication, particularly, but with security in general, all too often, we, we forget that we are effectively playing a game or we're many organizations globally over many years, right?
We, we move, they move. We, we put in place multifactor authentication, they shift to legacy protocols. We put in place strong hashing. They shift to rainbow tables. Every single move we make does not stop an attacker. There's no, no technology solution that would do that. Every single move we make, what does it do? It opens up a series of new moves for the adversary to take. And in this regards, there are certain things I think we need to think very carefully about such as what happens if a, a biometric or device is, is spoofed. What happens if a weakness in the device is used to circumvent the authentication protocol itself. And in those regards, if we can think ahead, a few steps to know that the adversaries are certainly gonna do that, we can start putting in place compensating controls and good guidelines to make sure that we can cut them off of the pass because effectively good security gets out of the way of the end users while getting in the way of adversaries. And that is what makes me so excited about pass less because there's a series of moves we can make. There's a series of controls we can implement. There's a series of better factors and better methods that we can utilize that are all transparent to the user, as opposed to asking them to remember more and remember longer and change it frequently.
So let's talk about what a path to a passwordless would look like. It begins with identifying what the puzzle pieces are, identifying those passwordless use cases and, and ensuring we've got good multifactor support. Now, my, my very simple way of explaining passwordless is to think about multifactor authentications, the password, and some other factor. And we've made some significant improvements in the other factors over the years, things like UTF, things like push have greatly improved the factors of authentication. And yet we're still reliant upon those in conjunction with arguably, what is today, the weakest factor that text password. So with passwordless, we're removing that password and using one or more factors as the primary authentication password. It's important to remember with these additional factors. There are some that we know are, are susceptible to fishing are susceptible to interception, are susceptible to theft. So when we look at all the possible factors for authentication, we need to eliminate, or at least minimize the use of those that we know can lead to issues.
Now, of course, the factor that most people think about when they think about passwordless and for a good reason is, is biometrics and biometrics is certainly a, a strong factor. There's been a significant amount of improvement in, in hardware, a significant amount of improvement in fraud detection. I remember back in the day, a lot of pastoral or pardon me, a lot of biometrics could be easily bypassed. I, I had a data center with a thumbprint reader in the man trap, and it, it could be worked around with the old gummy bear truck for, for a period of weeks. I was logging into my multimillion dollar data center with a gummy bear to demonstrate, Hey, this is a serious problem until they adjusted and, and secured down that platform. So there's, there's a lot of us who are old enough to remember how bad biometrics used to be, who may be a little bit cautious about moving forward with this technology.
But thankfully there's been a significant amount of improvement in the consumer space to address those issues. There's also a lot of us who are concerned about biometrics from our privacy issue. I don't, I don't necessarily know that I want my, you know, biometric data stored by my company. And if I'm a CSO, I know I don't want it stored because I'm running a risk of security issues. I'm running a risk of regulatory issues. And so again, that that platform approach that device of authentication is attractive. Why? Because that biometric data belongs to the user in the user's device and is never exposed or exportable. And finally, a interesting aspect of biometrics is the standardization and the growing adoption of these more platforms, more support. But I would urge you guys to separate hassle less from biometrics, because there are multiple factors that we can use.
And that becomes important. We talk about recovery. So the idea here is to move to a strong authentication, possibly with a single primary factor, rather than trying to chain together several week factors. And that's the potential we see with 5 0 2 second step in the, in the plan is to go ahead and consolidate our authentication workflows important because typical organizations have over 1400 apps and that is a significant footprint. So we want to consolidate those application workflows, move them onto a, a single platform. And again, address the legacy authentication, put in place a plan for either moving towards a more modern off stack or supporting those in the secure fashion until that legacy technology is retired.
Step three in this is so important. When I talk about the next steps a criminal might take, step three is increasing trust and authentication. Part of that is smarter platforms. Anti-fraud technology on cameras, liveliness sensors on fingerprint readers for biometrics. And that that's so fascinating to me, right? Because you can't necessarily put in place a smarter keyboard to detect when someone is typing in a wrong password, but we can put in place a lot of anti fraud that is invisible to users. And then finally bringing in place some of those zero trust aspects, device trust. Are we on a device we've seen before? Is that device have good security hygiene? Is it up to date? Is it free from malware? Is it free from Indy indications of compromise and are the users behaving? Like we expect them to, are they accessing what we expect from where we expect when we expect it?
Those two aspects can greatly reduce fraud and greatly reduce the likelihood of a, a criminal being successful with a SPS factor, of course, to act on that we need to act very quickly, which is where adaptive policies come in place so that we see that the authentication should not be trusted. We can Deth isolate and protect the organization until we investigate all. These are effectively stepping stones to a pass solution. When we actually get to enabling passwordless, this is where the users see the most benefit, but this is also where an it operations team will see a, a good amount of benefit too, for reducing support on passwords, reducing the time and effort to do rotation. This does mean that we should demand of our pass vendors, that they have good enrollment experiences, that they have good recovery experiences that they have good. Self-service why, so that we can indeed reduce the burden on the service desk while moving to this technology.
So once we've got that cadence in place, we consolidate, we put in place good compensating controls. We increase the trust authentication. We move into pass less. We can rinse and repeat and use a very agile, very scrum like approach to moving use cases over time into a pass, less framework that gets to the last step, like any good maturity approach. It's all about optimization, making sure that we're using the, the right amount of tools, lots of studies have shown including a recent one from Cisco that more tools, more technology leads to longer downtime, more complexity. So optimizing the tool set and then integrating passwordless in with broader initiatives, such as zero trust. So in conclusion passwordless is, is a rare security solution. That's both more secure. And in order our magnitude easier for the end user, it's, it's this rare moment in time where we can make the, the business case that we are indeed gonna improve the experiences for the workforce while at the same time we're iterating and improving our defensive capabilities around authentication. So here's some of the things to, to do next. And, and Paul, I'd love to hear your opinion on this, but in my, my view, if, if you're an organization considering pass list, I would encourage you today to prepare and plan for it. I think of those five steps that I just covered watch this space. There's a lot of fast moving innovations and it's a, it's an evolving market. And finally make sure you're tying strong authentication to broader initiatives.
Well, thanks so much the really great presentation. And it really struck me again, just how dependently are on passwords. Reminding me actually, again, real world example, I recently switched from a, a Android phone to an iPhone. And of course you can, you can, you can shake, you know, move your apps across, but what, what it doesn't do across is move any passwords across. So then I'm left with a load of apps. Do I remember any of those passwords for all that banking application for, for Amazon, for all of them? No, of course not. So I have to go in, reset them all and start all over again. We, we are a little bit shorter time, but we do have a, a couple of questions just having more than one passwordless passwordless access to an application or device is really good question to an application device, raise the risk.
Yeah. So if you've got multiple factors to authenticate to an application, your, your attack surface is certainly going to be increased. So you need to make sure those are multiple strong factors. However, I do think it's important to have more than one back to password recovery, as well as you know, there's, there's lots of research being done. And as we age, you know, biometrics don't always work for us. So there's, there's gonna be situations where biometrics are not able to get us into our devices. So having fallback factors I think is critical.
And how, how simple is it to reset or replace passwordless solutions if they're lost or stolen?
Yeah, that's an area where I know duo is spending a lot of time ensuring that that rotation and, you know, marketing devices as, as lost her stolen is as easy as possible. It's gonna certainly vary vendor to vendor, but when you're, when you're testing out technology, I would encourage you to make sure that's part of your pilot, because we all know that it's gonna happen.
I, I mean, what about some people might say, yeah, but passwords though, right? They're not the most secure, but they're easy to implement and that some of the alternatives are not so great either. Like, you know, they can be hacked biometric, certainly let's for example, the eye recognition, it's not unheard of, for a photograph of the genuine owner to be held up in front of a phone, things like that. So people are gonna say, that's gonna make us less secure.
Yeah. And there's, there's going to be people who want to, to hang on passwords, just like there's, there's times where I want to hang onto my data centers, we're shifting the cloud. And, and part of that is, is working through what use cases make sense and what use cases don't, but insofar as the risk of, of someone, you know, taking a snapping, a photo, or somehow getting your, your fingerprint off of a, a whiskey glass, you know, vis James Bond movie, that's where the step of increasing trust in authentication is, is critical. So if we assume that there is a likelihood, these factors will get compromised. How can we, you know, check and reduce the likelihood of fraud before that authentication completes?
Well, exactly. And of course the, like, like you say, there's a lot of James Bond scenarios, but we know that it's far more likely that weak passwords will be stolen and, and continue to do so or be so on, on almost a daily basis.
Okay. Well, I think we're almost out of time, so I really, really want to thank Wolf Wolfgang again for that excellent introduction to passwordless. And I hope it's given you some food for thought as to how passwordless can be implemented. It's not as hard as you might think, and the, the benefits are likely to outweigh any, any hardship. So that brings us right to the close of today's webcast. And thank you so much for listening and, and for your time this afternoon, again, a big thanks to Wolfgang and to J security. And I hope that we'll see you again on another webinar for now. Goodbye.
How can we help you