Passwordless Authentication for Your Workforce: Control the FIDO Authenticators Life Cycle

Hi everyone. So as we said, I mean personally I'm product line manager in Telus and today we'll speak about how to deploy Fido devices or even pass keys into specifically a workforce. Basically what are the key recommendation, but as well you will see that some recommendation can apply in different context. Just to pass this slide, yes, So in fact we'll have three parts on this plantation. The first one being first to understand what are the challenges when you want to deploy your pass keys to your employees after.

We'll see how the Federal Alliance is trying to solve that because of course FI is a standard which evolves and every release is improving the situation, trying to add some feature to that to be sure that the deployment will be as smooth as possible, but as well at the end we'll see what are the key recommendation we recommend today in Telas for doing that. Before going to the challenge, the first question you need to ask yourself is, is file ready to be deployed? And basically today all analysts say that yes, now it's starting to work in Microsoft, in Apple, in Android, everywhere.

Now it's key at the moment to start deploying PA Keys and Fido. But nevertheless, some are saying that even if it's working everywhere, you still have some legacy system to support. So then it can make sense sometimes to also mix Fido with either OTP or PPIX 5 0 9 certificate, et cetera, to be sure to deploy only one device to your employee. But even more importantly, the thing to understand when you want to deploy something like that is, okay, I need to secure access from to my employees. I need to deploy an identification protocol. Which one I should take.

Basically all recommendation are very basics is it must be phishing resistant. And there is today only two technology which are phishing resistant. It's either the PI the X 5 0 9 certificate or the Fido. And as you may know, Fido is much, much more simpler to deploy today.

Again, just one thing about past keys, since maybe one year and a half, two years, you start to think about and to heard about past keys. I do believe the wording is great because before Fido basically nobody's able to understand what Fido means when you say I want to deploy a file on ticket, et cetera. Nobody can understand. Public is not able to get it, but passkey versus password, replace password with pass keys make a lot of sense. Everybody understand what it is and how you can use it. But still the the standard is evolving.

And today there are two type of pass keys just for you to get it and to really understand on the left side you what we have what we call sync pass keys. It's where the OS manufacturer, apple, Microsoft, Android, it, all the password managers which are generating pass keys, et cetera, and synchronizing the pass keys are acting today. In this context, you need to understand that your pass keys are synchronized over all the devices. And I will do a simple example. I am on my Mac, I open, I connect to my bank account directly, I create an account very easily.

I have no password to login and boom, I'm connected. I have created the pass key in two seconds after I take my iPhone and I can connect to the same account using the same pass key without even knowing I'm using it just to click. And I'm connected as well because Apple is synchronizing all my credentials from one device to the device as long as they are connected with the same Apple account, same on Microsoft, same on Android with Google.

So this is good and definitely it's much, much, much better than any password that you can have 'cause the security is great, but very often when you want to deploy that in a company, it maybe doesn't make sense. Do you trust Apple for the keys to access your company? And specifically in general, you give just one device to the user and they have multiple device connected to the same account. So any user device will be able to access your company. That can be an issue.

That's why in general, what we recommend is more the right part, which is a device bond PA key, which means that the credentials that you have just in one place, a smart card, a token or even you, you have sometimes some software implementation specifically for the banks where is the credential is not stored in the US level but at the higher level in the app directly. So all these kind of method are perfect for stronger identification and basically the keys are in one place. So now let's discuss about what are the pain points.

We discussed with a lot of customer deploying pass keys, Fido, et cetera. And we think that there are three main pain points today. The first one being the configuration of the key Fido helps us with lot of different possibilities like what is minimum penland, et cetera, et cetera. But as a company, how you enforce that to your workforce are you assure that if you define a security policy, some constraint to the user, how how it'll apply. 'cause in Fido you can anytime token and change everything. So very complex to have us to maintain something like that.

The second problem is IDP registration. In a company very often you have two, three different IDPs being Okta and id et cetera. How the user will manage his and use his phylo token in the B2C ecosystem, it's very simple. I mean I'm doing the effort to buy my key on Amazon so I know that I will register my key, et cetera.

But if you unfold that in a company and giving a key to every employees, you will have to do a lot of education to say now you have your key, you need to set up your pin and after you need to go to an id, you need to go to ping to tap page to register yourself, et cetera, et cetera. That's really cumbersome. It's where Microsoft sellers that I mean they are failing basically deploying very, very large number of employees on this technology because of that. Because it's a B2C technology with a self-service minded approach. The last part is more about the ecosystem.

Here again, it's more specifically an enterprise. I will take one or two example. If you have a badge to open the door, maybe it makes sense to put file as well into the same badge like that you have one device to open the doors and to open the computer to access the internet, et cetera. Or sometimes it's better to have two devices up to the customer. But here the point is when you deploy something, look first at what you have already as an hardware component and try to put everything inside to avoid having different type of devices.

As I said, Fido is trying to fi alliance is trying to improve the standard. This is part of 5 0 2 0.1 and will solve some pain point already mentioned. First one being minimum pen length. As easy as it sounds in lightest version 5 0 2 0.0, it was not possible. It was four digit for everyone. If you wanted to increase, you didn't have the possibility by the standard, no, you can do so after you have the change pin.

