From Passwords to Passkeys: Securing Identities Today and Preparing for the Quantum Future

Hello everyone and welcome to this KuppingerCole webinar from Passwords to Passkeys where we will discuss authentication topics, obviously passkeys, and many other things including quantum future. First thing, first, audio control, you are soundfully muted so don't worry about that. It's under control. We will run two polls around the webinar. You will be able to enter inside the tools and we will go through the answer during our Q&A session. At the end of this webinar, you will have the opportunity to ask all your questions.

And finally, this webinar is recorded and you will get the slides after a few edits in the coming days in your mailbox. You will see that image.

So first, let me welcome David Noel-Lardin from Thales who will go through this webinar with me. Hello David. Hello. Can you introduce briefly you and tell us what authentication market you look after at Thales and what you see across your daily work there?

Yes, hello everybody and thanks for inviting me. I'm very happy to be there with you today to share Thales' view on this password-less topic. So Thales cybersecurity product line is really dedicated to provide solutions to protect and to secure data application and identities. So here we are more discussing today what identity is, which is the focus of the IAM product line in Thales CSP.

And inside this business line in Thales IAM, I am more in charge of the authentication product line focusing on high-level assurance solutions such as hardware authenticators, security keys based on somebody like FIDO, which will be one of the key topics for today's session. Yes, I think we will go through some of those topics. So first things first, the agenda, we will get to the phishing context today in the market and then how do you deploy a solution from pilot to production and what is next, that's the agenda we will follow.

But the first thing I would like to ask the audience is a very basic question not shy. If a convincing copy of your password went live today, what would actually stop the attacker according to you?

First, your security awareness training, user would spot it obviously. Second, email and web filtering, the link would never reach the inbox.

Your MFA, even with the password, the attacker will get nothing. And honestly, nothing I would fully rely on. So I expect you are more in the three first answers than in the fourth one. But I give you a few seconds to go through this poll.

So first, your user will spot it. Second, you will prevent the user to get the phishing link.

Third, you already have a strong MFA and well-deployed MFA that will block or leave the attacker with nothing. And fourth, you have no clue what will happen. So let's move on. So obviously, we will talk about phishing attack and it's obvious that today phishing has industrialized. So deepfake, read the news, deepfake is everywhere. You can deepfake voice, you can deepfake video, you can deepfake documents for IDV process. And you can do it in a very credible manner, but also very easy. What you see is that the barrier of entrance for that attack is really low now.

Almost anyone can run a script and fake something that will bypass most of the human control measure because human is really bad at spotting deepfake. And there are many attacks in the field today. And maybe this is where, David, you can share with us something that you see at Thales in the field, any adversary in the minor attack you could share with us?

Yes, so as you said Guillaume, the phishing attacks are really on the rise now more and more. Clearly, there's not a single day without reading some news in the headlines, in the press, mentioning an organization facing a cyber attack by phishing. We saw that in France during the summer with a big administration being attacked. And by the way, just one point additional as well, that we see clear acceleration since a few months and mainly driven by the power of AI with providing much power for attackers to provide. And then the click rate on the phishing mail is increasing by far.

So then we have multiple cases of customers coming to us and asking for solutions. So I will probably select one which is a French public administration or precisely a European community. I cannot mention the name here, but feel free to contact me because we have case to be available on this case and the customer was ready to share some data. But this is clearly an organization that faced phishing attacks, that faced an adversary in the middle and really decided to unblock a budget to secure the access to sensitive data for their employees.

And after a few months of deployment, they decided to deploy the palace Fido security keys. They really saw some improvement in the prediction of some phishing attacks. So they have a direct impact. So this is an example. We can provide much more with a use case. We have a different other example. And one question you mentioned, which sector can be hit first? So I think all the sectors can be addressed. Administration and BFSI financial services are clearly the main targets for the attackers because they have a large base of consumer credentials.

And unfortunately, this credential can be traded in a lot of criminal market marketplace, I guess. One of the things we hear is that MFA is one of the solutions to prevent this phishing attack. But what we see in the market and when we take care of that is that all MFA are multiple because on one side, you have MFA that are still phishable factors like SMS or push notification where someone will be able to call you and ask for SMS, dear customer, I'm doing this and that. Can you please share with me the SMS you will receive? So we validate together your operation.

