Security Keys - Hardware Authentication Devices
About 2 min read
A security key is a physical hardware authentication device that complies with the FIDO2/U2F standards. By simply plugging it into a USB port or tapping it via NFC, it functions as a strong second authentication factor in addition to a password. It adopts a challenge-response method based on public-key cryptography, and its structural resistance to phishing attacks is what decisively distinguishes it from SMS OTP and TOTP. In 2017, Google made the use of security keys mandatory for all of its employees (over 80,000 people), and reported that account compromises due to phishing dropped to zero thereafter.
Major Products and Connection Types
In the security key market, Yubico's YubiKey series holds an overwhelming share, followed by Google's Titan Security Key and Feitian's ePass series. The connection type is chosen to match the environment where the device will be used.
| Connection type | Supported devices | Characteristics |
|---|---|---|
| USB-A | PC (legacy ports) | Most widespread. High compatibility with legacy environments |
| USB-C | Latest PC / Mac / iPad | The future mainstream. Essential for MacBook users |
| NFC | Smartphones (Android / iPhone) | Authenticate just by holding it close. Ideal for mobile use |
| Lightning | iPhone (older models) | For iPhone 14 and earlier. Declining as devices shift to USB-C |
In practice, having one USB-C + NFC-capable model on hand is highly versatile, as it can be used with both PCs and smartphones.
Why It Is Highly Phishing-Resistant - Origin Verification
The biggest reason security keys are strong against phishing lies in the mechanism that cryptographically verifies the browser's origin (domain) at the time of authentication. Even if an attacker lures a user to a fake site (e.g., g00gle.com), the security key will not use credentials meant for the legitimate site (google.com) under the fake site's origin. Because this verification is performed automatically at the hardware level, the attack does not succeed even if the user misreads the URL.
This is a characteristic that SMS OTP and TOTP do not have. With OTP, if the user enters the code on a fake site, it is handed over to the attacker, but with a security key no signature is generated in the first place, so it is also resistant to adversary-in-the-middle (AiTM) attacks. For details, see the security key adoption guide.
The Difference From Passkeys
Both security keys and passkeys are based on the FIDO2/WebAuthn standards, but the way credentials are stored is fundamentally different.
The private key is locked inside the physical device and cannot be extracted. If lost, logging in with that key becomes impossible. It is suited to corporate security policies that want to physically control where keys reside.
The private key is synced across multiple devices via iCloud Keychain or Google Password Manager. It can be restored from the cloud even if a device is lost. It is suited to cases that prioritize convenience for general users.
Recovery Design for Loss
The biggest operational challenge with security keys is recovery in the event of loss or failure. Because the private key is bound to the physical device, there is a risk of being unable to access the account at all if the key is lost. In practice, the following multi-layered recovery design is recommended.
- Register a backup security key as a second key and store it in a safe place
- Set up alternative multi-factor authentication methods (passkeys, recovery codes, etc.) in advance
- In corporate environments, establish a recovery workflow handled by IT administrators
- Always register multiple authentication methods for important accounts
Reviewing the basics of two-factor authentication and the challenges of migrating to passkeys together will give you a clearer overall picture of authentication design.
Why Handing Out Keys Alone Does Not Raise Overall Resistance
Handing out security keys does not by itself raise an organization's resistance to phishing. Attackers can choose whichever path is easiest to get through, so with voluntary adoption used by only some people, or with conventional one-time code entry left in place as an alternative, that is the path that gets targeted. Adding a strong method and ceasing to accept a weak one are separate pieces of work, and unless the latter accompanies the former, overall strength is determined by the weakest remaining path. In planning an organizational rollout, the central questions are how far to extend the scope of covered users, when to stop accepting the older methods, and how much grace period to allow before that cutover. The hard part of the cutover is handling users who have reasons they cannot use a key. If manual exceptions are granted here, the exception procedure itself becomes a target, and if an exception is requested through impersonation, the original weakness returns. Deciding in advance how exceptions will be accepted, including the level of identity verification required, determines whether the cutover is effective. When assessing the results of the rollout as well, what needs to be checked is not the number of keys distributed but whether any path remains on which authentication can succeed with the older methods alone.
Was this article helpful?