Last updated on September 2, 2025
Cybersecurity is incomplete without Multi-Factor Authentication (MFA). MFA is the gold standard for protecting user identities. It strengthens login security by requiring two or more types of proof: something you know (like a password), something you have (like a phone), and something you are (like a fingerprint). In this article, we explore and compare popular MFA and 2FA methods, from basic SMS codes to phishing-resistant passkeys, so you can choose the best fit for your business or personal use. Whether you’re an IT admin or just MFA-curious, this article will help you navigate the evolving world of authentication technologies.
Here is a list of the most common MFA methods:
- SMS One-Time Passcodes (OTP) – A unique numeric code is sent via SMS to the user’s mobile device, valid for one specific login attempt; entering the code during login verifies the user’s identity.
- Authenticator App TOTP Codes – A time-based code is generated in an authenticator app on the user’s device, synced with the server, and refreshed every 30 seconds; entering the code during login verifies the user’s identity.
- Hardware OTP tokens – Physical devices like keyfobs or smartcards that generate OTP codes on a built-in screen or send them via USB; entering the code during login verifies the user’s identity.
- Magic links / Email or SMS links – A single-use login link is sent via email or SMS; clicking it verifies the user’s identity.
- Push notifications – A push message is sent to the user’s trusted mobile device, allowing them to approve or deny the login with one tap.
- Phone Call – The system calls the user’s registered phone number, and authentication succeeds if they answer or follow the prompt, such as pressing a key to confirm.
- QR code–based authentication – A QR code is scanned with a trusted mobile device to confirm login.
- YubiKey OTP – A physical YubiKey device generates a unique one-time password upon touch and transmits it directly to the system for authentication, ensuring fast and tamper-resistant login.
- FIDO U2F / FIDO2 Security Keys – Physical devices that the user plugs into a USB port or taps against an NFC reader to perform phishing-resistant authentication.
- Passkeys (FIDO2 passwordless) – A secure, passwordless sign-in method based on device-bound credentials like biometrics or PIN.
- Biometrics – Fingerprint, face, or iris scans are used to unlock a trusted device that holds the authentication credentials.
- Smart cards / PKI – Cards containing certificates and private keys used with a reader and PIN to verify the user’s identity.
- Backup codes – A static list of pre-generated codes that can be used to access the account when other methods are unavailable.
Want to deploy one of these methods? Start with Rublon MFA – free for 30 days →
What Is an Authentication Method?
Authentication Method is a form of verification that helps a security system decide if the person who tries to log in is who they claim to be.
During authentication, a security system uses one or more authentication methods to try to prove the user’s identity.
A password is also a type of authentication method. However, passwords are not very secure. Always use passwords together with at least one other method of authentication. We already said a lot about the security of passwords and why you should enable MFA. Let’s focus on more secure authentication methods.
MFA & 2FA Authentication Methods
SMS One-Time Passcodes (OTP via SMS)
SMS Passcode is one of the oldest and most widely used MFA methods. During login, the user receives a one-time numeric code by text message and enters it to complete authentication. SMS code is an out-of-band (OOB) method delivered over the public switched telephone network (PSTN).

Use Cases:
- Consumer-facing services that rely on users’ mobile phones for verification, especially online banking and other financial or retail applications.
- As a backup or “last resort” MFA method in organizations, when users cannot use more secure options (for example, if a user has no smartphone or internet access).
Advantages:
- No need to install any additional app; it works on any mobile phone capable of receiving text messages.
- Very simple to use, even for less tech-savvy users.
Disadvantages:
- Vulnerable to interception by attackers (through malicious SMS forwarding or exploiting weaknesses in phone networks like the SS7 protocol).
- Susceptible to SIM swap attacks, where an attacker fraudulently transfers the victim’s phone number to their own SIM card to receive your codes.
- Not phishing-resistant. Attackers can trick users into revealing SMS codes on fraudulent websites or via social engineering.
Recommendations:
- SMS 2FA should be used only if no stronger method is available. It is better suited as a fallback option rather than a primary MFA method.
- Organizations should plan to phase out SMS codes in favor of more secure, phishing-resistant methods whenever possible.
- NIST Special Publication SP 800-63B Digital Identity Guidelines: Authentication and Authenticator Management discourages using SMS OTPs and talks about risk indicators like device swap, SIM change, and number porting that need to be taken into account before using this type of authentication.
Authenticator App TOTP Codes
The user has an authenticator app on their smartphone (e.g., Google Authenticator, Microsoft Authenticator, Rublon Authenticator) or desktop (WinAuth, OTPClient) that generates a one-time code every 30 seconds. These codes are typically 6 digits and are based on the Time-Based One-Time Password (TOTP) standard defined in RFC 6238. During login, the user opens the app, reads the current code, and enters it in the login prompt to authenticate. This type of Passcode is one of the most common MFA methods.

