Passwords are Dead: Why You Need to Move to Passkeys

Passwords could easily be your biggest security gap. FIDO Alliance's CTO breaks down passkeys and a simple SMB action plan to go passwordless this week.

Passwords were built for a different era of the internet. See how modern organizations are moving past shared secrets entirely to close their largest threat vector for good.

Traditional passwords and legacy Multi-Factor Authentication (MFA) are no longer enough to protect your business. Automated, scaling phishing toolkits easily intercept shared secrets, leaving small and medium businesses highly vulnerable to credential breaches.In this episode, we sit down with Nishant Kaushik, Chief Technology Officer at the FIDO Alliance, to translate complex cryptographic standards into an actionable, resource-light deployment plan for your organization. You will learn how to transition away from legacy authentication and close the hidden security gaps that hackers actively exploit.

What You Will Learn:

  • The Flaw in Basic MFA: Why SMS codes and standard one-time passwords (OTPs) are failing, as well as what "phishing-resistant" actually means.
  • Passkeys Demystified: The practical difference between synced passkeys (cloud-managed) and hardware device passkeys (the gold standard).
  • The Account Recovery Trap: Why a weak account recovery workflow accidentally gives hackers their primary attack vector back and how to fix it.
  • The Bottom-Line Benefit: How moving to a passwordless model drastically reduces internal IT helpdesk tickets and password reset costs.
  • An SMB Action Plan: How to use the identity infrastructure you already own (like Google Workspace or Microsoft Entra ID) to deploy passkeys this week.

Podcast Timestamps:

  • 00:00 - Account Recovery Loophole00:21 - Intro and Guest Bio01:23 - What is the FIDO Alliance? 02:21 - Passkeys: A Solution to Phishing04:06 - Advantages of Passkeys for SMBs06:47 - Synced vs Device-Bound Passkeys08:08 - Why Traditional MFA will always lose to Passwordless09:29 - Adoption Gaps & Compliance Obstacles13:59 - The Shift to Outcome-Based Regulation15:34 - Security Blindspot: Account Recovery Flows19:01 - SMB Quick-Start Guide Passwordless21:17 - When to Use Hardware Keys22:54 - Cost Benefit of Switching to Passwordless25:50 - One Step You Can Take Today

Resources Mentioned:

Passwords are Dead: Why You Need to Move to Passkeys Transcript

"If I can bypass passkeys by just going down the account recovery path and saying, 'Here's my email address,' and all you're doing is sending somebody a link or an OTP, you've essentially given them back their attack vector that they were exploiting with passwords." — Nishant Kaushik, Chief Technology Officer, FIDO Alliance

Jen Stone: Hello, and welcome back to Practical Cybersecurity. Very excited today to have a guest on who's going to talk to us about passwordless authentication. Let me tell you a little bit about him. Nishant Kaushik is a renowned expert in digital identity, with a career dedicated to pioneering advancements in identity and access management. He currently serves as Chief Technology Officer at the FIDO Alliance, where he helps guide their technology strategy and efforts focused on making the online world safer and simpler for everyone.

He brings over 25 years of leadership in digital identity and security, having shaped strategies and built market-leading solutions at startups and global enterprises. Nishant serves on the program advisory committees for the RSA Conference and Identiverse, and is a founding member of IDPro. He holds nine patents and is a frequent keynote speaker, passionate about advancing cybersecurity, digital trust, and the future of identity.

Nishant, welcome. Thank you for joining me.

Nishant Kaushik: Thank you, Jen. I'm looking forward to the conversation.

Jen: So passwordless is a huge conversation right now, and I thought it would be great to have one of the leading experts on to actually tell us what it is. First of all, what is FIDO? What is passwordless—all of those things? But maybe starting with that: what is FIDO, and why does it matter that we have FIDO? Tell me a little bit about that organization.

Nishant: So the FIDO Alliance is a consortium, and it's an industry consortium made up of almost 300 member organizations at this point, ranging from the largest platforms in the world like Microsoft, Apple, Google, etc., all the way to startups that are working in the security space. And the real goal of the FIDO Alliance is to essentially build trust in digital interactions and online ecosystems. One of the ways it started is by tackling a very specific problem, which is: how do we get rid of passwords?

Jen: Thank you. That actually helps me understand where FIDO is positioned to help us with this. So a lot of times when we're talking about passwordless, we're talking about passkeys, right? Can you tell me a little bit about what passkeys are, and maybe some of the different flavors of passkeys?