And on the other side, you have something that is much stronger and where we will spend more time on being the best case, smart card PKI credential that are bound to a trusted device and where nothing can be shared with any attacker. Because once again, if you don't have anything to share, the attacker will get nothing on your behalf. And what we know is that human is always the biggest factor. And so if the human is not involved in carrying information, the attacker will not get anything. And did we get David back or not?

No, we didn't. I still don't hear you, to this. And as I said, there are different things we could we could we could argue or we could exchange about that.

First, you will have the same pass keys. And on the second side, you will have the device bank, the device bank. So the device bank passkeys are the passkey that you will get tied to your device with an attestation where the passkey will be linked to the device itself and where you can attest that the device or the passkey. David?

Yeah, no. The passkey is often stored in the secure enclave or in the TPM of the device.

And here, once generated, it will not leave the device. And so far, we have not seen any attack compromising that. So it's very suitable for the enterprise and the regulated market because it provides a high insurance on use. On the other side, we have the same passkeys that are much more convenient. They are often managed by customer platform. And they are recoverable through cloud account, great usability, fast adoption, very easy to use, but less enterprise ready, if I may say.

One other thing is that because they are recoverable through the cloud account, then the security of the cloud account itself becomes a point of failure on the process. So if you compromise the cloud account, you may get access to the passkey. I am back. David is back. Thank you very much.

No, I'm sorry. I don't know what happened. So I took a headset and it worked better.

So indeed, sorry for that, everybody. Technical issue.

Yeah, so regarding this passkey, there are clearly different types of passkey and passkey implementation possibilities. So I would say that at Thales, we really recommend our customer to deeply analyze what are their needs first. So what are the needs in terms of which assurance level is expected, which is the user experience they need to provide to the end user, which application data they want to protect. Based on all this factor, it will determine what type of passkey will be well suited. And by the way, we have developed a passwordless 360 tool that will be shared after the call.

You will have access. It's an online tool in order to, based on the criteria you can select, you can define which level of authenticators you will need. And if quickly, I can mention the different option in passkey. And as the one you mentioned, so for us, definitively a synchronized passkey could be proposed to replace password on low medium assurance cases. So that's clear. But as soon as you want to have a more high insurance use case, which is mainly the case of our customer, device bound key are definitely required.

With two flavors, one you are not really mentioning in this slide, which is a mobile implementation, it is a device bound passkey, which provide a higher insurance level than the sync passkey that can provide good UX, but which is not always fitted with the enterprise environment. So clearly for us, then the highest level of security and assurance can be provided by a hardware security key, like token, where you combine these keys in this hardware with the usage of the pin code. Sometimes you can even have biometric usage as well to improve the experience.

And here you have really the maximum level of assurance without compromising the user interface. So these key are really good fit for different use cases in enterprise, in BFSI, in government, in different usage. But one of the thing we, once again, I'm old enough to have seen the OTP coming, but then the passkey coming, and each time we hear the same thing about, okay, but what does it bring more in terms of security? What does it bring more in terms of convenience? What does it bring? What it will cost us? I put on the slide a few of the things we commonly find about the usage of passkeys.

So the user experience is great. Everybody likes to have these passkeys because most of the time you use your biometry to unlock everything, and then you go with that. You remove the credentials, so every day there's nothing to and on the cost, you remove the help desk cost, and that's something obvious. And the regulatory, the regulator from whatever regulator you may face, depending what country you are, they are all pushing it into the same direction. But that being said, you are facing the customer, you see them migrating, you see them enduring the pain, if any.

What I would like to ask you is, what, how do customers measure the change between the before and after in this kind of project when they go passwordless? Anything you can share that is symptomatic of this kind of project?

Yes, so even though the main driver to go passwordless and to use this new authentication method is driven by security, the fraud reduction and the phishing attacks is a clear target. So definitely the metrics on the phishing attacks and the exposure is the first one to be measured by a customer, for sure. And this is what I said earlier with the use case and this French administration that can be shared. Nevertheless, what is interesting is that on top of this security metrics, we have a lot of feedback from our customers on other metrics linked to user experience, linked to cost.