Use Cases:
- Consumer websites and online services that offer two-factor authentication via authenticator apps.
- Enterprise systems (VPNs, internal applications, remote access gateways) where TOTP codes are commonly used as the second factor for employee logins.
Advantages:
- After initial setup, it works without internet connectivity (codes are generated offline).
- Some authenticator apps allow an extra layer of protection, such as requiring fingerprint or PIN entry to open the app or reveal the code, adding security in case the phone is lost or left unattended.
Disadvantages:
- Requires the user to install an application on their phone or computer.
- Not phishing-resistant. Attackers can trick users into entering the code on a fraudulent website, which they can then immediately use to access the real site.
- Not very convenient. The user must manually open the app and transcribe the code, which adds friction and time to the login process.
Recommendations:
- TOTP authenticator apps are still recommended for many scenarios as they offer a good balance of security and usability, and are more secure than just the password.
- TOTPs are vulnerable to phishing, so it is wise to protect critical applications with phishing-resistant methods like FIDO2 security keys when possible.
- Educate users about the risk of entering codes into unknown or suspicious pages, and encourage the use of app-protected PIN/fingerprint features for additional security.
Hardware OTP Tokens
A hardware OTP token is a standalone physical device (often a small key fob) that generates one-time passcodes and displays them on a screen. The user reads the code from the device and types it in as the second authentication factor. Depending on the model, hardware OTP tokens can generate TOTP (RFC 6238) or HOTP (RFC 4226) codes. For example:
- The RSA SecurID SID800 token displays a new code every 30 or 60 seconds.
- The Feitian c100 token displays a new code on every button press.
Use Cases:
- Legacy and high-security environments, such as banking and enterprise systems (before the security key and smartphone authenticator app era).
- An alternative for users who cannot or do not want to use a personal smartphone for MFA. For instance, some organizations still offer hardware tokens to employees who do not have company phones or are uncomfortable using personal devices for work authentication.
Advantages:
- Completely independent of phones and network connectivity. The token works offline anywhere, anytime.
Disadvantages:
- Additional cost for each token device, plus ongoing costs for battery replacements and device replacement over time.
- Requires provisioning and management. Tokens need to be distributed to users, tracked, and eventually revoked or replaced. Administering a fleet of hardware tokens (especially across many departments) is logistically challenging.
- Less convenient for users; another object to carry and keep safe. Tokens can be lost, forgotten at home, or left in a desk drawer and not available when needed.
- Functionally similar to app-based OTP codes but without the multi-purpose convenience of a smartphone. For example, a user will always carry their phone anyway, whereas a separate token is easier to misplace.
- Not phishing-resistant. Just like app codes, a user could be tricked into entering the displayed code into a fraudulent website, allowing an attacker to immediately use that code on the real site.
Recommendations:
- Hardware OTP tokens are falling out of favor in many organizations due to cost and convenience issues, with mobile apps and FIDO2 security keys largely replacing them.
- If your organization still relies on hardware tokens, evaluate a transition to mobile authenticators or modern security keys for a better user experience and improved security.
- In scenarios where hardware tokens are necessary (e.g., no phone policy environments), ensure there are clear procedures for the timely replacement of lost tokens.
- Educate users about phishing risks. For a more secure hardware-based option, consider phishing-resistant devices like FIDO2 security keys, which do not rely on manual code entry at all.
Magic Links Sent via Email and SMS
The user receives a one-use link sent to their registered email address or phone via text message. Then, they click the link to verify their identity. This method relies on the security of the user’s email account or SMS as the second factor. SMS Link and Email Link methods are convenient but come with security trade-offs that organizations should carefully evaluate before deployment.

