Take Invisible MFA to the Next Level With Passwordless Continuous Authentication

Hi, welcome to the webinar, Take Invisible MFA to the Next Level With Passwordless Continuous Authentication. My name is Alejandro Leal, I'm a research analyst here at KuppingerCole, and today I'll be joined by Nawshad. How are you?

Hey, Alejandro. How are you? I'm good. Thank you. Thank you for having me today, and I look forward to our session. Great. Thanks. So first I will begin my part of the webinar, and then Nawshad will conduct the second part. So let's start with the first some important information regarding audio control. All of you are muted, so there's no need to mute or unmute yourself.

Polls, we're going to be conducting a couple poll questions, so I encourage you all to participate. Q&A, we will have a Q&A session in the last 20 minutes of the webinar, so you can enter questions at any time by using the GoToWebinar control panel. And regarding the recording and the slides, we will be sharing the slides in the coming days, and the recording will be available as well. So here's the agenda.

Like I said, I'll begin the webinar by introducing the concept of passwordless authentication, and then Nawshad will go more in depth into the topic, and then at the end we'll have a Q&A session. So here's the first poll question. I'm going to give you guys 30 seconds, and the question is, has your organization suffered an attack that was caused by breached passwords, yes or no?

Okay, we can proceed now. Here are some of the market drivers of the passwordless authentication space. With the COVID-19 pandemic and the shift to remote and hybrid work, credential-based attacks and account takeover fraud cases have been on the rise. Cybercriminals continue to come up with new ways to obtain users' credentials and access private information. Furthermore, the development of open standards, such as FIDO2 and WebAuth, together with the Biden administration's memorandum on phishing-resistant MFA, are likely to contribute to further adoption of passwordless solutions.

And in recent months, we've seen all over the news the introduction of passkeys by Microsoft, Google, and Apple, and these developments are also going to contribute to more adoption. And like I said, the shift to remote and hybrid work and the growth of e-commerce are likely to increase the demand for more modern authentication systems.

Of course, there are more market drivers, but here at Copenhagen Call, we highlight these specific market drivers that we have observed in our research. So I think the question is, what's wrong with passwords? I think we all know here that passwords are problematic. They are inconvenient and insecure. But if we look back at the history of passwords, if we trace back the origins, we will realize that passwords were not created to provide security. The password is remnant of an era before hacking and password-based attacks became a widespread problem.

Here we have five common issues involving passwords. Number one, there's research out there that points out that most data breaches involve the use of stolen credentials and compromised passwords. For many organizations, password resets are very costly and time-consuming. Another major problem is password reuse. Many customers and employees, they often use and reuse the same password across multiple systems and applications, which is perhaps not the best idea when it comes to security. Also we see friction. Adding MFA alongside passwords results in poor user experience.

I know that Noshad will talk more about MFA later on. And last but not least, legacy solutions. Most MFA solutions still rely on a password, and they can easily be bypassed by attackers. In the next slide, we see some of the most common attacks.

Phishing, credential stuffing, man-in-the-middle attacks, brute force attacks, and theme swapping. At Copenhagen Coal, we believe that organization systems must cease supporting legacy authentication methods that are prone to password-based attacks. Something that we also like to talk about is account recovery procedures. For example, when a user loses a device, a phone or a computer, or simply the user replaces the phone or the computer with a new one, solutions must make it easy for users to recover their accounts.

Users should not go to a store or spend 20 minutes waiting for customer support, but on the contrary, it should be very easy for them to recover their account. In addition to convenience, it also needs to be secure for them to recover their account. And that's why solutions must provide methods that are not prone to password-based attacks. So what's the alternative? The alternative is password-less authentication. And if implemented successfully, a password-less solution will increase both security and convenience.

In a nutshell, password-less authentication is a term used to describe a set of identity verification solutions that remove the password from the authentication flow and from the recovery process as well. These solutions can overcome the notion of balancing security with convenience and instead adopt a win-win approach, which involves increasing both security and convenience. So what are the use cases? During my research on password-less authentication, I believe that the most common use cases are workforce slash enterprise and consumer use cases.

