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

Hello everyone and welcome to this Coupling.Go.Go webinar, From Password to Passkeys, where we will discuss authentication topics, obviously passkeys, and many other things, including quantum future. First thing, first, audio control, you are centrally muted, so don't worry about that. It's under control. We will run two polls along 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 Lada 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. Thanks for inviting me. I'm very happy to be there with you today to share Thales' view on this interesting passwordless topic. So Thales' cybersecurity product line is really dedicated to provide solutions to protect and secure data, applications, and identities. So here we are discussing today what identity is, which is the focus of the IAM product line at Thales CSP.

And inside this business line at 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. If a convincing copy of your login 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 answers than in the fourth one. But I give you a few seconds to go through these polls.

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 countermeasure. 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 mineral 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 additional point as well, that we see clear acceleration since a few months. And mainly driven by the power of AI, which is 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 we really decided to unblock a budget to secure the access to this 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 are 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 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 we take care of that, is that all MFA are not equal. Because on one side, you have MFA that are still phishable factors like SMS OTP, Authenticator app OTP, 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. Smartcard 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 weakest factor. 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, David. So let's continue with that. So Passkey is one of the solutions to this. And as I said, there are different things we could argue or we could exchange about that.

First, you will have the same Passkeys and on the second side, you will have the device-bound Passkeys. So the device-bound 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 to the device or the Passkey. 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 high insurance on use. On the other side, you have the same Passkeys that are much more convenient. They are often managed by customer platform. They are recoverable through cloud account, great usability, fast adoption, very easy to use, but less enterprise-ready, if I may say.

One of the things 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, 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. I took a headset and it worked better. 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 customers 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 these factors, it will determine what type of Passkey will be well suited. And by the way, we have developed a password-less 360 tool that will be shared after the call.

You will have access. It's an online tool. Based on the criteria you can select, you can define which level of authenticators you will need. And quickly, I can mention the different options in Passkey.

So for us, definitely a synchronized Passkey could be proposed to replace password on low-medium assurance cases. But as soon as you want to have a more high-assurance use case, which is the case of many of our customers, device-bound keys 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 provides a higher insurance level than the synchronized key that can provide good UX, but which is not always fitted with the enterprise environment.

So clearly for us, the highest level of security and assurance can be provided by a hardware security key, like a card, like a token, where you combine 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 this key is really a good fit for different use cases in enterprise, in BFSI, in government, in different use cases.

But one of the things 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 is nothing to add. And on the cost, you remove the help desk cost. 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, 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. 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 time with Passkey 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 giving 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, 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.

So, we... No, no, no, I was just following you 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 cost 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.

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 open here. 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 lifecycle. It's more the lifecycle 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 four 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 poll 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 the 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 of 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, which is more or less important depending on your priority.

But everything needs to be in consideration. And what is complex as well is to take into consideration the two factors, as you can see on the graph on the slide, the combination between the timing efficient solution. We see the circle accelerate. So it's accelerated at all the stages. You need to accelerate at registration, at revocation, at 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 gaps. I can take some examples that will demonstrate the variety of problems faced by our customers and the lessons learned. As you said a few seconds ago, deploying hardware is always complex.

Here, with the FITO stack, we have solved a big part of the solution because the implementation of 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 partnered with us because they wanted to enforce and to strengthen the online banking security by replacing all OTP by FITO hardware security keys. They are convinced that the FITO 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 consumer was a key point. This is exactly what we deliver as a solution to them in order to be able to tackle the problematic 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 employees. 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 key. It's 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 pre-registration services in order to pre-register the FIDO 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 passive. 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. 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, we 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 trust you, I decided that I wanted to deploy pass keys, but definitely it's not a big 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 case. 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 many, all the organizations are doing pragmatic and fast, as you said, and not big bang. That's very clear. 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 coexistence is more 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 server are supporting the different authentication method 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 path, definitely we recommend this migration on the side to side.

So, again, what we recommend the organization 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 group 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 have 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, but not in the same sequence as shown here, first workforce, then customer, 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. You can comment about that.

Yeah, this slide is just enforcing what I've 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 of UX we want to provide. And then do this per 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 consensus to say that PASKE is the way to go today to resist the more and more phishing attack all organizations are facing. 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 PASKE now, but what people are maybe 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, 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.

and in France, other regulators in the rest of Europe that are saying to organizations and everybody basically that you should be ready by this date. So, it could be 2030 at the beginning to 2035, and 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 reason 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 are doing at Fido co-chair study group is that I would like to mention that Thales, at group level, Thales and group, not only in cybersecurity products, but Thales group, we are really engaged in PQC. The idea is we are seriously seeing this PQC day coming in the next five years, even a bit less now, around 2030, and we want our customers, we want the ecosystem where we are playing to be PQC safe, PQC ready by this date.

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 ZNC in France recently. We have in our map some PKI products for early next year for PKI authentication based on smart card. This is something we are actively working on. We are working on the back end on the HSM part in order to be sure that the HSM will be PQC ready in the ecosystem. Coming back on FIDO, yes, Thales is deeply involved in PQC and inside FIDO.