Nishant: Sure. So as we've been trying to get rid of passwords in the industry for a very long time—this is not a new problem, if you will. But passkeys are a very innovative way to tackle the problem by essentially replacing passwords in the authentication flows with something that is based on cryptography. When the alliance tried to solve this problem, they tried to approach it from the perspective of: how do we eliminate that threat vector altogether?

How do we get rid of phishing? Because it's the number one vector, alongside passwords getting stored in breached password databases. Those are the real challenges. That's really where passkeys came from. It was the idea of making sure that you as the individual, instead of having a shared secret, have a private key that you have control over. You use that private key to authenticate to the service that has the corresponding public key in a manner that cannot be intercepted.

It cannot be faked, the math cannot be broken, etc. I, as the user, have a private key stored either on my phone, on a hardware key that I carry around with me, or within a service that is my service that I control, like my password manager. And that's really what it boils down to: it's a really simple way of ensuring that I can authenticate using a secured device that I have access to.

Jen: Right. A lot of our listeners are small and medium businesses—either SMB leaders or the IT folks that support them. If they're looking at this from that perspective, and there are different versions of passkeys that they might consider, is there something that is maybe more supportive of what SMEs are trying to do than others? Or do they all have advantages and disadvantages that they might want to consider?

Nishant: I think the biggest advantage of it is actually that, in many cases, it's ideal for SMEs who are dealing with outsourced technology. Because they're working with technology providers in the SaaS space, etc., they don't have a lot of systems in-house; they're working with commodity systems. So they're not dealing with—if I go back to that idea of the PIV card—SMEs are not going to be purchasing and deploying PIV cards. They want to work with what they have access to, what is directly available, and easy to manage.

So, a solution can be based on what's available. "My employees have smartphones; I want to use that." Or maybe, "I have one system admin who has access to all my major systems, and for that one system admin, I want to get them a security key." And if my technology stack is based on the fact that I have Salesforce, or I have Okta, or I have Amazon underlying these systems, and I've deployed some light federation or single sign-on—how do I work with that? Well, the good thing is, with passkeys, you get uplifted to passwordless very, very easily because all these platforms are building it from the ground up.

If your employees have smartphones, they have access to passkeys because it's built into their devices—whether they have an Apple phone, a Google phone, a Samsung phone, whatever. They already have available credential managers deployed that can manage and store these passkeys for them. They have access to biometrics that provide really strong security and eliminate the need for having to remember a password and stuff like that. So it really does give them an advantage and a step up.

The other piece that often gets forgotten in this context is that passkeys also allow the SMB to right-size it to their risk. The vast majority of use cases and the vast majority of SMEs can take advantage of synced passkeys, which is what you get by default when you're using something like a platform-based credential manager like Apple Passwords or Google Password Manager. Or if you are using a third-party credential manager like 1Password, Dashlane, or Bitwarden , the same approach basically means that your passkey instance is based on a passkey that is tied to something in your control. You don't have to worry about the fact that losing a device means you lose your passkeys.

That is the number one question or misconception that folks have: "What happens if I lose my passkey ?" I know I can write a password down, but I can't write down my private key. So what happens if I lose my device? Well, synced passkeys set out to solve that exact problem. In the vast majority of cases, you can use synced passkeys because you have these really secure devices in your hand called your mobile smartphone.

Going back to the example I gave earlier, for your IT admin who is really like the root user or the root admin for your high-sensitivity accounts, there you can use what is called a device passkey, which is tied to a specific device and isn't getting synced around like a security key. Or, in a workforce scenario, it could be a workforce credential manager that is deployed on your workforce-managed device, like Okta Verify or the Microsoft Entra ID app and things like that. So it really allows you to right-size things.

Jen: Yeah, right. And a minute ago, the other thing I think is really good for SMEs is what you said about phishing resistance. But when I sometimes talk to some of the organizations that I work with, they'll say, "Why would we change? We already have MFA ." What does passwordless get me that MFA doesn't? Can you speak to that a little bit?

Nishant: Where we went from passwords to MFA eventually has now been outgrown by the new attack vectors. And therefore, you have to go to passwordless because every MFA technique, going back to my original point, relies on shared secrets of some sort. And every shared secret suffers the same vulnerability point: it can be intercepted and replayed by an attacker using a variety of techniques.

