Passkeys in a Zero Trust World – Blessing or Curse?

Hello, welcome to the webinar, Passkeys in a Zero Trust World – Blessing or Curse? My name is Alejandro Leal, I'm a Research Analyst at KuppingerCole, and today I have here with me Andre Priebe, he's the CTO of iC Consult, he will be talking about this topic with me and at the end we'll be having some nice conversation.

But before we begin with the webinar, we'd like to remind you just a few things, just to keep in mind that we control the features, so there's no need for you to mute or unmute yourself, and we'll be conducting two poll questions, so I'd like to encourage you to participate in those because it helps us in our research and also to understand the audience.

We'll be having a Q&A at the end, so anytime during the webinar feel free to enter a question by using the C-Event control panel, and in the coming days we're going to make available the recording as well as the slides that Andre and I used in the webinar. So, just to set the stage, I will be providing an introduction of the topic, the role of past keys in serial trusts.

We'll be a bit general, and then Andre will take over and he's going to be exploring this in more detail, and as I said at the end we'll be having some time for Q&A, and Andre and I will be having a conversation based on the questions. Okay, so first, the first poll question, so the question is, which of the following cybersecurity measures do you believe will be prioritized by businesses in the coming year?

Of course, there are probably more answers to this, but here we have four options, and we'd like to know in your opinion, which one do you think should be a priority? So, here's a motivational quote on past keys. I took this from my leadership compass on passwordless authentication. This year I published two reports on the topic.

One report was focused on the use of passwordless in the enterprise, and the other report focused on passwordless in the consumer space, and the quote is, the use of past keys is likely to contribute to the widespread adoption of a passwordless future, and as a consequence, we'll see the transition to phishing-resistant forms of authentication, which will continue to gain momentum.

However, as we know, there are some misconceptions regarding past keys, and I'm sure that many of you here in the audience would like to hear more about past keys, so that's always a good sign that people want to get more information on this. So, just to start, so we hear about serial trust all the time, and the question is, what is serial trust?

Many vendors, they use it a lot, some people could say that it could be like a buzzword, but in reality, serial trust, it's not a product or a particular solution, it's a strategy, it's a journey, you could say, and it's not an IT modernization project, so it's not about getting the latest solution, or the next generation VPN, but it's not about getting the latest product, but it's about reusing existing tools, and redesigning your processes and policies instead.

And there is more than one way, as I said, it's a strategic goal, so each organization has different needs and requirements, and it really depends on them, and how they plan to achieve serial trust.

Here's some tenets, the main principles of serial trust, so as I said, it's not a technology, but it's a shift in our security mindset, and as we know, traditional security tools have put an emphasis in the early days on defending the perimeter, but serial trust assumes that breaches can be prevented by verifying each request, so this means that whether an access request comes from inside or outside the organization, outside the network, it needs to be verified, so for example, if an attacker breaches the network perimeter, the damage they can do is limited, because they still need to authenticate and authorize each step within the environment, so here we have these seven principles, so all decisions are per resource, all communication is secured, we must follow the least privilege access principle, policy-based access, integrity, and security of access, and we need to be policy-based access, integrity, and security of assets, strong authentication, and context and metadata.

So now that we have the backdrop of serial trust, now let's take a look at what we hear on the news, so it's not a surprise that we are constantly getting information on the latest attacks, on compromised credentials, on data breaches, we hear it often, especially during this year, it was a year of a lot of elections in the world, and there were reports that some of these voting systems, the systems that register votes were breached, the latest happened in the U.S.

earlier this month, when they discovered that one of these systems, the password was used to breach, because one of these counties had a picture online that showed the password to the system, I don't think there was any breach or any information that was leaked, but that just shows that passwords still and unfortunately will remain in the news. So based on my latest research on passwordless, we can see that there is a demand, there's competition, many established players are competing with smaller but innovative vendors, we see developments in regulations in the U.S.

and Europe, we see technical advancements like the introduction of passkeys, which is the topic of today's conversation, which are probably going to be driving the momentum of passwordless, but as we know, it's not that easy to do because passwords are still going to be used in the years to come, it's about interoperability, it's about integrations, and it will take some time to really get to this passwordless future that many vendors often talk about. So the question, what are passkeys? So you could say that passkeys are a transformative leap forward in authentication technology.

