Set Up Passkeys and FIDO2 Keys: 13 Steps, 70 Min [2026]
![Set Up Passkeys and FIDO2 Keys: 13 Steps, 70 Min [2026]](https://trendintech.com/wp-content/uploads/2026/10/passkeys-fido2-security-keys-setup-tutorial-2026-gen.webp)
A password and a six-digit code used to be good enough. In October 2026 it is not, because the phishing kits criminals rent by the week now sit between a victim and the real login page in real time, capturing the password, the one-time code, and the session cookie in a single pass. That style of attack, often called adversary-in-the-middle phishing, is exactly why security teams keep steering people toward passkeys and FIDO2 hardware security keys instead of ordinary two-factor codes.
The sections below cover through how to set up passkeys and FIDO2 security keys for your own accounts, then how to roll the same setup out to a team or an organization. You will register a passkey, enroll a backup hardware key, turn off the weaker fallback methods that undermine the whole exercise, and build a small script that checks whether your setup is actually phishing resistant rather than just technically “on.” Thirteen concrete steps, six code blocks you can copy and run, and a troubleshooting table for when a key will not pair with a laptop that insists it has no idea what a FIDO2 device is.
Don't miss new tech stories on Google
Add TrendinTech once in the Google app and our stories appear in your news suggestions.
Why Passwords and Basic MFA Still Get Phished in 2026
Multi-factor authentication was sold for years as the fix for stolen passwords. For the SMS code and the six-digit authenticator-app code, that promise has quietly eroded. A proxy-based phishing page can show the victim the real login form, relay whatever they type to the real site, and grab the resulting session token before the victim even notices anything odd. The password gets stolen. The one-time code gets stolen. The session itself gets stolen. None of that requires the attacker to break any cryptography, only to sit in the middle of a connection the user believes is direct.
The Cybersecurity and Infrastructure Security Agency has spent years pushing organizations to turn on some form of multi-factor authentication, and its guidance on requiring MFA remains one of the most cited references for small and midsize businesses setting baseline account security. The gap it has increasingly called out is that not every MFA method offers the same protection. A code you type into a browser can be relayed by a phishing page. A credential that is cryptographically bound to the real website cannot be, because the browser itself refuses to hand that credential to a look-alike domain.
That distinction is the entire reason passkeys and FIDO2 security keys exist. The FIDO Alliance, the industry group behind the FIDO2 and WebAuthn standards that Windows, macOS, Android, iOS, and every major browser now support, put it plainly in a written 2024 response to European regulators: “If possible, avoid using SMS and voice calls to provide one-time codes and consider deploying phishing resistant tokens such as smart cards and FIDO2 (Fast IDentity Online) security keys.” That guidance from the FIDO Alliance’s comments on draft EU NIS2 guidance has only become more relevant as phishing kits have gotten cheaper and more automated since then.
The scale of adoption backs up the push. The FIDO Alliance reported on October 15, 2026 that roughly 7 billion passkeys are now in active use worldwide, a figure the organization framed as the start of the next phase of passwordless authentication rather than its conclusion. That is not a niche feature anymore. It is the default sign-in option on most major consumer platforms, and increasingly the required option for administrators and anyone who touches sensitive systems at work.
Passkeys vs FIDO2 Security Keys vs Authenticator Apps: What Changes
People use “passkey” and “security key” almost interchangeably, which causes real confusion when you are trying to set either one up. Both rely on the same underlying FIDO2 and WebAuthn cryptography. The difference is where the private key lives and how it gets backed up.
A passkey is a credential created and stored by a platform, your phone, your laptop, or a password manager, using public key cryptography. When you sign in, the device signs a one-time challenge from the website using a private key that never leaves the device. A synced passkey is backed up to an account like iCloud Keychain or a Google Password Manager vault and follows you across your devices. A device-bound passkey stays on a single piece of hardware and never syncs anywhere, which is why some organizations require it for administrator accounts: there is no cloud backup to compromise.
A FIDO2 security key is a small piece of dedicated hardware, usually a USB-A, USB-C, Lightning, or NFC device from a vendor like Yubico, that stores the private key in its own secure element and never syncs to any cloud service at all. You plug it in or tap it, touch a sensor, and it signs the challenge. Security keys do not depend on your phone’s battery, your phone’s operating system, or a cloud account being available, which makes them the preferred backup for passkeys and the preferred primary credential for high-risk accounts.
An authenticator app generating six-digit time-based codes, by contrast, is not bound to the website at all. The code is just a number, and a phishing proxy can ask for it and relay it to the real site exactly as easily as it relays a password. That is the core reason CISA and the FIDO Alliance both rank authenticator-app codes below passkeys and FIDO2 keys, even though an app is still much better than no second factor at all.
| Authentication method | Resists real-time phishing proxies | Works without a network connection | Typical backup path |
|---|---|---|---|
| Password only | No | Yes | None |
| SMS or voice one-time code | No | No | Carrier dependent, interceptable |
| Authenticator app code (TOTP) | No | Yes, once set up | Manual backup codes |
| Synced passkey (phone or password manager) | Yes | Yes, on the registered device | Cloud account sync |
| Device-bound passkey or FIDO2 security key | Yes | Yes | A second enrolled key |
The UK’s National Cyber Security Centre explained the mechanism behind that top row of resistance in a technical comparison of credential types for personal use: “Unlike password-based credentials, FIDO2 uses asymmetric cryptography where the user signs a unique per-request-challenge and the private key is never shared with the user’s client or relying party so it cannot be copied or stolen by a credential harvesting site.” Read the full breakdown on the NCSC’s comparison of traditional and FIDO2 credentials. That one property, the private key never leaving the device and never being transmitted anywhere, is what separates a passkey from every code-based method that came before it.
Prerequisites: Accounts, Devices, and Versions You Need
You do not need to buy anything to start. Every modern phone and laptop already has a built-in passkey authenticator. A hardware FIDO2 key is optional for individuals and close to mandatory for administrators, shared accounts, and anyone whose phone is not always within reach. Here is what to have ready before you start the numbered steps below.
| Requirement | Minimum version or spec | Why it matters |
|---|---|---|
| Operating system | Windows 10 or 11, macOS Ventura or later, Android 9 or later, iOS/iPadOS 16 or later | Built-in platform passkey support (Windows Hello, Touch ID, Face ID, Android fingerprint and face sign-in) |
| Browser | A current release of Chrome, Edge, Safari, or Firefox | WebAuthn and passkey autofill support |
| Hardware security key (optional but recommended) | Any FIDO2/WebAuthn-certified key, firmware 5.7.4 or later for Yubico’s current line | Offline, phishing-resistant backup credential that is not tied to your phone |
| Key management utility | ykman (YubiKey Manager CLI), latest release | Lets you inspect, PIN-protect, and reset a hardware key from a terminal |
| Python (for the project later in this guide) | Python 3.10 or later, with the python-fido2 package | Builds the local readiness checker in the final section |
| A recovery plan | At least one offline note of your recovery codes, plus a second enrolled authenticator | So you cannot lock yourself out mid-setup |
If you plan to roll this out at work rather than just for yourself, also check whether your identity provider, Microsoft Entra ID, Okta, Google Workspace, or a dedicated authentication platform, already supports FIDO2 and passkeys natively. Most do at this point. Enterprises that need Windows logon, VPN, and on-premises application coverage in one package increasingly look at purpose-built products such as Intercede’s MyID Authenticate, which launched on October 12, 2026 specifically to cover that gap, a point this guide returns to in the organization-wide rollout section.
Step 1 to 3: Audit Your Accounts and Build a Recovery Plan First
Step 1: List your highest-risk accounts. Start with email, since it is usually the account that can reset every other account. Add your password manager, your bank and investment accounts, your work identity provider, your domain registrar, your cloud provider console, and any account with administrator privileges over other people’s data. You are not trying to protect everything on day one. You are trying to protect the handful of accounts that, if taken over, would let an attacker take over everything else.
Step 2: Decide which authenticators you will actually use. For most individuals, a synced passkey on your phone plus one hardware FIDO2 security key as backup covers nearly every case. For administrators, shared service accounts, or anyone who cannot risk a cloud sync being the single point of failure, use a device-bound passkey or a hardware key as the primary credential, with a second hardware key stored somewhere safe as the backup. Buy two keys, not one, from the start. A single key is a single point of failure, which defeats the purpose of the exercise.
Step 3: Write down a recovery plan before you change a single setting. Every account you are about to touch needs an answer to the question of what happens if you lose this device. Generate and print or write down the recovery codes most services offer. Store that paper somewhere physically secure, not in the same password manager you are trying to protect. If the service supports multiple registered passkeys or keys, plan to register at least two before you remove any older, weaker method. This step feels slow. It is the single most common thing people skip, and skipping it is how people end up locked out of their own email at midnight.
Step 4 to 6: Register Your First Passkey and a Backup FIDO2 Key
Step 4: Register a passkey on your primary device. In almost every major service, the path is the same. Open account settings, find the security or sign-in section, choose to add a passkey, and follow the on-screen prompt. Your operating system will ask you to confirm with a fingerprint, face scan, or device PIN, which creates the key pair and registers the public half with the website. Nothing is typed, nothing can be phished, because the browser itself checks that the domain asking for the credential matches the domain it was created for.
Step 5: Check your hardware key before you enroll it. If you are adding a physical FIDO2 security key, plug it in first and confirm it is healthy and set up with its own PIN. Yubico’s free ykman command-line tool is the fastest way to do this on Windows, macOS, or Linux.
# Check FIDO2 application status and PIN settings on a connected key
ykman fido info
# Set or change the FIDO2 PIN (required before some services will let you register the key)
ykman fido access change-pin
# List every FIDO2/WebAuthn application slot currently in use on the key
ykman fido credentials list
A healthy key returns output similar to this:
$ ykman fido info
PIN is set, with 8 attempts remaining.
FIPS Approved Mode: No
Options:
rk: True
up: True
uv: False
Max resident credentials: 25
Minimum PIN length: 4
Firmware version: 5.7.4
If “PIN is set” shows as False, run the change-pin command before trying to register the key anywhere. Most services will silently refuse an unprotected key, or will skip the step entirely in a way that leaves your enrollment weaker than you intended.
Step 6: Enroll the hardware key as a second authenticator, not a replacement for your first passkey. Go back into the same security settings page where you registered your passkey in step 4, and look for an option to add another security key or sign-in method. Register the hardware key the same way, confirming with a touch or tap. You should now see two authenticators listed for the account: one synced or platform passkey, and one hardware-bound FIDO2 key. That pairing is what gives you phishing resistance and a working recovery path at the same time.
If you want to confirm WebAuthn support programmatically, Yubico’s open source python-fido2 library lets you query a connected device directly rather than relying on a browser prompt.
# pip install fido2
from fido2.hid import CtapHidDevice
from fido2.ctap2 import Ctap2
devices = list(CtapHidDevice.list_devices())
if not devices:
print("No FIDO2 device detected. Plug in your security key and try again.")
else:
for dev in devices:
ctap2 = Ctap2(dev)
info = ctap2.get_info()
print(f"Device: {dev.descriptor.product_name}")
print(f"Versions supported: {info.versions}")
print(f"AAGUID: {info.aaguid.hex()}")
Running that script with a key plugged in returns something like this:
Device: YubiKey OTP+FIDO+CCID
Versions supported: ['U2F_V2', 'FIDO_2_0', 'FIDO_2_1']
AAGUID: 2fc0579f811347eab116bb5a8db9202a
Seeing FIDO_2_1 in that list confirms the key supports the current CTAP2.1 protocol, which is what most modern passkey-on-hardware flows expect.
Step 7 to 9: Turn On Phishing-Resistant MFA for Google, Microsoft, and GitHub
Step 7: Set up a passkey on your Google account. Sign in to your Google Account security settings, open the section covering how you sign in to Google, and select passkeys. Google will offer to create a passkey on the device you are using and will also let you add security keys as a separate entry in the same section. Add both. Google treats a hardware security key and a device passkey as independent entries, so losing one does not lock you out of the other.
Step 8: Set up a passkey on your Microsoft account. From your Microsoft account’s security page, choose advanced security options, then add a new way to sign in, and select passkey. Microsoft 365 and Entra ID accounts route through the same underlying WebAuthn flow, so a passkey registered for your personal Microsoft account uses the identical standard as one registered for a work account, just under a different administrative policy.
Step 9: Set up a passkey on your GitHub account. In GitHub, go to Settings, then Password and authentication, then add a passkey. GitHub supports both platform passkeys and hardware FIDO2 security keys under the same menu, and it allows multiple registered credentials, so register your phone first and a hardware key second. For anyone with push access to production repositories, this single change closes one of the most common entry points attackers use against developer accounts.
| Platform | Where to find it | Hardware key support alongside passkeys |
|---|---|---|
| Google Account | Security, how you sign in to Google, passkeys | Yes, listed separately under security keys |
| Microsoft Account / Entra ID | Security, advanced security options, add a new way to sign in | Yes, plus Windows Hello for Business for managed devices |
| GitHub | Settings, password and authentication, add a passkey | Yes, multiple credentials allowed |
| Identity providers with SAML or OIDC (Okta, Entra ID, dedicated FIDO platforms) | Admin console, authentication policies | Yes, and usually required for admin roles |
Step 10 to 11: Enforce FIDO2-Only Sign-In for Admins and Remote Access
Step 10: Require phishing-resistant authentication for administrator and remote-access accounts first. CISA’s guidance on multi-factor authentication singles out two groups to protect before anyone else: administrators, and employees who handle sensitive data or connect remotely. If you manage identity policy for a team, start there rather than trying to flip the switch for every user on day one. Review CISA’s own recommendations on requiring multi-factor authentication for small and midsize businesses before writing your own policy, since it lays out the baseline most auditors will expect to see.
Step 11: Write a conditional access policy that excludes weaker methods for privileged roles. In Microsoft Entra ID, this means building an authentication strengths policy scoped to your administrator role group, then assigning it inside a conditional access rule. The exact console labels change between tenants, so treat the example below as illustrative syntax to adapt rather than something to paste verbatim.
# Illustrative Microsoft Graph PowerShell example.
# Adjust role IDs, group IDs, and policy names to match your own tenant.
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
DisplayName = "Require phishing-resistant MFA for admins"
State = "enabled"
Conditions = @{
Users = @{ IncludeRoles = @("Global Administrator", "Security Administrator") }
Applications = @{ IncludeApplications = @("All") }
}
GrantControls = @{
Operator = "OR"
BuiltInControls = @()
AuthenticationStrength = @{ Id = "" }
}
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params
The important line is the authentication strength reference. Microsoft Entra ID ships a built-in phishing-resistant MFA authentication strength that only accepts passkeys, FIDO2 security keys, Windows Hello for Business, and smart cards, and explicitly excludes SMS, voice calls, and authenticator-app codes. Pointing a conditional access policy at that strength, rather than a generic require-MFA control, is what actually closes the real-time phishing gap for the accounts that matter most.
Step 12 to 13: Remove SMS Fallbacks and Test Account Recovery
Step 12: Remove SMS and email codes as fallback options wherever the service allows it. Most phishing kits targeting ordinary users default to prompting for an SMS or email code because it is the weakest link left standing once a password is already compromised. Go back into the same security settings pages from steps 7 through 9 and look for an option to remove or turn off any text-message or voice-call recovery method. If a service will not let you remove SMS entirely, at minimum move it to the bottom of the list so passkeys and hardware keys are tried first.
Step 13: Test your recovery path on purpose, before you need it by accident. Sign out of the account on a device, then sign back in using only your backup FIDO2 key, not your phone. Confirm it works end to end. Then do the reverse. Confirm the account still works if the hardware key is left at home and you are relying only on the synced passkey. Never delete your only working authenticator while testing. The entire point of enrolling two credentials in steps 4 through 6 was to give you room to test one without risking a lockout.
If you suspect an account was already touched by a phishing attempt before you finished this setup, a password change by itself is not enough, since a stolen session cookie survives a password reset. Revoke active sessions and sign the account out everywhere, not just on the device you are using right now.
# Illustrative session-revocation pattern using a generic REST-style identity API.
# Replace the endpoint and token with the real values for your identity provider.
curl -X POST "https://your-idp.example.com/api/v1/users/{user_id}/sessions/revoke-all" \
-H "Authorization: Bearer $ADMIN_TOKEN" \
-H "Content-Type: application/json" \
-d '{"reason": "suspected credential phishing, revoking all active sessions"}'
Rolling Out Passkeys and FIDO2 Keys Across a Whole Organization
Doing this for your own accounts is an afternoon of work. Doing it for a few hundred employees across Windows desktops, VPNs, and on-premises applications that were never built with WebAuthn in mind is a different project, which is why several vendors have built dedicated platforms around it this year.
Intercede launched MyID Authenticate on October 12, 2026, pitched specifically at government and enterprise customers who need phishing-resistant sign-in that covers Windows desktops, cloud services, and on-premises applications in one deployment rather than stitching several products together. It supports both device-bound and synced passkeys plus FIDO2 security keys, connects to cloud and third-party applications through SAML 2.0 and OpenID Connect, and reaches VPNs and network devices through RADIUS, with a dedicated Passkey Windows Logon option and federation to Microsoft Entra ID and Microsoft 365. The product made its international debut at GovWare 2026 in Singapore, October 13 through 15, and can run on premises on Windows Server 2022 or 2025, or in the cloud across AWS, Azure, and private cloud environments. Intercede’s CEO Klaas van der Leest and Chief Product Officer Dan McLoughlin have positioned it as a standalone platform that optionally integrates with the company’s existing MyID credential management system for organizations that also need high-assurance smart card issuance.
On the hardware side, the YubiKey 5 Series remains the most widely deployed line of FIDO2 security keys, and it went through a meaningful certification transition this year. Yubico shipped YubiKey 5.8 firmware with general availability on July 21, 2026, adding CTAP 2.3 support and a preview of the emerging WebAuthn signing extension on top of everything the 5.7.4 firmware already supported. Separately, Yubico’s FIPS-validated line moved from FIPS 140-2 to FIPS 140-3 certification, with the new YubiKey 5 FIPS Series receiving NIST certification under Certificate #5291 effective May 22, 2026. The older FIPS 140-2 validation followed a formal sunset path of its own: Yubico’s documentation states that the FIPS 140-2 certification for firmware 5.4.x moved to the Sunset List effective May 2026, and that all FIPS 140-2 certifications moved to the Historical List effective September 22, 2026. In practice that means organizations with a FIPS compliance requirement should be specifying the FIPS 140-3 generation of the YubiKey 5 Series now, not the older 140-2 models, even though Yubico has said customers may continue existing 140-2 purchases under previously approved projects.
| Milestone | Date | Current status |
|---|---|---|
| YubiKey 5 FIPS Series, firmware 5.7.4, NIST FIPS 140-3 certification (Certificate #5291) | May 22, 2026 | Current validated generation |
| YubiKey 5.8 firmware general availability, adds CTAP 2.3 and WebAuthn signing preview | July 21, 2026 | Current firmware release |
| YubiKey 5 FIPS Series, firmware 5.4.x, FIPS 140-2 certification | Effective May 2026 | Moved to Sunset List |
| All FIPS 140-2 certifications across NIST’s program | Effective September 22, 2026 | Moved to Historical List |
| FIDO Alliance passkey adoption milestone, approximately 7 billion passkeys in use | October 15, 2026 | Reported ecosystem scale |
Not every organization needs a dedicated identity platform, and not every FIDO2 device is a login key at all. SecuGen’s Unity 20 line, for example, is a fingerprint biometric device built for national digital identity programs rather than everyday account sign-in. SecuGen announced commercial availability of the Unity 20 MOSIP variant, which is compliant with the MOSIP SBI 2.0 L1 specification, on April 14, 2026. A related model, the Unity 20 USB-S Plus announced in December 2025, supports up to 20,000 stored fingerprint templates compared with up to 200 on the standard Unity 20 USB-S, which tells you the device is built for large-scale identity enrollment programs, not for protecting a single employee’s email account.
| Hardware category | Protocols and scope | Best fit |
|---|---|---|
| FIDO-only security key (Yubico Security Key line) | FIDO2/WebAuthn and FIDO U2F only | Budget-friendly backup key for individuals and small teams |
| Multi-protocol security key (YubiKey 5 Series, FIPS 140-3 generation for regulated use) | FIDO2/WebAuthn, FIDO U2F, CTAP1/2/2.1, plus PIV, OTP, OATH, OpenPGP | Mixed consumer and enterprise use, including government FIPS requirements |
| Platform passkey (phone, laptop, password manager) | FIDO2/WebAuthn via the operating system or browser | Everyday sign-in for most personal accounts |
| Biometric enrollment device (SecuGen Unity 20 family) | Fingerprint capture for national digital identity schemes such as MOSIP | Large-scale identity programs, not individual account login |
Five Common Pitfalls When Deploying Phishing-Resistant MFA
Enrolling only one authenticator. A single passkey on a single phone is one broken screen or one factory reset away from a lockout. Always register at least two independent authenticators before you consider the setup finished, exactly as outlined in steps 2, 3, and 6 above.
Leaving SMS enabled as an unused fallback. An attacker does not care that you prefer passkeys if the account still accepts an SMS code as an alternative. Any weaker method left active is a method a phishing kit will try first, which is why step 12 exists as its own dedicated task rather than an optional cleanup step.
Approving an MFA prompt you did not request. Repeated, unsolicited prompts are a known attack pattern called MFA fatigue, where an attacker who already has your password triggers prompt after prompt hoping you will tap approve just to make the notifications stop. Never approve a prompt you did not personally initiate, and treat a wave of unexpected prompts as an active attack worth reporting immediately rather than an annoyance to dismiss.
Confusing a device-bound passkey with a synced one when planning for loss. If your only passkey is device-bound and that device is lost, stolen, or wiped, there is no cloud copy to fall back on. That is a deliberate security tradeoff for high-risk accounts, but it means the backup hardware key from step 6 is not optional in that scenario. It is the entire recovery plan.
Rolling this out to end users before admins. It is tempting to announce a company-wide passkey mandate on day one. CISA’s own sequencing advice, and the reasoning behind step 10 above, is to lock down administrator and remote-access accounts first, since those are the accounts that can do the most damage if phished while the rest of the rollout is still in progress.
Troubleshooting: Eight Passkey and FIDO2 Problems and Fixes
| Problem | Likely cause | Fix |
|---|---|---|
| Browser does not offer a passkey option at sign-in | Outdated browser or an OS without a platform authenticator configured | Update the browser and operating system, then confirm Windows Hello, Touch ID, or your device’s fingerprint or face sign-in is already set up |
| Security key is not detected over USB | Faulty cable, a USB-C to USB-A adapter with a bad data connection, or a key that needs a firmware reset | Try a different port and cable, then run ykman fido info to confirm the key is recognized before touching the website again |
ykman fido access change-pin fails with a lockout warning | Too many incorrect PIN attempts, which can trigger a factory reset after a set number of failures | Stop guessing. If the attempts remaining shown by ykman fido info is low, treat the key as locked and switch to your backup authenticator instead of retrying |
| Passkey synced to your phone does not appear on your laptop | The devices are not signed into the same cloud account, or Bluetooth is off for the cross-device hybrid flow | Confirm both devices use the same Apple ID, Google account, or password manager vault, and enable Bluetooth so the laptop can relay the request to the phone |
| Service says passkeys are not supported even though the browser supports WebAuthn | The specific website has not enabled passkeys yet, even if it supports basic MFA | Fall back to the hardware FIDO2 key, which most sites that support WebAuthn security keys enable before they enable full passkey support |
| Admin cannot enforce the phishing-resistant authentication strength in Entra ID | The custom authentication strength was never scoped to the correct conditional access policy, or is still in report-only mode | Check the policy’s enforcement mode and confirm the authentication strength ID referenced in your script matches a strength that actually excludes SMS and TOTP |
| Locked out after removing SMS fallback too early | Only one authenticator was enrolled before the fallback was removed, skipping step 3’s recovery plan | Use the account’s documented recovery process immediately, and treat this as the reason steps 1 through 3 exist before any fallback removal |
| Python script cannot find any connected FIDO2 device | Missing USB permissions on Linux, or the python-fido2 package is not installed | Run pip install fido2, confirm the key is plugged in, and on Linux check that udev rules grant your user access to the device |
Advanced Tips: Device-Bound Passkeys, Sync, and Post-Quantum Readiness
Once the basic setup works, a few refinements separate a casual passkey user from a genuinely hardened one. First, decide deliberately between device-bound and synced passkeys rather than accepting whatever default your operating system offers. Synced passkeys are convenient and recover themselves automatically if you replace a device, which is the right tradeoff for most personal accounts. Device-bound passkeys and hardware FIDO2 keys are the right tradeoff for administrator accounts, financial accounts, and anything where a cloud account compromise should not be able to cascade into every other credential you own.
Second, if you manage identity for a regulated environment, track certification status rather than assuming last year’s hardware is still current. The shift from FIPS 140-2 to FIPS 140-3 on Yubico’s own product line this year is a useful reminder that FIDO2 certified and currently validated for your compliance regime are two different questions, and the answer to the second one changes on a schedule set by NIST, not by your procurement calendar.
Third, start paying attention to post-quantum cryptography support in your authentication stack even though it is not yet a near-term requirement for most organizations. Intercede’s MyID Authenticate was explicitly built and marketed around being quantum-ready alongside its phishing-resistant FIDO authentication, and vendors across the identity space are starting to describe their roadmaps the same way. None of this changes how you set up a passkey today, but it is worth knowing that the standards bodies behind FIDO2 are already planning the next cryptographic transition, the same way FIDO2 itself replaced password-plus-code MFA.
Finally, treat a dedicated password manager as the companion to this setup, not a competitor to it. A password manager still matters for the accounts that have not added passkey support yet, and a well-run one gives you a single, auditable place to see which of your accounts are still protected by nothing stronger than a password. If you have not already standardized on one, a password manager setup walkthrough is a reasonable next stop once your highest-risk accounts are covered by passkeys and FIDO2 keys.
Complete Working Project: Build a Local Passkey and FIDO2 Readiness Checker
Everything above is manual, click-through setup. This last piece is a small, complete Python script that scans for connected FIDO2 hardware, reports its capabilities, and prints a plain-language readiness summary you can run before and after your rollout to confirm nothing regressed. It builds directly on the python-fido2 checks from steps 5 and 6, combined into one reusable tool.
# fido_readiness_check.py
# Requires: pip install fido2
#
# Scans for connected FIDO2 security keys and prints a readiness report
# covering protocol support, PIN status, and resident key capacity.
from fido2.hid import CtapHidDevice
from fido2.ctap2 import Ctap2, ClientPin
def check_device(dev):
ctap2 = Ctap2(dev)
info = ctap2.get_info()
report = {
"product": getattr(dev.descriptor, "product_name", "Unknown FIDO2 device"),
"versions": info.versions,
"supports_fido2_1": "FIDO_2_1" in info.versions,
"resident_key_support": "rk" in (info.options or {}) and info.options["rk"],
"pin_protected": False,
"max_resident_credentials": getattr(info, "max_creds_in_list", None),
}
try:
pin_proto = ClientPin(ctap2)
report["pin_protected"] = pin_proto.get_pin_retries()[0] is not None
except Exception:
report["pin_protected"] = False
return report
def main():
devices = list(CtapHidDevice.list_devices())
if not devices:
print("No FIDO2 security key detected.")
print("Readiness: FAIL (plug in a hardware key or rely on a platform passkey only)")
return
print(f"Found {len(devices)} FIDO2 device(s).\n")
for dev in devices:
report = check_device(dev)
print(f"Device: {report['product']}")
print(f" CTAP versions: {report['versions']}")
print(f" Supports CTAP2.1 (current protocol): {report['supports_fido2_1']}")
print(f" Resident key (passkey-on-hardware) support: {report['resident_key_support']}")
print(f" PIN configured: {report['pin_protected']}")
if report["supports_fido2_1"] and report["resident_key_support"] and report["pin_protected"]:
print(" Readiness: PASS, this key is ready for phishing-resistant enrollment\n")
else:
print(" Readiness: NEEDS ATTENTION, see missing items above\n")
if __name__ == "__main__":
main()
Save that file, plug in the hardware key you enrolled in steps 5 and 6, and run it from a terminal:
$ python fido_readiness_check.py
Found 1 FIDO2 device(s).
Device: YubiKey OTP+FIDO+CCID
CTAP versions: ['U2F_V2', 'FIDO_2_0', 'FIDO_2_1']
Supports CTAP2.1 (current protocol): True
Resident key (passkey-on-hardware) support: True
PIN configured: True
Readiness: PASS, this key is ready for phishing-resistant enrollment
A “NEEDS ATTENTION” result almost always traces back to a missing PIN, which the troubleshooting table above covers directly, or an older key that only reports U2F and FIDO 2.0 without the current 2.1 protocol. Either way, you now have a repeatable check instead of a guess, which is the difference between a setup you assume is phishing resistant and one you have actually confirmed.
If your organization is also standardizing on authenticator apps for services that have not added passkey support yet, pair this checklist with a proper rollout of whichever app you choose, whether that is a 2FAS setup guide for individuals or a team authenticator app comparison for shared accounts that genuinely cannot move to hardware keys yet. Organizations that also need self-hosted credential storage rather than a vendor’s cloud sync should review a self-hosted Vaultwarden deployment alongside this guide, and iPhone-only teams migrating between authenticator apps can check the iPhone authenticator switching guide for the export and import steps that passkeys do not need but authenticator-app codes still do. For the broader category of threats this setup defends against, the cybersecurity section tracks the breach and exploit stories that make phishing-resistant MFA worth the setup time in the first place.
Frequently Asked Questions
Is a passkey the same thing as a FIDO2 security key? No. Both use the same FIDO2/WebAuthn cryptography, but a passkey is a credential stored by a platform such as a phone or password manager, while a FIDO2 security key is dedicated hardware that stores the credential independently of any phone or cloud account. Many setups use both together, one for convenience and one as an offline backup.
Can a phishing page steal a passkey the way it steals a password? Not through the same mechanism. A passkey is cryptographically bound to the website’s actual domain, so a look-alike phishing domain cannot trigger the browser to release or use the credential, which is the core property the FIDO Alliance describes when it says passkeys are “always strong and phishing-resistant.”
What happens if I lose the only device my passkey is on? If the passkey was synced through a cloud account, sign in to a new device with that same account and the passkey follows you. If it was device-bound, it does not transfer, which is exactly why this guide has you enroll a second authenticator, usually a hardware FIDO2 key, before you rely on either one alone.
Do I need a physical security key if I already use passkeys on my phone? For most personal accounts, no, a synced passkey is sufficient. For administrator accounts, financial accounts, or any account where a compromised phone or cloud sync should not cascade into everything else, a hardware key as a second, independent authenticator is the safer standard, and it is what CISA recommends starting with for privileged users.
Why does my bank or employer still ask for an SMS code instead of a passkey? Not every service has migrated yet. SMS and voice codes remain common because they are cheap to implement and require no app or hardware on the user’s side, even though they are the weakest widely used option against real-time phishing. Where a service offers a stronger option, use it, and keep SMS only where no alternative exists yet.
What should I do if I get an MFA prompt I did not request? Do not approve it. A single unsolicited prompt can be a misfire, but repeated prompts are a recognized attack pattern where someone who already has your password is hoping you approve one out of frustration. Deny the prompt, change the account’s password, and review recent sign-in activity for anything unfamiliar.
Is FIDO2 hardware required to meet government FIPS requirements, or will any security key do? If your organization has a FIPS compliance requirement, specify a key validated under the current FIPS 140-3 certification, not an older FIPS 140-2 model. NIST moved FIPS 140-2 certifications to its Historical List effective September 22, 2026, so a 140-2-only key is no longer the current validated option even if it still functions technically.
How long does it realistically take to set this up for one person versus a whole company? For a single person covering their handful of highest-risk accounts, expect roughly an hour following the thirteen steps above. For an organization rolling out enforcement through conditional access policies, SAML or OIDC integrations, and hardware key distribution, expect a multi-week project, which is exactly the gap that dedicated platforms like Intercede’s MyID Authenticate are built to shorten.
Related Coverage
Rachel Kowalski
Rachel Kowalski is the Cybersecurity Analyst at TrendinTech, where she covers vulnerabilities, ransomware, supply chain attacks, nation-state operations and the security rules shaping organizations in the United States and Europe. She writes to make risks and countermeasures understandable to people who are not specialists.
All stories by Rachel Kowalski (257)![California Student Data Breach: ETS Hack Hits 5.7M [2026]](https://trendintech.com/wp-content/uploads/2026/10/california-student-data-breach-ets-2026-gen-640x360.webp)
![Plex2Shell Exploit Hits 36,000 Unpatched Servers [2026]](https://trendintech.com/wp-content/uploads/2026/10/plex2shell-exploit-36000-unpatched-servers-2026-gen-640x360.webp)
![Florida DMV Breach: Hackers Claim 200,000 Records [2026]](https://trendintech.com/wp-content/uploads/2026/10/florida-dmv-breach-plant-city-police-login-2026-gen-640x360.webp)