Security key compatibility: identify the sign-in task

Before choosing a physical key, describe the account task you want it to support. Security key compatibility begins with the actual service and sign-in method, then the applicable hardware and software requirements. This guide reads seven services’ documented conditions alongside two retail key accounts. It performs no sign-in, enrollment, fingerprint capture, credential inspection or account change, and certifies neither retail unit for a reader’s account.

Name the job before choosing the accessory

Consider a fictional planning request from Rowan: “I want a key for my accounts.” Ask Rowan to name the account and the intended job. A note can say that the requested method is still unknown. Do not fill that gap with the feature that happens to be most prominent on a retail package. The examples below explain why the service’s own description belongs beside the proposed accessory before anyone commits to a setup.

Keep Apple Account’s prerequisites together

Apple’s Security Keys for Apple Account feature requires at least two FIDO Certified keys that work with the Apple devices used regularly. Its requirements include two-factor authentication and supported software on all devices signed in to the account: iOS or iPadOS 16.3, or macOS Ventura 13.2, or later. Child accounts and Managed Apple Accounts are not supported. These account and software conditions belong with the key requirement.

Apple describes signing in with the account password plus the physical key or another trusted Apple device. Its connector guidance distinguishes USB-C, USB-A, Lightning and NFC; NFC keys work with iPhone, while USB-C works with iPhone 15 or later and most Mac models. Do not turn a connector photograph into proof that every device in the account is eligible. Apple also warns that losing all trusted devices and keys can permanently lock the user out. Apple also specifies iCloud for Windows 15 or later for that particular sign-in route. This article neither enables the feature nor verifies a recovery arrangement.

Read Google’s FIDO2 passkey support separately

Google distinguishes a security key used as the second step of 2-Step Verification from creating a passkey on the key. Its documentation allows FIDO1 or FIDO2 keys for that second step. Creating a passkey requires FIDO2. Keep the intended authentication job attached to FIDO2 passkey support instead of treating every reference to a security key as the same request.

Google says a passkey on the security key can let the user skip the password when possible and satisfies the second authentication step. Its instructions also identify compatible-browser conditions. That account-specific description should not be transferred to another service’s password-plus-key procedure. A key already associated with an account and a newly created passkey are different records to establish. This guide does not inspect those records, remove an existing key or create a replacement credential. Google also says a newly added key may take seven days to become available at sign-in. It supplies no PIN-reset or account-recovery procedure and reports no successful Google sign-in.

Keep Microsoft’s organization conditions visible

Microsoft’s work-or-school verification guidance requires the administrator to enable the feature, an approved physical key, a supported device and browser, and a key that is both FIDO2 and Microsoft-compliant. It also requires another security-verification method to be registered before key registration. Those are organization-specific prerequisites, not a promise that every personal Microsoft account or workplace offers the same option.

The captured Microsoft page labels the feature as public preview and says an absent security-key option can reflect the organization’s policy. Read the actual administrator’s supported arrangement rather than assuming that the retail key’s appearance grants eligibility. Microsoft distinguishes a USB key from an NFC key and directs uncertain users to the manufacturer or their help desk. Its registration instructions include different Windows-version branches. This compatibility review does not follow those branches, create a PIN, delete security information or reset a key. The page names Microsoft Authenticator and Windows Hello as other passwordless methods, with their own conditions. The appropriate next answer may belong to the organization responsible for that account.

Distinguish GitHub’s portable key from a synced credential

GitHub’s passkey guidance is for personal-account owners managing their own credentials. A passkey can satisfy the password and two-factor requirements for a browser sign-in. The authenticator may establish authorization with a PIN, passcode, biometric or device password, depending on its capabilities and configuration. A picture of a fingerprint-style sensor does not reveal which authorization method an account has actually configured.

GitHub distinguishes cloud-backed passkeys that can sync through a service from device-bound passkeys. Passkeys on FIDO2 hardware security keys are device-bound: they remain on that authenticator while the physical key can be carried to other devices. Portability therefore should not be described as a synced backup of that credential. GitHub also notes that platform and browser combinations affect support. GitHub says passkeys are bound to a website domain and require a secure connection. This guide performs no registration or upgrade of an existing security-key credential, tests no browser combination and makes no claim that a reader’s passkey has been backed up or moved.

Check 1Password’s security key second factor

1Password describes a FIDO U2F-compatible key as a second factor in supported apps and browsers, in place of a six-digit authentication code. Support for the FIDO U2F interface must be enabled on the key. Read those conditions when investigating a security key second factor. A key advertising another protocol does not by that wording alone establish the enabled interface required for this particular task.