They are based on the use of public key cryptography that offers a more secure method of access and they eliminate the risk associated with phishing attacks primarily and password theft. So each passkey is unique to the user and the device, which means that the private key used in the authentication process never really leaves the device. So this blocks many common attack vectors, such as remote phishing and others, making passkeys a strong choice for authentication.

But many vendors and many organizations ask if passkeys are the way to go, and well, that really depends on each organization and the context, right? So there are different types of passkeys. I know that Andrew will provide more detail on this, but we can break it down into two types, device-bound and cross-device. So device-bound passkeys are stored in a single device, which means that if the user loses the device, he would lose the access.

And if we look at cross-device passkeys, on the other hand, it allows users to authenticate across various devices, which increases the flexibility and improves the user experience without really sacrificing security. But we need to understand that there are differences in the implementation of passkeys in the enterprise and the consumer, the implementation of passkeys in the enterprise and the consumer space.

I'll talk about it in my next slide, but also when it comes to the use of device-bound and cross-device, it really depends on the context that we're talking about, and it can also be more challenging depending on the context. So if we look at the enterprise versus consumer, in enterprise environments, the integration of passkeys can help, I guess, streamline access management and reduce the load on IT, but it also has some challenges when it comes to how organizations see the use of passkeys.

You could argue that passkeys work better in the consumer space because they provide a more seamless user experience by eliminating the need for passwords. So each setting requires, say, a tailored approach to integrate passkeys. Andrea and I will talk about it during the Q&A, but it's important to keep in mind that there are different expectations for users depending if they are from the enterprise world or from the consumer world. So here are some challenges. So as I said, the benefits are clear. Passkeys can be easy to use and they are phishing-resistant, but the adoption can be more tricky.

So compatibility may arise with legacy systems that were designed around traditional authentication methods. So that's also a challenge that many enterprises face. So if they are still relying on legacy systems that do not support the use of passkeys, then it's very difficult for them to transition. So that would require enterprises to have a, let's say, a more cautious and slow transition by first modernizing their systems and applications and then modernizing their systems and applications and then transitioning to the use of passkeys.

So compatibility is one, but also ensuring interoperability across various platforms is also essential. So adopting standards can help achieve this, standards such as FIDO2. So another challenge could also be redesigning the account recovery process. So that's a topic of conversation that I have and I've mentioned before in previous webinars that when I talk to passwordless vendors, I often ask about their account recovery methods and many of them are still offering username, password, SMS codes, one-time passcodes, etc.

And I like to get their opinion on how they plan to move to a passwordless future because if we keep offering these methods that are not the most secure to the customers, then it will take more time. But as I tell the vendors, it's easy for me to say that because I'm sort of an analyst. I'm not dealing directly with customers. But if you're a vendor, then it's probably more difficult because you have to understand your customer and help them transition. And some of them are still used to weak authentication methods.

So education is crucial here to help them make this transition and by informing them about the latest technological developments. So here we have the second poll question, which is in the next year, 2025, where will your organization focus its cybersecurity investment in identity and access management solutions, threat detection and security analysis, cloud security, or the skills of your workforce? And that's all from my side. I will just share with you some information on coping your goal. Here we have the KC OpenSelect.

So if you're struggling to find the solution that your organization needs, you can go to our website and check this KC OpenSelect to help you select the solution that best meets your requirements. We also have a new membership program. So make sure to go there and check the latest. And here you can find more information on our research. We have plenty of material that cover the passwordless space as well as passkeys and some trends and predictions for next year. And here you can see that we also do some events. We'll have the cyber evolution event next month in a couple of weeks.

And identity security will be one of the main topics. So that's all from my side. Thank you. I know Andrew will go more deep into passkeys.

So Andrew, the floor is yours now. And let me just stop sharing. Thank you very much for that excellent introduction to the topic of passkeys and the topic of zero trust. Before we zoom into the topic, a few words about iConsult. So iConsult is a system integrator, a consulting company, and a managed service provider for all topics related to identities and cyber security. And we are acting globally, having offices in Europe, North America, Asia. We are vendor independent, but working together with important vendors in this segment.

And my role as CTO is to make sure we have the right portfolio when it comes to software vendors, that we are aware of all the trends in the market and helping our clients during the implementation of leading-edge technology around digital identities and cyber security. So one very important driver that you should have in mind when thinking about getting rid of the password, what is the mission of passkey, is the vulnerability of users when it comes to spear phishing. Generative AI is really improving our efficiency. And depending on the task, the gain of efficiency is different.

