MFA – The Choice Challenge
Multi-Factor Authentication (MFA) is considered a standard recommendation by all security experts for improving security. Nevertheless, we continue to see successful attacks on accounts even when some form of MFA was active. The issue is not that MFA fundamentally does not work. However, MFA methods themselves can be attacked in different ways.
A common question is: Are hardware tokens the better MFA? A first short answer could be: For particularly sensitive access, absolutely – but not automatically for every user and every use case.
How can MFA methods be attacked?
Many organisations have introduced various forms of MFA and then feel completely secure against attacks targeting user authentication. Professional attackers, however, have adapted. MFA methods and their specific weaknesses can be targeted.
Well-known examples include:
Phishing proxies, that first intercept passwords and then one-time codes before forwarding them
Push fatigue attacks, in which users receive a large number of alarming fake MFA requests and are ultimately lured into a fraudulent re-authentication process
Smartphones hosting MFA apps are convenient, but as general-purpose devices they also present a broad attack surface
Smartphone-based MFA options: practical and quick to roll out, but security levels must be evaluated carefully
Smartphone-based MFA offers clear advantages. Almost every user owns a smartphone. Deployment is comparatively inexpensive, quick, and familiar to many users. TOTP codes also work offline, push-based methods with number matching improve usability, and passkeys stored within an operating system platform provide a highly convenient user experience.
For many standard applications and the general workforce, selecting an MFA method via a smartphone can represent a sensible balance between security, cost, and usability.
However, MFA methods associated with smartphones also have limitations. For example, TOTP codes can be intercepted. Push-based MFA can be abused through fatigue attacks. Bring-Your-Own-Device scenarios raise compliance concerns. Device replacement can generate significant helpdesk effort. Smartphone-to-cloud synchronisation of passkeys also changes the trust model: generated credentials for the second factor are no longer tied exclusively to a local device but are stored in a cloud account, introducing new attack vectors.
In short: Convenience does not automatically equal strong security.
Hardware tokens: stronger, but operationally more demanding
Hardware tokens are dedicated physical components for storing credentials used by the second factor. Private keys stored in this way remain protected by the respective hardware. Examples include USB/NFC hardware tokens from commercial vendors, as well as usable hardware components integrated into end-user devices such as Windows and macOS Trusted Platform Modules (TPMs).
The MFA standard FIDO2/WebAuthn (Fast Identity Online combined with the Web Authentication API) uses such hardware-stored tokens and provides very strong protection against phishing. Users do not enter a reusable secret into a website. Instead, the web service sends a challenge, and FIDO2 signs it with a private key generated specifically for that application.
Hardware-stored credentials offer practical security benefits: they are independent of personal smartphones, create a clearer separation between business and private identities, and are particularly suitable for administrators, developers with production access, executives, and finance, HR, and legal roles.
Unfortunately, hardware tokens also have disadvantages. They must be procured, inventoried, distributed, and replaced. Users can lose them. Backup procedures for device replacement or loss are therefore essential. Additional questions arise as well: USB-A, USB-C, NFC, or Lightning? And, naturally, users require training to initialise and use these MFA methods.
The key message is: Using hardware tokens requires strong lifecycle management.
A hardware token is not a single MFA method
Commercial hardware tokens are not “the MFA method”. They are platforms supporting multiple authentication mechanisms, for example:
FIDO2/WebAuthn
Resident passkeys
TOTP via token-integrated applications
One-Time Password mechanisms for legacy applications
Smart card scenarios
OpenPGP
This distinction is important because not all of these methods provide the same level of protection. TOTP on a hardware token improves the security of secret storage, but it is still not as phishing-resistant as FIDO2/WebAuthn. Therefore, when someone says “hardware token”, they should specify which MFA mechanism is actually being used.
The strongest recommendation is therefore not simply “use a YubiKey”, but rather: Where possible, use FIDO2/WebAuthn with hardware security keys.
First perform threat modelling, then select MFA methods
Before selecting tools, organisations should first develop their MFA concept based on risk. Useful guiding questions include:
Can a second factor be intercepted?
Can malware steal a secret?
Can a user be manipulated into approving requests?
What happens when physical items are lost?
Is the recovery process stronger than potential attackers?
The last point in particular is often underestimated. An MFA solution is only as strong as its weakest recovery or fallback path. If a lost hardware token can be replaced through a weak helpdesk process by the wrong person, the technical strength of the token becomes irrelevant.
Practical decision-making guidelines
Not every user type requires the same MFA strength. A sensible matrix could look like this:
For regular employees, approved authenticator apps or platform passkeys may be sufficient, provided that risk analysis and application requirements support this choice.
For privileged accounts and developers with production access, FIDO2-compatible hardware tokens may be mandatory.
For finance, HR, legal, and executive roles, hardware tokens should be considered because these positions are particularly attractive targets for attackers.
The basic rule is: The strength of the selected MFA method must match the risk profile of the user type.
What organisations should do in practice
Organisations should gradually move away from SMS and other simple push-approval mechanisms.
Where possible, phishing-resistant MFA should be preferred. Adoption should begin with the highest-risk user groups: privileged administrators, users with production access, and critical business functions.
Hardware tokens should be issued in pairs: one primary token and one securely stored backup token. Otherwise, work may not be able to continue efficiently in the event of loss. In addition, loss, replacement, and recovery processes must be documented and reviewed regularly.
TOTP can still play a role, particularly for legacy systems or fallback scenarios. However, it should be regarded as not phishing-resistant.
Conclusion: Hardware tokens are highly secure – but not always the best answer for every use case
Hardware tokens are particularly suitable when high security, privileged access, and phishing-resistant authentication are required. In combination with FIDO2/WebAuthn, they provide significantly stronger protection than traditional OTP or simple push-based methods.
For standard users, smartphone-stored passkeys or well-managed authenticator applications may still offer the better balance between security, user convenience, and deployment effort.
The real question is therefore not: “Hardware or smartphone-based?” but rather: Which risks do we want to mitigate for which user groups – and which MFA method provides the appropriate level of protection?
Keywords