Use Cases:
- Legacy systems and consumer websites that have not implemented dedicated MFA apps or more modern solutions, but can at least send a Magic Link to the user’s email or SIM card.
- Fallback and account recovery scenarios, such as when a user loses their phone and needs an alternate way to receive a second factor.
Advantages:
- No extra app or device needed beyond access to the email account or SIM card.
- Universally accessible: virtually everyone has an email address and a SIM card, making it a broadly available option.
Disadvantages:
- The security of this method is only as strong as the security of the email account or SMS. In many cases, the email address is also the one linked to password recovery. If an attacker gains access to the email, they can intercept these Magic Links and also reset other passwords, effectively undermining the entire MFA.
- Emails can be delayed or fail to send. Messages might land in spam folders or experience latency, frustrating users or locking them out if the code arrives too late.
- Links sent in a text message share the vulnerabilities of OTP via SMS.
Recommendations:
- Email-based MFA (and SMS-based MFA) is better than nothing, but it is one of the weaker methods.
- It should primarily be used as a backup or temporary method (for example, while transitioning to a more secure MFA system).
- If you enable Magic Links via email, make sure the email account itself is protected with MFA and a strong, unique password, since it becomes a critical point of failure.
- Always encourage users to use stronger MFA methods if available.
- Educate users to be cautious about unexpected emails requesting codes or logins, as those could be phishing attempts
Push Notifications
The user receives a push notification on their phone (called Mobile Push) and can approve the login with a single tap. The notification typically includes details of the login attempt (e.g., location, requesting app, and timestamp) so the user can verify its legitimacy.
Some implementations also support number matching, where the login screen displays a number that the user must enter on their phone to confirm they are approving the correct request. This ensures the user is actively verifying the specific login attempt and helps prevent accidental and malicious approvals.

Use Cases:
- Corporate MFA solutions and modern online services where user convenience is important.
- Single Sign-On (SSO) scenarios, where logins prompt a push notification on the user’s phone instead of requiring a code, streamlining the authentication for the user.
Advantages:
- No need to type in a passcode from one device to another.
- Fast and user-friendly. Typically, just “tap to approve” to complete login.
- Provides contextual information for the login attempt (who, where, and when), helping users spot unauthorized access attempts in real time.
- If using number matching or similar confirmation steps, it mitigates “push bombing” attacks because the user must consciously verify the login with the given code, making it much harder for an attacker to get an approval through sheer repetition.
- Depending on the implementation, the authenticator app may enforce a biometric or PIN lock before viewing/approving the push notification.
Disadvantages:
- If number matching is not enabled, attackers may overwhelm users with repeated fake login requests (a technique known as push fatigue or push bombing) so that the user will eventually accept one out of frustration or confusion.
- Requires the user’s mobile device to have an active internet connection (Wi-Fi or cellular data) to receive notifications.
Recommendations:
- Push notification MFA offers an excellent balance between security and convenience and is generally recommended over other non-phishing-resistant MFA methods.
- To maximize security, organizations should enable features like number matching and require biometric confirmation in the authenticator app.
- Educate users to never approve an unexpected login request. If they receive a surprise prompt, they should deny it and report the fact to the security department.
- For highly sensitive systems that demand the utmost security, consider migrating to fully phishing-resistant methods (like FIDO2 security keys).
Hardware FIDO U2F & FIDO2 Security Keys
Hardware security keys are small physical devices (USB keys or NFC/Bluetooth dongles) that store cryptographic secrets and utilize protocols like FIDO U2F and FIDO2 to provide a second MFA factor or passwordless authentication.
To authenticate, the user connects the key to their device (by inserting it into a USB port or tapping it on the device’s NFC reader) and then touches the key to confirm. Some security keys also support user verification, requiring a PIN or fingerprint on the key itself.