Unfortunately, the efficiency gain when it comes to spear phishing is tremendous. It's an efficiency gain of 95%. Why is that the case? Because spear phishing today, for an attacker, is time consuming. The success rate is very high, because we are not talking about mass mailing.

No, it's a single mail or single message to one user, providing a lot of contextual information, making it absolutely valid from end-users' perspective. And based on that, the success rate for the threat actor is very high. We're talking about 60%, something like that. So the user is entering a credential, downloading a mailer, these kind of activities that really put your IT at higher risk. And by leveraging the information in social networks via large language models to frame a context around that, this is really something generic and supports attackers very well.

So that's the reason why we are here together and talking about passkey. And what is passkey from an architectural point of view? First of all, passkey is a kind of end-user terminology for FIDO2, the authentication protocol that provides us phishing-resistant passwordless artifact authentication. So if you look to the architecture, we have two elements in FIDO2. One is the CTAP protocol, and that is a protocol that standardizes everything related to the browser operating system and the device storing the keys, especially the private key. This can be the TPM of your notebook.

It can be a USB token or a card with an NFC interface. And this is the one part. The other part is everything related to the browser and the server, so the identity provider, taking care of the authentication process. This is the JavaScript API from a browser perspective and defining the communication with the server. The very important thing to have in mind, we are talking here about a reliable, robust standard that does not require any installation of additional software that's built into the browser's operating system and the identity provider product on the server side.

And that's a big difference to other mechanisms where you have to deploy a mobile app or an on-time password generator on your notebook or whatever. So this is a high-level architecture perspective.

Then here, a tool to categorize what is available in the past keyword. And Alejandro mentioned these topics on a higher level. So there are two dimensions I would recommend you to separate the different tools out there.

So one is, are we talking about built-in capabilities into the hardware operating system? Or are we talking about third-party installations or hardware you have to buy in addition to what the end user already has? And the other dimension is, are we talking about a device-bound approach? So the keys are just living on that single device. Or are we talking about something that is synchronized between different devices? To provide you a few examples. So for the device-bound path keys, we're talking here about a platform authenticator like Windows Hello. Leveraging the TPM on your Windows notebook.

Or Ruby key and USB key you can plug into your notebook. Or if it has an NFC interface that you can use with an NFC reader, for instance, your Android phone, to log in to a target system. Or the synchronized approach. So for instance, the path key that is put into the iCloud keychain during the enrollment process on your iPhone. And then you can use it on your MacBook as well. There's one other thing you should have in mind. Are you talking about an authenticator that is a roaming authenticator that you can use via several devices?

Or are we talking about an authenticator that you can just use on that one single device? Like this is the case with Windows Hello today. So the UB key, obviously, you can use it for several devices. That's the purpose of having it on a USB key. You have it always with you.

But also, if you're enrolled on your iPhone or Android, you can use this device as an authenticator to log in to your Windows notebook. We'll look to support metrics in a second. But this is important to have set in mind because it depends on how many enrollments you expect for your end users. When it comes to third party, passkey providers, these can be your password managers like 1Password. They also implemented the capabilities around passkey. Very important today, this kind of first party passkey providers for the synchronized scenario are Google and Apple.

But Microsoft is a little bit later to the party, but they announced to provide that next year as well. If we now look to the support landscape here provided by passkeys.dev, so I can recommend you to have a look to that page to see what kind of capabilities are provided on which platform.

So, the synchronized passkeys, as I mentioned, on the Apple universe and on Android. But other capabilities that I mentioned, trust device authentications, authenticator capability provided by Apple on iPhones, on Android.

So, that's also something that is important to have set in mind. But when it comes to the client capabilities, we have broad coverage.

So, it doesn't matter if it's a Chrome notebook, if you're running your Edge browser on Ubuntu, all these kind of scenarios are supported. And there's also that coverage is really complete for all major use cases, I would say.

Now, how does it play together with Zero Trust? So, I'm quite sure a lot of you are familiar with the maturity model provided by the CISA when it comes to Zero Trust.

So, showing us the different pillars, like the identity pillars, the device pillar, and so on. And then what you have to provide as features to move up to the higher levels of maturity. When it comes to the identity pillar, the advanced level highlighted here is defining explicitly phishing-resistant MFA. And honestly, having in mind the improvements spear phishers, threat actors are doing, a lot of MFA methods are clearly not phishing-resistant. For instance, a one-time password.

