Daniel's been thinking about hardware authentication tokens — not in the abstract, but the very specific workflow of keeping one permanently plugged into a machine. A crusted home desktop, or a laptop when you're on the road. His argument is that the always-attached use case is far more common for him than the standard advice about carrying a token on a keychain for occasional two-factor prompts. He wants to know what's actually on the market right now, which form factors survive being left in a port for months at a time, how SSH key storage works on these things, and why this matters especially for developers who travel.
And it's the right obsession, because the always-attached workflow changes every calculation. Most reviews test a token the way a consumer would carry it: in a pocket, on a keyring, pulled out once a day for a login. Daniel's talking about a token that lives in the port. That means different priorities for size, durability, and which connector you actually need. And the phone-based fallback that most two-factor setups assume you have — that's not the primary path. The token is.
So let's start with the landscape. What's actually on the market right now, mid-twenty-twenty-six, and what's changed in the last year or two.
The core thing to understand is what problem a hardware token solves versus a phone-based authenticator app. TOTP — those six-digit codes that rotate every thirty seconds — are about proving you know a shared secret. If your phone's clock drifts, the codes stop working. If your battery dies, you're locked out. Hardware tokens using FIDO2 or U2F solve a fundamentally different problem: possession. The token holds a private key, and when you authenticate, the service sends a challenge that the token signs. No shared secret, no clock synchronization, no battery in the token itself. The YubiKey draws power from the USB port. It works in places where your phone is a brick.
That's the travel argument in one sentence. Connectivity and power are unreliable. The token doesn't care.
So the market. YubiKey 5 series is still the dominant player. They support FIDO2, U2F, OpenPGP smart card, PIV, challenge-response, static password, OATH-TOTP, and OATH-HOTP. The build quality is excellent. But the landscape has shifted. Nitrokey has gained real ground, especially with developers who care about firmware transparency. The Nitrokey 3 is forty-nine dollars, USB-C and NFC, and the firmware is fully open source. You can audit it, you can build it yourself. That matters when you're trusting a device with your private keys. There's also the Nitrokey Start — USB-A only, twenty-five dollars. It does FIDO2 and U2F, but not the full smart card functionality. If all you need is web authentication, it's solid. Then there's Google's Titan key — they now have a USB-C plus NFC model that supports both FIDO2 and TOTP, which is an interesting combination. And SoloKeys remains the only fully open-hardware option — schematics published, bill of materials public. If you want to verify the hardware itself isn't doing anything sneaky, that's the one.
That's the landscape. But Daniel's prompt isn't about which token has the best spec sheet. It's about which one makes sense when it never leaves the USB port.
And that's where the form-factor conversation inverts most of the standard advice. USB-A is still the most universally compatible connector — legacy desktops, older laptops, docking stations, server front panels. If you're plugging into a crusted home machine, the convenient ports are probably USB-A. USB-C is the future, but it has compatibility gotchas. Some USB-C ports on cheap laptops are power-only, or don't support the data modes that FIDO2 needs.
I've seen that on a budget Chromebook. The port charges fine, but plug in a data device and nothing happens.
And there's a subtler problem on MacBooks. If you have a MacBook Air with two USB-C ports and you put a security key in one, you've just lost half your connectivity. The YubiKey 5C Nano is designed for this — it protrudes only six and a half millimeters. You can leave it in and still slide the laptop into a sleeve. But if you need to charge while authenticating, and you've only got two ports, now you're in dongle territory. That sort of defeats the "permanently attached" idea.
So the Nano form factor is a tradeoff between permanence and port availability.
It is. And NFC is great if you're tapping a token against your phone. But if the token is permanently plugged into a desktop or laptop, NFC never fires. It's completely irrelevant. The always-attached workflow makes NFC a feature you pay for and never use. The real decision is between a Nano-style key that lives in the port and a standard key that lives on your keychain and gets inserted only when needed.
Let's talk about what "lives in the port" actually means for SSH keys, because that's the part of Daniel's question that gets technical fast.
This is where hardware tokens go from being a convenience to being a genuine security boundary. Normally, when you generate an SSH key pair, the private key lives as a file on your disk, encrypted with a passphrase. If someone compromises your laptop, they can copy that file and brute-force the passphrase offline. With a hardware token, the private key never leaves the device. The key is generated on the token itself, stored in a secure element, and when you need to authenticate, the signing operation happens inside the token. Your laptop sends the challenge, the token signs it, and sends back only the signature.
So even if the laptop is completely owned by an attacker, they can't extract the key.
Can't extract it. They could use the token while it's plugged in — if they have your PIN — but the moment you unplug it, the attack surface closes. And the PIN is enforced by the token's hardware, with a limited number of retries before it locks. This works through two main mechanisms: the OpenPGP card applet, where the token acts as a smart card and SSH uses the key through gpg-agent, and FIDO2's hmac-secret extension, which lets the token derive an SSH key tied to the specific service. The modern way to set this up is a single command: ssh-keygen dash t ecdsa-sk. That generates a resident key on the token. You set a PIN, touch the token to confirm, and that's it. The corresponding public key goes on the servers you're connecting to, same as any SSH public key. The difference is there's no private key file on your machine at all — just a pointer file that tells SSH to use the key on the token. The actual secret is sealed in hardware.
So for Daniel's AWS example — he wants to store an SSH key for EC2 access, plus use the same token as a second factor for the AWS console.
That's one of the cleanest use cases. You generate an SSH key on the YubiKey, register the public key with AWS for EC2 access. Then register the same token as a U2F second factor for your IAM user. Now one physical device handles both SSH authentication and web console login. The private key for SSH never touched your disk. The second factor for the console isn't a phone that might be dead. And if you're traveling, you plug the token into whatever laptop you're using, authenticate once, and work.
The travel scenario is what I want to dig into next. Daniel's prompt draws a distinction between the always-attached token on a home machine and the travel workflow where the token is in your pocket.
They're different threat models and different ergonomics. The always-attached token on a home desktop is about local security — it's a physical anchor that says "someone is physically at this machine." For travel, the token is for remote service authentication. You carry it with you, plug it in when you need to push to GitHub or SSH into a server, and unplug it when you're done. The session stays alive for a while, so you're not constantly inserting and removing.
And the phone-as-backup problem. Daniel mentions that phone-based auth is rare for him, but most services still demand a fallback.
Every service that supports hardware tokens requires at least one backup method — usually TOTP or SMS. You can't escape that. But the smart practice is to register multiple hardware tokens. WebAuthn lets you register as many credentials as you want per account. The standard advice is three tokens: one always plugged into your primary machine, one on your keychain, and one stored somewhere safe. If you lose your primary, you use the keychain token to log in and de-register the lost one. If your house burns down, you retrieve the backup and start over.
Three tokens sounds excessive until you've been locked out of something important for a week.
It's the difference between "I lost my token" being an inconvenience and being a catastrophe. Most major services now let you name your tokens, see which ones are registered, and remove individual credentials without affecting the others. The one thing you can't do is export a private key from a token and import it into another one. By design. The key is bound to the hardware. So you register multiple tokens independently, each with its own key pair.
Let's talk about why developers specifically should care about this, beyond the obvious security arguments.
The developer workflow is where hardware tokens go from "nice to have" to "why wouldn't you." Think about what a developer does on a typical day. SSH into servers. Push to GitHub or GitLab. Sign commits. Authenticate to cloud consoles. Maybe decrypt a file or two. Every one of those operations involves a private key or a credential. If those keys are files on disk, and you're on hotel Wi-Fi, you're one zero-day away from having your entire infrastructure compromised.
The hotel Wi-Fi part is not theoretical. Conference networks are famously hostile.
And the thing about SSH keys stored on a hardware token is that you can authenticate to GitHub without ever typing a passphrase that could be keylogged. GitHub has supported SSH keys stored on FIDO2 tokens since twenty twenty-two. You generate the key on the token, register the public key with GitHub. When you push, SSH asks the token to sign the challenge. You touch the token. Done. No passphrase to type, no agent forwarding to worry about, no private key file that could be exfiltrated.
And the GPG side — commit signing.
Same principle. You generate a GPG key on the token's OpenPGP card applet. The signing subkey lives on the token. When you sign a commit, the token does the signing. Your commits are provably yours, and the key that proves it can't be stolen from your laptop. For open-source maintainers, signed commits are increasingly required by projects that care about supply chain integrity. If your signing key is on a hardware token, it's a much stronger assertion of identity than a key stored in a dot-gnupg directory.
There's a knock-on effect here. Once you have a hardware token for SSH and web auth, you start wanting it for everything.
You do. Sudo on Linux — you can configure PAM to require the token. Disk encryption unlock — systemd-cryptenroll has supported FIDO2 since version two forty-eight. You can bind your LUKS volume to a hardware token, so the disk won't decrypt without it. Windows Hello supports security keys for login. The ecosystem is catching up to the idea that a hardware token is the root of your digital identity.
But the failure mode is real. You lose your only token, and suddenly you can't decrypt your disk, can't log into your servers, can't push code.
That's the nightmare scenario, and it's why the backup token isn't optional. But there's a subtler failure pattern specific to the always-attached workflow. The YubiKey 5C Nano protrudes six and a half millimeters. That's small enough to forget it's there. If you're packing your laptop in a hurry, you might not notice the Nano is still in the port. You toss the laptop in your bag, the token snags on something, and either the token breaks or the port gets damaged. Or you just leave it behind in a co-working space.
I've done exactly that with a USB receiver for a wireless mouse. Left it in a library computer. Never saw it again.
And a mouse receiver is ten dollars. A YubiKey 5C Nano is about fifty-five. The Nano form factor is great for permanence, but it trades visibility for convenience. A standard key on a keychain is harder to forget because it's attached to the thing you use to start your car or open your front door.
So there's a tension between "always there when you need it" and "always there when you don't want it to be."
Which brings us back to the two-token strategy. If you have a Nano in your desktop at home and a standard key on your keychain for travel, you get the best of both. The home token never moves, so it's always there and you never forget it. The travel token is attached to your keys, so you notice if it's missing. And if you lose the travel token, you use the home token to log in and de-register it.
Let's talk about physical durability, because I think it's under-discussed.
USB connectors have a rated number of insertion cycles. USB-A is typically rated for about fifteen hundred cycles. USB-C is rated for ten thousand. The always-attached workflow means you're doing far fewer insertions. The token goes in once and stays there for months. That's actually better for the connector than inserting and removing it ten times a day.
So leaving it in the port extends the token's lifespan, not shortens it.
Counterintuitively, yes. The thing that kills USB connectors is repeated mechanical stress. A token that lives in the port avoids that entirely. The risk shifts from mechanical wear to environmental exposure — if you spill coffee on your desk, the token gets hit. But most of these tokens are potted in epoxy or sealed. The YubiKey 5 series is IP68 rated, meaning it can survive being submerged. Not that I'd recommend testing that with coffee. The Nitrokey 3 has a plastic case that's less robust — not IP rated. If you're hard on your gear, the YubiKey's build quality is a real advantage. The SoloKeys are somewhere in between — the case is 3D-printed on some models, which is charming from an open-hardware perspective but not exactly rugged.
So for the always-attached use case on a travel laptop that gets knocked around, the YubiKey's physical durability is a genuine differentiator.
It is. And that's the kind of thing you don't learn from a spec sheet comparison. You learn it by having one break in your bag.
Let's pull back to Daniel's specific scenario. He wants SSH access to AWS, plus second factors for Google Workspace and other services. What does a reasonable setup look like?
Two tokens minimum. I'd recommend a YubiKey 5C Nano for the always-attached slot and a YubiKey 5 NFC or Nitrokey 3 for the keychain. Register both with Google Workspace, both with AWS IAM, both with GitHub. Generate an SSH key on the always-attached token for EC2 access, and optionally generate a separate SSH key on the keychain token as a backup. Set up a third token as cold storage if you're really paranoid, but two gets you ninety-five percent of the way there.
And the setup process — is this still the command-line archaeology project it used to be?
It's gotten dramatically better. For SSH with a YubiKey, it's literally ssh-keygen dash t ecdsa-sk. It'll prompt you to touch the token, set a PIN, and that's it. The public key is printed to the terminal, you copy it to your server's authorized_keys file. For GPG, you use gpg dash dash card-edit to generate the key on the token. For web services, you go to the security settings, click "add security key," and touch the token. The whole setup for three services takes maybe fifteen minutes.
Fifteen minutes is the difference between "I'll do it eventually" and actually doing it.
And the tooling keeps improving. The ykman command-line tool from Yubico lets you manage every aspect of the token — configure OATH-TOTP credentials, set PIN policies, check firmware versions. Nitrokey has a similar tool called nitropy. These aren't obscure utilities anymore; they're packaged in most Linux distributions and available through Homebrew on macOS.
One thing we haven't touched on — what about the scenario where you're using a machine that isn't yours? A borrowed laptop, a hotel business center computer.
That's the one case where the hardware token really shines over phone-based two-factor. If you're logging into your email on a shared computer, you don't want to type your password — keyloggers are a real threat on public machines. With a hardware token, you can use FIDO2 passwordless login. You plug in the token, enter your PIN, touch it, and you're in. No password typed, no TOTP code to enter. Google and Microsoft both support this flow now. And the token never exposes its secrets to the host machine. The host sees only the signed assertion, not the key that produced it. Even if the machine is completely compromised, the attacker gets a single signed assertion valid only for that one login session. They can't reuse it, they can't extract the key, and they can't impersonate you later.
I want to get Hilbert in on this, because I know he's been making a face for the last two minutes.
The implementation fails.
Hilbert: They do. All the time. You're talking about this like the token is the point. It's not. The point is that the private key never touches the host operating system. I had a client back in twenty-nineteen — a company that made bespoke USB tokens for enterprise clients. They had a financial services client who spent two hundred thousand dollars on custom tokens. Deployed them to three hundred employees. Then they pushed a software update that pulled the private key off the token for what they called backup purposes.
Backup purposes.
Hilbert: The key was in a text file on a network share. They might as well have used a Post-it note. The token was just a very expensive dongle at that point. Nobody had told the IT team that the whole reason you buy hardware tokens is so the key never leaves the hardware.
That's exactly the failure pattern I worry about. The token becomes security theater.
Hilbert: It happens more than anyone admits. Another client — same year — set up their tokens with no PIN. Just touch to confirm. So if someone stole the token, they had everything. The token was the only factor.
The token became a single factor.
Hilbert: A fifty-five dollar single factor. I still have a drawer full of prototypes from that job. One of them had a hardware bug where the USB connector would snap off after exactly eight hundred and forty-seven insertions. We knew because we tested it. The QA guy had a counter and a spreadsheet.
Eight hundred and forty-seven. That's oddly specific.
Hilbert: The plastic around the connector was a millimeter too thin. They fixed it in the next revision. But the drawer prototypes — every single one of them is a time bomb at eight forty-seven.
That's an argument for the always-attached workflow right there. If the token lives in the port, you're doing maybe ten insertions a year instead of ten a day.
Hilbert: Fewer insertions, longer life. The connector lasts longer sitting still. That's true of any USB device. But it only matters if the implementation is sound. I've seen too many deployments where the token was the right answer to the wrong question.
The question being "how do we check a compliance box" instead of "how do we protect a private key."
Hilbert: That's the one. If you're a developer traveling with a laptop, you're not checking a compliance box. You're trying not to get your infrastructure owned from a hotel lobby. That's the right question. The token is just the answer. But you have to actually set it up correctly — PIN on the token, backup token registered, and never, ever let the key leave the hardware.
The PIN part seems obvious, but I can see how someone would skip it for convenience.
Hilbert: Convenience is how you lose. The PIN is what stops someone who steals your token from using it. Without a PIN, the token is just a physical key — whoever holds it gets in. With a PIN, they get eight tries before the token locks. That's the difference between a bad day and a career-ending incident.
Eight tries is the FIDO2 standard. After that, the token resets and all credentials are wiped.
Hilbert: Which is also why you have a backup token.
Hilbert, do you still use any of the tokens from that consulting gig?
Hilbert: I use a production one from the batch after they fixed the connector. It's in my desktop right now. Has been for three years. Never had a problem. But I also have a backup in my bag, and a third one in a safe. I learned that from watching clients get locked out of their own systems.
Three tokens, three locations.
Hilbert: It's not paranoia if it's happened to someone you know.
The thing Hilbert's story makes me think about is how much of security is implementation discipline versus tool selection. You can buy the best hardware token on the market and still defeat it with a bad deployment.
The tool is only as good as the process around it. And that's the thing about Daniel's question — he's asking about the right tool for a specific workflow, which is the right way to approach this. But the follow-up question nobody asks is "what process am I committing to by adopting this tool?" If you're not willing to register backup tokens, if you're not willing to set a PIN, if you're not willing to keep the key on the hardware, then a hardware token is just an expensive USB ornament.
The always-attached workflow makes some of that easier, though. If the token lives in the port, you're not going to forget your PIN — you'll type it often enough that it becomes muscle memory. And you're not going to lose the token, because it never moves.
Lower friction means you're more likely to actually use it correctly, not cut corners.
Where does this leave us? Daniel asked what's on the market, which form factors work for always-attached, how SSH key storage works, and why developers should care. We've covered the market — YubiKey 5 series still the leader, Nitrokey 3 as the open-source alternative at forty-nine dollars, Google Titan with its TOTP integration, SoloKeys for open hardware. Form factors — the Nano for always-attached, USB-A for legacy compatibility, USB-C for the future with port-availability caveats, NFC irrelevant for this workflow. SSH key storage — the key never leaves the token, signing happens on-device, setup is a single command with modern tooling.
The developer angle — if you're pushing code, signing commits, and SSHing into servers from hotel rooms and conference centers, a hardware token moves your private keys from a file that can be stolen to a physical device that can't be exfiltrated. That's not a marginal improvement. It's a categorical difference in your security posture.
The open question I keep coming back to is where this goes as passkeys and WebAuthn replace passwords entirely. Right now, a hardware token is one of several ways to authenticate. But if passwords disappear — and that's the direction Apple, Google, and Microsoft are all pushing — the hardware token could become the primary identity anchor. Or it could be replaced by phone-based passkey sync, where your credentials are backed up to iCloud or Google's servers and follow you across devices.
That's the fork in the road. Phone-based passkey sync is more convenient — you get a new phone, your passkeys come with it. Hardware tokens are more secure — the key is bound to physical hardware that can't be synced to the cloud. The question is whether users will value possession over convenience. My guess is that most people will choose convenience, and hardware tokens will remain a tool for people who have a specific threat model that justifies the friction.
Developers who travel. People who handle infrastructure. Anyone whose private key is worth more than fifty-five dollars to an attacker.
Which is a lot of people who don't realize it yet.
The next frontier, I think, is hardware-backed SSH certificates. Not just keys — certificates. Imagine a token that signs a short-lived certificate granting access to an entire fleet of servers. The certificate expires after an hour. No individual SSH keys to manage across machines. The token becomes the root of a certificate authority that lives in your pocket.
That's already possible with the PIV functionality on a YubiKey. You can set up a small internal CA, store the CA key on the token, and issue short-lived SSH certificates from it. HashiCorp Vault can do this, and Step CA has good support for hardware-backed keys. It's not a beginner workflow, but for someone managing more than a handful of servers, it's the right answer.
If you travel with a laptop, ask yourself a simple question. Where is your private key right now? If the answer is "in a file on this machine," you have homework.
Fifteen minutes of homework. That's all it takes.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the show running, and for the drawer full of time bombs.
If you want to dig deeper on any of this, the show notes have links to setup guides for SSH with hardware tokens and the current spec sheets for everything we discussed. Find us at my weird prompts dot com.
We'll be back soon.