Use Cases:
- Protecting privileged and administrator accounts, where the highest level of security is warranted.
- Organizations with very high security requirements (such as government agencies, defense, finance, and tech companies) are deploying keys to employees to secure access to sensitive systems.
- Securing access to cloud services and identity providers. For example, using security keys with Microsoft Entra ID (Azure AD), Google Workspace, GitHub, and other services that support FIDO2/WebAuthn authentication.
Advantages:
- Phishing resistance. Security keys will only complete the login if the real, correct website (domain) is requesting authentication. This origin binding mechanism means that even if a user is tricked into visiting a lookalike fraudulent website and starts authentication, the key will not work.
- Very fast and convenient for users. In many cases, login is as simple as plugging in the key and touching it, with no codes to read or type.
- Nothing sensitive for an attacker to intercept. Unlike OTPs and SMS codes, no credentials are passed over the network; all verification is done through public-key cryptography.
- Extremely secure. The private keys used for authentication never leave the device and cannot be extracted, cloned, or phished. Also, security keys are durable and do not rely on batteries.
- One security key can be used across many different services (as long as those services support the standard), reducing the need for multiple devices. For example, a single key could secure your email, cloud accounts, password manager, and so on.
Disadvantages:
- Cost. Each user needs at least one key (ideally two, including a backup key). This can be a significant upfront investment.
- Distribution and management. You have to physically distribute the keys. Deploying them to remote workers can involve shipping, and you will need a process for replacing lost or stolen keys. Keeping an inventory of assigned keys and backups is important.
- If a key is lost or stolen and it is not protected by a PIN or biometric, someone who gains possession of it can use it to authenticate (though they would still need the user’s login name and password). This risk is mitigated by the fact that the key alone is usually not enough to gain access without the account’s other credentials.
- User resistance. Some users find the process unfamiliar at first (it is a new piece of hardware to carry and use), so user education is needed to ensure they understand and adopt the technology.
Recommendations:
- For any account or system where security is paramount, physical FIDO2 keys are the gold standard and should be strongly considered.
- Start by rolling them out to your most sensitive user groups (administrators, executives, developers with access to production systems, etc.).
- Always issue at least two keys per user (one primary and one backup key) to avoid lockouts if a key is lost, and instruct users to keep their spare key in a safe place.
- Have a clear process for replacing keys and revoking lost ones.
- While the cost is higher upfront, the security payoff is substantial. FIDO keys help drastically reduce account takeovers due to phishing and credential theft.
Biometrics
Biometric MFA methods leverage the user’s unique physical or behavioral traits to verify identity. This includes technologies like fingerprint scanning, facial recognition, iris or retina scanning, voice recognition, or even behavioral biometrics like keystroke dynamics.
Biometrics like fingerprints and facial recognition are often used to unlock authenticators embedded in personal devices. For example, Windows Hello’s passwordless authentication allows users to authenticate using a fingerprint sensor, unlocking a passkey stored securely on the device. This passkey is then used to complete a phishing-resistant login without ever typing a password.
Use Cases:
- Consumer electronics: smartphones, tablets, and laptops use fingerprints or facial recognition to unlock devices and authenticate app access (e.g., Apple Touch ID and Face ID, Android fingerprint sensors).
- Corporate and government security: biometric scanners for physical building access (fingerprint readers, facial scanners) and for computer login in high-security environments.
- Passwordless authentication solutions. For example, macOS allows users to log in to websites and apps using passkeys stored in iCloud Keychain. Authentication is performed via Touch ID or device PIN, without ever typing a password. This method uses public key cryptography and is resistant to phishing, replay, and credential theft.
Advantages:
- Convenience. Extremely fast and easy for users: no passwords to remember, no codes to type. You always “have” your biometrics with you, and authentication is as simple as a touch or glance.
- It cannot be forgotten or left behind, unlike a password or security key.
- Biometric data on modern systems is usually stored and matched locally (in a secure enclave/TPM on the device), meaning the actual fingerprint or face data is not sent over the network. This avoids creating a central repository of biometric info and reduces the risk of a mass compromise of that data.
Disadvantages:
- Biometrics are not secret. Fingerprints, faces, and voices can be copied or faked with sufficient effort and technology. For example, lifting fingerprints from a surface or using a high-resolution photo or a deepfake to spoof facial or voice recognition. Advanced biometric systems have liveness checks and anti-spoofing, but cheaper or older solutions can be tricked.
- Some users have privacy concerns with providing biometric data. They may fear misuse of their fingerprints or face scans, even if the system is designed to protect that data.
- Typically platform-specific. A fingerprint registered on a phone or laptop is only used on that device. There is no universal biometric database across all your services. This is good for security, but it also means biometrics have to be paired with other methods for cross-platform access, or used to unlock some stored credential on the device rather than directly with a website.
Recommendations:
- Use biometrics to enhance user experience and security on personal devices, but not as a completely separate and standalone authentication factor.
- Biometrics are best used to unlock a device or a local credential (like a private key or an encrypted token), which then authenticates with the server. For example, a fingerprint can unlock a FIDO2 passkey on a device.
- Organizations implementing biometrics should do so in compliance with privacy laws (like GDPR); this usually means biometric use should be optional and data should remain on the user’s device.
- Always provide an alternative method for those who opt out of biometrics.
- Because biometrics can be spoofed in rare cases, it is wise to combine them with another factor.
Phone Call
Phone call authentication uses the public telephone network to confirm a login. During authentication, an automated system calls the user’s registered phone number. The system either reads out a one-time code for the user to type into the login form or requests that the user press a specific key (for example, “Press 1 to approve”). Because this verification travels over a different channel from the login itself, Phone Call MFA is an example of out-of-band authentication (OOBA).

