Quick answer
A YubiKey is a hardware authenticator that performs cryptographic operations for compatible services and apps. Different protocols serve different purposes: FIDO helps protect website sign-ins, while Krypt uses an OTP-capable key's challenge-response function alongside your vault PIN. Krypt's answer is an optional physical-key requirement for normal vault unlock, with a separate recovery path.
The useful question is not simply whether an app supports “security keys.” Ask which protocol it uses, what the key actually proves, and how you recover if the key disappears. Those details determine whether a purchase solves your problem. This article explains the mechanisms; Krypt's existing YubiKey setup guide covers the practical workflow.
What is stored on a YubiKey?
A YubiKey is not a USB drive for your photos, documents, or password database. Its role is to hold authentication material and perform supported operations with it. Your application still stores its own data. For Krypt, encrypted vault content remains in Krypt's storage; the physical key supplies a response used during unlock.
Think of the device as containing separate applications. Yubico's protocol documentation identifies distinct FIDO, OATH, OTP, PIV, and OpenPGP functions with separate credential storage. Configuring one function does not automatically configure the others. Registering a key with an email provider therefore does not enroll it in Krypt, and resetting one application is not a general-purpose backup procedure.
Which protocol does what?
| Function | Typical purpose | Relationship to Krypt unlock |
|---|---|---|
| FIDO2 / WebAuthn | Public-key account authentication and passkeys | Different mechanism from local YubiKey vault unlock |
| FIDO U2F | Public-key second-factor authentication | Does not supply the required OTP response |
| OATH TOTP / HOTP | Time-based or counter-based one-time codes | Separate from Krypt's hardware unlock configuration |
| OTP HMAC challenge-response | Derive a response from a supplied challenge and secret | Krypt uses this with the vault PIN |
| PIV / OpenPGP | Smart-card and OpenPGP workflows | Not Krypt's YubiKey unlock path |
“OTP application” is a device application name, not a promise that every response is a one-time password. Krypt asks that application for HMAC-SHA1 challenge-response. It does not ask you to paste a changing six-digit code or a string typed by a short touch of the key.
How does a YubiKey protect website login?
In a WebAuthn registration ceremony, the authenticator creates a credential scoped to the service, called the relying party. The service records the public key. During authentication, it sends a fresh challenge; the authenticator signs data associated with that request, and the service verifies the signature and expected request context. The browser mediates the operation.
The WebAuthn standard specifies checks for the challenge, origin, relying-party identity, and required user presence or verification. These checks make a signature from one context unsuitable for an unrelated login. Fresh challenges also prevent a recorded authentication response from simply being reused for a later request.
FIDO2 combines WebAuthn and the Client to Authenticator Protocol, CTAP. WebAuthn is the web-facing interface; CTAP handles communication with external authenticators. The USB or NFC connection alone does not create phishing resistance. The protocol and the service's verification behavior provide it.
Why is a touch different from a PIN?
Touching a key can demonstrate user presence. It does not necessarily establish who touched it. Depending on the authenticator and operation, user verification can require a PIN or biometric. A key left connected to a shared computer is still physically available to someone else at that computer.
NIST's authentication guidance distinguishes phishing resistance from ordinary possession checks. Codes that a person manually enters can be relayed to the legitimate service by an impostor. A hardware token producing such a code does not automatically make that particular login phishing-resistant. Likewise, a security-key label is not evidence that an entire product meets a particular NIST assurance level.
For Krypt users, there are two separate PIN concepts: your Krypt vault PIN and any PIN protecting a YubiKey application such as FIDO2. Setting the latter does not change the former. Krypt's local hardware unlock combines its own vault PIN with the OTP challenge-response result.
Krypt's answer: PIN plus physical proof
Krypt is a zero-knowledge password manager with optional local hardware unlock. Krypt Pro can configure YubiKey unlock for a supported real vault. Before enabling it, Krypt checks the vault PIN and requires a complete Rescue Key slot. It generates a random 64-byte challenge and asks the configured OTP slot on the key to compute a response. The key must already have a compatible HMAC-SHA1 configuration.
HMAC is a keyed message authentication construction. Here the key's configured secret and the challenge produce a 20-byte response. For the same secret and challenge, that response is repeatable. Yubico's Android YubiOTP documentation shows HMAC-SHA1 slot configuration and calculation through sessions supporting USB OTP connections and NFC smart-card connections. This is neither a WebAuthn signature nor the cipher used to encrypt Krypt files.
Krypt combines the response and vault PIN using a labeled input, then runs the vault's configured key-derivation function with its salt and parameters. That produces a key-encryption key, which wraps the existing vault key using AES-256-GCM. Krypt saves the challenge, wrapped-key data, verifier, slot, and transport configuration. It clears the mutable response and derived-key buffers when that operation finishes.
On later normal unlocks, Krypt checks the PIN and sends the stored challenge again. A successful response lets it derive the wrapping key, verify it, and unwrap the vault key. A missing response, missing metadata, or mismatched verifier prevents that normal unlock path from succeeding. Biometric unlock is disabled for a vault requiring YubiKey, so the usual biometric shortcut cannot satisfy the requirement.
What does that protection actually cover?
The immediate benefit is concrete: someone who knows your PIN and tries to unlock the vault through Krypt's normal interface also needs the configured hardware response. This can help when another person has seen you enter the PIN, or when you want physical possession to be part of every normal unlock.
The boundary matters. Krypt retains a separate PIN-only wrapped-key slot, and its hardware unlock implementation checks that slot before requesting the YubiKey response. Consequently, the hardware requirement should not be interpreted as making a stolen storage copy cryptographically dependent on the key in every circumstance. Someone with the relevant PIN-only slot and PIN, or sufficient control to modify the client, faces a different boundary from a person using the normal lock screen.
There is also no fresh server challenge or website-origin binding in this local flow. A captured response to Krypt's stored challenge can remain relevant to that configuration. Malware controlling the device during unlock may capture inputs or access plaintext after unlock. Hardware unlock does not disinfect a compromised phone, secure exported plaintext, or revoke a stolen website session.
Those limits help you place the feature correctly. Use the physical requirement alongside a strong vault PIN, device updates, device locking, controlled exports, and protected recovery material. Krypt adds a deliberate local access step; website authentication still needs the protections offered by the individual provider.
Which key and connection should you choose?
Check the exact model, supported applications, and firmware before buying. Yubico's product-family documentation distinguishes multiprotocol YubiKeys from the FIDO-only Security Key Series. A FIDO-only key can be appropriate for website authentication but lacks the OTP challenge-response application required by Krypt's local unlock.
Compatibility also depends on the installed Krypt build and device. Supported implementations include Android NFC or USB, supported-iPhone NFC, and macOS USB. Do not infer wired iPhone or iPad support from a key having a matching connector: Krypt's current iOS challenge-response path uses supported-iPhone NFC, and wired iPhone/iPad challenge-response is not generally available. Confirm the option in your installed app before committing to a hardware setup.
Choose the matching configured OTP slot, either 1 or 2, and test the exact transport you intend to use. Existing slot contents may serve another application. Reprogramming that slot can break its existing use, so identify its purpose before changing it. Plugging in a key and successfully logging into a website is not a test of Krypt compatibility.
How should you prepare for a lost key?
A spare device is useful only if the relevant service or configuration recognizes it. For website accounts, enroll and test a second key with each provider that permits it. Do not assume that registering the first key copies its credentials to another key you purchase later.
For Krypt challenge-response, an unrelated spare does not produce the original key's response. A deliberately provisioned matching OTP secret and slot can reproduce that response, but doing so requires advance planning and careful handling of the provisioning secret. Krypt's current configuration is not a general list of independently enrolled hardware keys. Follow the supported setup procedure and test the intended spare before relying on it.
Krypt's matching Recovery Kit or Rescue Key provides a separate route. Preserve the necessary recovery material and encrypted backup independently of the phone and everyday key. The setup check confirms required recovery metadata exists; it does not prove that your written recovery copy is readable, current, and accessible. The Recovery Backup guide explains that workflow.
One key, three separate decisions
Consider a person who uses a compatible multiprotocol key for email and for Krypt. Adding the key to email establishes a relationship with that provider. Enabling its OTP slot in Krypt establishes another relationship with a local vault. Keeping the Recovery Kit somewhere accessible establishes a third, independent continuity plan. Success in any one of these does not prove that the other two work.
If that person loses the key while traveling, an enrolled email spare may restore email access but have no usable Krypt OTP configuration. If the phone is lost instead, possessing the key does not supply the missing vault database or encrypted backup. If both survive but the vault PIN is forgotten, the key alone does not replace the recovery procedure. Write down the dependencies while everything is working: which accounts recognize which keys, which OTP slot serves Krypt, and where the matching recovery material is kept. That small inventory makes a physical authenticator part of a usable security system.
A practical evaluation checklist
- Name the problem: website phishing, normal local vault access, or recovery after loss. Each needs a specific mechanism.
- Verify the protocol, exact key model, installed app support, and intended connection.
- Identify any existing OTP slot use before configuring challenge-response.
- Prepare and test recovery independently, then enable hardware unlock in Krypt.
- Lock and unlock with the intended key and transport; verify that the requirement behaves as expected.
- Keep the daily key and recovery material in separate places, and repeat the access check when changing devices.
FAQ
Does every YubiKey work with Krypt vault unlock?
No. Krypt's local unlock requires a compatible key with an OTP application slot configured for HMAC-SHA1 challenge-response, plus a supported Krypt build and transport. A FIDO-only Security Key does not provide that OTP function. Check compatibility before buying or configuring a key.
Does a YubiKey replace my Krypt PIN?
No. Krypt combines the vault PIN and the hardware response for its YubiKey unlock path. When the requirement is enabled, normal unlock needs both, and biometric unlock is disabled for that vault. The vault PIN is separate from a YubiKey's FIDO2 PIN.
Is Krypt YubiKey unlock the same as phishing-resistant website login?
No. Krypt uses local HMAC-SHA1 challenge-response with a stored vault challenge. WebAuthn website login uses scoped public-key credentials and fresh server challenges. The mechanisms have different security properties; Krypt's local flow does not inherit WebAuthn's website binding or fresh-challenge replay protection.
Can my YubiKey recover a lost Krypt vault?
A YubiKey is not a replacement for Krypt's matching Recovery Kit or Rescue Key. Keep the recovery material and any required encrypted backup independently accessible, and test recovery before depending on hardware unlock. Buying another key does not recreate the original key's configuration.
Technical references
The linked Yubico application, product-family, and Android YubiOTP documentation explains key capabilities, configuration, and native USB/NFC connections. WebAuthn, FIDO, and NIST provide the protocol and authentication context. Krypt-specific behavior described here follows its vault-unlock implementation reviewed on September 10, 2026; installed-build support should be checked on the target device.
Use Krypt to organize encrypted vault data and add a physical-key requirement to normal unlock on supported devices. Prepare recovery before enabling it.