So such, for example, as the employee login time, the help desk number of incidents that are reported. And all this is very important because it will come in the ROI, the return of investment of the solution that I wanted to elaborate. I can quickly share some feedback on what we had from key customers or from survey we organized as well. There was some survey that has been organized by the FIDO Alliance, for example. So there are quite a lot of data that are circulating, which has been, I would say, confirmed by the discussion we had with our customers.

So if you look at the signing time and the efficiency, we see a six-time faster signing times with fast key based on device rather than password. We have as well a very important point, which is the success rate, the signing success rate versus password is four times more interesting. So globally, faster and more efficient, so being a good improvement. And some feedback we had as well confirmed by our customers on the help desk incident, 81% prediction of the help desk incident.

So it's massive and we all know that the password is one of the key and the major root cause of the call in the help desk. So definitely there is not only a security metric to be followed, which again has been proven by some cases like the one I mentioned, but as well as some key metrics followed by a customer for user experience cost. And this is important because it will justify as well the ROI of the solution and why it's important to migrate on this type of solution, not only to be secure, but as well to have a good profitability. I was just following your view on this point.

I mean, it's not only security, you maybe have the security driver or the regulatory driver because you can be forced to move to this kind of solution. But we know that user experience and costs are definitely the two other pillars. And you don't win only on security. If I hear you well, you also win on cost, 81% of reduction on help desk. And that's, I think, good to know for those who will want to migrate or will migrate.

And that's good because this is the first thing or the second thing we will discuss is, okay, now that you are convinced because either you are convinced or you are forced to move for any reason, how do you move from pilot to production? And what is the experience we could also add and could share with you?

So, before I'm turning this into details, let me ask the audience the second question. In your environment, which part of a Pascal rollout would be hardest to solve, according to you today? What is your feeling? Your legacy application that cannot do web app?

So, that's something we often heard, we often hear. Environment and proving who the user is at registration.

So, the provisioning of the past keys. How do you deploy this new authentication factor? Account recovery and the loss authenticator.

So, the life cycle. It's more the life cycle that concerns you. What do we do when something goes wrong, basically? And the fourth point, maybe you have shared workstation, you have different typology of workers, frontline and field workers. You have third-party workers, you have suppliers, you have other workers in your field, in your factory, in your ecosystem that are there. And that you have to manage. Maybe it's the fourth of them, but the question is the hardest.

So, please pick one and we will get to those results at the end of this session. I'll give you 10 more seconds if you need more time.

So, let's move forward. So, deployment.

So, most of the time, the complaint we hear is, okay, how much difficult will it be? We already went through different difficulties when we deployed all the authentication factor or all the authentication mechanism we are being asked to deploy in the past, as I said. When we deployed the OTP 10 years or 15 years ago with the hardware token, it was a pain to deploy the hardware token because people had to do physical logistics. Then we got the smartphone with the OTP authenticator and we got the fragmentation of the smartphone ecosystem.

And then people are, okay, we went through that and now you tell me that we have to deploy ASCII. So, obviously, all the topics that were on the polls are something we hear and we ask them because this is something we got. And that's the five points that come back the most in the discussion. On your side, David, out of the five, what comes most often according to you or according to your customer base and how do you design the solution around that?

Good question and difficult to answer because, in fact, it's difficult to say which one derails most often because it's really dependent on the organization and the way the organization, the customer will deploy and will plan its deployment. It's a matter of size, project, budget, targets, use cases, project management, governance. There's a lot of factors that will influence on the struggling ones. What is clear, nevertheless, is that all these items are key points to take into consideration when you want to deploy.

So, it's more or less important depending on your priority, but everything needs to be in consideration. And what is complex as well is to to take into consideration the two factors, as you can see on the graph on the slide, the combination between the timing efficient solution, which is a circle accelerate.

So, it accelerates at all the stages. You need to accelerate at the registration, at the revocation, at the recovery, at issuance of the token, without any compromise on the security, without any compromise on the flexibility that the IT administrator will have.

So, that's, in fact, the main complexity for this type of deployment. So, we have at all the stages some cases. Perhaps I can take some examples that will demonstrate the variety of problems faced by our customers and the lessons learned. As you said, Guillaume, a few seconds ago, deploying hardware is always complex.