Use Cases:
- Workplaces and scenarios where users have access to a landline telephone but not mobile apps or texts, such as call centers or certain government offices with desk phones.
- Users who do not have a mobile phone, or who work in areas with no cellular coverage (but perhaps have a landline available).
Advantages:
- Does not require internet access or a smartphone. A landline or basic mobile phone can be used, which makes it accessible in low-tech environments.
- Voice delivery can assist users who have visual impairments or difficulty reading text messages; they can hear the code and instructions.
Disadvantages:
- Not practical in noisy or public environments, as the user might not hear the code or could feel uncomfortable taking an authentication call in front of others.
- Slower and less convenient than other methods. The user has to wait for the call, listen to the entire message, and either enter the code or press a button. This takes longer than simply glancing at a phone notification in an authenticator app.
- If the method relies on entering a code read over the phone, it has similar phishing vulnerabilities to other OTP methods. An attacker could trick a user into divulging the spoken code.
Recommendations:
- Reserve phone call MFA for cases where no other method works.
- When using this authentication type, the approach of “press a key to confirm” is preferable to reading a code aloud because an interactive confirmation is less prone to error and slightly more secure than a code that could be written down by someone nearby.
- Administrators should ensure phone numbers are kept up to date and consider the user’s environment (for example, a customer support center might use this method, but provide a quiet line or headset for the employee to hear the call).
- Always have an alternative available in case phone service is down or the user cannot take a call.
QR Code-Based Authentication
The user is shown a QR code on the login screen and is prompted to scan it with a mobile app as a way to verify the login. Scanning the QR code with the proper authentication app like Rublon Authenticator will confirm the user’s identity. This method often ties into an app that the user is logged into on their phone, establishing an out-of-band confirmation that the person at the computer is the same person who has the trusted phone.

Use Cases:
- Enterprise and remote access systems, where the login process can present a QR code that employees scan with a company-approved authenticator app.
- Government and public-service portals (e.g., e-government services, appointment systems) that implement QR codes as an additional security step.
Advantages:
- Very fast authentication. Scanning a QR code can approve a login in seconds without any typing.
- The QR code is typically single-use and expires immediately after scanning, which increases security. Even if someone captured the image of the code, it would be useless after the first scan or after a short time.
- Eliminates manual entry errors; users do not have to type in any codes, reducing the chance of mistakes and login timeouts.
Disadvantages:
- Requires the user to have a smartphone with a camera and the appropriate app installed.
- If the QR code is displayed on a screen that others can see, there is a risk that someone else could quickly snap a photo of it. However, without the associated password and the trusted app, a QR code alone is not enough to breach an MFA-protected account.
Recommendations:
- QR code MFA can provide a smooth login experience, especially in controlled environments.
- To use it safely, ensure that QR codes expire immediately after use and cannot be reused.
- Ensure the QR code is not easily visible to shoulder surfers and security cameras.
- Provide clear instructions to users for the first time (“open your company app and scan the QR code to approve the login”) so they understand what to do.
- As with other phone-based methods, have an alternative available for those who might not have their smartphone handy.
YubiKey OTP
YubiKey OTP is a dedicated feature of YubiKey hardware keys developed by Yubico. When activated — typically by a simple touch — the YubiKey generates a 32-character one-time password composed of modhex characters and automatically enters it into the active text field, emulating keyboard input. This code is then validated by a verification service, either via Yubico’s cloud infrastructure or a self-hosted YubiKey validation server, to authenticate the user. YubiKey OTP serves as a bridge between traditional OTP-based authentication and modern hardware key solutions.