But there are also use cases for citizens and partners. When it comes to enterprise, it seems like security is the main priority, while for consumer use cases, user experience is the main focus.

However, leveraging both at the same time is essential. Some solutions in the market provide nearly every feature one would expect.

However, there are some highly innovative and small companies that are more specialized and provide different technical capabilities. For example, some of them choose to focus on device trust or on risk-based authentication, or some of them prefer to target different industries like the small and medium enterprise market. So on this slide, we see some of the main capabilities of password-less authentication solutions.

Of course, there are different flavors and different views exist on password-less authentication solutions, but essentially there are two elements that are required. Number one, no password is required for user authentication, but a strong authentication is performed. Number two, no password or password hash is traveling over the network. On the right side, we see in these small boxes some of the capabilities that we observe in password-less authentication solutions.

They should support a broad range of authenticators, strong authentication, risk-adaptive, context-based, and continuous authentication, adaptive and step-up authentication, support for legacy application and services. This is an important one, especially for organizations that continue to rely on legacy systems. Password-less solutions must make it easy for them to migrate from a traditional system to a more modern authentication system.

Password-less solutions should also enable strong cryptographic approaches, integration with third-party authenticators, device trust on multiple devices, support for all major identity federation standards, and a comprehensive set of APIs. Of course, there are more capabilities, but we like to highlight these. So what's the difference between legacy MFA versus invisible MFA? Traditional MFA solutions back in the days were once hailed as the ultimate solution that will basically overcome the issue of passwords.

However, the problem is that some traditional MFA solutions continue to rely on a password as the first factor or as the backup factor. In addition, MFA on top of passwords only increases the inconvenience and it often results in poor user experience. While a password-based MFA system may once have been enough, its viability in today's threat landscape has been diminished. Password-less MFA, on the other hand, should be able to eliminate the reliance on passwords or other easily feasible factors. Device trust is an essential component of password-less authentication solutions.

Essentially, it is the process of analyzing whether a device should be trusted or not. It requires solutions to possess the ability to verify the user behind the device and, importantly, to continuously validate the security poster of the device to make sure that the correct and authorized user is the one who will get access to the resources and information. Having strong device trust policies in place gives organizations the confidence to control access to critical resources. Another essential component is risk-based adaptive authentication.

The goal of risk-based adaptive authentication is to provide the appropriate risk mitigation assurance level for access to sensitive resources by requiring users to further demonstrate that they are who they say they are. When it comes to risk-based adaptive authentication, there are different attributes that are analyzed, such as the IP address, the geolocation of the device, or the geovelocity, the device type. There are lots of these attributes, and this is one of the main components of password-less authentication solutions.

However, we all know that there are obstacles that many of the password-less vendors are facing. Many customers and organizations don't know how to start, and like I said before, especially those that continue to rely on legacy systems. There's also a problem when it comes to business and IT alignment. Sometimes business leaders might not be very tech-savvy, and they don't know what the organization truly needs. There's also the old-school mentality, which is similar to my previous point.

Some people perhaps do not understand what password-less truly means, so vendors need to deliver the right message and to be more straightforward when it comes to how a password-less authentication solution can benefit the organization. There's also some issues with deployment costs, with selecting the right product, and with licensing and subscription costs. So how to move forward? The right password-less authentication must meet the unique requirements and needs of organizations regarding security, user experience, and technology.

It is important to identify your organization's needs, to then follow a zero-trust security plan, then select the right password-less solution, and then choose the appropriate deployment model. It's not easy to do this, but one needs to understand what your organization needs in order to select the appropriate password-less authentication solution. During our research at Coping a Call, we recently published a leadership compass on password-less authentication.

It was published in October of last year, and we used these criteria to evaluate the – I do not remember – I think 25, 26 vendors participated. And these seven criteria – this criteria was used to rate the different vendors. Account recovery is one of them, and like I said in one of my first slides, solutions must make it easy for end users to securely recover access. Then we also looked at architecture and deployment, authenticator support, APIs, device trust, IAM support, and scalability.

