What is passwordless authentication?

Passwords are perhaps the most common method of user authentication. They are also the weakest. Passwords can be stolen through phishing attacks and infostealer malware, guessed through brute force attacks or purchased off the dark web, where hackers sell them for a few dollars apiece.

Armed with stolen credentials, threat actors can take over legitimate accounts, abuse their valid privileges and evade detection—because their activity looks like an authorized user’s. According to the IBM X-Force Threat Intelligence Index 2025, valid account theft is one of the most common initial access vectors, present in 32% of the cyberattacks that X-Force analyzed. 

Other knowledge factors—that is, any authentication factor that relies on a secret the user knows—suffer from the same weaknesses. The answers to common security questions, such as a first pet’s or childhood best friend’s name, can be easily uncovered through social engineering or simple social media snooping.

While “password” is in the name, passwordless authentication does away with all knowledge factors, including security questions. Passwordless methods replace these knowledge factors with hardware tokens, cryptographic passkeys, fingerprints, facial scans, authenticator apps and more. 

These passwordless authentication factors are considered much more secure than knowledge factors. They cannot be easily stolen or forged, rendering them resistant to some of the most pervasive cyberthreats today. For example, cybercriminals cannot steal a passkey through a phishing link, nor can they create fake fingerprints without highly sophisticated technology.

Passwordless authentication works by replacing knowledge factors in the authentication process with non-knowledge-based alternatives. So instead of asking for a password, a passwordless login process might ask a user to click a magic link or tap a push notification.

To fully understand the logic of passwordless authentication, it can help to first break down how authentication works in general.

In a typical authentication process, users prove their identity by offering evidence that they are who they claim to be. This evidence is called an “authentication factor,” and it usually falls into one of four categories:

• Knowledge factors: Something the user knows, such as a password or the answer to a security question. 

• Possession factors: Something the user has, such as a one-time password generated by a personal smartphone or a private cryptographic key. 

• Inherence factors: Something the user is, typically meaning biometrics such as fingerprint, face and retina scans.

• Behavioral factors: Something the user does, such as unique typing patterns or mouse gestures.

Passwordless authentication solutions use only possession, inherence and behavioral factors. More specifically, common password alternatives include:

Passkeys are based on public key cryptography, typically implemented according to a set of standards known as FIDO or FIDO2. 

Passkeys work by generating a cryptographic key pair: a public key shared with whatever service the user is signing up for, and a private key kept on the user’s device, such as their personal smartphone. The private key is never shared with the service. Furthermore, the private key is locked behind a PIN or biometric challenge. 

(The FIDO standard also supports hardware security keys. For more information, see “Hardware tokens.”)

With a passkey, the authentication flow works like this: 

1. The service sends a challenge to the user’s device. 
   
   
2. The user unlocks their private key and uses it to sign the challenge. 
   
   
3. The challenge is sent back to the service, which uses its public key to verify that the challenge was signed by the appropriate private key. 
   
   
4. The user is granted access.

Passkeys are considered much more secure than passwords for several reasons. The private key never leaves the user’s device, so it cannot be intercepted. If an attacker does steal the device containing the private key, they still need to enter a PIN or pass a biometric challenge to use the key.

As Jeff Crume, IBM master inventor and distinguished engineer, said on an episode of the IBM Security Intelligence podcast: 

The number-one vector for breaches [in the 2025 IBM Cost of a Data Breach Report] is phishing. And phishing, what are they after? They’re after your credentials. Well, guess what? If you don’t have a password, nobody can steal it from you. If you have a passkey, then it’s much more difficult.

Biometric authentication relies on a user’s physical characteristics. Retina scans, facial recognition technology and fingerprint scanning are some of the most common forms of biometrics.

Biometric factors are considered secure because they cannot be stolen or forged with ease. They’re also considered user-friendly because users don’t need to do anything special to enter biometric credentials—just look at a camera or press their thumb to a screen.

The downside is that, while it’s exceedingly rare, biometrics can be stolen. In 2024, for example, hackers stole facial recognition data from an Australian firm called Outabox. And when biometrics are stolen, they can’t be reset like a password. One can’t change their fingerprints or retina patterns.  

As the name suggests, one-time passwords (OTPs) are single-use passwords, usually valid for only a brief period, that replace standing credentials. Anytime a user needs to log in to a service, they generate a new OTP. 

OTPs can be generated in multiple ways. The most common methods include:

• Using a hardware security key to generate OTPs at the press of a button.
  
  
• Using a smartphone-based authenticator app, which continuously creates short-lived time-based OTPs (TOTPs) for paired services. 
  
  
• Using SMS text messages to receive OTPs from an authentication service. 