Use Cases:
- Securing high-value accounts and systems (servers, administrator accounts, VPN access) that support YubiKey OTP integration, especially where a direct internet connection may not be available for push notifications, and where FIDO U2F & FIDO2 standards are not supported.
- Environments that consider SMS and mobile apps too risky or unreliable, and prefer a hardware-based OTP solution, but with the ease of automatic entry (the YubiKey types the code for the user).
Advantages:
- A physical token that cannot be duplicated by digital means. The secrets stored on a YubiKey are unique to the device and not extractable.
- No need to install drivers or software on the client device; a YubiKey acts like a standard USB keyboard when delivering OTPs, which means it is broadly compatible with many systems out of the box.
- Quick to use: just plug in and tap the YubiKey; the OTP is entered automatically, avoiding manual typing errors.
Disadvantages:
- If a YubiKey is lost or stolen, the user loses that factor of authentication until a replacement or backup method is used. Unlike a password, you cannot just reset a YubiKey OTP; you need another physical key or an alternative way in. (Having a backup method is essential.)
- Not phishing-resistant. YubiKey OTP codes can be captured by a malicious site just like Google Authenticator codes can. If an attacker tricks a user into using their YubiKey on a fake login page, the one-time code can be instantly used to access the real service (within that brief code validity window).
- Management overhead. You either rely on a third-party service (Yubico’s cloud) to validate OTPs or maintain your own validation server, and you must securely associate each YubiKey with the user’s account.
Recommendations:
- YubiKey OTP can be a useful option for bridging older systems into a more secure MFA realm and for applications that do not support FIDO U2F & FIDO2 standards.
- For deployments in new systems, consider using the YubiKeys in modern FIDO2 mode first (for phishing resistance) and only use OTP mode for systems that do not support WebAuthn.
- Over time, aim to upgrade or replace systems that only support OTP with those that can support newer, phishing-resistant standards.
Passkeys (FIDO2 Passwordless Credentials)
Passkeys are FIDO2/WebAuthn credentials that enable passwordless or multi-factor logins.
When a user registers a passkey, their device generates a unique public/private key pair tied to the site’s domain.
During login, the device signs a challenge with the private key after the user confirms via a local method (such as a fingerprint scan, face recognition, or device PIN).
Then, the signature is verified with the public key stored on the website. The private key never leaves the device and is useless on a different domain, making this method inherently phishing-resistant.