Really, what it fundamentally boils down to is that with anything where you have to provide a shared secret to the services that you're interacting with, there is a way for the attacker to get into the middle of that, capture it, replay it, and compromise it. So you really want to go down a path where you're eliminating that modality of authentication entirely.

That's where phishing resistance becomes really important. It's not to say that passkeys are the only way you can achieve phishing resistance, but especially for SMEs, it is the simplest, easiest way, and in many cases, you almost get it out of the box for free.

Jen: Let's talk about FIDO adoption. I think you said that a lot of the platforms are starting to support this just by default. Is the uptake really that good, and where are we seeing gaps still?

Nishant: Every major platform has deployed passkeys at this point as part of their tech stack. So, whether you're on the client side of things where you're talking about what your users have—like I said, all the smartphones now have credential managers available to them, whether natively within the OS by the platforms themselves or as third-party applications that you can download and use across all your devices.

Then, on the deployment side, whether it's SaaS services like Salesforce or various e-commerce sites that consumers are using like Amazon, they're all building in passkey support at this point. Most of them have rolled it out, and they're increasing their reliance on it in many ways. We've even started to see some services basically say they're sunsetting passwords. Microsoft, very famously, basically said they were not only supporting passkeys, but once users adopt them, they give them the option of going in and removing their password altogether. They are basically saying now that there is no password that can be compromised in any way, shape, or form. So that is a very critical thing that is helping drive adoption—all the platforms recognize the value that it brings them from a simplicity perspective, but also from a fraud reduction perspective, and they are actively promoting it to their customer base.

Jen: So in the cases where adoption isn't happening, is it an SMB versus enterprise thing, or is it a legacy application issue? What is actually blocking adoption?

Nishant: It actually falls into two buckets, right? There are definitely cases where the tech stack isn't amenable to passkey adoption. People are still running on legacy architectures or legacy tech stacks that haven't yet been upgraded, or, in many cases, there's a resistance to change, as you pointed out earlier, where people don't want to upgrade because it comes with a whole bunch of change control and change costs. Those are the situations where we're seeing that passkey adoption hasn't quite taken off.

The other bucket is education. People are worried about the user experience and whether their users—whether workforce users or consumer users—will understand what passkeys are and know how to use them. There often tend to be misconceptions around passkeys. We spend a lot of time trying to explain how synced passkeys meet requirements that organizations might have from a security perspective, but especially from a compliance perspective.

And compliance is one of those tricky things because, oftentimes, regulation gets written and doesn't evolve in step with technology. So you run up against really weird language where people are like, "I know that this makes my security better, but it doesn't meet the compliance requirements because of the way the regulation is written. So I can't really afford to change at this time." And that's one of the things that, again, the Alliance tries to tackle: how can we help businesses, but also influence the regulations and make sure that they keep up with the times a little bit. Those tend to be the biggest adoption barriers that I see. Regulation and compliance things tend to be challenging because it's hard to interpret those frameworks, and so people just don't spend the time on them.

Jen: I for sure see that because most of the work that I do is in PCI DSS compliance, and passwords have been a challenging, sticky issue because of just what you said: the standard has not kept up with what's happening in the larger world regarding the best way to do this. What I love is that in version 4.0, it is more supportive of using a known standard or a known good way of doing things. You just need to explain it, your assessor needs to understand it, and then it works. I think that's good because what you're describing has historically been very difficult to assess when it comes to PCI.

Nishant: Regulators also have started to come to understand some of the implications of being too prescriptive in their language, and they are shifting more to an outcomes-based approach. The outcomes-based approach gives a certain degree of freedom and flexibility to organizations to adopt things that meet their specific needs. One can easily see that what's needed in the consumer space is very different from what's needed in the healthcare space, for example. And we shouldn't be applying the same barometer to those sectors in any way, shape, or form.

The other thing that you just reminded me of is that regulation is actually changing now across the globe, where they're actively writing out legacy forms of authentication. In the US, for example, NIST did really great work in basically going down the flexibility route of saying, "Think about it from a risk perspective. Think about it from an outcomes perspective." There are other jurisdictions where they're explicitly writing into the regulation: "You will no longer use SMS OTP, for example." And they're explicitly stating that if you're using it, you are in violation of the regulation. So these things are changing dramatically as we speak.

Jen: I agree. I think anytime you look at any kind of security problem from a position of risk and then outcome, it's going to drive some of the best controls in order to accomplish that. I hope to see more regulations and standards embracing that concept.

