In today’s increasingly intricate digital landscape, maintaining cyber resilience is more crucial than ever. This involves not only proactively safeguarding against threats but also ensuring a swift recovery in the event of a breach. As organizations and individuals continue to rely on digital technologies, robust cybersecurity measures are essential to preventing disruptions and mitigating potential losses. One of the most powerful tools in the fight against cyber threats is multi factor authentication. MFA is a highly effective strategy for strengthening cyber resilience. Let’s delve deeper and explore its optimal implementation scenarios.

What is multi factor authentication?

Multi factor authentication is a security measure that enhances account protection. By requiring users to verify their identity through multiple authentication methods, it goes beyond traditional single-factor methods.

MFA relies on a combination of at least two distinct authentication factors. These factors are categorized into three main types.

• Something you know – This first category involves knowledge-based authentication methods. Examples include passwords, PINs, or answers to security questions. This type of authentication is based on information that only the user should be aware of, providing a basic layer of security.
• Something you have – The second category is based on possession-based verification. It involves using physical devices such as smartphones, hardware tokens, or security keys to authenticate the user. By requiring users to possess specific devices, it adds an additional layer of security.
• Something you are – The third category utilizes biometric data for authentication. Examples include fingerprints, facial recognition, or voice patterns. This type of authentication is based on inherent characteristics unique to the user. Therefore, it provides a more secure and convenient way to verify identity.

Multi factor authentication provides a robust defense against unauthorized access by layering multiple security factors. Even if one factor is compromised, the remaining layers act as a barrier. This approach significantly increases the difficulty for an attacker to gain access. As a result, MFA offers strong protection against a range of common cyber threats that hackers often use to take advantage of weak security measures.

Why do we need multi factor authentication?

Studies show that 50 percent of businesses have experienced a successful cyberattack in the past three years, reflecting the alarming scale and sophistication of cybercrime. The projected global cost of cybercrime is expected to exceed $20 trillion by the end of 2026. Hence, businesses cannot afford to take a reactive approach to cybersecurity. It’s critical to proactively safeguard against threats while ensuring the ability to recover quickly.

Cybercrime often makes headlines when large organizations fall victim to attacks. Contrary to popular belief, SMBs are just as appealing to cybercriminals. In some cases, they may even be more attractive targets. The 2008-2022 Data Breach Investigations Report highlighted that 93 percent of security breaches at small and very small organizations were linked to compromised credentials. Yet this issue is not unique to SMBs. Verizon’s 2020 report revealed that 77 percent of data breaches involving cloud assets were also tied to compromised credentials.

It is evident that traditional single-factor authentication has become increasingly susceptible to attacks. Password-protected accounts are commonly targeted by phishing, brute force, and credential stuffing. Implementing multi factor authentication is one of the most effective strategies for enhancing cyber resilience.

In what way is multi-factor authentication (MFA) more secure than a password?

Multi factor authentication is more secure than passwords alone because it adds an additional layer of security by requiring users to provide multiple forms of verification, such as a one-time password, biometrics, or hardware tokens. This significantly reduces the likelihood of unauthorized access, even if one layer (like a password) is compromised.

Passwords alone are a single point of failure. Considering that compromised credentials are a primary factor in many data breaches, implementing MFA addresses one of the most common vulnerabilities exploited by cybercriminals. By adding this extra layer of defense, businesses can make it substantially harder for attackers to gain unauthorized access, protect sensitive data, and build a foundation for stronger cyber resilience.

Multi factor authentication examples

There are many methods to implement MFA. Which of the following is the strongest form of multi factor authentication? Let’s take them one by one to find out.

TOTP (Time-Based One-Time Password)

TOTP is a widely used multi factor authentication method that generates time-sensitive one-time passwords on a separate device, such as a mobile app or a cloud-based service.

While TOTP offers portability and convenience, its security level is considered lower compared to other MFA methods. This happens mainly because it relies on the physical security of the device where the TOTP generator is installed. However, losing the device that stores the TOTP app or key can pose a significant problem. Without the backup codes or access to a synced cloud service, regaining access to accounts secured with TOTP may require additional recovery steps or support from service providers.

Backup codes