This can be very interesting if you have someone in the company configuring the key on behalf behalf of the user because it can use configure the key using a basic pin and after it can give the key to the user and the user will be forced to change this pin like that. You're sure and you're unsure that the user will select his own pin respectful about the pin policy of the company after you have the user verification where the you will force user to always use the pin. And the last part, which is a bit complex to deploy today is what we call enter presentation in the FI alliance.

It's a capacity for a customer to to recognize the specific key when you associated with a specific user. Because again, the main focus of FI alliance was to create something for the end users, not for the companies, not for the workforce. So you are fully autonomous anonymous, sorry. When you connect to one system and another system, you have different ideas managed by the protocol. So there is no way for a company to recognize that it's the same token using two different context.

This can be solved now with this type of feature, but again, complex to deploy because in fact you need to do that in the factory when you create the device. If you look at the standard, you cannot do that on the field. So if you change the configuration later on it can be a mess.

But again, FI alliance took and understand that Fido make a lot of sense for the employee and every release, they're improving the feature to have something more and more deployable after. Now when you want to deploy a Fido token or a pass key, again FI is PA key. Paki is Fido the same. You have poss multiple approach and you need to think to think about what make more sense for you. Basically here we are showing two possible approach, but there are of course more than that. You have either a self-service driven approach or an admin driven approach.

Here it's, I'm more talking about who will do the registration to the IDP to enter idea as an example. In any case, individual approach, we do recommend to have someone in the company configuring the key or your hardware provider configuring the key, the factory directly to, to give you something that makes sense for your employee directly up to you. So someone either in your company or you ask key provider to do it. And after you will see that there are multiple possibilities. First thing is all key providers have software, have some software, sorry, to configure a key, okay?

It's not only TELUS but of course other people have that. And we do believe that in the scenario that I will show just after, when you want someone to configure the product, you need to use such tools. So there are tools on mobile phones, there are tools on Windows, et cetera. That's a good first step. If I explain how you can deploy a key today, just to go to the recommendation here in this example you have an IT operator in your company. So you are, you are buying whole key directly from the internet, from your supplier whatever.

And the IT manager before going, giving a key to an employee will just put it into a system. And here you will see a key manager will configure the security policy. So here you will have a defined pin complexity, defined settings about et cetera. So a lot of settings will be set after that. You can give the user the key to the user and the user will unroll himself into the IDP. That's good. If there is an issue, you can use the same tool basically to unblock some tokens or to to do some self-service operation.

So that's the first approach, basically having a tool and deploying a tool for you to configure the keys. Again, if you don't want to do that, you can ask the key provider to configure the key on the factory directly And to go to the Mex complete and complete approach here. What we do recommend today is to also have some software on top that manage registration of the IDP. All the IDP in the market today are starting to add APIs because they understand the the struggle. So what happen here is basically you have here, I try to have two scenarios for you to get it.

First one we are still in the on B, the top line, you are still on B. It means that the Francis, we plug this key on the computer, we run some software and here on top of the security policy, the software will unroll the key directly into the IDP or if they have two IDP into the two IDPs. So like that, when you give the key to Paul, he can use it directly, maybe charging his pin. That's all is good to go. He has nothing to think about. But as well this type of software company can also provide some different workflows where you don't even have to do that internally.

You give the key, the whole key to a user and the user on his machine will plug the key, the software will kick in and then will configure theon and we do the enrollment. So all the complex step will be bundled into one step that you control that will do the key registration and the credential creation against the IDP like that. If you want to revoke your key, it'll be easy. You need to go in a single place and it'll revoke the key to all your IDP that you have. So that's typically what we recommend today.

Last thing is, as I already mentioned, depending on what you want to deploy, you need to think about the form factors and the other technology you, you need to have, very often you have OTP or PPI mix with Fido to be sure to be compatible with legacy system. But as well you have Fido mix with smart card for physical access or for mobile phone access, et cetera. So you can have a lot and plenty different contractors.

So again, as a key takeaway I would say if you are in the workforce, I mean if you want to keep your workforce first, you need to maintain a security policy for your accounts, whatever the method you prefer because you want to be sure that the employee are using the product in the right way. And ideally as well, you will simplify the life of your employees by doing the IDP registration on behalf behalf in this two step.

And again, last thing is to have one hardware that cover all the needs of your employee and that's all. Well thank you very much Gregory. I think we do have time for a question. Yeah. First of all, thank you so much for the presentation. I have one question regarding pin length and best practice and pin length since PIN should not replace password in respect of complexity, right? So what is the best practice here?

Yeah, but basically what we see today is six is a kind of good practice in the workforce. I agree in terms of attack, it's much harder to attack your pin, so, so you don't have to be very, very complex pin et cetera. But six seems to be a good value today.

No, no more than that Question. Hey, regarding the pin change requirements, does it require hardware support or can that be done by a software on the computer? Both of them. I mean you can have the different approach of course if it's only at the software level, you will never stop a user going elsewhere in the road if you don't put that in the hardware. I mean that that's common sense. But in general, yes, there is some protection at hardware level and DEL as well software level. Okay.

So if I have already like 5,000 U keys deployed with 5 0 2 0.0, I will not be able to enforce it on those devices, is that correct? That's correct. Thank you. Okay. If you do not have any further question, thank you very much Gregory.