If you use a YubiKey for one-time passwords (OTP), you’ve probably done it at least once: you meant to type something, touched the key, and a long modhex string landed in Slack, a commit message, or an email. Annoying for everyone, and worse, it’s a real security risk.
This post pulls together practical ways to reduce accidental triggers and what to do when a code gets out, plus how YubiOTP compares to TOTP so you can use both wisely. We also cover FIDO2 / WebAuthn and how to use them alongside OTP.
Why accidental YubiKey OTPs are a problem?
A YubiKey OTP is often used as a second factor, similar to an SMS code. Sending one by mistake is a lot like accidentally forwarding a six-digit SMS code—except YubiOTP is worse in one important way.
Unlike SMS or email OTPs, which usually expire after a short window, YubiKey OTPs stay valid until they (or a later-generated code) are used. So if you dump a code into a channel or commit, anyone who can see it can exploit it: they combine the leaked OTP with your password (or stolen credentials) and log in as you. That mistaken keypress is a valid second factor until you invalidate it by authenticating somewhere with a new OTP. That’s a buffered replay risk.
Try the demo — a walkthrough that shows the leaked OTP being exploited (verification succeeds), then how to invalidate it and prove it can’t be used again.
So: fewer accidental triggers and a clear “what to do when I leak one” drill are both part of good YubiKey OTP hygiene.
Two ways to reduce accidental triggers
Both approaches below assume you’re okay with the CLI; if not, there’s a GUI option at the end. You need ykman (YubiKey Manager). On macOS with Homebrew:
brew install ykman
1. Stop the YubiKey from sending Enter
By default, the key sends an <Enter> after the OTP. That can submit forms or send messages as soon as the code is typed. You can turn that off.
Check which slot has OTP configured:
$ ykman otp info
Slot 1: programmed
Slot 2: empty
If slot 1 is programmed, disable the trailing Enter for that slot:
$ ykman otp settings --no-enter 1
Update the settings for slot 1? All existing settings will be overwritten. [y/N]: y
Settings for slot 1 updated.
That alone can prevent a lot of “sent to the wrong place” incidents.
2. Make OTP require a long press (swap slots)
The YubiKey has two OTP slots. Slot 1 is a short touch (~0.5 s), slot 2 is a long touch (~2 s). OTP is usually in slot 1, so a brief brush can fire it. Moving OTP to slot 2 means you must hold the button longer—much harder to do by accident.
$ ykman otp swap
Swap the two slots of the YubiKey? [y/N]: y
Slots swapped.
$ ykman otp info
Slot 1: empty
Slot 2: programmed
This moves the configuration from slot 1 to slot 2. Good if you use YubiKey OTP only occasionally; if you use it all day, the longer press can get tedious. Your call.
Without the terminal: Install the YubiKey Manager GUI, open Applications → OTP, then click Swap to move OTP to the long-press slot. You can’t disable the trailing Enter from the GUI, but the slot swap alone helps a lot.
Optional: Toggle OTP on/off
Turn OTP off over USB so a touch does nothing until you need it; turn it back on when you’re about to log in.
$ ykman config usb -f -d otp # disable OTP
$ ykman config usb -f -e otp # enable OTP
The key’s LED (e.g. green when OTP is on) shows the state. Script it (e.g. yk) to toggle quickly.
If you accidentally expose a YubiKey OTP
Because YubiOTPs don’t expire until used, a leaked code stays dangerous until something invalidates it. What you do depends on how each service verifies your OTP.
Services that use YubiCloud (most consumer apps, many VPNs, Bitwarden, etc.)
Those services call Yubico’s API to verify your OTP; they don’t hold your key’s secret. To invalidate the leak for all of them in one go:
- Go to https://demo.yubico.com/otp/verify.
- Touch your YubiKey to generate a new OTP and submit it there.
Submitting a fresh OTP there updates the counter on YubiCloud. After that, any code you accidentally pasted elsewhere can’t be replayed at any YubiCloud-using service.
Services that validate in-house (e.g. Okta with a Secrets File)
Some enterprises (like Okta) upload a YubiKey OTP “Secrets File” and verify OTPs themselves. They don’t use YubiCloud, so the demo.yubico.com step above does not invalidate the leak for them. To invalidate the leaked OTP for Okta (or similar):
- Sign in to Okta (or the Okta-protected app) with your YubiKey — when prompted, touch the key so Okta receives a new OTP. Okta will accept it and update its counter; the old (leaked) OTP will then be rejected.
- If you can’t sign in (e.g. you suspect the account was compromised), ask your Okta admin to revoke that YubiKey. Once revoked, that key’s OTPs are no longer accepted until the admin re-enrolls a key.
If you use the same YubiKey for both YubiCloud-based services and Okta, do both: submit a new OTP at demo.yubico.com for the former, and sign in to Okta with your YubiKey (or have the key revoked) for the latter.
YubiOTP vs TOTP: when to use which
- YubiOTP: Counter-based, one key for many services. No time expiry—invalid when you use a newer code. YubiCloud = one new OTP at demo.yubico.com invalidates everywhere; in-house (e.g. Okta) = invalidate per service.
- TOTP: Time-based, one secret per service (authenticator or YubiKey OATH). Codes expire in ~30 seconds.
Tradeoffs: Leaked TOTP = short window. Leaked YubiOTP = risky until you invalidate. With TOTP, someone with your key could precompute future codes; with YubiOTP, using a newer code kills theirs everywhere. YubiOTP = one touch, hard to backup; TOTP = easier to backup. Use whichever the service supports; if YubiOTP, use the mitigations above and know how to invalidate.
What about FIDO2 / WebAuthn?
Modern YubiKeys also support FIDO2 / WebAuthn (passkey-style authentication). When you use the key that way, the browser and site talk to the key directly; you tap to sign a challenge. There is no OTP string that gets typed or pasted—so there’s nothing to accidentally send to Slack, and no “leaked code stays valid until used” problem. FIDO2 is also phishing-resistant: the key signs a challenge bound to the real site’s origin, so a fake login page can’t reuse it.
Many services (including Okta, GitHub, Google, and a growing list of others) let you register the same YubiKey as a FIDO2 security key in addition to, or instead of, YubiKey OTP. If a service offers both, prefer FIDO2. Use the OTP mode (and everything in this post) when the service only supports OTP, or when you need compatibility with legacy flows. Okta’s own docs note that “YubiKey in OTP mode isn’t a phishing-resistant factor” and recommend FIDO2/WebAuthn for stronger MFA.
Summary
| Practice | Why |
|---|---|
| Disable “send Enter” on the OTP slot | Avoids submitting forms or sending messages as soon as the code is typed |
| Swap OTP to slot 2 (long press) | Makes accidental triggers much less likely |
| Optionally toggle OTP off when not needed | No OTP output at all until you turn it back on |
| If you leak a YubiOTP: use demo.yubico.com/otp/verify with a fresh code | Invalidates for all services that use YubiCloud |
| If the service validates in-house (e.g. Okta): sign in with your YubiKey (new OTP), or ask admin to revoke the key | Invalidates for that service; demo.yubico.com doesn’t affect them |
| Prefer FIDO2/WebAuthn over OTP when the service supports it | No typable OTP to leak; phishing-resistant |
A few minutes of setup (and one bookmark for the Yubico verify page) will make YubiKey OTP both safer and less annoying for you and everyone on the other end of your keyboard. Where you can, use FIDO2 on the same key and reserve OTP for services that don’t support it yet.