It's not very complicated for spear phishing to convince a victim to enter a fresh one-time password on the hacked login page. And then you have a credential that is just valid for a short period of time. It doesn't matter because it's good enough to get into your IT infrastructure and then moving on from there. What's about a mobile app and push notifications? Unfortunately, there's evidence out there in which push notifications were used for phishing attacks successfully.

Even if you have things like number matching enabled, it's just about convincing the victim that he should now perform that operation. And then it's a human decision if it's a valid request or not. And this is a huge difference when it comes to PaaSKey because in PaaSKey, it's not a human decision if the credential should be provided or not because it's bound to that domain that has issued the credential. So that's the difference compared to the push notification approach to the one-time password generator and so on. So there are not too many options out there for phishing resistance.

Therefore, PaaSKey and Zero Trust makes a lot of sense together. So why did not all of you already enroll PaaSKey into your organization? If it's such a great tool.

And often, we are requested to help our clients to assess the maturity when it comes to Zero Trust. And I would like to share here one part of the frameworks we are using for that to go through the different pillars and provide a rich understanding of not what capabilities are in the organization, but to which degree are they really leveraged for these different paths the user might have. So first of all, when it comes to PaaSKey, we are typically talking about authentication assurance level two or even three. And then we have different types of identities.

And of course, you have your workers maybe on the office, maybe in production sites, but also a couple of external users that might be important, different levels of authentication assurance and different device types. Some of these device types are under your control. Others are not. And different mechanisms to protect these devices. One very crucial or one very important question is always, if you give PaaSKeys to our user, do we still need the password to log into the device?

No, there are options to use PaaSKeys also to log into the device. But there are challenges related to that. We will talk about these challenges in a second. And there are different other pillars. I don't want to go into the details, just give you a few examples to make it a little bit more precise. What is about the database that might be accessed via ODBC from an end user's device where that client application is running through a VPN that has been opened before? For which of these steps can I really apply PaaSKey? Is it playing together with ODBC? Is it playing together with Kerberos?

Can I use it to open the VPN connection, maybe in an embedded browser component? Unfortunately, these are areas in which it is getting very, very challenging with PaaSKey.

So, let's go through that a little bit. VPN clients, unfortunately, these kinds of VPN clients with embedded browser components are out there and PaaSKey and an embedded browser component is not playing together very well. In other words, if on a slide before I was telling you all browsers are supporting PaaSKeys, that is not true for all these kinds of embedded browsers.

Might be, might be not. If you can jump into the operating system browser for that kind of activity, great.

If not, that might be a blocker for you. Be aware of these kinds of things before. And then we have sync lines. I mentioned the PaaSKey support on Ubuntu Linux, but what is about the very ardent sync client lineups notebook you are giving to your contractors to open a VPN and a remote desktop connection to a terminal? Maybe it's working, but the likelihood that PaaSKey is not working there out of the box is very high. Maybe you can make it work somehow, but be aware of these kinds of edge cases before being convinced that you will recover everything with PaaSKeys.

Then I mentioned the device lock-in before. It's great to get rid of the password for the lock-in to the Windows desktop. And there are a couple of products out there that are supporting PaaSKey to lock-in to the device. And there's also in-box, out-of-the-box capability. But which degree is it working for your use cases? It might be it's working perfectly via USB, but not via NFC. And if you're on a production site, a couple of persons are accessing the hardware and you want to have an easy, convenient contactless lock-in process, that might be a blocker. Or there are limitations.

Different users are using the device and maybe the out-of-the-box functionality is limited with 10 PaaSKeys already. And then it's not possible to enroll further PaaSKeys. So these are the kinds of cases you have to look at before starting an enrollment at large scale. Then from a regulatory perspective, how strong is a PaaSKey? Is it a true factor? Something I have combined with something I know or maybe biometrics. Is it true for one password? Is it true for dashlane? And what is if the next third-party PaaSKey provider comes out? How does a reset process look like for that provider?

So that's a question that's sometimes not easy to answer because it's a dynamic area. And then we have the token management challenge. So the consumer scenario is more or less clear. I can go to a shop, buy a hardware token or use my iPhone to enroll the PaaSKeys and control that. But if you as a company are providing a token to your end user, you want to manage that and be aware of who did you issue a token. I might have to be able to revoke a PaaSKey issue because your key has been lost. So that kind of token management topic comes up.

And if a couple of providers are really focusing just on the consumer segments, they are not working around the enterprise segment at the same time. And then there's this end user. So what topic? Something is not working with the authentication process.