Here, with the FIDO stack, we have solved a big part of the solution, because the implementation of a hardware on a PC is much faster and easier than in the old time of PKI, but we still have to deliver hardware. So, for example, we had a leading European bank that has partnered with us because they wanted to enforce and to strengthen the online banking security by replacing all OTP by FIDO hardware security keys. They are convinced that the FIDO hardware security key can bring them additional security, and then their problematic was to deliver the key directly to the end user.

So, the last mile delivery to the consumer was a keypoint. This is exactly what we deliver as a solution to them in order to be able to tackle the problem from the issuance part. We have another example of a global transport manufacturing organization in Europe who is convinced to deploy a phishing-resistant solution to their employee, but as a global transport manufacturing organization, they have a lot of subcontractors, partners that are acting and that need to interact with their IT system.

So, the idea is not only to deploy this, and they want to use this high assurance level of security with the keys, then they have to deploy them to the partner. Here, the question was not really a matter of how I will distribute the keys. How I will facilitate the onboarding of the user in order for the user, my external partner, my external contractor, how it will be easy for them to onboard and to be, as it's mentioned in the slide here, to have a fast onboarding.

So here, we developed a solution which is more a pre-registration services in order to pre-register the file key before delivering to the end user in order to facilitate the onboarding for the end user. Another example, more in the US, with a big organization in aerospace and defense, on their side, the idea is that they have more than 1,050 employees to manage.

Here, it's massive. You need a full lifecycle management solution in order to be sure you are able to manage and revoke in an efficient way the solution.

So, the lifecycle management is a key success factor in this case, and it was not possible for them to deploy any keys on a massive rollout without having this type of solution, which was missing on the market. So, that's why we worked on them and we developed this solution to bring this solution.

So, different case, very different from issuance, lifecycle management, etc. But, I can say that depending on the size and the topic from the customer, they have different problematics, and then we intend to design a solution to answer this.

Okay, these are clearly five topics that are concerned from the customer in the market. And, maybe the sixth one is what we see is that, okay, I decide, I trust you, I decide that I want to deploy PaaS keys, but definitely it's not a bang. I still have to deal with my former authentication factor. I will still have to migrate. There is a migration phase in all the cases.

And so, I have to keep fallback because I have some people who will not be able to be in the early adopter when I deploy and so on. So, if I have a customer who runs OTP today, and that has to or wants to deploy FIDO side by side, how do you address that? How do you support the coexistence of these multiple factors that may have been provided by you or by someone else in the past and that could not be just revoked or replaced in one shot? Yeah.

Indeed, this coexistence is between the different methods is key because I would say mainly all the organizations are doing pragmatic and PaaS, as you said, and not big bang. That's very clear. Even except for very small organizations that can do a big bang, generally it's progressive and we recommend as well a progressive.

So, the coexistence is important. Having said that, I think what is important is that the main subject of the capability of the backend authentication platform to be able to continue to support the legacy, the old method versus the new method. I would say at the authenticator level that is in the hand of the user, whatever it is, hardware or software or whatever, it's more a matter of user experience for the user to jump between one method to another one. But what is more important is that the backend servers are supporting the different authentication methods.

And on our software part, where we are delivering authentication server, we are really willing to support all the standards to be able to support. So, coming back on the migration paths, definitely we recommend this migration on the side to side.

So, again, what we recommend the is to evaluate the different variety of user profile to select the authentication method and then to deploy a plan per group of users, targeting obviously the more sensitive one at the beginning, the one that needs probably more user experience and easy user experience. So, there is a selection of what are the different groups of users that will be deployed phase after phase. And then after, you can have the full workforce.

Coming back to the customer, what we see is generally, even if we have an organization like a bank or an institution that has internal workforce and external customers, generally, they can use the same technology. They are not obviously linked in terms of project management. They can be very parallel projects because the problematics between an external customer and an internal workforce can be different in terms of life cycle, insurance, level of security.

So, generally, that project that are more run in parallel or one after the other, it can be a really different strategy. So, that's a bit of a comment we can do on that one. Thank you.

So, maybe this is your slide. So, I will hand over to you for this part. This is the transformational part of the implementation.