Now we have the second poll question, and the question is, what is the biggest challenge your customers face today? Deployment costs, the so-called old-school mentality, selecting the right product, or migration from legacy systems? I will give you approximately 30 seconds, and then we can move forward. Okay. Now I will hand it over to Nushad, and he will go more in detail into the topic.

Thank you, Alejandro. Thank you, Alejandro. Just to kind of continue what Alejandro was saying about password disidentification and the issue that comes with password and MFA in general. So I would like to introduce a little bit the concept of invisible MFA to you today, but first of all, just kind of a quick question so we can discuss a little bit later, what is it that is common between casino security and MFA?

So let's think about that, and then later in the presentation we'll come back and we'll try to kind of talk a little bit about the different things that we have in common between these two objects. So first of all, traditional MFA comes with a set of challenges. So we have today MFA, when you get an MFA on your phone, you don't usually know why you get this MFA, what are the application that you are trying to access, whether it's a legitimate MFA or maybe something that is just popping up on your phone or maybe on your browser. So contextual information is key, right?

And unfortunately, traditional MFA do not always bring enough context to the end user. It's also difficult to deploy, and as a result, it does not usually gain enough user adoption. The other issue we see with MFA is the lack of user convenience that come with it. So because MFA, the main priority of MFA is obviously to increase security, but with that usually you kind of lose a little bit of user convenience as well.

The other thing is with different devices, different channels that we use today to access to resources, like you connect to your desktop, then you open your browser, and then you access your application, usually all these channels are not really aligned together, so they are disjointed, and you may be asked to do MFA multiple times depending on the channel you are using to access the resource. And last but not least, today we talk a lot about cybersecurity insurance. That usually comes with a significant cost, and it's not something that you get without being secure enough in a certain way.

So if you use, for example, just TOTP, you may not even be able to get a proper cybersecurity insurance. Fortunately, there is a new approach to these challenges. We can provide a good user experience without compromising security. And how do we do that? So let's first of all extend a little bit what Alejandro was saying in terms of difference between invisible and traditional MFA. So with traditional MFA, you get an MFA prompt every time you authenticate. It's kind of very binary.

So if you meet a certain condition, then if your policy mandate a step of authentication, then you have to do that step of authentication as long as you satisfy the condition. But with invisible MFA, we can decrease that friction. We can only ask for the user to explicitly perform MFA when there is a significant risk. So that's a big difference between traditional MFA. The other one is obviously with invisible MFA, we can – first of all, we can provide a passwordless authentication, and at the same time, we can leverage more advanced form of MFA.

For example, we can use biometric authenticator. We can use behavioral modeling with machine learning, and we can consolidate multiple signals from your devices, from your browser. And this is more – this provides a more complete 360-degree view of really what's – of the security hygiene of the access request. As opposed to traditional MFA, where it's really like you get to get a push notification or you get an MFA request based on just the authentication request that you are doing at that specific moment in time.

The other thing with invisible MFA is, like I said previously, you can obviously get users' context – you can take users' context into account, and you don't have to do that just during authentication. You can do it before you authenticate to your application, so when you just access maybe the login page, or maybe if you have, for example, an agent on your devices, that agent can feed information into the IDP, and then you can start assessing the security posture of the user.

And obviously, during authentication, you get additional context, but also post-authentication and authorization, your device or your phone actually can even continuously send contextual information about maybe your IP address, your geolocalization, or whether you disabled maybe your firewall on your device.

So all this contextual information can be consolidated continuously by the IDP, by the authentication service, as opposed to traditional MFA, where you only do that step of authentication at a specific moment in time, and it usually happens during authentication, not before or after authorization. Now what is invisible MFA? There are different layers that we use to achieve this experience. The first is, obviously, we need to consolidate the processors into a single centralized service. So basically, we don't want to have different security policy based on the channels that you access, right?