Okay, what was the PaaSKey authenticator used for your enrollment? Was it your MacBook? Incapabilities? Or the one password? Or did you use a USB token? So you have to be aware of what was happening. And the AA grid gives you that kind of insight. So you should be aware of that. And by the way, PaaSKeyDeveloper.github.io is providing a list in addition to the metadata provided by the FIDO alliance. And that helps you to get an understanding of what your end user was using for the enrollment. And then it helps you to provide the support.

Of course, in a control scenario, you can also decide what authenticators you want support and what authenticators you don't accept to get rid of the challenge mentioned before with the question of is it really multi-factor authentication or not. My closing note on that, even if there are a couple of challenges out there I mentioned, the bottom line here really is PaaSKey are from all perspectives superior to the password. And it's absolutely necessary to move into the direction of a phishing-resistant authentication method.

And therefore, I would recommend really to everybody, if you're not already using PaaSKey, move on in the journey, even if it is not always easy. It's much better than dealing in the very, very near future with a tremendous increase of spear phishing that are then successful on your end users and bringing threat actors deep into your IT landscape. And having said that, Alejandro, back to you. Looking forward to an exciting conversation.

Thank you, Andre. That was a very nice session. And as you said at the end, it's good to remind the audience that passwords and SMS codes, these were never originally created to provide secure authentication. And it's a bit strange that we keep using them, right? So the PaaSKeys are for sure a better alternative.

Well, now we have a few questions from the audience. So one of the questions is, you talked a little bit about assurance levels. So what has to be taken into account when using PaaSKey for highly sensitive use cases targeting assurance level number three? If I think about that question, I'd say endpoint security, since the integrity of the device is very important. But I'm interested to hear more about your thoughts on that. In that kind of area, we are really focusing on having a hardware authenticator. And so here we are not talking about the scenario in which you are putting trust in a...

So, third-party software running on your device, but really on a hardware token. That would be my recommendation to leverage PaaSKey to go into that direction. But in that case, it's absolutely valid using it. And if you're managing them, as mentioned before, so having token management in place for this kind of token, there's no drawback compared to a smart card, for instance. Okay. The next question is referring to, are there any alternatives, in your opinion, to PaaSKeys? And what might be the reasons for going for alternatives?

In a recent discussion with the director, I talked about how maybe organizations that are still relying on legacy systems, that they can maybe use a 502 key to help with the transition to support the legacy systems and wait for the organization to adopt more modern approaches. But what do you think? Okay. Yeah.

So, my take on that is, if you have a lot of legacy IT out there, it might be better to still go for the smart card. But maybe using a device that is capable of doing both. X509 certificate-based authentication, so the traditional smart card approach. And at the same time, being able to use a PaaSKey 502. And then you have one stick with both on it. And depending on the target application or the way you are accessing the application, you're using one or the other. But from the end-user perspective, it's just one token for him.

And then that allows you to move to more modern protocols, web-based protocols, or 2.0, or Mighty Connect, or even SAML, that play together with PaaSKey very well and getting rid of older protocols where you really have to protect the access based on the transport layer by a mutual DLS with a smart card, for instance. Yeah, that makes sense.

How about, are there any, let's say, misconceptions that, in your opinion, exist around the use of PaaSKeys? Anything that you maybe would like to address now that you have the chance to talk to more people about it?

Yeah, of course. So one thing is really that the primary purpose of smart cards is a little focused on the consumer world. For PaaSKey, it's a little bit focused on the consumer world. And it makes a difference if you are talking about end-users or if you're talking about workforce. And that sometimes makes it a little bit complicated. So we have very good established approaches around the management of certificates that we use on our smart cards, with registration authority, ways to issue it, provide information about revoking it, and so on. There's a lot of complexity.

And PaaSKey, on the other side, very, very simple, but maybe a little bit too simple today for that enterprise use case scenario. So that's something that, from my point of view, it is just important to spend enough time thinking about these kinds of management aspects around PaaSKeys before enrolling it and then understanding at a later stage, oh, there's something missing. And that's something where I would recommend taking that aspect very seriously.

Again, not doing it, but being aware of specialty compared to other mechanisms out there for many years. It's still quite new, quite done right.

Yeah, right. We have time for two more questions, and then we're going to show the results of the polls. The next question is about how do PaaSKeys work together with ZDNA solutions and VPNs?