So, maybe the floor is yours. Yeah, this slide is just enforcing what I have said before. We need to really look at what type of user, what type of focus, meaning what is the target you want to improve, security, is it UX, is it efficiency, the method, whether you want the method will give you the level of insurance, whether you want a token to have high insurance, a pattern base for low insurance, a smart form for better UX.

So, this is the method. And then you will have the result group after group. And all the group, what is important to understand is that in an organization, in many organizations, all the workforce will not have the same target, will not have the same problematic. For some of them, the efficiency is very important. When I am in a shop floor, where I have some very key target in terms of efficiency in production, I need to be very efficient. When I am on a desktop, I have less constraint on the timing, on my implementation of authentication.

So, that's why we need to absolutely segment the users, the level of insurance, whether they are sensitive or less sensitive data to protect, and then what type UX you want to provide. And then do this group of users in order to have at the end the full workforce and the full employees covered, because at the end, the attacks can come from everywhere. That's indeed the situation we see today.

And so, that being said, so I think there is a way to go today to resist the more and more phishing attacks all organizations are facing. We still, we start to have a certain number of returns from the market on the transition and how to deal with the transition from legacy authentication to passkey now. But what people may be wondering is, what is next? And one of the things in the what is next is definitely everything around the quantum computing.

So, there are a lot of things around quantum computing being told. So, each time cryptography is involved, there is someone asking, okay, but what about PQC readiness or post-quantum computing readiness? That's a topic in our organization, or that should be a topic in our organization. And specifically, if you use cryptography for authentication, because that's a real concern. There is also recommendation from different regulators from different countries, at least in the U.S.,

or NC in France, or the regulators in the rest of Europe that are saying to organizations and everybody basically that you should be ready by this day. So, it should be, it could be 2030 at the beginning to 2035.

Now, it starts to be 2029. So, everything is moving fast. Everybody is talking about the harvest now, decrypt later. It's maybe less a concern for the authentication business. It's more a concern for the long life data. But I think that, as far as I know, Thales co-chaired the final PQC study group. What is it producing, basically, and what horizon do you have in terms of publication on those topics?

Yeah, thanks to elaborate on this one, because it's a very key topic and I have a very important message to provide here. The first point, before coming on what we're doing at FAIDO co-chair study group, is that I would like to mention that Thales, at group level, we, Thales and group, not only in cybersecurity products, but we are really engaged in PQC. The idea is really to, we are seriously seeing this PQC day coming in the next five years, even a bit less now, around 2030.

And we need, we want our customers, we want the ecosystem where we are playing to be a PQC safe, PQC ready by this date. So, and just to give you some example, we co-developed some Falcon post-quantum algorithm that has been selected by NIST. We have developed the first common criteria EL for smart card that has been certified by the NC in France recently.

So, we are in our own maps and some PKI product for 2027, for early next year, for PKI authentication based on smart card. So, this is something we are actively working. We are working as another backend on the HSM part in order to be sure that the HSM will be PQC ready in the ecosystem.

So, it's an ecosystem. Coming back on FAIDO, yes, Thales is deeply involved in PQC and inside the FAIDO, we are co-chairing FAIDO PQC study group and Beatrice Perrani from Thales is leading this study group.

So, the idea was to deliver and we delivered end of last year some recommendation to the technical working group on the best way to apply PQC algorithm in the standards. Now, the FAIDO Alliance technical working group is currently working on the specification to be sure that all the specifications of FAIDO are evolving, taking this recommendation and the need of PQC in order to have a published specification in 2027.

So, as soon as we will have this specification, we will be using industrial and the manufacturing of tokens card like we are, we'll be able to implement products. What is important to understand on PQC is that PQC algorithm are much more heavy than classical algorithm and especially the size of the key as MLKM, MLDSA, you are mentioning on your slide, there are different size of key we can do and we have done already some implementation, as I said, of product based on low size of keys.

But what will be recommended by many organizations, many body organizations in the future will be large size of keys for which we need some more powerful chip and that's what we are working on in order to have a better suite hardware to fit the needs, not only in 2027, but to be sure that this will be ready and efficient for the PQC is not only a firmware update, it's the new hardware. But having said that, as soon as the specification will be ready, we'll be able to develop products that will feature both PQC with a larger key and the standard crypto that we have today.