So it has to be very centralized, so it's easy for organization to manage, but it's also a consistent user experience from an end-user perspective. Obviously, I mentioned risk engine and device trust, which are kind of at the center of how you can achieve this, because it's important to not just do conditional-based authentication, because with contextual information, you can have more than just part of your decision, right? You can look at trends, you can look at abnormal behavior based on what your peers are doing, and so on and so forth.

So with all this centralized into one system, then you can start adding the MFA layer. So you obviously would want to use hacker-proof invisible MFA. You don't necessarily want to keep using password, so if you can eliminate password, that's even better. And obviously, from an administration perspective, you have one single place where you can manage your policies and everything. And like I said initially, the risk engine is really at the center of this, right?

So it's important to have a risk engine that can provide the most accurate and real-time risk score, so that the policy decision point can really decide whether there's a need to step up your authentication or not. And if not, then maybe the user is just reassessed, and then transparently, the user is allowed to access to any upcoming application, for example. And then device trust, Alejandro mentioned also the importance of having device trust. So just reinforcing that here, it's important as part of your trust architecture to have a set of different information feeding from different sources.

And device is a critical part of your user journey, so it's important to have that root of trust at the device level, really at the beginning of your journey. And then the final piece, I would say, is really from an end-user experience perspective. So you don't want your end-user to have to MFA multiple times.

So if you're accessing an application, or you're just connecting to your workstation, your Mac, your Windows, or even a VDI virtualized workstation, if you can have a universal authentication method, so you always sign in with maybe your phone, or maybe your USB stick, or WebAuthn, or Passkey, as we can do today with the support from Apple and Windows, and then Google as well. So you can use, you can leverage this modern authentication, but at the same time, secure authentication method.

And this will provide, obviously, the best user experience to your end-user, but also to your customer, and partners, and so on. So let's take a look at the usual, the traditional authentication, which we've been using since another 20 years now. So we have always been requested to use a username and a password.

Obviously, the password comes with multiple challenges. We talked about earlier, the password complexity, the need to change your password every now and then, the inconsistency in terms of password policy between different applications that you access.

Obviously, this brings a poor user experience. Obviously, we tend to work around it as much as we can, and obviously, that brings the security hygiene to a lower level. So how do we transform that user experience into a more modern and risk-based continuous authentication? Like I said, on the device level, we can use maybe an agent that we deploy, and that agent will allow us to bring the root of trust at the device level, so at the beginning of the journey. And then that agent will also feed information about the security posture of the device, the screen resolution, the IP address.

If someone, for example, managed to hijack your session, and then, obviously, the device fingerprint will be different. So that can be detected, because this contextual information about your devices, about your IP address, and so on and so forth, can be automatically detected by a risk engine based on the conditional base or machine learning-based model as well. And then this, obviously, can happen before authentication. So all this information can feed continuously before you access any application.

During authentication, you can sign in as you would do maybe with your username and password, but if possible, using a passwordless method.

And then, most importantly, post-authentication, usually the IDP is not usually involved, but if you somehow manage to feed information to the IDP about things that can, you know, about any, you know, anomalies or, you know, something has changed from a security hygiene, like the firewall has been disabled, then the IDP should be able to, you know, trigger a step of authentication, maybe on your phone, to make sure that the user session, for example, hasn't been hijacked, or if the application mandate or the policy mandate that, you know, you have your, maybe your firewall enabled all the time, then maybe we can eventually trigger maybe a lockdown or a remote session lock from, I mean, on the device itself.

So this continuous authentication, you know, allows, you know, organization really to make sure that, you know, you just don't control at the gate, but you kind of continuously assess the risk posture of the user. And then, this slide kind of shows us a little bit the difference, you know, in terms of friction between traditional MFA and invisible MFA, more modern form of authentication. Traditionally, you know, you would have to authenticate multiple times a day, you know, based on the application or your workstation, your VPN, maybe your virtual desktop.

And then if you access some SaaS application, maybe you have SSO, maybe you don't. And then, you know, at the end of the day, the end user is being, you know, continuously asked to, you know, to do a step of authentication, or maybe to enter his username and eventually his password.

