A hard token is a physical device and a soft token is software, but what matters is whether it is phishing-resistant: FIDO2 security keys and passkeys are, while OTP fobs, authenticator-app codes, push and SMS are not. Tell this planner who signs in, on what devices and with what budget, and it recommends a method for each group, shows what NIS2, DORA and PCI DSS actually require (none of the EU texts names FIDO2), and builds a rollout plan you can copy. Everything runs in your browser.
No download, no card
Phishing-resistant coverage
100%Phishing-resistant for every group
3 of 3 groups on a phishing-resistant primary method · 2 regimes mapped
Your users and estate
Watch-outs
medium priority: Phone-based help desk resets are a common social-engineering path. Verify the caller before issuing a time-limited enrolment code: call back on a number from the HR record, require manager approval, or use a video check.
Backup: a passkey on a second device (for example the work phone) so a lost laptop is not a lockout. Check that your identity provider allows the passkey type you pick.
Move remote access behind the identity provider so the VPN or zero-trust gateway sign-in can use FIDO2. A VPN that only accepts RADIUS usually cannot.
Phishing-resistant or not: every method
Per CISA’s phishing-resistant MFA fact sheet and NIST SP 800-63B-4. “Hard token” describes the form, not the strength: an OTP fob is a hard token and is still phishable.
Method
Form
Phishing-resistant?
Why
FIDO2 security key (device-bound passkey)
Hard token
Yes
The credential is bound to the real site’s domain, so a lookalike site cannot get a usable sign-in. Nothing is typed, so nothing can be relayed.
Platform authenticator (device-bound passkey on a managed laptop or phone)
Built into the device
Yes
Same origin binding as a security key. It is tied to that one device, so a new or lost device means enrolling again.
Synced passkey
Soft token
Yes
Still origin-bound, so still phishing-resistant at sign-in. The private key can be exported to the sync service, so the security of that cloud account matters.
Smart card or certificate-based sign-in (PKI)
Hard token
Yes
Channel binding ties the sign-in to the TLS connection, so a relaying site cannot reuse it.
Authenticator-app push with number matching
Soft token
No
Resists push bombing, but a real-time phishing proxy can show the user the right number and pass the approval through.
Push approval without number matching
Soft token
No
Open to push bombing (MFA fatigue) and to phishing.
TOTP authenticator app (soft token)
Soft token
No
The user types the code, so a phishing page can collect it and replay it within its lifetime.
OTP hardware token (key fob)
Hard token
No
Being hardware does not make it phishing-resistant: the code is typed, so it can be phished and relayed like an app code.
SMS or voice code
Phone number
No
Phishable, and exposed to SIM swap and SS7 interception.
TL;DR
What this tool is
Hard token or soft token describes the form, not the strength. A FIDO2 security key (hard) and a passkey (soft) are phishing-resistant; an OTP key fob (hard), an authenticator-app code (soft), push and SMS are not.
Answer questions about your users (admins, office staff, BYOD, frontline and shared devices, remote access, high-value roles, contractors, developers, customers), devices, recovery and hardware budget.
Get a primary method, a backup, interim options for systems that cannot use FIDO2 yet, and what to avoid, for each group, with a phishing-resistant coverage score.
Map NIS2, the NIS2 implementing regulation, DORA and its RTS, PCI DSS v4.0.1, OMB M-22-09, NIST SP 800-63B-4, Cyber Essentials and the Essential Eight to what each text actually says, with article references and source links.
Get a phased rollout plan (admins first) and copy everything as a plain-text report. Runs in your browser; nothing is uploaded.
Hard token vs soft token vs passkey
“Hard token” and “soft token” describe where the secret lives. “Phishing-resistant” describes whether a fake sign-in page can steal and reuse what the user does. CISA calls phishing-resistant MFA “the gold standard” and names two kinds: FIDO/WebAuthn and PKI-based. NIST SP 800-63B-4 (final, July 2025) says authenticators that need the user to type an output, such as OTP and out-of-band codes, “SHALL NOT be considered phishing-resistant”.
FIDO2 security key (device-bound passkey) (hard token): phishing-resistant. A USB, NFC or Bluetooth key that holds a FIDO2/WebAuthn credential. The private key cannot be copied off the device. The credential is bound to the real site’s domain, so a lookalike site cannot get a usable sign-in. Nothing is typed, so nothing can be relayed. NIST: Phishing-resistant (verifier name binding, Sec. 3.2.5). A hardware key with a non-exportable private key can meet AAL3. CISA: Phishing-resistant MFA: the "gold standard" (FIDO/WebAuthn).
Platform authenticator (device-bound passkey on a managed laptop or phone) (built into the device): phishing-resistant. A FIDO2/WebAuthn credential held in the laptop or phone’s secure hardware and unlocked with a PIN or biometric. Windows Hello for Business is a common workforce example. Same origin binding as a security key. It is tied to that one device, so a new or lost device means enrolling again. NIST: Phishing-resistant (Sec. 3.2.5). Can meet AAL3 only if the key is non-exportable and hardware-protected. CISA: Phishing-resistant MFA (FIDO/WebAuthn "platform" authenticator).
Synced passkey (soft token): phishing-resistant. A FIDO2 passkey that a platform or password manager copies across the user’s devices through a cloud account. Still origin-bound, so still phishing-resistant at sign-in. The private key can be exported to the sync service, so the security of that cloud account matters. NIST: Allowed up to AAL2 (Appendix B). "Syncable authenticators SHALL NOT be used at AAL3" (Sec. 2.3.2). CISA: Phishing-resistant MFA (FIDO/WebAuthn).
Smart card or certificate-based sign-in (PKI) (hard token): phishing-resistant. A certificate on a smart card or device, used with client-authenticated TLS. US government PIV and CAC cards are examples. Channel binding ties the sign-in to the TLS connection, so a relaying site cannot reuse it. NIST: Phishing-resistant through channel binding (Sec. 3.2.5). CISA: Phishing-resistant MFA (PKI-based), "less widely available" and needs mature identity management.
Authenticator-app push with number matching (soft token): not phishing-resistant. A prompt on the phone app; the user types the number shown on the sign-in screen to approve. Resists push bombing, but a real-time phishing proxy can show the user the right number and pass the approval through. NIST: Out-of-band authenticators are not phishing-resistant (Sec. 3.2.5). CISA: App-based: "vulnerable to phishing", "resistant to push bombing". A best option for organisations that cannot yet deploy phishing-resistant MFA.
Push approval without number matching (soft token): not phishing-resistant. A tap-to-approve prompt with no extra step. Open to push bombing (MFA fatigue) and to phishing. NIST: Out-of-band; not phishing-resistant (Sec. 3.2.5). CISA: Vulnerable to push bombing and user error.
TOTP authenticator app (soft token) (soft token): not phishing-resistant. A six-digit code that changes every 30 seconds in an authenticator app. The user types the code, so a phishing page can collect it and replay it within its lifetime. NIST: OTP authenticators involve manual entry and "SHALL NOT be considered phishing-resistant" (Sec. 3.2.5). CISA: App-based OTP: vulnerable to phishing; SS7 and SIM swap do not apply.
OTP hardware token (key fob) (hard token): not phishing-resistant. A physical fob that shows a one-time code. It is a hard token, but it is not a FIDO2 key. Being hardware does not make it phishing-resistant: the code is typed, so it can be phished and relayed like an app code. NIST: OTP: manual entry, not phishing-resistant (Sec. 3.2.5). CISA: Token-based OTP: vulnerable to phishing.
SMS or voice code (phone number): not phishing-resistant. A code sent by text message or phone call. Phishable, and exposed to SIM swap and SS7 interception. NIST: "Use of the PSTN for out-of-band verification is restricted" (Sec. 3.1.3.3). CISA: "Should only be used as a last resort MFA option", as a temporary step while moving to stronger MFA.
What the regulations actually say about MFA
None of NIS2, the NIS2 implementing regulation, DORA or the DORA RTS contains the words FIDO2, WebAuthn or passkey. They require multi-factor or strong authentication matched to risk and asset classification. PCI DSS, OMB M-22-09, NIST and Cyber Essentials are more specific, as below.
NIS2 Directive (EU) 2022/2555
Essential and important entities in the EU, through national law. Member States had to apply the measures from 18 October 2024.
Art. 21(2)(j): Cybersecurity risk-management measures must include "the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate."
Art. 21(2)(i): "human resources security, access control policies and asset management".
Does it require FIDO2? No. The Directive does not mention FIDO2, WebAuthn or passkeys. It asks for multi-factor or continuous authentication "where appropriate" and leaves the method to you.
DNS providers, TLD registries, cloud, data centre, CDN, managed and managed security service providers, online marketplaces, search engines, social networks and trust service providers.
Annex, 11.6.2(a): Ensure "the strength of authentication is appropriate to the classification of the asset to be accessed".
Annex, 11.6.3: "to the extent feasible use state-of-the-art authentication methods, in accordance with the associated assessed risk and the classification of the asset to be accessed".
Annex, 11.7.1: Users must be "authenticated by multiple authentication factors or continuous authentication mechanisms for accessing the relevant entities’ network and information systems, where appropriate, in accordance with the classification of the asset to be accessed."
Annex, 11.7.2: "the strength of authentication is appropriate for the classification of the asset to be accessed."
Does it require FIDO2? No. It asks for "state-of-the-art" methods matched to asset classification, without naming a technology.
DORA: Regulation (EU) 2022/2554 and RTS (EU) 2024/1774
EU financial entities (banks, insurers, investment firms, payment institutions and others). DORA applies from 17 January 2025.
DORA Art. 9(4)(d): Financial entities shall "implement policies and protocols for strong authentication mechanisms, based on relevant standards and dedicated control systems".
RTS 2024/1774 Art. 20: Identity management policies must "ensure the unique identification and authentication of natural persons and systems" accessing the entity’s information.
RTS 2024/1774 Art. 21, point (f): The access control policy must cover "(i) the use of authentication methods commensurate to the classification ... and to the overall risk profile of ICT assets and considering leading practices; (ii) the use of strong authentication methods in accordance with leading practices and techniques for remote access to the financial entity’s network, for privileged access, for access to ICT assets supporting critical or important functions or ICT assets that are publicly accessible".
RTS 2024/1774 Art. 33, point (d): For entities under the simplified framework: "authentication methods that are commensurate to the classification ... and to the overall risk profile of ICT assets, and which are based on leading practices".
Does it require FIDO2? No. Neither DORA nor the RTS mentions FIDO2, WebAuthn or passkeys. They require "strong authentication" based on "relevant standards" and "leading practices".
Anyone who stores, processes or transmits payment card data, for access to the cardholder data environment (CDE). 8.4.2 and 8.5.1 became mandatory after 31 March 2025.
8.4.1: "MFA is implemented for all non-console access into the CDE for personnel with administrative access."
8.4.2: "MFA is implemented for all access into the CDE."
8.4.3: MFA for "all remote network access originating from outside the entity’s network that could access or impact the CDE", including all remote access by third parties and vendors.
8.5.1: MFA systems are not susceptible to replay attacks, cannot be bypassed by any users (including administrators) unless documented and authorised by management as a time-limited exception, use at least two different types of factors, and require success of all factors before access.
PCI SSC FAQ 1595 (May 2025): Synced passkeys implemented according to the FIDO2 requirements are considered phishing-resistant authentication and can be used in place of MFA for 8.4.2.
PCI SSC FAQ 1596 (May 2025): Phishing-resistant authentication alone is not accepted as MFA for 8.4.1 or 8.4.3: it must be used with another factor.
Does it require FIDO2? Requirement 8 is factor-based. The Council’s FAQs name FIDO2: FIDO2-conformant passkeys count as phishing-resistant authentication for 8.4.2.
US OMB Memorandum M-22-09 (federal zero trust strategy)
US federal agencies and their systems, including access by contractors and partners.
Section A (Identity), actions: "For agency staff, contractors, and partners, phishing-resistant MFA is required." "For public users, phishing-resistant MFA must be an option."
Section A, part 2 (Multi-factor authentication): For routine self-service access, agency systems "must discontinue support for authentication methods that fail to resist phishing, including protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications."
Section A, part 2: Recovery processes "should be designed with the expectation that they are exceptional, and require high-friction methods that are costly for an adversary to overcome, such as in-person verification, live video interaction, or other similar methods."
Does it require FIDO2? Yes. It names PIV and the W3C Web Authentication standard (WebAuthn, "developed as part of the FIDO Alliance’s FIDO2 standards"), and permits FIDO2 and WebAuthn authenticators where PIV is not practical.
US federal agencies by policy; widely used as a reference elsewhere.
Sec. 2.2.2 (AAL2): "Verifiers SHALL offer at least one phishing-resistant authentication option at AAL2." Federal agencies "SHALL require their staff, contractors, and partners to use phishing-resistant authentication to access federal information systems."
Sec. 2.3.2 (AAL3): The authenticator "SHALL have a non-exportable private key and SHALL provide phishing resistance." "Syncable authenticators SHALL NOT be used at AAL3."
Sec. 3.2.5 (Phishing resistance): Two methods count: channel binding (for example PIV/CAC with client-authenticated TLS) and verifier name binding (WebAuthn, used by FIDO2 authenticators). Authenticators that need manual entry of an output, such as out-of-band and OTP, "SHALL NOT be considered phishing-resistant."
Sec. 3.1.3.3: "Use of the PSTN for out-of-band verification is restricted."
Does it require FIDO2? Yes, as the example of verifier name binding (WebAuthn / FIDO2). Synced passkeys are covered in Appendix B as syncable authenticators, usable up to AAL2.
UK organisations certifying to Cyber Essentials or Cyber Essentials Plus.
User access control, requirements: "implement MFA, where available – authentication to cloud services must always use MFA".
User access control, passwordless authentication: "FIDO2 authenticators are regarded as MFA because user authentication is performed."
User access control, MFA: SMS "is not the most secure type of MFA but still offers a huge advantage over not using any MFA at all"; use alternatives where they work for you.
Does it require FIDO2? Yes. v3.3 names FIDO2 authenticators and treats them as passkeys and as MFA. It requires MFA, not phishing resistance specifically.
Australian government entities by policy; widely adopted by Australian businesses.
Multi-factor authentication strategy: ASD’s November 2023 update raised the bar so that phishing-resistant MFA is required from Maturity Level Two. Check the current maturity model for exactly which users, services and workstations each level covers.
Does it require FIDO2? The model asks for phishing-resistant MFA as an outcome. Read the current ASD text before citing specific controls.
Prepare: confirm your identity provider can require phishing-resistant authentication, set up two break-glass accounts with security keys, and fix recovery so it is not weaker than the new authenticators.
Admins, IT and help desk: two phishing-resistant authenticators each; CISA suggests help desk and IT system administrators as an initial group.
High-value roles, remote access and developers: the people and entry points attackers target next.
The general workforce: in waves, with a second authenticator registered before the old method is removed.
Frontline, shared devices and contractors: usually security keys, because there is no personal device to hold a passkey.
Remove weaker methods: SMS, voice and plain push off; OTP and number-matching push only as documented exceptions with an end date.
Hard token vs soft token: what is the difference?+
A hard token is a physical device: a FIDO2 security key, a smart card, or an OTP key fob that shows a code. A soft token is software on a device you already have: an authenticator app that shows a code or receives a push, or a passkey stored on a phone or laptop. The difference that matters for security is phishing resistance, and it cuts across both: a FIDO2 security key and a synced passkey are phishing-resistant, while an OTP key fob and an authenticator-app code are not, because the user types the code and a phishing page can relay it.
Is a hardware token phishing-resistant?+
Only if it is a FIDO2/WebAuthn security key or a PKI smart card. Those bind the sign-in to the real site (NIST SP 800-63B-4 calls it verifier name binding and channel binding), so a lookalike site gets nothing usable. An OTP hardware token is a hard token too, but NIST says authenticators that need manual entry of an output "SHALL NOT be considered phishing-resistant", and CISA lists token-based OTP as vulnerable to phishing.
Does NIS2 require FIDO2?+
No. NIS2 Article 21(2)(j) requires "the use of multi-factor authentication or continuous authentication solutions ... where appropriate". The Directive does not mention FIDO2, WebAuthn or passkeys. For digital infrastructure and digital providers, Implementing Regulation (EU) 2024/2690 adds that authentication strength must be appropriate to the classification of the asset and that "state-of-the-art" methods should be used to the extent feasible. FIDO2 is one strong way to show that, especially for admin and remote access, but it is a choice, not a mandate.
How does FIDO2 support NIS2 compliance?+
It gives you evidence for Article 21(2)(j) and (i): multi-factor authentication that resists phishing, applied according to the classification of what is being accessed. Put FIDO2 security keys or device-bound passkeys on admins and critical systems first, synced passkeys or platform authenticators on the wider workforce, and document why each group got its method. National laws transposing NIS2 and your supervisor may add detail, so check them.
Do you need a FIDO2 key for DORA compliance?+
No specific technology is required. DORA Article 9(4)(d) requires "strong authentication mechanisms, based on relevant standards", and the ICT risk management RTS, Delegated Regulation (EU) 2024/1774, Article 21 point (f) requires strong authentication "in accordance with leading practices" for remote access, privileged access, systems supporting critical or important functions and publicly accessible ICT assets. Neither text mentions FIDO2. Phishing-resistant FIDO2 keys or passkeys are a defensible reading of "leading practices" for those four areas.
Passkeys vs FIDO2 security keys: which should we use?+
Usually both. Synced passkeys are phishing-resistant and easy to recover, which suits customers and most staff; NIST SP 800-63B-4 allows them up to AAL2 but says syncable authenticators "SHALL NOT be used at AAL3". Device-bound FIDO2 security keys keep the private key on one device, which suits admins, break-glass accounts and shared devices where no phone is available.