This is a commonly used MFA method that provides users with a set of one-time use codes to access their accounts in case other authentication methods are unavailable. These codes are typically stored in a secure location, either locally (on a personal device or printed out) or remotely (in a cloud-based database). They can be used on browsers (on macOS and Windows) and mobile devices (iOS and Android), making them a flexible option for various platforms.

Their security largely depends on how securely the storage medium is protected. If the database storing these codes—whether local or remote—is compromised, an attacker could potentially gain unauthorized access to the associated accounts. Therefore, it is crucial to store backup codes in a highly secure environment, such as a password-protected file, an encrypted storage device, or a secure password manager.

External hardware keys

External security keys are among the most secure multi factor authentication methods available, offering strong protection through public-key cryptography. These hardware devices, such as YubiKey, are highly resistant to phishing and other common cyberattacks, making them an excellent choice for users seeking enhanced security. However, their use can be somewhat complex and may not be ideal for all situations. The key is then connected via USB or NFC, depending on the hardware and the device in use.

While effective, this method can pose compatibility issues, particularly on mobile devices that may lack the required ports or NFC capabilities. Furthermore, portability can be a challenge. Security keys are small and can be easily lost or misplaced, potentially leaving users locked out of their accounts.

Biometric verification

It’s a powerful and increasingly popular multi factor authentication method that verifies a user’s identity based on unique physical or behavioral characteristics. Examples of biometric factors include fingerprints, facial recognition, voice patterns, and iris or retina scans. Since biometrics are unique to each individual and cannot be easily shared, they provide robust protection against traditional attacks.

Biometric systems are not infallible and can occasionally fail either with false positives or false negatives. The storage and use of such sensitive personal information raise privacy issues. Its implementation must account for potential privacy and hardware limitations to ensure effectiveness and user trust.

Passkeys

This is an emerging and highly secure multi factor authentication method that aims to eliminate the need for traditional passwords. Built on the WebAuthn standard, passkeys use public-key cryptography to authenticate users. Passkeys can be used across multiple devices and platforms, with synchronization mechanisms in place for convenience.

This cross-device compatibility makes passkeys particularly appealing for users who want a balance of strong security and convenience. Traditional MFA methods often involve cumbersome processes like entering one-time passwords or carrying physical tokens. In contrast to this approach, passkeys streamline authentication by leveraging built-in device features like biometrics or PINs. This simplicity enhances user experience while maintaining robust security. In the following sections, we will explore passkeys in greater detail.

The WebAuthn standard

Web Authentication (WebAuthn) is a standard defined by the World Wide Web Consortium (W3C) that provides a secure way for web applications to authenticate users securely without relying solely on passwords. WebAuthn is a core component of the FIDO2 standard, developed by the Fast Identity Online (FIDO) Alliance. It works in conjunction with the Client to Authenticator Protocol (CTAP) to enable strong, passwordless, and phishing-resistant authentication. WebAuthn has two main features:

• Supports passwordless authentication. Users can authenticate using biometrics, hardware security keys (e.g. YubiKey), or cryptographic authenticators. These methods provide a secure and user-friendly alternative to passwords.
• Supports Two Factor Authentication (2FA). WebAuthn can also function as a second factor in multi-factor authentication setups, adding an extra layer of security.  For instance, it can be used in combination with a password (something the user knows) to add a second layer of security, such as a security key or biometric verification (something the user has or is).

WebAuthn operates by generating a pair of cryptographic keys. The public key is stored on the server, while the private key remains securely on the user’s device. During authentication, the private key signs a challenge issued by the server, and the signature is verified using the public key. This process ensures that only legitimate users can authenticate, making phishing attacks nearly impossible.

What are passkeys?

To make WebAuthn more commercially appealing and user-friendly, discoverable FIDO2 credentials are commonly referred to as passkeys. This terminology helps users associate the feature with a seamless, modern authentication experience.

Here are some key characteristics of passkeys:

• Cross-device and cross-platform synchronization – Passkeys are designed to be easily used across different devices and platforms. For instance, Apple’s implementation syncs passkeys via iCloud, allowing users to access their credentials on any Apple device they own. Other ecosystems, such as Google and Microsoft, are implementing similar synchronization capabilities, ensuring interoperability.
• User experience – The main goal of passkeys is to simplify the authentication process. Using biometrics like Face ID, Touch ID, or a familiar method like a device PIN, passkeys make logging in quick and intuitive. This streamlined experience reduces friction associated with traditional passwords or even other multi factor authentication methods.
• Security – Passkeys are built on the WebAuthn standard, which uses public-key cryptography for authentication. Since no passwords are transmitted or stored, the risk of password-related breaches, such as leaks or phishing, is eliminated. This makes passkeys significantly more secure than traditional password-based systems.

