Can a hardware security key be used with all SaaS applications?

Most modern SaaS platforms that support FIDO2 or U2F (e.g., Google Workspace, Microsoft 365, Salesforce) work with hardware keys. Legacy services that only accept OTP codes will still require a mobile authenticator app as a secondary factor.

What should I do if I lose my hardware key?

Enroll a spare key during initial provisioning and keep a mobile authenticator app as an emergency factor. Administrators can reset the lost key after verifying the user’s identity through existing identity‑provider workflows.

Does using a mobile authenticator app drain my phone battery or expose me to malware?

Authenticator apps generate codes locally and have minimal impact on battery life. However, if the phone itself is compromised, an attacker could potentially extract the secret seed, so the security of the device remains important.

Hardware Security Key vs Mobile Authenticator App for Remote‑Worker MFA

Question: Should a remote worker use a hardware security key or a mobile-based authenticator app for MFA?

Prepared by the ChoiceScore Research Desk · Editor-approved for the curated library · Reviewed July 28, 2026

Recommended Choice Score: 78/100

Direct answer

Both approaches satisfy MFA requirements, but a hardware security key generally offers stronger protection against credential‑theft attacks while delivering comparable or faster login times. For most remote‑worker deployments the recommended practice is to make the hardware key the primary factor and keep a mobile authenticator app as a backup.

Summary

Multi‑factor authentication (MFA) is a core control for protecting remote access to corporate resources. Both hardware security keys (e.g., FIDO2/U2F tokens) and mobile authenticator apps (e.g., Google Authenticator, Authy) satisfy the MFA requirement of presenting two independent evidence factors. The choice between them hinges on three practical dimensions: security posture, user experience, and total cost of ownership. Hardware keys provide a cryptographic “something you have” factor that is isolated from the operating system, which reduces the attack surface for credential‑theft techniques such as phishing. Mobile apps are free, widely supported, and require no additional hardware, but they depend on the security of the user’s phone and are vulnerable if the device is compromised. By modelling illustrative cost inputs, breach‑impact assumptions, and adoption rates, the analysis shows that a mixed‑approach—primary hardware key with a mobile app as a backup—delivers the strongest overall balance for most remote‑worker populations, provided the organization can absorb the modest upfront token expense and manage token lifecycle processes.

Choice Score breakdown

Security 85/100 — Hardware keys add a cryptographic factor that is isolated from the host OS.
Usability 75/100 — Mobile apps are familiar; hardware keys require a tap but no code entry.
Cost 70/100 — Hardware keys have an upfront purchase price; apps are free.

Best for / Not best for

Best for

organizations that handle high‑value or regulated data
teams that experience frequent phishing attempts
workforces with modern laptops that support USB‑C, NFC, or Bluetooth tokens

Not best for

budget‑constrained teams that cannot absorb token purchase costs
environments where the majority of devices lack compatible ports for the chosen token form factor
situations where a single device must serve as the only MFA factor without any backup

Scenarios

Optimistic (33% likely)
Bulk purchase discounts lower token cost, adoption is high, and phishing incidents drop sharply while productivity improves because of faster logins. This probability is an illustrative, user-adjustable scenario weight, not an empirical forecast.
Likely (33% likely)
Standard retail pricing applies, 70 % of users adopt the hardware key, the remainder keep the mobile app, and a modest reduction in phishing risk is realized. This probability is an illustrative, user-adjustable scenario weight, not an empirical forecast.
Pessimistic (33% likely)
Higher token price and low user adoption limit security gains; frequent token loss drives up replacement costs. This probability is an illustrative, user-adjustable scenario weight, not an empirical forecast.

Calculations

Metric	Result	Formula
2‑Year Total Cost of Ownership (TCO) – Hardware Key	44 USD per user	initial_cost + (initial_cost × replacement_rate × years)
Expected Phishing‑Related Breach Cost Reduction	1,500 USD per user over 2 years	(baseline_breach_prob - reduced_breach_prob) × breach_impact
Average Login Time Difference	5 seconds faster per login with hardware key	login_time_app - login_time_key
Weighted Composite Phishing‑Resistance Score (0‑100)	81	(security_score × weight_security) + (usability_score × weight_usability)

Pros & cons

Pros

Hardware keys use public‑key cryptography that is isolated from the host device, limiting exposure if the workstation or phone is compromised.
Tap‑and‑go interaction typically requires fewer seconds per login than entering a time‑based code.
A single hardware key can be used across multiple services (e.g., Google Workspace, Microsoft 365, Salesforce) that support FIDO2/U2F.
Mobile authenticator apps are free, require no additional purchase, and work on any smartphone that can run the app.

Cons