1Password also distinguishes using the security key from a browser offering to save or use a passkey. Follow the intended account method rather than calling every authenticator prompt equivalent. Its current help includes a Windows passkey-access condition for an “Unable to sign in” case after the account password and Secret Key. That is a documented conditional branch, with no diagnosis of the reader’s installation here. The page describes an authenticator app as an alternative for browsers without security-key support. This guide neither enables a key interface nor changes Windows permission, and it asks for no account password, Secret Key, security-key PIN or authentication code.

Keep Bitwarden’s three passkey jobs distinct

Bitwarden describes three separate passkey features: storing passkeys for other services, using a passkey to log in and unlock the Bitwarden account, and using one for Bitwarden two-step login. Its two-step documentation accepts FIDO2 WebAuthn Certified credentials and gives an application-support matrix. Keep the particular feature, application and supported browser in the compatibility question. An available credential is not evidence that all three jobs have been configured.

Bitwarden says its secondary two-step login is not required merely to unlock a vault after logging in. That distinction matters when describing what a key is expected to do. The same page warns of a phishing scenario affecting self-hosted servers and tells users to verify the correct domain before interacting with a prompt. Do not replace that explicit limitation with a claim that hardware-key use makes every deployment immune to phishing. For this two-step feature, Bitwarden says non-security-key options such as Touch ID on macOS are unsupported. This article performs no vault login, export, recovery-code inspection, logout, key registration or NFC setting change.

Read Proton’s website and browser limits

Proton’s security-key 2FA guidance describes entering the username and password, then using a physical U2F or FIDO2 key for the second step. It explicitly says the protonvpn.com website does not support security-key 2FA; the feature is enabled and used through proton.me. Keep that website distinction with the account task. A company name alone is insufficient to identify which sign-in surface is being discussed.

Proton separately says Tor browser does not support security keys. Its registration account also distinguishes physical keys from platform authenticators such as Windows Hello or Touch ID. Those documented choices are not evidence that a particular reader has enrolled either kind. The page describes additional keys and alternative recovery arrangements, but this guide sets up none of them. It does not sign in, toggle platform-key permission, register a spare, rename or remove a key, or attempt recovery. Proton says up to four security keys can be associated with an account. No passwordless Proton result should be inferred from a procedure that retains the password.

Read the two key offers as catalog accounts

The native Yubico 8880001145 YubiKey 5C NFC offer uses FIPS wording, with one USB-C key pictured. That wording and the Y/radio-wave icon are not an independent FIPS validation or delivered-unit authentication. The Yubico Y-399 Bio C FIDO offer describes FIDO2 and U2F support, fingerprint or PIN use, and exclusions including OTP, TOTP, PIV and OATH. Its packaging and multiple views represent one key. The contextual laptop, door keys and keyring are not supplied inventory. Neither retail account proves service eligibility, biometric enrollment, a completed sign-in or a security result for the reader.

The related ThinkPad configuration guide includes a security key among accessories when planning occupied ports. That physical planning question does not establish an account’s authentication method. The Windows app compatibility guide reads application requirements against an intended task. Its software and hardware examples do not certify either key or replace the service-specific conditions above.

Turn an unclear request into an answerable question

Return to Rowan’s fictional request. Suppose Rowan can identify the service but cannot say which account feature they intend to use. Record that uncertainty before choosing an accessory. A colleague’s statement that “my key works” needs its own context: the colleague’s account, intended method and actual observation. The example supplies none of those facts for Rowan. It shows why another person’s reassuring report should not silently become a compatibility certificate for a different arrangement.

A second fictional request comes from a team member buying equipment for an organization. The member can identify the purchasing task but has not received an answer from the person responsible for account policy. Their next enquiry can name that missing answer without attempting to alter the policy. Leave the decision with the authorized account owner or administrator. A retail order should not be used to force a technical or administrative question into an assumed answer.

Keep the review separate from enrollment

A concise planning note can identify the service, the job requested, the documentation consulted and the requirement still unanswered. Keep a statement about the planned arrangement separate from a result somebody actually observed. If the request changes, retain the earlier question so the new answer remains understandable. This is an editorial way to organize an enquiry, not a provider-mandated enrollment form or permission to inspect another person’s credentials.

Finish the Security key compatibility review with an identified intended method and its applicable prerequisites, or a precise question for someone able to answer. Do not write “ready” on the strength of a familiar connector or a package’s feature list. No enrollment or sign-in has occurred in this guide. A configured credential, maintained access arrangement and successful permitted use each need their own actual evidence before anyone relies on them.

Conceptual compatibility review; no exact credential, fingerprint, enrollment, sign-in or security result is shown.