Use Cases:
- Modern consumer platforms and major websites are rolling out passkey support to replace or supplement passwords (e.g., Google accounts, Microsoft accounts, Apple ID, GitHub, PayPal, and many others allow passkey login).
- Enterprises are pursuing a passwordless strategy, where employees use biometrics or PINs on their laptops/phones to log into corporate services without ever typing a password. Passkeys can greatly enhance security while simplifying the user login experience.
- Scenarios where using a separate physical key might be inconvenient, and instead, leveraging the user’s existing device (with its secure hardware and biometrics) is preferred. Passkeys can serve as a possession factor (the device) combined with an inherence factor (biometric) or knowledge factor (device PIN) in one smooth workflow.
- Odporność na phishing. Urządzenie odmawia podpisywania wyzwań z innej domeny, zapobiegając atakom typu adversary-in-the-middle i credential replay.
- Wygoda użytkownika. Logowanie jest szybkie i bezproblemowe. Użytkownicy uwierzytelniają się za pomocą biometrii lub kodu PIN na własnym urządzeniu, zamiast wpisywać hasło lub kod.
- Lokalne przechowywanie kluczy. Klucz prywatny jest bezpiecznie przechowywany w sprzętowych komponentach urządzenia (np. w bezpiecznej enklawie lub module TPM) albo w oprogramowaniu (np. w menedżerach haseł).
- Obsługa wielu urządzeń. Wiele ekosystemów pozwala na tworzenie kopii zapasowych lub synchronizację kluczy dostępu z innymi urządzeniami (np. przez iCloud Keychain, Google Password Manager, menedżery haseł), co zapewnia awaryjność w przypadku niedostępności głównego urządzenia i umożliwia wdrożenie kluczy dostępu zarejestrowanych przez administratora za pomocą korporacyjnych menedżerów haseł.
Advantages:
- Phishing resistance. The device refuses to sign challenges from a different domain, preventing adversary-in-the-middle attacks and credential replay.
- User convenience. Logins are fast and seamless. Users authenticate with a biometric or PIN on their own device rather than typing a password or code.
- Local key storage. The private key is securely stored in the device’s hardware (e.g., secure enclave or TPM) or software (e.g., password managers).
- Cross-device support. Many ecosystems allow passkeys to be backed up or synced to other devices (e.g., via iCloud Keychain, Google Password Manager, password managers), providing a fallback if the primary device is unavailable and allowing use cases like deploying admin-enrolled passkeys with enterprise password managers.
Disadvantages:
- Dependency on device security and cloud accounts. If a user’s device is compromised (malware, for instance), an attacker might initiate an unauthorized authentication if they can also spoof the biometric or know the PIN.
- If passkeys are synced via a cloud account and that account is compromised, an attacker could potentially access the encrypted passkey material. The design of these systems is very secure (typically requiring the attacker to also compromise the device or the user’s authentication to the cloud), but the risk is not zero.
- Ecosystem lock-in and interoperability concerns: passkeys created in one ecosystem (say, Apple’s) are designed to be used within that ecosystem’s devices by default. There are standards for cross-platform usage, but the user experience can be a bit more complex if not all devices are in the same ecosystem. This is improving over time, but can be confusing in the early stages.
- Newness and user understanding. Passkeys are still a new concept for many people. Users might be confused by how to set them up or what to do if prompted to create a passkey.
- Account recovery and device loss. If a user loses all their devices (and access to any cloud backup of keys) and has no other recovery method on their account, they could be completely locked out. This means services should still offer alternate recovery options (which might be less secure if not done carefully).
Recommendations:
- Passkeys represent the future of account authentication, combining strong security with ease of use. Organizations and developers should begin offering passkey login options to users, especially for high-value accounts, but with careful consideration for user education and backup methods.
- Allow users to register multiple passkeys (e.g., one on their phone, one on their laptop) so they have redundancy.
- It’s wise to allow a fallback method (such as a security key or backup codes).
- Educate your user base about how passkeys work and how to manage them across new devices. As passkeys become more ubiquitous, they have the potential to greatly reduce reliance on passwords and traditional OTPs, thereby significantly improving security for everyone.
Backup Codes
Backup codes are single-use codes (often 8–10 digits each) that a user can generate or receive in advance to use when all other MFA methods are unavailable. Typically, a service will provide a set of 5 or 10 backup codes that the user should store in a safe place (even offline, like printed on paper or saved to an encrypted file). For best security, each backup code can be used only once to log in. They serve as an emergency fallback for multi-factor authentication.
Use Cases:
- Regaining account access after losing the primary MFA device. For instance, if a user loses their phone or their security key, a backup code can be used to get into the account.
- Travel or special circumstances where a user might not have their phone or token with them, and alternative access is needed without contacting support.
- Nie wymaga żadnego urządzenia w momencie logowania. Wystarczy kod z zapisanej listy.
- Daje użytkownikowi pewną kontrolę nad odzyskiwaniem konta, co potencjalnie oszczędza czas i kłopoty. Jeśli kody zapasowe zostaną przygotowane z wyprzedzeniem, użytkownik może samodzielnie zalogować się awaryjnie, bez czekania na pomoc techniczną (co jest kluczowe, jeśli zajdzie taka potrzeba poza godzinami pracy).
- Kody zapasowe można łatwo wygenerować i unieważnić, zarówno po ich użyciu, jak i w sytuacji, gdy użytkownik obawia się, że mogły zostać ujawnione.
Advantages:
- Does not require any device at the time of login. You just need the code from your stored list.
- Puts some control in the user’s hands for account recovery, potentially saving time and hassle. If backup codes are prepared ahead of time, the user can self-serve an emergency login without waiting on support desks (which is crucial if the need arises off-hours).
- Backup codes can be easily generated and revoked if one is used or if a user is worried they might have been exposed.
Disadvantages:
- Secure storage is absolutely essential. If a user stores the backup codes insecurely (like in plain text on their computer or a sticky note on their monitor), an attacker can steal the backup codes. Because they are often long-lived, the attacker can use them only after some time.
- Often not used until an emergency, so users might forget where they stored them or might not have them handy when needed. If not properly handled, a user could end up locked out despite having been given backup codes.
- If the codes never expire until used, they present a long-term risk if someone unauthorized obtains a copy. Conversely, if they expire too quickly or after a single use each, the user has to periodically refresh them or request new ones, which involves IT.
- There’s usually no specific alert if someone uses a backup code (depending on the system), so it might be harder to detect if one was stolen and used by an attacker, unless the system notifies the account owner.
Recommendations:
- Any robust MFA setup should offer backup codes or an equivalent account recovery method.
- Administrators should generate a limited number of bypass codes that expire after a given period of time.
- Upon issuing backup codes, services should remind users to store them offline in a secure location (for example, in a locked safe, or within an encrypted password manager) and not to keep them where they could be digitally compromised.
- While they are a necessary fallback, backup codes should be protected and used sparingly. The goal is that users rarely need to resort to them.
Smart Cards and PKI Certificate Authentication
Smart cards are physical identification cards with an embedded microchip that can securely store cryptographic certificates. They are often used in conjunction with a PIN code.
When authenticating, the user inserts the smart card into a reader (or taps it on an NFC reader) and enters their PIN; the system then uses the certificate on the card to verify the user’s identity (usually via a cryptographic challenge-response).
Similarly, PKI certificate authentication can be implemented without a physical card by storing a user’s certificate on their device (in a secure certificate store) and using it to automatically authenticate to services (for example, mutual TLS authentication to a website).
Both methods rely on Public Key Infrastructure (PKI) – with issued personal certificates – as the “something you have” factor, often combined with a PIN or password (“something you know”).
Contactless form factors are common: the same certificate-bearing smart-card technology can be delivered as RFID/NFC cards, key fobs, or wristbands (tap-to-auth).
Be careful to distinguish true contactless smartcards (ISO 14443 with mutual authentication) from legacy 125 kHz proximity credentials that only transmit an ID number and are widely clonable—the latter are not appropriate as an MFA factor.
In regulated or high-assurance environments, prefer cryptographic contact or contactless smartcards (e.g., PIV/CAC) or NFC security keys that meet phishing-resistance requirements at higher AALs.
Use Cases:
- Government and military environments, where smart ID cards (CAC cards or PIV cards) are issued to personnel for secure login to computers and facilities. These cards often double as photo ID and access badges.
- Large enterprises with high security requirements and compliance mandates (e.g., financial institutions) that have an existing PKI in place. Employees use smart cards or USB token equivalents to log into corporate laptops, VPNs, or sign important transactions.
- Scenarios requiring digital signatures and non-repudiation, where a personal certificate from a smart card is used to sign documents or emails, proving the origin and integrity of the message.
- Environments with limited internet connectivity where an offline certificate can be used to authenticate users without needing a real-time code or push (e.g., logging into a machine that’s not internet-connected but can validate a certificate against a local authority).
Advantages:
- Strong security and phishing resistance. When using certificate-based login, there is no reusable password being transmitted. Authentication involves a cryptographic exchange that a phishing site cannot replicate without the actual card or certificate. An attacker can’t simply trick a user into “sending their certificate” the way they could trick them into sending an OTP code.
- Private keys are stored securely, often in hardware (the chip on the card or a USB token) and protected by a PIN. Even if a hacker got physical access to the card, they would need the PIN (and often the cards have mechanisms to lock or self-destruct the certificate after too many wrong PIN attempts).
- Once set up, it login is seamless for the end user. They might just insert their card, and the login happens automatically (after PIN entry). No additional steps like reading codes or approving notifications.
- Smart cards can serve multiple purposes (physical door access, computer logon, encryption, and digital signing), consolidating security tools.
Disadvantages:
- Infrastructure complexity. Deploying and maintaining a PKI is non-trivial. It requires certificate authorities, management software, issuance and revocation processes, etc. This overhead is typically only justified in larger organizations with dedicated security/IT staff.
- Hardware and logistics costs. Every user needs a card (or token) and possibly a USB or NFC reader if their device does not have one built in. Replacing lost cards and expired certificates involves administrative work. Securely distributing cards to remote users presents an additional challenge.
- User inconvenience. Carrying a card and a reader (if not built-in) can be seen as cumbersome compared to phone-based methods. If a user leaves their card at home, they cannot log in. Similarly, if a card breaks or malfunctions, it can create an immediate work stoppage for that user.
- Limited cross-platform ease. Unlike app-based MFA, which can work across any device with an internet connection, smart card solutions often require specific configurations on each device (e.g., the device must trust the corporate CA, have a reader, etc.). For example, using a smart card to log into a personal mobile device is usually not practical.
- If a device that stores a software certificate (not on a card) gets compromised, the certificate could be stolen without the user knowing, which is why storing certs on a physical smart card is preferred.
Recommendations:
- Smart cards and PKI-based authentication are highly secure and well-suited for organizations that truly need them and can support the overhead (many government agencies and regulated industries use them successfully).
- If you already have a PKI deployment, leveraging smart cards for MFA can significantly increase security. However, for organizations starting fresh, consider whether modern alternatives (like FIDO2 security keys or passkeys) can meet your needs with less complexity.
- If you do implement smart cards, enforce policies like requiring PIN unlock and lockouts after a few failed attempts, have a clear procedure for lost/stolen cards (immediate revocation and replacement), and train users on their responsibilities (caring for the card, not leaving it in the reader, etc.).
- Smart cards can provide an extremely high level of security, on par with the best modern MFA, but they come with administrative burdens that should be weighed against the benefits for your specific situation.
Conclusion
There’s no one-size-fits-all in MFA. The best authentication method depends on your risk tolerance, user convenience, industry compliance requirements, and device ecosystem. While some methods like SMS are widely used but vulnerable, others like passkeys and FIDO2 hardware security keys offer stronger, phishing-resistant protection.
For a broader look at MFA concepts, user adoption, benefits, and deployment strategies, visit our main guide: What is Multi-Factor Authentication (MFA)?
And if you are ready to deploy robust, flexible MFA across your organization, try Rublon MFA for free (no credit card required).