Obviously, this is not great user, this is not the best user experience. So with, you know, with invisible MFA, you can streamline all these, you know, authentication into just one single channel, and then you can access multiple resources with minimum friction.

So yeah, so just to recap a little bit the benefit of invisible MFA. So obviously, from a user experience, it's critical. It also allows organization to meet, you know, their zero trust, you know, architecture, and obviously, from a cybersecurity compliance perspective, it's also critical. And it's also a way to secure on top of maybe your MDM solution, and you know, and other tools that you have in place in your security stack, then with a invisible MFA, and you can have a set of control on the device level as well by bringing that trust to the endpoints also.

And obviously, the MFA is something which we need. So it's important that, you know, the end user feel that there is a real benefit of using MFA. It's not just, you know, a friction that is being, you know, added to their user, you know, journey. So it's important that, you know, we make sure we have a good MFA adoption. And then obviously, from a cost perspective, it's also very critical, because, you know, when you save time, without having to do MFA all the time, obviously, it allows you to be more productive.

And obviously, you spend more time doing what you are supposed to do, rather than just doing friction with MFA prompt all the time. And this is just an example of, you know, just to show how, you know, from a cost perspective, you know, and in terms of user experience, you know, the benefit that you get, right. So what we call the benefit trifecta, which is basically user experience, cost saving, and at the same time, strengthening the security.

So if you take, for example, a company with, let's say, 30,000 users, and if you have roughly 12, 15 prompts per day, then you get approximately around 400,000, 500,000 prompts a day. Now, if you can reduce that prompt to at least four times in a day, then obviously, you know, you can save time, but at the same time, you can save money as well, your company will save money, right. So in the case of 30,000 users with a daily rate, and so on, you obviously, you know, the figures will differ, but approximately, we can save around 20 to 30,000 million dollar or, you know, euros, if you want to use.

And that's something which is significant, right, it's very important. Now, in terms of how do we get there, right.

So obviously, you can go through every single step, starting from, you know, password, username and password, the traditional form of authentication, and then, you know, going one step at a time, or you can just leapfrog, you know, your way through, and then use, start using passwordless and continuous authentication straight away, right, because obviously, you don't want to just, you know, keep on trying to, you know, to kind of, you know, you don't want to be behind the curve all the time, you want to make sure to provide the best experience to your employees, because, you know, it's also important nowadays to make sure the employees and the customers have the best and the greatest when it comes to, you know, to authentication experience.

Kind of, you know, but to come back to the initial slide I had about, you know, casino and MFA, so basically, you know, if you go to a casino, you don't want to be always, you know, you don't want the security to always check on you and see whether you are, you know, compliant or you are doing anything that you shouldn't be doing, so, you know, security is important in casino, as you can imagine, so it's important that the users are happy and they can, you know, enjoy their, whatever they are doing in casino, so it's important that, you know, we have that, you know, security, but at the same time, we don't want to give the bad user experience to the end user, so, and this is what we want from an authentication perspective as well, so we don't want the end user to feel that, you know, security is actually a pain from an end user perspective, you know, it has to be frictionless, and we only want to step up the authentication when there's a need to do so, rather than doing it continuously and conditionally based on, you know, binary decision, whether you meet something or you don't meet it, then, you know, you have MFA prompt, you know, all the time, so this is just to kind of, you know, to show a little bit the, you know, the importance of having, you know, a good user experience without compromising security, and last, before I kind of, you know, hand over back to Alejandro, I just wanted to kind of share this, you know, tool that we have on our website, which kind of gave you an indication of how much saving you can do from a, you know, return on investment perspective, because with this tool, you can set the number of users that you have, you know, and the number of, you know, password reset call that your help desk has on a daily basis, and then this will give you an estimated cost of, you know, how much saving you can do, just by removing some friction, you know, getting maybe rid of password whenever possible, but at the same time, without compromising security and making the end user experience even better than what it is, most probably today.

Thank you, thank you, Noshad, for sharing your thoughts. Before we proceed with the Q&A session, I'll just, I would like to share some information from Copenhagen Call.