It will provide the crypto agility, but for that we need first to have this larger chipset and as well as the specification. And that's what I want to say on this topic, which is quite important. I would really like to insist on the fact that organizations should not wait PQC to enhance security. I hear sometimes, okay, let's wait for PQC and we will go.

No, it will be too late because the weakness on phishing attack is now. And as we said at the beginning of the call, it's even increasing like L thanks to AI. So it's very important to protect the organization. And in this, and you will see in the, in the, in the, we will see, we will send after the call that the real pain on the short term to have a modern authentication method to tackle the weakness. This is the password. So we invest now on a, on a, on a, on a system, which is not PQC.

What is important to keep in mind is that you are investing not only on the key itself with some crypto, you are investing in the full ecosystem. As I said, you need to involve a life cycle management tools, issuance method, policy regulation, et cetera, in your organization. All this will still be valid. The day PQC product will be ready. You can replace your standard key by another, another key, without having to redesign all the ecosystem, which is key in this type of deployment.

So this, there is an investment to be done. And the idea is to be done now, even though the industry is preparing for the PQC roadmap for the future. And coming back to the crypto agility you mentioned, will it be a feature of the standard, FIDO standard, or will it be something that will have to be implemented above the standard by the supplier or the solution of the manufacturer? But the standard will specify both crypto and then the migration path will be probably, I would say specified by the standard, by FIDO.

But the fact that I would say you support both algorithms will be more a choice of implementation of the industrial. So it will be our choice to implement or not, depending on the capability and the size of the component. So it will be both a recommendation, I would say from specification and an implementation. It's a little bit like today, we are implementing products with both PKI and FIDO, because we know that we can have as well some use cases where we can feature both. So it's two types of processes and we can both. We'll do the same for all.

Okay, that's clear. So if I have to come to your point, but if you want to be ready for the next step of the we'll say it again. So phishing is rising, phishing is easier and easier, and there is no chance that it becomes different in the future. It will be easier and easier in the future. And so Paskey as a standard phishable factor is a standard against phishable factors. But when you deploy Paskey's lifecycle is a topic you have to take care about that. Environment recovery, revocation, these are points to take into account in the principle.

And when we talk about PQC readiness, as stated by David, you should anticipate that it will be clearly a strong point from the vendors that will be able to address non-PQC and PQC compliant algorithms to support the present and the future. And you should measure the impact of that phishable. Phishing should be reduced by the deployment of Paskey. That's what we see. And there's no reason why if you deploy Paskey it doesn't happen to you.

And I think that, and that will be the point of our next slide, you have a portfolio that aligns with that, obviously, because you have this understanding of the market. And maybe I can switch to this slide so you can present it to us.

Yeah, indeed. Yeah, and coming back to your four points you mentioned, indeed, I would say our offer fits all of them. And this is exactly what we have, this is, as you mentioned on the bottom, our passwordless 360 approach to get full passwordless coverage, as you said. So this is the approach we have undertaken at TELUS. And this approach is to provide a full set of solutions, software, hardware, which will provide not only a password removal solution, but as well an architectural, I would say, coherence between different items. The fourth you mentioned below, but some others.

So for us, we need to have a coherence between a phishing resident authentication, second, a lifecycle governance, the integration of access management and authorization management platform, the support across all workforce, consumers, partner, and machines. Machines is another subject that is coming now. And the flexibility to incorporate new crypto, like the one we mentioned, post-quantum crypto authentication, and emerging digital identity models, like AI adjunct as well, we have not mentioned, but that's an evolution. So the idea is really to provide this coherence.

So you will have access to a link after the call where our passwordless 360 tool, where you can map based on which type of organization you are, which type of user you want to select, which type of insurance you will configure, and it will provide some recommendation on how the solution should be architectural and what type of solution we can use. And if I look at your four principles, of course, everything starts by the foundation, which is security. So by nature, this solution, our solution, should be phishing resistant by default.

And it is both on the backend platform, as you can see here on the right, on the left of the slide, whether it's for external or internal users, the Siam platform, the B2B platform, as well as all the finder. Speaking about security, indeed, it should need to be crypto agile, as we say, able to address the next stage of PQC.