OTPs are not considered knowledge factors because they are not long-lived secrets. OTPs are possession factors. It’s not knowledge of the OTP that verifies a person, but possession of the registered authenticator app, phone number or security key that generated the OTP.

OTPs generally expire after one use or a set period of time, limiting their value if they’re stolen or intercepted. But they can be stolen through certain crafty measures, such as infostealers or man-in-the-middle (MitM) attacks.

Also called security keys, hardware tokens are dedicated devices—often in the form of USB dongles—that contain or generate authentication information.

Some hardware tokens use OTPs. They either create new OTPs regularly, like an authenticator app, or generate OTPs on demand when the user presses a button. Other tokens automatically transmit authentication information to a service when plugged into a device.

Hardware tokens are considered strong because they’re often not connected to the internet at all, and a person must physically possess the token to use it. 

That said, security keys can be lost or stolen. It can be expensive—and logistically prohibitive—to issue a key to every employee or user of a service. 

Magic links are special links that contain authentication tokens.

First, the user registers their email account or phone number with a service. Then, when they want to log in, they request a magic link. The service sends the link to the registered email or mobile device. When the user clicks it, they’re taken to the service they want to access, fully authenticated and logged in.

Magic links are a kind of possession factor, but it’s not possession of the link itself that proves the user’s identity. Rather, it is possession of the previously registered email account or phone number. 

Like OTPs, magic links stay valid for only a short period, and they automatically expire after one use. 

However, if an attacker does gain access to a user’s email inbox or phone number, magic links can be easily abused. The attacker simply has to navigate to the service they want to crack, request a link and they’re in. 

Functioning somewhat like magic links, this method sends push notifications to a user’s previously registered mobile device when they try to log in to a service. The user must tap “approve” (or some equivalent) on the push notification to gain access.

Push notifications are another possession factor. The act of tapping confirms that the user possesses the registered device, verifying their identity.

Push notifications are convenient and largely secure, but they are susceptible to attacks known as “push notification floods” (also called “MFA fatigue,” “MFA bombing,” or “prompt spamming”). 

In this attack, a threat actor navigates to the service they want to breach, enters their target’s user ID and repeatedly requests authentication by push notification. The sudden flood of notifications to the target’s device is meant to overwhelm, such that the victim approves one by accident or simply to make it stop. With that approval, the hacker can get into the user’s account.

QR-based logins display a QR code. The user scans the code—typically with an authenticator app or an app specific to the service that they’re accessing—and this logs them in. 

The basic mechanism here is a session transfer. For example, say that a user wants to log in to a website on their laptop by using a QR code: 

1. The website presents the user with a QR code. This code contains a short-lived token representing the pending, unauthenticated session.
   
   
2. The user scans this code with their previously registered and authenticated mobile device.
   
   
3. The mobile device approves the session.
   
   
4. The web server links the approved session to the user’s identity, and the user gains access to the service on their laptop.

Even if an attacker obtains the QR code, they can’t do much without the user’s preauthenticated device. That said, an attacker can hypothetically hijack the user’s phone session and break into an account that way. 

QR-based authentication is also susceptible to quishing, also known as QR phishing or QR jacking. Attackers present victims with fake QR codes that, when scanned, approve attacker-controlled sessions instead of legitimate ones.

Behavioral factors are digital artifacts that verify a user’s identity based on behavioral patterns, such as the user’s typical IP address range, location and average typing speed. 

These factors are rarely used as sufficient proof of identity on their own. They’re more commonly part of a risk-based authentication scheme that continuously assesses a user’s security posture to dynamically determine authentication requirements based on risk level. 

For example, a user logging in from their normal device at their normal time might need to supply only one authentication factor. That same user logging in from a new device or a strange location might need to supply an additional factor. 

Driven largely by the rise of cloud services, artificial intelligence and machine learning, the number of nonhuman identities (NHIs) active in the average corporate network has increased dramatically in recent years. And as AI agents enable increasingly sophisticated automations, managing NHIs’ permissions and securing their credentials become core concerns for cybersecurity teams. 

Nonhuman accounts can be hijacked just like a human’s. They often have elevated privileges (think of a backup process that can read the most sensitive enterprise databases) and rely on a single credential for authentication, making them attractive and potentially weak targets.

While NHIs don’t use passwords the same way humans do, they often rely on certificates and tokens that can be stolen, forged or cracked much like passwords can.

Passwordless authentication for human users is about removing long-term credentials that are easily stolen or faked. Organizations can get similar benefits for NHIs by using a combination of just-in-time access and credential vaulting, as seen in the security lifecycle management process. 