So, we have this protocol, KC OpenSelect, which helps you optimize your decision-making process and select the right passwordless solution that is for your own organization. We had, the first version of this product was on passwordless authentication, and I think the second version is on PAM, Privileged Access Management, and I'm pretty sure it was already released, so check it out if you are interested.

Then, we have coming up the European Identity and Cloud Conference taking place next month in Berlin, so I look forward to meeting some of you, hopefully. And here's some related research that we do at Copenhagen Call related on passwordless authentication. Like I said, there was a leadership compass that was published in October of last year. We will be making an update in October of this year, so I expect many more vendors to participate. And finally, some of our services. And I think it's time now to do the Q&A, and from what I can tell, I believe that most questions are for you, Nushad.

So, are you ready? Yeah.

Okay, the first question says, does Arculis store biometric information? No, we don't store biometric information, so what we do is, you know, so when we do biometric authentication, so some of the hash can be sent over, but we won't store any information, you know, in terms of biometric, because usually, especially when you use FIDO, you don't really, you know, send the biometric information to the server.

Now, we do have some hashes which we store, which is essentially for, for example, the browser fingerprint and things like that, but not regarding biometric. Is that a question that you often face when dealing with your customers?

Yes, I mean, obviously, security is very important, right? So, the data is critical as well.

So, we have a very kind of strong policy in the product to not store any information we don't need. Even when we do authentication, for example, we will rely on the source of truth whenever possible.

So, we will have, for example, we can have an agent that we deploy on, you know, on-premise to connect maybe to your Active Directory or your LDAP, and then if we need to do authorization, we will just simply check on the fly whether the user belongs to a certain group, or if the user is going through a password authentication, then the password will be checked, you know, on the fly against Active Directory. There is no hash or anything being stored on our side.

So, this is, again, it's all about making sure we don't store information we don't really need, and kind of, you know, remove any challenges that come with synchronization and things like that. Right, okay. Let's look at the next question. This user is asking, does Aculix product, does the Aculix product, does Aculix product false negatives?

Oh, yeah, maybe does Aculix produce false negative, I'm guessing. So, we, so, what, well, first of all, let's kind of try to understand what we mean, or what usually the industry mean by false positive and false negative.

So, false negative usually, by false negative, we understand it as the following. So, basically, if a user is trying to sign in, it's the legitimate user, but we feel there's a need for the user to step up, right?

So, we can eventually ask the user to do a step up authentication when we actually have maybe enough information to make sure the user is really the legitimate user. So, in general term, from a security standpoint, it's not a bad thing to have false negative, right?

But, obviously, we don't want friction. So, as far as I remember, you know, I think we did some benchmarking before, and we have, you know, customers testing our product against other product, and they, the data that we have is over, I mean, for a million of authentication requests, you can eventually have like a dozen, 10 to 12 authentication prompt, which will be regarded as a false negative, right?

So, this is kind of, you know, friction that may eventually have been removed, but the system somehow asks you to do that. So, that's kind of very, you know, very minimum if you want, right? Over a million, if you have 10 requests, it's probably not a big deal for the end user experience perspective.

However, the other, on the flip side, the false positive is the one which we don't want, right? That's essentially when a, you know, a threat actor potentially managed to get through without the system detecting it, right? That's kind of the thing which we don't want, and our system has been, you know, tested, you know, extensively, and we are confident to say we don't let any false positive to go through.

So, basically, whenever there is a, an abnormal situation, like a change of IP address, or a session hijacking, or someone doing an impossible travel, this can be detected by the system, and, you know, the, either, you know, the user is being rejected, or maybe there will be a step of authentication just to kind of validate the user's identity before getting access to the application. Okay, that makes sense. Thank you for explaining that. And there are two more questions for you. How does IQLICS work with other single sign-on providers?

So, yeah, that's a good question. Actually, we don't have to, we can coexist with other IDPs, right?