We are co-chairing the FIDO PQC study group and Beatrice Perrani from Thales is leading this study group. The idea was to deliver at the end of last year some recommendation to the technical working group on the best way to apply PQC algorithm in the standards. Now the FIDO Alliance technical working group is currently working on the specification to be sure that all the specifications of FIDO are evolving, taking this recommendation and taking the lead of PQC. In order to have a published specification in 2027.

So as soon as we will have this specification released, the industrial and the manufacturing of tokens, cards, like we are, will be able to implement products. What is important to understand on PQC is that PQC algorithms are much more heavy than classical algorithms, and especially the size of the key, MLKM, MLDSA, you are mentioning on your slide. There are different sizes of key, we can do and we have done already some implementation, as I said, of products 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 MCUs. And that's what we are working on in order to have a better suite of hardware to fit the needs, not only in 2027, but to be sure that this will be ready and efficient for the next four or five years. And when the PQC day will be there. So that's why transitioning to 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 largest chipset 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, OK, 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 paper, 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 need to tackle it now.

Nevertheless, as well, even if you invest now 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 standard crypto, you are investing in the full ecosystem. As I said, you need to involve lifecycle management tools, issuance method, policy, regulation, etc. in your organization. All this will still be valid. The day PQC product will be ready, you can replace your standard key by another key without having to redesign all the ecosystem, which is key in this type of deployment.

So 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 preparability you mentioned, will it be a feature of the standard, the 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?

The standard will specify both crypto and then the migration path will be probably 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 industry. 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 asymmetric cryptography, but with different process and we will do the same for both. Okay, that's good.

So, if I have to come to a point, but if you want to be ready for the next step of the authentication, definitely PASKY is the way to go. I will 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 PASKY as a standard phishable factor is a standard against phishable factors. But when you deploy PASKY'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 you talk about PQC readiness, as stated by David, you should anticipate that. CryptoID 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 PASKY. That's what we see. And there's no reason why if you deploy PASKY, 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, our offer fits all of them. And this is exactly what we have.

This is, as I mentioned on the bottom, our passwordless 360 approach to get full passwordless coverage. So this approach we have at Thales. 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.

So for us, we need to have a coherence between a phishing resident authentication, a lifecycle governance, the integration of access management and authorization management platform, the support across all workforce, consumers, partners, 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 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. So 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, you have to move to phishing-resistant authentication. I am a strong advisor of PASKE.

I do that for a living, but I cannot tell you once again, you should move to PASKE. PASKE 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 FingerCore on other dimensions, but this is a transversal 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. 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 giant cloud services. My answer is yes, but maybe David you have something more. Is FIDO sufficiently supported now through the entire IT ecosystem?

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

Indeed, there were some lags on the backend system and probably the question was on the cloud and the backend where some server, authentication server was not supporting the FIDO standard. That's a topic I mentioned earlier, saying that indeed it's very important for the crypto-LGBT and the co-existence of the system that the backend servers are supporting different types of standards.

So, it's important that us, but not only, our competitors, we are supporting all these standards in the backend. I think it's becoming more and more better in the past two or three years.

Yeah, and if you want to have 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 solutions and those who are FIDO certified, those who are not, to support PaaSK or not. That will give you a flavor of the readiness of the ecosystem when it comes to supporting PaaSK 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 ecosystems, talking about people, and that's often difficult for them to address this topic.

So, on your side, how do you handle 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 frontend 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 gap system, etc. To be sure that this FIDO 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 is not perfect, but the ecosystem is more and more solid in order to support all of this.

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 a challenge for all the vendors to have at the same time a large portfolio, but also everything working together. That's what we have here. The third question from Peter is a very good one because that's one I may have asked also. What is your recommendation as a suitable identity anchor to ensure that the right person is registering a very secure passkey?

Because as we said, 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?

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 that 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 you can be, your credential can be stolen. But indeed, if you want to bypass this, you want to provide a secure tool, we 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 not a promotion, but today there is a leadership compass about ID verification.

And definitely that's one of the topics that is covered. If you have to secure the way you deliver the authentication at all, whatever the factor, it will be weak if the process is weak. And ID verification is one of the angle that you should tackle for this kind of things. And so we should, we should, we should, 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 algorithms in combination to mitigate the risk that MLDS may contain logic or implementation flaws, making it weaker than ERC-ECDSA. Will you support this? It's a long question.

Yeah, yeah. We support both algorithms, but a 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 hybrid algorithm supporting. So I will reserve the answer. If you want, Alan, I can answer secretly. I will check that. I don't want to say something which is not true. So I will check whether it is possible to have this hybrid algorithm side by side for coexistence.

As I said, it's totally what we want to implement. 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 of FIPS or criteria. So we need to be sure it is well documented and then well certifiable.

Yeah, I think your choice was to implement PQC and legacy algorithm 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 to Microsoft.

So, yes, Microsoft is supporting passkey. It can be software or passkey. It can be a device-bounded passkey.

Again, device-bounded on mobile or on hardware. But for this specific customer, they were pushing with us 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 passkeys 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 I think that was the end of the question. This is a nearly push from Microsoft. And everything, 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. Thank you very much. Bye-bye.