Passkeys leverage discoverable credentials, a mechanism in WebAuthn that allows for seamless authentication without requiring the user to manually enter a username or a password. The credential is stored on the authenticator device (e.g., a phone or hardware key) and can be retrieved directly, enabling a smooth login process. In fact, whether a WebAuthn credential qualifies as a passkey is determined by its discoverability.

Apple, Google, and Microsoft are all working on passkeys as a cross-platform, passwordless authentication.

What does discoverable mean?

Discoverable credential means that the private key and associated metadata is stored in persistent memory on the authenticator, instead of encrypted and stored on the relying party server. The ability of a relying party to utilize a credential on an authenticator without requiring the user to provide a username makes it discoverable.

Most WebAuthn implementations focus on discoverable credentials, on mobile devices or in the desktop browser.

What does non-discoverable mean?

Non-discoverable credentials are not considered passkeys, but they are considered valid WebAuthn credentials. These are credentials that cannot be generically invoked by a relying party. Instead, a user must provide the relying party with a username (user handle). This allows the application to present a list of credential IDs that can be used for authentication.

Non-discoverable credentials are specifically important in the context of hardware keys. We’ll get back to them shortly, no worries.

How do passkeys work?

There are two main parts of this process.

First, passkeys are used during the user’s registration to the chosen service, namely:

• The user’s device employed for registration generates a public-private key pair.
• The public key is sent to the server and associated with the user’s account (user identifier, device information etc.)
• The private key remains securely on the user’s device.

Next, passkeys are employed during the user’s authentication process, namely:

• When the user tries to log in, the server sends a a random string (challenge) to the user’s device.
• The device uses the private key to sign the challenge.
• The signed challenge is sent back to the server.
• The server uses the stored public key to verify the signature, confirming the user’s identity.

With passkeys, what’s stored on your device is not only the private key (the crucial security information) but also:

• Relying Party Identifier (RP ID) – This is essentially the domain for which the passkey is valid (obtained during user registration). It is verified during authentication. We do not want the passkey for 4psa.com to be used on google.com, although technically there is no security impact if they match.
• Username or account identifier – This could be a username, email address, account ID, or other identifier. It links the passkey to the specific user account on the Relying Party (RP). During authentication, it tells the server which account the passkey is associated with.
• Credential ID – A unique identifier for the passkey. It helps the server recognize which public key to use when verifying the authentication. The server can support multiple passkeys for the same user across different devices or accounts.

Vendor verification

iOS and Android check that the app creates/gets credentials only for associated domains. A domain is associated with an iOS or Android app when:

• The app declared the domain(s).
• The server declared the domain(s).

This enforcement is a business decision, not a security feature. And it creates problems for apps that can be used with the domains of multiple service providers, where no predefined list exists.

The autofill feature

We are all familiar with the autofill feature used for passwords. And now, in a paswordless authentication process, you might ask why you would need such a feature and how it could be implemented. Truth is that WebAuthn added a new layer of friction in your UX when verifying whether your device has a passkey for a particular website.

Currently, authentication to locate discoverable credentials only begins if the user prompts it. However, users may not initiate the process if they’re uncertain whether they have a passkey. And this creates a cycle where neither the client nor the relying party takes action without a clear trigger. Autofill addresses this usability issue by enabling the client to non-intrusively prompt for passkey options without interrupting the user. This enhances the traditional WebAuthn process, which often stalls due to timeouts during authentication method selection.

Note however that autofill is important only when passkeys fully replace passwords. Which means that autofill is not relevant for multi-factor authentication scenarios, as the flow is driven by the server after user identification with the password.

Security

Multi factor authentication is a security mechanism to make it harder for unauthorized parties to gain unauthorized access to systems, applications, or data.

In what follows, I will use the generic term credential, as its discoverability is irrelevant from a security standpoint.

Here are some high-level requirements:

• Credentials must be stored (ideally) in a location that cannot be easily accessed by an attacker.
• Credentials must be stored encrypted because location is not a sufficient guarantee.
• There should be very difficult for an attacker to obtain the encryption key.
• All cryptographic operations and credential handling must be performed within a secure, isolated environment.

This is a simplified overview on MFA, intended to convey the broader perspective. Fact is that by implementing multi factor authentication effectively, organizations can dramatically reduce the risk of breaches and provide a more secure environment for their users.

Storage

Depending on the device used for WebAuthn, credentials may be stored on:

• Hardware keys – Credentials are stored securely within the hardware key, on its secure memory. Such hardware keys are designed to ensure credentials never leave the device.
• Apple devices – Some platform authenticators support credentials synchronized across devices via the cloud. For Apple devices—iPhone, iPad, Mac—credentials are stored in the encrypted iCloud Keychain. The encryption key is stored in a dedicated hardware module—Apple Secure Enclave. These credentials may also be wrapped.
• Windows devices – On Windows devices, credentials are stored in the encrypted database with support from hardware—TPM (Trusted Platform Module). Software implementation is also available at different levels.
• Android devices – On Android devices, credentials can be stored in the encrypted Android Keystore or on a secure hardware module—TEE (Trusted Execution Environment). High-end Android devices also have HSM (Hardware Security Module).

WebAuthn is designed to leverage the highest level of security available on the device, prioritizing hardware-backed solutions when possible.

FIDO2 certifications

FIDO establishes various certification levels. Please note that:

• Apple’s iOS and macOS support FIDO2 authentication standards, enabling users to utilize features like Touch ID and Face ID for web logins.
• Android OS has achieved FIDO2 certification, enabling devices running Android 7.0 and above to support passwordless authentication with methods like fingerprint recognition or security keys.
• Web browsers such as Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari support the FIDO2 standards, enabling passwordless authentication through the WebAuthn.

But these certifications are tricky and should not be exclusively used to assess the security of a solution.

• Technically, any device with TEE (even not certified) can reach Level 2.
• Devices with certified TEEs that use PoP packaging (which is much more resistant to physical tampering) can reach even Level 3. Note that technically many TEEs on Android phones may be Level 3 certified.
• Apple didn’t bother to certify Secure Enclave, although, most likely, it meets at least the Level 2 standard.
• Yubico’s YubiKey hardware keys are FIDO2 certified on Level 1 or Level 2, depending on the model.

Certification is about meeting the respective requirements, the actual security of the device may be a totally different story.

Is using hardware more secure than software?

It’s generally accepted that specialized hardware devices can achieve superior security vs. pure software implementations. Several factors contribute to this development. Desktop computers, laptops, and mobile devices are increasingly incorporating dedicated security chips. This happens because it is not feasible to completely isolate security operations within a single execution context. Pure hardware devices, such as YubiKey, use their own security controllers powered through the USB port.

If the security of your passkeys is a priority, choose a computer equipped with integrated hardware security devices or use a dedicated hardware key.

There are however some big differences between these hardware devices:

• TEEs are integrated into CPUs and tightly coupled with the CPU. Usually, they are a functionality of the CPU—an isolated environment within a processor that separates secure operations from normal operations. For example, Snapdragon 865, one of the most popular SoC (System on Chip) used today has the Qualcomm TEE feature. AMD, Intel, and ARM CPUs all have TTEs with different features and characteristics.
• HSMs are dedicated hardware devices, independent from the SoC. They are used to enhance the security provided by the TEE (e.g.: Google Titan M2 chip).
• Apple Secure Enclave is also integrated into the SoC but is isolated from the main CPU. It functions as a dedicated security coprocessor rather than a trusted environment like the TEE.
• Windows computers rely on TPM, which can use a dedicated chip or may be integrated into the CPU—Intel PTT or AMD CPU fTPM. There are other options too, even pure software implementations that run in hypervisors.
• Hardware keys use off the shelf security controllers, for example YubiKey uses Infineon SLE78 family of security controllers. Similar controllers are available from NXP, STMicroelectronics, Renesas, Microchip etc.

Security considerations on hardware

It is challenging to rank the security level of these hardware devices solely based on their type. However, there are a few key considerations worth highlighting:

• HSEs are considered the most robust alternative.
• Apple Secure Enclave may be more secure than most TEE implementations.
• Discrete or integrated TPMs are safer than pure firmware/software or virtual ones. Unfortunately, TPM side channel attacks are discovered quite often.
• Security controllers have long been utilized in various devices and have demonstrated their reliability in other fields, such as banking and military applications.

Unfortunately, the hardware landscape is not without its challenges:

• Hardware vulnerabilities can and do occur, often being discovered over time. Depending on their severity, these vulnerabilities may be mitigated, or in some cases, the entire device (e.g., the entire computer) may need to be replaced.
• Microcode or firmware vulnerabilities are frequently identified. In many cases, the impact of these flaws requires device replacement, as firmware updates are not always possible due to hardware restrictions.

For example, a vulnerability has recently been discovered in the Infineon ECDSA implementation that affects all YubiKey products with firmware < 5.7.0. More details here and in this security advisory. Exploiting the vulnerability is challenging as it requires specialized equipment and physical access to the hardware key. But even so, all hardware keys sold by Yubico are affected. Moreover, this issue cannot be resolved, meaning you will need to purchase a new key.

Should I use a dedicated security key?

Despite the Yubico vulnerability, hardware keys are safer than most devices, especially mobile phones. Most attacks, including the recently discovered one, require physical access to the hardware key and are quite complicated to execute. However, please keep in mind that:

If a state agency targets you, even a Level 2 certified hardware key may not provide sufficient security. With a budget in the low millions, the keys can potentially be compromised.

Security also depends on the configuration. For example, many users will not protect their hardware key with a PIN, which means that only a touch is necessary for authentication.

Hardware keys can connect to mobile phones via USB or NFC. However, this presents a drawback, as it increases the need for the hardware key to be more portable. Since credentials stored on hardware keys cannot be backed up or synced to other devices, losing or damaging the key poses a significant risk. Best practices recommend not relying solely on a single MFA factor. Just as a phone can be misplaced, the same risk applies to a YubiKey or similar hardware device.

In certain environments, the absence of backup and sync features can actually be considered a significant advantage.

Security is about the weakest link

Keep in mind that an attacker will not try to attack the hardware or software stack. There are better choices.

Although public-key cryptography is highly secure, its security fundamentally relies on the protection of the private key(s). Device manufacturers leverage hardware to protect the private key and handle cryptographic operations while ensuring the solution remains user-friendly. Typically, users must authenticate with a biometric feature or a password to activate the private key.

Eventually, all passkeys are as strong as your device’s passcode.

It is important to note that biometric security on consumer devices is not particularly robust, namely:

• Both fingerprints and facial recognition can be spoofed. The difficulty varies based on the software implementation and sensor quality. In some cases, it’s unfortunately quite trivial.
• Users can be forced or deceived into providing their biometric data to unlock their devices.

At their core, it’s clear that passkeys are significantly more secure than passwords:

• They don’t need to be memorized.
• There’s no such thing as a weak passkey.
• They cannot be stolen in a data breach, as the public key alone is useless to an attacker.
• Passkeys cannot be shared or reused between websites like passwords can.

However, it’s important to evaluate the entire security system from the perspective of its weakest link. And, in my opinion, it is unlikely that passkeys will fully replace passwords in high-security applications. These environments are more likely to integrate passkeys within a multi factor authentication framework rather than relying on them as a standalone solution. This hybrid approach leverages the strengths of passkeys while addressing their limitations in substituting something you know.

Attack exemplified

Here are two scenarios I can imagine:

• The device gets stolen. In such a case, after stealing the mobile device, the attacker would record the passcode used by the owner or forge the owner’s face or fingerprint. If successful, the attacker gets instant access to all the victim’s accounts (bank, social networks etc.). The solution is to use passkeys as a second factor in a multi factor authentication framework.
• Account is stolen. Since Apple and Google store passkeys in a shared keychain, gaining access to an Apple or Google account is sufficient to access these passkeys. While this can be challenging without direct access to a device linked to the account (such as a mobile phone, which is typically used for MFA), it is not impossible. Unfortunately for users, Apple and Google rely on less secure multi factor authentication methods, like SMS or alternate email. Additionally, users may inadvertently make configuration errors, further weakening security.