And then, what we already said, which is important to insist on here, is that to have this coherence, as I said, in the architecture, you can have the best secure product. But if you have no way to deploy it correctly in an organization, it will be totally useless. So that's why we insisted a lot in our portfolio as well, to really focus on the lifecycle management. We have some offer dedicated on that. I mentioned some issuance topic earlier on, some revocation, some pre-registration as well. All these need to be managed as well. So this is a coherence of all these activities that I mentioned.

And the last one you were mentioning on your slide before, I think, was on the metrics and the measurability of the solution. Indeed, it's important as well that our customer can measure the efficiency of the solution, both on security, cost, user experience. And we have some metrics, some dashboard logging report in our platform that can provide this as well, to support our customers to measure. Thank you. So three things before we switch to Q&A. We are almost on time. We will have 10 minutes for the Q&A, so that's great. So legacy MFA doesn't stop phishing.

That's obvious for everyone, I think, after this webinar. So you have to move to phishing-resistant authentication. I am a strong advisor of Paskey. I do that for a living, but I cannot tell you once again, you should move to Paskey. Paskey is already for the enterprise. Maybe it came more from the customer ecosystem, but definitely it's ready for enterprise, the workforce, even the third party joining their solutions. And you should think about crypto-agile infrastructure that's adjacent to our crypto-agility topics we covered at the beginning on other dimensions.

But this is a controversial topic. Everything that has cryptography today, that is probably 100% of the things in cybersecurity and IAM business, should be crypto-agile because PQC readiness is enforced by regulation. And because even if regulation doesn't enforce it, it's the way to go if you understand what is PQC. That's the takeaway I wanted to share with you. And now it's time for our Q&A session. I see there are already questions in the chat, so maybe I will take them by chronological order. So the first one from Thomas, is FIDO sufficiently supported now through the IT ecosystem?

FIDO coverage was really spotty two years ago, even among tech giants cloud services. My answer is yes, but maybe David, you have something more. Is FIDO sufficiently supported now to the entire IT ecosystem?

Yes, that's a very good point. So it has been really supported by the hyperscaler on the customers, on the PC side, it's on the browser. It's now five years and we have really good coverage.

Indeed, there were some lags on the back-end system and probably the question was on the cloud and the back-end where some server, authentication server, was not supporting the FIDO standard. And that's a topic I mentioned early on, saying that indeed it's very important for the crypto-LGBT and the co-existence of the system that the back-end are supporting different types of standards. So it's important that us, but not only our competitors, we are supporting all these standards on the back-end. I think it's becoming more and more better in the past two or three years.

Yeah, and if you want metrics for the people who asked this question, the leadership compass about passwordless authentication I did a few months ago, you have the different vendors providing passwordless solution and those who are FIDO certified, those who are not, to support PASKE or not. That will give you a flavor of the readiness of the ecosystem when it comes to supporting PASKE as a server or as an authentication. The second question, how do you cover shared workstations, frontline staff, and people with no phone?

Yeah, that's often a question that we ask also to the different vendors, like, okay, there are customers who have a single persona, if I may say, but there are customers with heterogeneous ecosystem, talking about people, and that's often difficult for them to address this topic. So on your side, how do you address that?

Yeah, so this is a bit the idea of having a standard like FIDO in order to be as large as possible in the acceptance. So indeed, when you don't have a mobile, you say mobile was one of them, you need to have a dedicated device, but this dedicated device needs to be accepted on the different front-end service, non-connected, etc.

So that's where having a very strong standard like FIDO that is deployed now in a lot of organizations and supported by a lot of tech giants, I would say, it will help to deploy this standard in all the border cases, I would say, that are perhaps not the first target, but that will come later on.

So we are working with different partners to be able to support even non-connected machines to work with air credentials that I host in my key, that allow me to connect to my PC on Windows, for example, I can use it as well on an environment that is not obviously a connected Microsoft environment, or I can use it as well on an Apple one. So that's exactly the idea. So everything's not perfect, but the ecosystem is more and more solid in order to support all this.