Up‑front purchase cost for each hardware token; organizations must budget for initial acquisition and periodic replacement.
Physical tokens can be lost, damaged, or forgotten, requiring a backup authentication method and a process for secure replacement.
Not all legacy applications support FIDO2/U2F; some still rely on OTP‑style codes, which would still need a mobile app or a secondary token.
Mobile apps depend on the security of the user’s phone; a compromised phone could expose the OTP seed.

Assumptions

Hardware key unit price: 40 USD — Illustrative retail price for a common FIDO2 token in 2024; adjust per vendor quote.
Annual replacement / loss rate: 5 % — Illustrative industry estimate for physical token loss or damage; organization can refine based on historical asset loss data.
Average breach impact (phishing‑related credential theft): 50,000 USD — Illustrative figure drawn from publicly reported breach cost studies; replace with organization‑specific impact analysis.
Baseline phishing‑related breach probability (password + app MFA only): 5 % — Illustrative probability for a typical enterprise that uses only password plus OTP; adjust with internal incident data.
Reduced breach probability when using a hardware key: 2 % — Illustrative reduction reflecting the added cryptographic factor; organizations should validate with threat‑model outcomes.
Login time with mobile authenticator app: 10 seconds — Illustrative average time to open the app, read the code, and type it; actual times vary by user proficiency.
Login time with hardware security key: 5 seconds — Illustrative average time for a tap‑and‑go interaction; no code entry required.
Weight for security in composite score: 0.6 — Illustrative weight reflecting the organization’s emphasis on security.
Weight for usability in composite score: 0.4 — Illustrative weight reflecting the organization’s emphasis on user experience.
Illustrative scenario probability — Optimistic: 33% — A user-adjustable modeling weight used to compare scenarios; it is not a measured probability or forecast.
Illustrative scenario probability — Likely: 33% — A user-adjustable modeling weight used to compare scenarios; it is not a measured probability or forecast.
Illustrative scenario probability — Pessimistic: 33% — A user-adjustable modeling weight used to compare scenarios; it is not a measured probability or forecast.

Practical next steps

1. Inventory the device portfolio of remote workers (USB‑A, USB‑C, NFC, Bluetooth) to determine compatible token form factors.
2. Select a hardware key model that matches the most common interface (e.g., a USB‑C/NFC‑enabled token for modern laptops and phones).
3. Follow the identity‑provider documentation (Azure AD, Okta, Google Workspace, etc.) to enroll the hardware key as a primary factor.
4. Deploy a mobile authenticator app as a secondary factor for scenarios where the hardware token is unavailable (loss, travel, device incompatibility).
5. Create a token‑lifecycle policy that defines issuance, secure storage, loss reporting, and replacement procedures.
6. Conduct a brief training session (video + quick‑start guide) to demonstrate the tap‑and‑go workflow and the backup app process.
7. Enable logging and monitoring on the identity platform to track MFA method usage and detect any unexpected fallback to the app.

Methodology

The analysis starts with the baseline definition of MFA from CISA and Cisco, confirming that any additional factor beyond a password satisfies the security requirement. Remote‑work context is drawn from Remote.co to ensure relevance to distributed teams. All numeric inputs (cost, breach impact, adoption rates, etc.) are marked as illustrative assumptions that can be tuned by the organization. Simple arithmetic models calculate total cost of ownership, expected breach‑cost reduction, login‑time productivity, and a composite security‑usability score. Three scenario narratives (optimistic, likely, pessimistic) combine these calculations with illustrative probability weights to illustrate possible financial outcomes over a two‑year horizon. The final choice_score aggregates the three dimension scores (security, usability, cost) to provide an at‑a‑glance recommendation.

Sources

Sources support specific claims; they do not replace our analysis. Read the research and source standards.

FAQ

Can a hardware security key be used with all SaaS applications?: Most modern SaaS platforms that support FIDO2 or U2F (e.g., Google Workspace, Microsoft 365, Salesforce) work with hardware keys. Legacy services that only accept OTP codes will still require a mobile authenticator app as a secondary factor.
What should I do if I lose my hardware key?: Enroll a spare key during initial provisioning and keep a mobile authenticator app as an emergency factor. Administrators can reset the lost key after verifying the user’s identity through existing identity‑provider workflows.
Does using a mobile authenticator app drain my phone battery or expose me to malware?: Authenticator apps generate codes locally and have minimal impact on battery life. However, if the phone itself is compromised, an attacker could potentially extract the secret seed, so the security of the device remains important.

Related decisions

What are the security differences between FIDO2 keys and OTP apps?
How to set up password‑less login for remote employees?
What is the best backup strategy for MFA devices?

Disclaimers

This report provides general guidance and should not replace a formal risk assessment conducted by your organization’s security team.

All monetary figures, probabilities, and performance metrics are illustrative; replace them with organization‑specific data before budgeting or decision‑making.