Security lifecycle management automates the creation, rotation and secure storage of NHI credentials, replacing persistent, hardcoded secrets with ephemeral or just-in-time credentials stored in a central, secure vault. Vaults are, in turn, protected by encryption and strong authentication measures to help ensure that only authorized users can access these credentials when needed.

Jake Lundberg, field CTO for HashiCorp, outlined a vision for hyper ephemeral NHI credentials on an episode of Security Intelligence:

The best case scenario is that you’re moving to session-based credentials. When my session is stood up, I have a just-in-time credential. And as soon as the session is torn down, then I actually get rid of those credentials. So when my session is over, even if it only lasted for five minutes, we remove those credentials from those systems.

Workload identity specifications such as SPIFFE/SPIRE can tie NHI identities to cryptographically verifiable runtime attributes. These frameworks make it possible to verify a workload based on where and how it’s running, allowing NHIs to authenticate without using passwords or API keys.

Passwordless logins can be implemented as either single-factor authentication (requiring one non-knowledge factor) or multifactor authentication (MFA) (requiring two or more non-knowledge factors). Passwordless MFA implementations are considered more secure than standard MFA or two-factor authentication (2FA), which usually use a password as the first factor. 

(An MFA implementation asking for both a password and some other non-knowledge factor is not passwordless because it still involves a password. All the factors involved need to be non-knowledge factors for a truly passwordless login.)

Not every app natively supports fully passwordless options. To implement passwordless authentication across the entire enterprise network, organizations often use identity orchestration platforms. These tools connect and coordinate disparate identity and access management (IAM) systems from multiple identity providers into a holistic identity fabric with a single, frictionless identity workflow. Identity orchestration is the technology behind many single sign-on (SSO) systems.

Essentially, identity orchestration works by routing login requests for individual services through a centralized process instead, and many identity orchestration platforms support a passwordless centralized authentication process. Thus, the entire enterprise can be passwordless, even if individuals apps and services in the tech stack don’t support it.

Password-based authentication has long been the default method of verifying user identities. Unfortunately, it is also the least secure. Passwordless methods can remove one of the weakest links in modern networks, closing a widely exploited gap in the enterprise attack surface.

Passwords are easily stolen through social engineering attacks such as phishing and malware such as spyware and infostealers. They’re particularly vulnerable to help desk attacks, social engineering scams where malicious actors call a help desk pretending to be a user or employee in need of a password reset. These attacks are becoming more common because they are so devastatingly effective. As Stephanie Carruthers, former chief people hacker of IBM X-Force, once said:

We do social engineering campaigns for our clients where the objective is to call their help desk and see if we can impersonate an employee to reset their password. To date, we have been successful every single time we’ve done that.

People often use weak passwords that attackers can crack through brute-force and dictionary attacks—that is, trying common passwords until one works. People also reuse passwords across multiple services, enabling credential stuffing. When attackers have a password for one service, they can try it for a bunch of other ones, too. 

Even when people follow best password practices—using a different, hard-to-guess password for every service—they run into problems. Given how many accounts people have, it’s easy to forget these passwords. In the case of NHI credentials, such as API keys, they might be left hardcoded into apps or unprotected as plain text in shared drives.

Password management tools arose to solve these password hygiene challenges, but they have their own peculiar vulnerabilities. Namely: Most password managers are protected by master passwords, which can themselves be stolen. So, yes, hackers can steal saved passwords with the right maneuvers.

The proliferation of NHIs has also played a role in making passwordless authentication a priority.

Apps, system processes and other nonhuman users don’t have classic passwords, but they do use OAuth tokens, API keys, certificates and other secrets to authenticate themselves. AI agents—which straddle the line between traditionally human and nonhuman capabilities—might even “borrow” their human users’ credentials to run automated tasks. All of these secrets can be stolen and misused much the same way passwords can.

Traditional IAM systems were not designed for NHI secrets management, creating an identity security gap. 

Identity and security pros have recognized these pressures for quite some time. But passwordless approaches are now gaining steam because technology is finally catching up. Smartphones make it feasible for everyday users to adopt biometrics and time-based one-time passwords. The development of FIDO standards and the underlying WebAuthn and CTAP2 protocols has made passkey-based authentication widely available to websites and web apps. And new security lifecycle management tools enable organizations to automate credential creation, rotation, storage and access management for NHIs.

Passwordless authentication is widely considered to be more secure and more convenient than password-based approaches. The cons are largely related to the potential complexity and expense of going passworldess in the first place.

Despite all these pros, passwordless authentication does have its disadvantages, including complex implementations, difficulty resetting lost or stolen credentials and the unique cyberattacks that passwordless logins are susceptible to.