Okay, so the idea is to have a portfolio of solutions so you can find the right authenticator or the right server for the right persona, and everything working together inside the same ecosystem. And I think this is the challenge for all the vendors, to have at the same time a large portfolio, but also everything working all together. That's what I hear. The third question from Peter is a very good one, because that's one I may have asked also, or I ask often, what is your recommendation as a suitable identity anchor to ensure that the right person is registering a very secure passkey?

Because as we say, lifecycle is something if you deliver a passkey to someone that is an attacker, in the end the attack is successful. So as good as is the authentication factor, if it's poorly provisioned, or that you can switch from a trusted user to a non-trusted user, then you enter in the weakness. So how do you address that problem at Thales?

Indeed, here we are attacking a point, which is the fact that to be protected, an organization needs not only to focus on this topic of passwordless, but everything. And for example here, there is another angle that is a bit adjacent, which is the ID verification. So how you are proving that the person you are discussing with, the person to whom you are going to distribute a passkey on a secure device, is the right person. So the ID verification topic, which is another topic adjacent, is as well a very important topic.

So it can be very traditional way with face-to-face person validation of the people, but as we are going more and more online, indeed we need to have online ID verification. And this is part of the global suite of solutions that we have. We have ID verification tool online that can be used to secure onboarding of users. So this part is adjacent, but indeed totally.

So again, as we said, there is a holistic approach that needs to be taken, and here we are tackling the fact that your credential can be stolen. But indeed, if you want to bypass this, you want to provide a secure tool, you need to be sure to provide the tool to the right person. And thank you for talking about that, because it's a coincidence, but today we released the IDV leadership compass that I did. I didn't know. I didn't know. You are not aware.

It's hard to promotion, but today there is a leadership compass about identity verification, and definitely that's one of the topics that is covered. If you have to secure the way you deliver the authentication factor, whatever the factor, it will be weak if the delivery process is weak, and identity verification is one of the angles that you should tackle for this kind of things. And so we address that in that leadership compass.

One of the questions from Mark regarding PQC, what is your view on hybrid algorithm authentication, using classical and post-quantum algorithm in combination to mitigate the risk that MADSA might contain logic or implementation flaws, making it weaker than a recent ECDSA? Will you support this? It's a long question.

Yeah, yeah. We support both algorithms, but an hybrid one, I'm not aware of that. If I understand the question, I cannot see the question, but if I understand what you say, it's a question where there is a an hybrid algorithm supporting. So I will reserve the answer if you want. I don't want to say something which is not true, so I will check whether it is possible to have this hybrid algorithm.

Okay, side by side for coexistence, as I said, it's what we want to implement. Having this hybrid algorithm, question mark will be as well, how you have this algorithm certified, whether it will be specified, and then how it will be certified, because all the implementation we are doing are certified, whether it's by the list or for FIPS or payment criteria. So we need to be sure it is well documented and then well and not the hybrid algorithm that indeed has some cryptographic weakness, and so you decided it's either or and not the hybrid way. I understood you correctly.

I'll jump about this one. How do you see the growing push of Microsoft to introduce passkeys for corporate environment by removing SMS voice from SSPR? And it will be the last question because we are running out of time, so if you want to comment.

Yeah, I can comment. I can even say that we are even working together with Microsoft to promote this passkey to customers. We are doing some joint promotion event, so that's quite clear for the answer, and we have recently deployed some keys in North American customer where it was a common project between Microsoft and Microsoft.

So yes, Microsoft is supporting passkey. It can be software or SYNC passkey. It can be device bonded passkey.

Again, device bonded on mobile or on hardware, but for this specific customer, they were pushing with us a high-level assurance based on security, so quite clear. And I think it goes further than that. I think the strategy of Microsoft is to push easily on passkeys and as a standout and to remove or get rid of everything else, so it will be the default way of authenticating to the Microsoft ecosystem, and indeed I think that was the end of the question. This is a nearly push from Microsoft and everywhere I look at, I see that from their communication and their ecosystem.

So it was the last question because we ran out of time. Thank you very much everyone for attending this webinar.

As I said, you will receive everything in the coming days. You will have a white paper and all the links together with the presentation.

Thank you, David, for your time. It was a pleasure to welcome you. Sorry for the technical issue. It happens and I wish everybody a nice afternoon, journey, whatever day, wherever you are. Thank you everyone. Have a good day. Thank you very much.