For ZDNA, I guess they would follow the principle of least privilege access, but is there anything that comes to your mind? Oh, I mentioned VPN a few times during the talk, not ZDNA at all. And when it comes to VPN, again, the challenge might be that kind of embedded browsing or even RADIUS is still in use when it comes to VPN very often.

Of course, that's something that you have to modernize your approach for the VPN authentication and really moving into the direction of using browser-based approach. And when it comes to PaaSKey, I would really recommend using an approach in which you jump into the operating system browser, not using an embedded browser.

Otherwise, it's challenging. So ZDNA solutions, on the other hand, are very modern, supporting protocols like OpenID Connect, like SML2, and they play together very well with PaaSKey. So I'm not aware of any challenges that we had with ZDNA and PaaSKey in combination. I think that's much better. Absolutely.

Okay, for the last question, maybe you can share with us some, let's say, practical challenges that you've seen when you talk to people when it comes to deploying PaaSKeys across multiple devices. You briefly touched upon this, but I'll be interested to hear more. I think it's a question about providing some precise examples. For instance, Windows Credential Provider. The idea of getting rid of the password for the login to your desktop is a kind of critical element because that's often the active directory password in nearly all situations.

And we know that this is something the attacker is always looking for. Getting the active directory password, moving on to the domain controller, and so on.

And here, we unfortunately really were often facing the situation that this kind of credential provider components will not always work perfectly. There are scenarios in which it is getting difficult. So remote desktop protocol, RDP, for instance. Or maybe the external NFC reader is not working. For any reason, then we are in troubleshooting mode together with the vendors, figuring out, okay, what is exactly the constellation? Why is it not working in this situation?

So, this kind of thing. So, I think it is important, again, to have a pilot up front, figuring out are there situations in which I might not be aware of how the large organization is today using their IT infrastructure? Are there use cases I'm not aware of in my role as responsible for the central IT?

So, if you have a lot of sites, then that might be challenging. So, doing a pilot and really making sure that you're not hitting these situations in the rollout, but before, and then that you have time to solve that together with the vendors of the different components. Yeah.

Well, thanks so much for sharing that. I think we still have some time to take a look at the poll results. The question is, which of the following cybersecurity measures do you believe will be prioritized by businesses next year? 40% on cybersecurity awareness training. That includes onboarding as well, but any surprises here, Andre?

Well, no surprise. I think end-to-end encryption is also important, but I cannot understand that. Unfortunately, when it comes to the awareness training, I'm a little bit disappointed when it really comes to the outcomes offset.

So, my take is, even with a lot of training, it is very challenging to get the numbers down, especially when it comes to spear phishing. So, it's very hard to detect that if you're not a professional in the cybersecurity industry.

Yeah, I'd say that a combination of having the right tools and also having a good cybersecurity training is a good way to deal with these things. We had another poll question in a previous webinar on what's the current status of most organizations when it comes to passwordless, and I think over 70% of organizations have MFA on top of passwords, and the rest were evenly split between already adopting PaaS keys or a passwordless solution, and the other half are still using username slash password.

So, yeah, I can see why that's happening. But let's take a look at the second question now.

Okay, so looks like most people will be investing in IAM solutions and cloud security. It's interesting to see this, though, because we also see the ITDR space.

So, it would be nice to see maybe some investment when it comes to also some threat detection. But what do you think?

Yes, absolutely. So, first of all, I think it's always good to invest into identity access management. It's a kind of foundation when it comes to zero trust, without having your identity perfectly under control and authentication and least privilege and these kind of paradigms implemented, then everything else is not really bringing strong value.

So, that makes a lot of sense, and I see that also as a kind of precondition before investing more into that kind of analysis part. But at the end of the day, it doesn't matter how strong we build the prevention layer, you know, it's a question of time.

One day, someone will be able to bypass it, getting through. And then it's a question of how fast are you able to detect it? Are we talking about minutes or something like that? And then you're able to detect it and stop it? Or are you understanding it after you've really compromised everything, the backups, running the ransomware or whatever? Or it's hurting you a bit over a long period of time, again and again.

So, I think that's a kind of question. So, I think it's an important investment as well. But anyhow, if the resources are limited, the question is, what is an area I take care of first, right?

Yeah, that's right. Well, I think that's all for today. Thank you so much, Andre, for joining us today and for sharing your insights and experiences. And thank you everyone from the audience. Thank you. Thank you. Thank you very much for having me and thank you for taking care of that in the discussion today. Bye.