You also talked earlier about the account recovery problem. If an organization doesn't properly set up the account recovery path, it can cause some major problems for them. Do you see common mistakes in organizations in their design of a recovery path when they deploy passkeys?

Nishant: Yeah, I think it's mirroring challenges that have existed for a very long time. I've been on the product side selling solutions to customers for a long time, and I saw this over and over again where people are focused, in many cases, on the compliance checkbox—the thing that is written down that they have to comply with—but they aren't looking at the broader security aspect of what they're trying to do. They're not thinking about their attack surface.

The analogy is very easy to visualize: I'm securing my house, and I spend a lot of time and money making my front door really secure with multiple locks, but I spend no time on the windows or the back door. It's basically just a screen door at the back. You don't want that, but that's really the analogy that plays out.

Account recovery actually tends to be one of the weakest links in everybody's security architecture because they don't pay attention to it. It's viewed more as, "How do I let somebody get back in really quickly?" as opposed to a robust security gate. I have a good friend in the industry who phrased it perfectly: account recovery is just another authentication mechanism. So why would you want to offer multiple authentication mechanisms where one is really strong and the other one is really weak? Because the minute you do that, you know exactly where all the attackers are going to go.

It's great to set up passkeys for authentication. But if I can bypass passkey authentication by just going down the account recovery path and saying, "Here's my email address," and all you're doing is sending somebody a link or an OTP, you've essentially given them back the exact attack vector that they were exploiting with passwords. So really paying attention to account recovery flows is vital. Passkeys just make it all the more crucial because you're locking down the main authentication path, which means even more malicious attention is being diverted to your account recovery flows. Making sure those recovery flows are solidified is critical, and it does require a mindset shift.

Account recovery flows are an exception case. And because they are exceptions, it's completely okay to have additional friction and stronger controls there. It makes it a little bit harder to use, but we are doing that from the perspective of keeping attackers out. We want to let the right person in, and we often forget that the legitimate user actually appreciates that the recovery flow is harder because it gives them psychological assurance that their account is protected. Once you start going down the passwordless path, whether using passkeys or otherwise, it really puts an emphasis on account recovery flows being completely locked up and solidified.

Jen: All right. A lot of the organizations that I meet with—and I think this is probably a common challenge out there—are resource-constrained. So let's say we have an organization that is resource-constrained, but they want to deploy passwordless. Is there a reasonable path for them to start?

Nishant: It really does depend on the architecture of the tech stack that they have. As I mentioned, if they're already in a SaaS environment or utilizing an identity platform—some sort of modern identity and authentication platform—almost all of them have support for passwordless solutions at this point. All of them have support for passkeys right now.

And the tech stack for passkeys is, as I mentioned, everything you already have. It's built into the mobile operating systems and it's built into the browsers, so it doesn't really matter what browser you're using —Chrome, Firefox, etc., they all support passkeys and all the major identity platforms support it. The tech stack you need is already there, and it's really a matter of going into your authentication platform configuration and turning on the passkeys option.

But turning on passkeys is not simply flipping a switch; you do need to do it with care. One of the major emphasis points within the FIDO Alliance, specifically as part of our UX working group and our deployment working groups, is: how do you prepare your users, whether they're customers or workforce users? How do you prepare them for the transition? What is the communication strategy in terms of educating them on passkeys and what the user experience will look like? You want to take the time to map out and design that path. Modern authentication platforms provide a lot of options and templates to help define that, so you do want to spend the time to chart it out properly.

The great thing is that the investment from an SMB perspective really is just a little bit of planning and time. The underlying tech stack is actually already there, so it's not a matter of procuring massive new infrastructure. Unless you're on a very old, legacy architecture stack, it's already sitting there waiting for you to take advantage of, and you can roll it out pretty quickly and simply.

Jen: In a lot of cases, what I'm hearing is that platform passkeys are a great idea, and they're often more than enough. But you also mentioned dedicated hardware. When do you think it makes sense to have individuals or organizations use a dedicated hardware approach?

Nishant: Dedicated hardware keys are sort of the gold standard in the passkey ecosystem, in the sense that they are the most secure deployment model you can roll out. Because of that, you want to deploy them thoughtfully for the most at-risk individuals within your ecosystem. If you're talking about the workforce side, it might be your root admins or the users who have highly privileged access. In a healthcare environment, it might be the person who is deploying, installing, and managing your core database systems. Those are the users you want to deploy physical hardware keys for.