So, if you have an existing IDP in place that maybe perform authentication, maybe, you know, some MFA authentication as well. So, if you want to add IQLICS on top, you can do that.

So, we can just plug onto existing IDP, just to perform the risk assessment and the MFA service. But if you want to rip and replace, you know, your existing IDP, and you want something to be different, or maybe more with, you know, different features and so on, that's something which you can do as well.

So, we kind of, you know, perform both the goal of a full-fledged IDP, but also, you know, just an MFA service sitting on top of your existing IDP. Okay, there's actually another question. The user is asking, are we ever going to get rid of passwords? I can take that one if you want.

Well, I think it's going to be difficult to do that, but I think with the trend that we observe with passwordless solutions, we're slowly going to make them less important. But in the long term, I feel like there's going to be a user in some corner of the world that is still going to be using passwords. And if we see some of the, let's say, social media platforms that still continue to use usernames and passwords, that will need to change for more users to accept passwordless solutions and to eliminate passwords. But what do you think?

No, I think you're absolutely right. It's kind of, it's been there for a while, and we know, you know, some legacy systems will probably still require you to use your password, right?

So, maybe, you know, they cannot be modernized, so they've been sitting there, and they work, and you don't want to touch them, right? It's working, it's IT, you don't want to touch them.

So, you would probably still have a password, you know, especially for on-prem application. But I think with SaaS, with the adoption of cloud and with SaaS application, you know, we have federation in place, and, you know, IDPs are becoming very critical to your security stack.

So, I think, you know, as we go forward, passwordless authentication would become more and more significant, more and more relevant, because also of the user experience that come with it, right? So, we know that password is not always secure, you know, we've tried passphrase, but it's not, it's not, it's not convenient as well, you know, it's, and different, it's not always consistent as well, right?

So, every password, every application has a different password policy, so you end up with multiple passwords anyway, you cannot have one password that fits every single password policy. So, yeah, so that's kind of, so it is going to be there, unfortunately, but whenever possible, yeah, I think we should probably start considering, you know, moving away from passwords, especially in SaaS world. Absolutely. I think people have talked about getting rid of passwords for decades now, so I think we're in the right track. Exactly.

Last question for you, this user is asking, we already use another phone MFA app, can you just use that? Yes and no.

So, yes, because we support any form of TOTP in Oculic, so if you have, you know, your own MFA application, you know, you don't want to download a separate application, but obviously we support that, that's fine. Now, the benefit of our MFA application on the mobile is, it is also, it allows the system to get information from that device, so it is also, it sends signal continuously to the Oculics platform, and so Oculics can then decide and detect actually whether the phone is, for example, far away from your desktop, right?

So if your phone is miles away from your desktop, then obviously we know something is wrong, or at least we can double check if it is really the end user, you know, if your, the other thing which we can do as well is, you know, with device first, we can use the phone as a command, as an agent, so basically if we want to lock your, if you want to lock your device, you can use that, you can use your phone application to just lock remotely your device, so let's say you went out for a coffee at the office, and you are not sure whether you locked your device before going out, so you can just simply take your phone, if the session is open, you will see it on your phone, and then you can just simply remote lock your device while having a coffee with your colleagues, so yeah, it's, yeah, there are some additional features that come with our mobile application.

Okay, I believe that was the last question. Well, thank you, Nostad, for joining me today. It was a very fruitful discussion. Anything you would like to add?

No, I mean, that was really, you know, great to have, you know, to be on this call today. I hope, you know, the attendees, you know, you know, learn something, or at least, you know, it's helpful in some ways, or shape, or form, and maybe, you know, if you need additional information, you can always go to cqof.com.

We have, you know, a couple of other, you know, documentation about, you know, what we do, and how we can help your organization, maybe meet your Zero Trust architecture, and from a user experience perspective as well, you know, things that we do, which can provide a more modern, you know, user journey for employees, staff, but also for customers and partners as well. So yeah, everything is on the website. Feel free to go and have a look.

But yeah, thank you, thank you for having me. That was really great. Thank you for sharing your perspective. Goodbye. Thank you. Bye.