If you are reading this, it’s almost certain that you’ve been tasked with helping your organization go passwordless. Perhaps it’s because Management heard that compromised passwords play a key role in 80+% of cybersecurity breaches, or maybe it’s because of the cyber insurance incentives and discounts for going passwordless. Why you are here is not as important as what you are going to learn, though. In this guide, I will guide you on how to go passwordless in Entra ID (Azure AD), from all the “gotchas”, to links, to step-by-step guides for each process, to the pointers that helped us follow Azure Identity best practices and go fully passwordless.
The first step to going passwordless is figuring out which passwordless credentials make sense for your users. Below I will break down each authentication method - their pros and cons, and for which scenarios it works best. If you don’t want as detailed information, skip to the “Which Passwordless Method Should I Use” section of this blog.
The oldest and most supported passwordless authentication method is smartcard (PIV) authentication. This method uses an x.509 certificate in a smartcard or hardware token such as a YubiKey. This is the only authentication method that is supported by all on-premises and Azure-cloud authentication libraries, making it the most versatile authentication method.
One of the most common questions we get is, “What’s the difference between a smartcard and a YubiKey?” …and the answer is that there are not much (other than Yubico being the only PIV provider compatible for Azure CBA in mobile devices), but in a regular PC or Mac, the YubiKey is read as a smartcard. The main factors you might consider are:
1) Cost: while YubiKeys might seem expensive with their $50 USD cost, smart cards are around $20, however you also require a smart card reader that are usually sold for $15 dollars bringing the price gap closer. However, when having thousands of users, those small savings can add up!
2) Form-factor: many organizations prefer having their employee ID printed in the card they use to authenticate learn how Keytos can help you with smartcard printing and distribution, while others are ok with having their card for physical access be different than the hardware key they use for online access.
3) Features: most smartcard formfactors are PIV only, meaning they can only do certificate-based authentication, modern hardware tokens such as YubiKeys can do both FIDO2 authentication and certificate based authentication always giving your users the best authentication method.
FIDO2 has gained popularity in the passwordless community due to its reputation of being easier to implement and more convenient to authenticate with (which it is). Unfortunately, as with any new technology, there are some problems authenticating with legacy systems such as on-premises, and there is still no full FIDO2 support in iOS or Azure PowerShell. Learn how you can leverage FIDO2 and Azure CBA to go fully passwordless in Azure.
The last mainstream authentication method is Phone authentication. While it is not as secure as FIDO2 or Smartcard authentication, it is the most popular due to its convenience. Everyone has a smartphone, so there’s no need to roll out hardware keys for authentication. While passwordless phone authentication is way more secure than traditional password-based MFA (Multi Factor Authentication), it is still not fully unphishable as users are prone to MFA fatigue. We recommend using this in cases where convenience is paramount, or budget is tight. (Read our blog on how passwordless authentication is cheaper than password authentication might help convince management on going passwordless).
While in this section we are breaking it out into different categories, you don’t need to use the same authentication method for all your accounts. You might have your sales team use Microsoft Authenticator App, and your C-level executives using FIDO2 + Smartcard; when it comes down to it, it is all a balance between usability, cost, and risk tolerance.
If you are on a budget, using the most popular passwordless authentication method (Microsoft Passwordless Authenticator) is a great option. Why?
1) It is free.
2) Users are used to using their phone as an authentication method.
However, as mentioned above, it is not fully unphishable. There have been many phishing attacks caused either by notification fatigue (sending enough notifications until the user clicks yes), or through social engineering (someone calling the employee and telling them they are IT and if they are testing something if they can approve the notification on their phone).
If you subscribe to our newsletter, you probably read the post on FIDO2 on-premises and know that for on-premises, Smartcard is still king. Meaning that if you have a hybrid environment you can get away with Smartcard only authentication, and even get the legacy smartcards that are cheaper (and multipurpose since they can be used for building access and employee IDs) than more modern hardware tokens such as YubiKeys or Feitian Keys. However, keep in mind that what you are saving on smartcards, will be spent on smartcard readers and with the more modern hardware keys you also get FIDO2 capabilities allowing you to have the two best unphishable credentials in one single device.
If you only have cloud resources (Azure and/or Microsoft 365), you might be inclined to go with FIDO2 only since Microsoft has marketed it as the cloud based unphishable credential; unfortunately, though, it is not compatible with all their services. Tools using MSAL such as Azure PowerShell do not support FIDO2 authentication, and while they are making strides to make it available in more places such as in iOS browsers it is still not supported in Microsoft iOS applications. To mitigate this, we use FIDO2 + Azure CBA certificate authentication. EZCMS is the only CMS to add a Smartcard certificate and FIDO2 credential to a YubiKey in the same onboarding process, making it seamless for the user - they don’t know when they are using Azure CBA and when they are using FIDO2, they just know they are using their hardware key for passwordless authentication.
Now that you have selected your passwordless method, the fun part begins! You must consider your whole user lifecycle and how it will look in a passwordless world, this includes: creating a user without a password, hardware key distribution, user onboarding, personal computer onboarding, network authentication, conditional access, and passwordless access to non-AD resources such as Linux. But don’t worry about it, below you will see how to overcome each of these hurdles.
While Microsoft has been talking about passwordless for quite some time now, they don’t have the option of creating users without a password, the best we can do is creating users with very long passwords (that are not stored anywhere) and have conditional access policies that require a passwordless authentication method. We have a great guide on how to create users with random passwords that will provide you with the PowerShell code to create the users.
For both large and small businesses, one of the hardest parts of going passwordless with hardware tokens is the distribution.
For large enterprises, distribution around the world becomes a problem. From dealing with customs, to having a dedicated team to manage and ship the keys, it can become exceptionally complex. Luckily, we have learned from distributing tens of thousands of keys around the world. This is why EZCMS offers integrated ticketing software making it easy for your IT desk to ship and manage your inventory, to even our managed smartcard and YubiKey logistics services where we leverage our partners around the world to distribute keys to your users around the world.
For small businesses, the challenges are different but equally as hard, from being limited to by industry players that will not sell keys to small businesses, to not having the infrastructure to ship or print smartcards, can become a huge hurdle to going passwordless. This is why at Keytos no matter your size, we can help you with everything from smartcard printing to hardware key purchasing and shipping, let our team of experts make this move to passwordless as simple as possible.
The first hurdle is onboarding users to the passwordless method of your choice without a password and protecting yourself from social engineering attacks on your IT staff such as the MGM password reset attack where attackers impersonated a user to get a temporary password.
If you are reading the Microsoft documentation, they will recommend using a TAP but if you really break it down, a TAP is just a one-time password vulnerable to the attacks we mentioned before and it will be your weakest link. We have a full article on how to onboard users without TAP but basically you must have a self-service onboarding option such as EZCMS’s government ID validation shown below:
Once we have created the user identity (we recommend either having a kiosk where users can use the EZCMS application without their PC, or having remote users use their personal computer to enroll). Don’t worry EZCMS has extra validations to prevent attacks from an unmanaged device the user must setup their work PC, Windows 11 supports sign in with a security key for OOBE, meaning the user can login for the first time to their computer using their FIDO2 key, no need for a password or a TAP!
If you are using autopilot, you are using Intune, and the best way to authenticate to your VPN and WIFI is using X.509 Certificates managed through Intune SCEP. You can setup your ADCS CA and SCEP server and manually maintain those servers. However, there are third-party Intune PKI services such as EZCA that make the whole process super easy and can have your HSM backed CA and passwordless WIFI profile in minutes.
Once you have rolled out passwordless authentication to your organization, it is time to enforce that only those methods are used for authentication. Thankfully, Microsoft makes it easy with conditional access (as long as you have an Entra ID Premium P1 or higher license, but it is definitely worth it). To set this up you can go to the Azure portal as a global administrator, click on Entra ID then on Security -> Conditional Access Policies -> New Policy. Name your policy, set a handful of test users to test the policy (you don’t want to lock out your users), Select the applications you want to enforce this policy on. Set your conditions (in here you can exclude device platforms that do not support your selected authentication method, however, we recommend enforcing it everywhere, remember hackers only have to find one weak spot). Set the “Require Authentication Strength” to Passwordless MFA in the Grant section of the access controls. We also recommend setting device requirements; you can watch our webinar on device security, but this blog is already too long to go in depth on device security as well.
While the first step to passwordless authentication is getting your corporate account secured, many organizations end there and forget about one of the biggest portions of their critical infrastructure: Linux. Linux, by default, is designed to have local accounts that are not connected to Active Directory; while that was good enough for the beginning of SSH, the overhead of credential lifecycle and user management does not scale to cloud requirements. To solve this, many try to AD join their Linux machines which, while it works, is not as secure and is prone to many DNS caused outages. Large organizations such as Google, Facebook, Uber, and Netflix have instead turned to SSH certificates.
SSH certificates are cryptographic certificates that grant short term access to the Linux node. The hardest part of SSH certificates is the creation: while you can manually create them, Linux does not have a way to automatically check the user access level to grant access to the user. These large companies use internal tools they have developed to check the user permissions and create the SSH certificate. While those internal tools are not available, you can use EZSSH, this tool authenticates the user using Azure AD, checks the user meets all the conditional access polices you have created, and then checks either your Azure RBAC or the hybrid policy ACLs for non-azure SSH endpoints and creates a short term SSH certificate to gran access to the user, once the session is done, the certificate cannot be misused because it is expired.
As you can see by this long guide, going fully passwordless in Azure may have a lot of moving parts, but it is possible, and once you do it you will never look back (believe us, we have been fully passwordless for over two years and we love it). If you are ready to take the next step on your passwordless journey, book a call with one of our engineers with over decades of experience moving some of the largest companies (including Microsoft) to a fully passwordless environment. We are happy to review your plan and ensure that you have crossed all your t’s and dotted all your i’s!