The other angle is that hardware keys are fantastic as a backup option. Going back to the account recovery conversation: synced passkeys live on your mobile device. They go with you wherever you go, so you have them accessible at all times. But from an account recovery perspective, it's an excellent practice to back up your authentication options by having a hardware key attached to the account as well. That way, if for whatever reason you are completely locked out of your primary credential manager, you still have a physical hardware key sitting in a vault that you can use to get back in. It's a highly resilient approach from that perspective.

Jen: I think another angle to look at this is what's driving adoption. Risk, of course, drives it. But we see CISA putting out explicit guidance on phishing-resistant MFA. We're also seeing cyber insurance checklists evolve; where the question used to be, "Do you have MFA?", they're now asking, "Do you have phishing-resistant MFA?" It feels like there are real-world commercial pressures driving everyone toward passwordless. Is that what you're seeing as well?

Nishant: Yes, absolutely. As you pointed out, these are being recognized at this point as required controls. Everyone sees that on the attack side, a lot of the standard malicious toolkits are automated and scaling rapidly. The biggest change in the threat landscape has always been scale, and now it is incredibly easy for attackers to scale their operations.

It's easy to focus solely on the risk reduction and the fraud benefits, which are obviously massive. The drop in fraud losses when moving to passwordless is highly significant. If you look at the Verizon Data Breach Investigations Report or any other industry data, phishing and credential breaches remain the number one attack vector by a wide margin.

But beyond security, there is a massive bottom-line cost benefit. There are actual hard financial benefits you drive by going to passkeys because you are leveraging commodity hardware that your users already own. Think about how much capital an organization spends just supporting password resets. The cost of executing manual password resets is significant. By transitioning to a model where there is no password to forget, account recovery is vastly simplified or completely eliminated in day-to-day operations.

Think about the sheer reduction in customer support needs, internal helpdesk tickets, and workforce support requirements. These metrics have been proven out in real-world deployments. The drop in account recovery requests is massive, which frees up your technical personnel to actually focus on growth and core operations. There are clear cost-saving benefits that directly help your company's bottom line.

Jen: Sure. That's huge. As someone who started off working on the helpdesk back in the day, the sheer volume of password reset requests that come through is something you feel in your gut. You just sit there thinking, "Can I please just have one day where I don't have to reset passwords?"

For the people running SMBs who are listening—who might not be strictly forced into this yet by regulation or insurance, but understand the value and want to take a step forward despite being strapped for time or money —what is one immediate thing they can do this week to move toward passwordless?

Nishant: I think the best place to start is to look at the primary authentication platform you are already leveraging and see what it takes to turn passkeys on. For example, at a previous startup I was with, our entire enterprise footprint was built on top of Google Workspace. Going into the admin console, enabling passkeys within Google Workspace, and encouraging your employees to link a passkey to their primary email account is an incredibly seamless transition. Because that identity provider is linked to all the other services you use, you get an immediate security uplift.

Take an inventory of your most commonly used apps and services, figure out what it takes to turn passkeys on, make it available, and then start doing some simple, clear outreach to your workforce to begin rolling it out. If you're an SMB that runs an e-commerce site or a customer-facing platform, enabling passkeys should be evaluated as part of the core application platform you've built on top of anyway. It becomes a very smooth, front-facing end-user experience for customer sign-ups.

Jen: This has been incredibly helpful in terms of demystifying what exactly we are talking about, and it takes away a lot of the deployment fear because the knowledge is there. Is there anything else you would like to leave our audience with before we wrap up today?

Nishant: One of the final things to remember is that your end users genuinely benefit from passkeys because it is fundamentally simpler for them. Managing passwords is a massive, universal mess that we all suffer through in our daily lives. Anything you do to alleviate that pain—giving them the ability to sign in across all their devices seamlessly and significantly faster—is a massive win. Passkey authentication is objectively faster than all other legacy forms of authentication.

By switching to passkeys, you aren't just hardening your security posture; it's one of the very rare instances in tech where greater security directly equals greater convenience and a far superior user experience. That is the ultimate takeaway I would highlight for your audience.

Jen: Absolutely. Thank you so much for coming on and sharing your expertise with us today. I really appreciate it.

Nishant: Thank you, I appreciate it.

Get the Guide To PCI Compliance
Download
Get a Quote for Data Security
Request a Quote