Hardware beveiligingssleutels: wanneer, waar en hoe
Een hardware beveiligingssleutel is het sterkste tweede-factor dat voor de meeste mensen beschikbaar is. Hij is bestand tegen phishing, werkt zonder batterij, en gaat tien jaar mee.
Hardware beveiligingssleutels: wanneer, waar en hoe
Een hardware beveiligingssleutel is het sterkste tweede-factor dat voor de meeste mensen beschikbaar is. Hij is bestand tegen phishing, werkt zonder batterij, en gaat tien jaar mee.
Maar hij is geen vanzelfsprekende volgende stap voor iedereen. Dit gids helpt je beslissen wanneer het zinvol is, welke accounts je als eerste aansluit, en hoe je het operationeel verantwoord inricht.
Wanneer een hardware sleutel pas zinvol is
Een authenticator-app (TOTP) is al een sterke keuze voor de meeste lezers. Een hardware sleutel voegt iets toe boven TOTP, maar dat verschil doet er alleen toe in specifieke omstandigheden.
Een hardware sleutel is de juiste stap als:
- je een verhoogd risico loopt op gerichte phishing — denk aan journalisten, advocaten, politici, IT-beheerders
- je toegang beheert tot systemen van anderen en jij daarmee een aantrekkelijk doelwit bent
- je werkt bij een organisatie die passkey of FIDO2 verplicht stelt voor bepaalde toegangen
- je SSH-toegang hebt tot productieomgevingen en de sleutel ook als SSH-authenticatie wilt gebruiken
Een hardware sleutel is overkill als:
- je belangrijkste accounts nog geen gewone 2FA hebben — fix dat eerst
- je nog niet zeker weet hoe je met back-upcodes omgaat — ook dat eerst
- je de sleutel alleen koopt omdat je het “goed wilt doen” maar er geen duidelijk dreigingsprofiel achter ligt
De basislijn is: TOTP op al je kritieke accounts, back-upcodes veilig opgeslagen. Daarna pas de afweging voor hardware.
Wat een hardware sleutel anders maakt
Het verschil zit niet in encryptie, maar in phishing-resistentie.
Bij TOTP vul je een code in op een website. Als die website nep is, kan een aanvaller die code in real-time doorsturen naar de echte site en zo toch inloggen. Dit heet een adversary-in-the-middle aanval.
Een hardware sleutel werkt anders: de sleutel controleert zelf de domeinnaam van de site voordat hij authenticatie verleent. Een nepsite krijgt nooit een geldig signaal — zelfs als je de sleutel erin stopt. Deze bescherming is ingebakken in het FIDO2- en WebAuthn-protocol en kan niet worden omzeild door een nep-inlogpagina.
Dit maakt hardware sleutels fundamenteel sterker dan TOTP tegen phishing. TOTP beschermt goed tegen zwakke aanvallen zoals credential stuffing. Hardware sleutels beschermen ook tegen actieve gerichte aanvallen.
Welke sleutel
Twee opties domineren voor privacybewuste gebruikers:
YubiKey 5 NFC — de bewezen standaard. Brede compatibiliteit met vrijwel elke dienst. Gesloten firmware, niet bij te werken. Speciale FIPS- en CSPN-varianten zijn extern gecertificeerd; het standaard retailmodel niet.
Nitrokey 3 NFC — open-source firmware, volledig inzichtelijk. Firmware-updates mogelijk. Iets minder breed compatibel bij obscure diensten.
Voor de meeste lezers maakt het verschil in dagelijks gebruik weinig uit. De YubiKey is de veilige keuze als compatibiliteit prioriteit is. De Nitrokey is logischer als open-source firmware een harde eis is of als je de lagere prijs benut om meteen twee sleutels te kopen.
Zie de YubiKey vs Nitrokey review voor een gedetailleerde vergelijking.
Koop altijd twee sleutels. Eén als primaire, één als back-up. Sla de back-upsleutel op een veilige locatie op — niet in dezelfde tas als de primaire.
Welke accounts zet je er als eerste op
Begin met de accounts die het meest schade aanrichten als ze worden overgenomen. Dat zijn doorgaans niet de accounts die je het vaakst gebruikt.
Prioriteit 1 — Accounts die toegang geven tot andere accounts
- je primaire e-mailaccount (wachtwoordresets lopen hier doorheen)
- je wachtwoordmanager (als die een hardware key ondersteunt)
- je werkaccount of identity provider (Google Workspace, Microsoft Entra, Okta)
Prioriteit 2 — Privileged en beroepsgerelateerde toegang
- GitHub, GitLab of andere code-repositories
- cloudomgevingen (AWS, GCP, Azure console — niet alleen de CLI)
- servers, VPN-toegang, beheerinterfaces
- accounts voor cliënt- of patiëntdata
Prioriteit 3 — Overig kritisch
- financiële accounts die hardware keys ondersteunen
- domeinregistrar en DNS-beheer
- back-updiensten en archieven
Leg eerst prioriteit 1 goed vast voordat je verder gaat. De meeste phishing-aanvallen richten zich op e-mail- en identiteitsproviders, niet op een obscuur dashboard.
De back-upsleutel goed inrichten
De back-upsleutel is geen sieraad — hij moet werken als de primaire sleutel verdwijnt. Dat vereist dat je hem op dezelfde accounts inschrijft.
Werkwijze:
- Schrijf de primaire sleutel in op account A.
- Schrijf de back-upsleutel ook in op account A, in dezelfde sessie.
- Doe dit voor elk account voordat je naar het volgende gaat.
- Bewaar de back-upsleutel apart van de primaire — apart huis, kluis, of een plek die de primaire niet deelt.
Schrijf de back-upsleutel niet pas in als de primaire al weg is. Dan heb je hem niet.
Sla ook de back-upcodes op voor accounts die die aanmaken bij inschrijving. Bewaar ze net zo zorgvuldig als de sleutels zelf.
Hardware sleutels voor SSH
Voor IT-professionals is SSH-authenticatie via een hardware sleutel een extra laag bovenop een SSH-sleutelpaar. Het werkt via FIDO2-gebaseerde SSH-sleutels (resident keys of discovery keys).
Hoe het werkt:
- je genereert een FIDO2 SSH-sleutel die is gebonden aan de hardware sleutel
- bij verbinding vereist de authenticatie dat de sleutel fysiek aanwezig is én je erop drukt
- een aanvaller met alleen je SSH-sleutelbestand kan niet inloggen zonder de hardware sleutel
Aanmaken:
ssh-keygen -t ed25519-sk -O resident
De -O resident optie slaat de sleutel op op de hardware sleutel zelf, zodat hij bruikbaar is vanaf meerdere machines zonder het sleutelbestand te kopiëren. Zonder resident werkt het ook, maar dan blijft een lokaal sleutelbestand nodig.
Beperkingen:
- Niet alle SSH-servers en configuraties ondersteunen FIDO2 SSH-sleutels — controleer dit voor je afhankelijk wordt van deze methode in productie.
- OpenSSH 8.2+ vereist op de client; de server hoeft alleen het
ed25519-sksleuteltype te accepteren, wat ondersteund is vanaf OpenSSH 8.2 maar in sommige configuraties ook met oudere serverversies werkt. - Dit vervangt de passphrase-bescherming van een normale SSH-sleutel, niet het sleutelpaar zelf.
Wat te doen als je een sleutel verliest
Als de primaire sleutel verdwijnt:
- Log in via de back-upsleutel of back-upcode.
- Verwijder de verloren sleutel uit alle accounts — doe dit account voor account, niet alleen op één plek.
- Activeer een nieuwe primaire sleutel en herschrijf die in op dezelfde accounts.
- Overweeg of de locatie van de back-upsleutel nog veilig is.
Als je geen back-upsleutel en geen back-upcodes hebt, is accountherstel volledig afhankelijk van de procedure van die dienst. Sommige diensten bieden identiteitsverificatie als terugvaloptie, andere niet. Plan er niet op.
Veelgemaakte fouten
Slechts één sleutel kopen. De meest voorkomende fout. Als die sleutel verdwijnt of stukgaat, sta je buiten elk account waarop hij stond.
De back-upsleutel niet inschrijven. Een ongeregistreerde back-upsleutel helpt niet. Schrijf hem direct in naast de primaire.
Beginnen met een account dat je nooit gebruikt. Zet de sleutel als eerste op accounts die er echt toe doen, niet op obscure testaccounts.
TOTP verwijderen zodra de hardware sleutel werkt. Behoud TOTP als tweede inlogoptie totdat je back-upsleutel en back-upcodes goed staan. Daarna kun je beslissen of je TOTP als fallback wilt houden.
Ervan uitgaan dat elke dienst het ondersteunt. Controleer vóór de aankoop welke accounts in jouw workflow FIDO2 of WebAuthn ondersteunen. Niet elke dienst heeft dit.
Volgende stap
Kies je sleutel
- YubiKey vs Nitrokey review — voor de productbeslissing als je al weet dat je een hardware sleutel wilt
Zorg eerst dat de basis staat
- Twee-factor authenticatie gids — als TOTP nog niet goed staat op je kritieke accounts
- Welke wachtwoordmanager moet je kiezen? — als je wachtwoordbeheer nog zwak is
Gebruik dit in context
- Profiel: IT professional en sysadmin — als privileged access de reden is voor hardware 2FA
- Profiel: journalist of activist — als gerichte phishing het concrete risico is
- Profiel: hoog risico — als hardware keys onderdeel zijn van een bredere OpSec-aanpak