The good new is that in both scenarios, there are methods to significantly mitigate the associated security risks.

Passkeys syncing and recovery

Features are platform dependent. Apple, Google, and Microsoft have passkey implementations that try to lock you into their ecosystem. And in my opinion, this is a major drawback of passkeys. It’s not a flaw in the passkey concept itself but rather a limitation of current implementations. Future developments could address this issue, making passkeys a more universally viable option.

Apple

Apple offers the best implementation overall. Passkeys can be used on macOS and iOS seamlessly. Passkeys created on an Apple device are synchronized through iCloud Keychain, provided the user is signed in with their Apple ID. Apple handles both the synchronization and recovery processes. And passkeys can be selectively shared with third-parties.

Devices can opt in or out of iCloud Keychain. If iCloud Keychain is not used, all passkeys remain stored locally on the device’s keychain, meaning they are neither synchronized nor backed up unless sync to iCloud is activated.

Disabling iCloud Keychain sync can be quite confusing from a security perspective. Even after the sync is disabled, the previously synchronized keychain remains on the device. For the average user, removing the synced keychain from the device is challenging, as it requires direct keychain manipulation. While the term sync is technically accurate, users who disable it are likely expecting something entirely different—such as the complete removal of the iCloud Keychain from the device.

Google

Google Password Manager is integrated seamlessly with Chrome and Android devices and allows users to store and synchronize passkeys across multiple platforms.

However, their passkey implementation falls significantly short when compared to Apple’s.

Microsoft

While passkeys are available on Windows versions 10 and 11, their implementation does not support synchronization or backup, which means passkeys cannot be recovered.

Passkey management is available starting with Windows 11 22H2.

At the Authenticate 2024 conference, Microsoft announced improvements to passkey support in Windows, read this high-level article for more details.

Other vendors

There are alternative cross-platform options for managing passkeys, like the one implemented by 1Password. While their solution is particularly useful in an enterprise ecosystem where passkeys can be shared among team members, it has limitations in terms of usability and potentially security:

• On Windows and macOS, passkeys are managed through browser extensions, whose security is questionable.
• On iOS and Android, a dedicated app is provided for passkey management. However, using the passkeys requires manually copying and pasting them into the authentication window. In contrast, both iOS and Android offer seamless integration with their native passkey management options.

Alternative vendors will only be able to build strong solutions when OS manufacturers are required (or even forced) to introduce plugin capabilities for the authentication process, similar to how keyboards are handled. While this is likely to happen eventually, it will face significant resistance and will come with strict rules (authentication is critical, and vendors emphasize its importance).

Unfortunately, by the time this becomes a reality, it may no longer be practical for most users to switch, as they will already have dozens or even hundreds of passkeys stored in the cloud. Additionally, current specifications do not outline methods for migrating passkeys between vendors.

Lock-in explained

The following operating systems have passkey implementations:

• Windows – Windows Hello supports fingerprint, face recognition, or PIN (depending on the computer’s capabilities and user preferences), with PIN/password available as a last resort.
• macOS – Supports fingerprint authentication, with PIN/password as a fallback option.
• iOS – Supports face recognition or fingerprint authentication, with PIN/password as a fallback option.
• Android – Supports fingerprint or face recognition, with PIN/password as a fallback option.

All OS examples above can also rely on external security keys (like YubiKey).

The platforms aim to guide users toward a passkey ecosystem, especially on mobile devices. Apple and Google hold a significant advantage in this area, as mobile devices are well-suited for securely storing passkeys.

Apple

An Apple account user can share their passkey (via iCloud Keychain) and use it on the following devices:

• iOS device – The passkey is stored in the device’s keychain and can be accessed by unlocking it (requires iCloud Keychain).
• macOS browser – The passkey is available in the device’s keychain and can be unlocked by the user. If the passkey isn’t shared using iCloud, it can still be used from a mobile device via Bluetooth proximity.
• Windows browser – While the passkey is not stored in the device’s keychain, the user can retrieve it from their mobile device using Bluetooth or NFC proximity.
• Android device – Similarly, if the passkey isn’t in the device’s keychain, the user can access it via their mobile device using Bluetooth or NFC proximity.

Google

A Google account user can utilize their passkey as follows:

• iOS device – The user can access the passkey from their mobile device via Bluetooth or NFC proximity.
• macOS device browser – The user can provide the passkey using their mobile device via Bluetooth or NFC proximity.
• Windows device browser – The user can use their mobile device to supply the passkey through Bluetooth or NFC proximity.
• Android device – Since the passkey can be shared between devices, it is typically stored locally. If the passkey isn’t synced to the device, the user can log in using another Android device via Bluetooth or NFC proximity.

Microsoft

A Microsoft user will likely prefer using an iPhone or Android phone. In my opinion, at this time, Windows Hello is not only less convenient, but also less secure due to issues with TPM and biometric sensors.

Why are hardware keys special?

Most people are not familiar with the technical WebAuthn implementations. As mentioned earlier, credentials can be either discoverable or non-discoverable. This distinction is crucial for hardware keys, as they have traditionally handled non-discoverable credentials, which are different from passkeys.

Discoverable credentials (passkeys)

Discoverable (or resident) credentials are stored directly on the hardware key and can only be accessed or used with the corresponding Relying Party ID. For example, to retrieve information about a discoverable credential, you can request the YubiKey to enumerate all credentials linked to a specific relying party. An API is also available to list all passkeys. However, YubiKey has a storage limit of only 25 passkeys. It is highly recommended to protect the passkeys with a PIN to prevent unauthorized access. Otherwise, anyone with physical access to the hardware key could use the passkey.

The device user, provided they know the PIN, can delete any passkey stored in the device’s memory, effectively disabling authentication for the associate relying party. A very important characteristic of passkeys stored on hardware devices is that they cannot be backed up or synced. This means that one of the primary advantages of passkeys—portability and synchronization—is not available in this context. Depending on the application, this might be intentional and considered a feature.

Non-discoverable credentials

Non-resident credentials use the device’s master key, but do not store any information on the hardware key about the websites it has been registered with. A YubiKey can reconstruct a non-discoverable credential (private key) if it receives enough information, specifically the credential ID provided by the server during the authentication. If the credential ID was generated using the device’s master key during the registration phase, the hardware key can sign the server’s challenge. The server can then verify the signature using the public key linked to the credential ID. Thanks to this mechanism, a hardware key can be used with an unlimited number of websites, as it does not rely on internal memory storage.

Since these credentials are not stored on the device, they cannot be managed at the device level. If a hardware key was previously used to login to a website, it will always allow login unless the master key is regenerated. Furthermore, it’s not even possible to determine the list of relying parties the key has been registered with.

Additionally, as the master key cannot be backed up, it is recommended to use redundant devices to ensure access continuity.

What type of key to use?

From the client’s perspective, using passkeys is beneficial due to their management advantages. However, the 25-slot limit may be insufficient. That said, 25 slots can be enough if the client is willing to use another device, such as a mobile phone, for less critical services. For instance:

• Use a hardware key for high-security services like banking or national registries.
• Use a mobile phone for less critical services like Instagram or X.

This approach allows clients to align their choices with the physical security and importance of the services.

Unfortunately, the client cannot control the implementation choices made by the relying party. Therefore, they must accept the available registration method, whether it uses discoverable or non-discoverable credentials.

Are hardware keys flexible enough?

Hardware keys can be used on Windows, macOS, iOS, and Android. To use an external hardware key:

• It must be plugged into a USB port.
• It must be connected via NFC (if supported by both devices).

This means that physical access to the security key is required. However, it’s worth noting that using hardware keys on mobile devices is generally not a common practice.

The future of authentication

Authentication technology is rapidly evolving, and passkeys are poised to play a significant role in shaping the future of MFA and secure access. As advancements continue, you can expect even more innovative and robust authentication methods to emerge.

It is essential to remember that security is only as strong as its weakest link. Therefore, the best strategy is to adopt a holistic approach to security. By combining multiple layers of protection, you’ll build a more resilient defense against cyber threats.

Moving forward, it’s also important to prioritize user education and awareness. By equipping yourself and others with the knowledge and tools to protect digital identities, you can help create a safer online ecosystem.

Whether you’re an individual or an organization, take proactive steps to strengthen cybersecurity. Investing in robust authentication measures is paramount for protecting against cyber threats. Additionally, it supports the development of a more secure and trustworthy digital future for everyone.