TL;DR: per gli accessi umani, soprattutto quelli amministrativi, le passkey sono una scelta migliore di password + MFA. Tolgono di mezzo il segreto condiviso e resistono al phishing. I nuovi attacchi Pass-ta-key non ribaltano il verdetto: partono da un computer Windows già compromesso. Cambia però la responsabilità operativa. Passare alle passkey senza proteggere endpoint, recovery e autenticatrici di riserva lascia un buco diverso, non un sistema sicuro.
Il criterio: quale rischio elimina davvero?
Il confronto non va fatto sul numero di passaggi nella schermata di login. Il criterio utile per una PMI è la riduzione della superficie d’attacco lungo quattro punti: phishing remoto, furto dei dati sul server, compromissione del dispositivo e recupero dell’account.
Una password resta un segreto condiviso: l’utente la conosce e il servizio deve conservarne una rappresentazione verificabile. Il secondo fattore alza il costo dell’attacco, ma un codice TOTP può ancora essere raccolto in tempo reale da un sito di phishing. Una passkey usa invece una coppia crittografica legata al dominio. Il servizio conserva la chiave pubblica; la privata resta nell’autenticatore. Lo standard WebAuthn Level 3 del W3C lega la credenziale al Relying Party ID e prevede la verifica dell’utente tramite PIN o biometria.
Su phishing e violazioni del database, quindi, il confronto è netto: vince la passkey. Non c’è una password da riutilizzare, esfiltrare o digitare sul dominio sbagliato.
Dove password + MFA resta più semplice
Password + MFA ha ancora due vantaggi pratici. Funziona quasi ovunque e il recupero è familiare. Per un team con software legacy, hosting diversi e clienti poco tecnici, questa compatibilità riduce l’attrito iniziale. È anche più facile separare una credenziale destinata a un’integrazione da quella usata da una persona.
Il prezzo è operativo. Servono password uniche, un password manager, un secondo fattore, codici di recupero e una procedura per revocare tutto quando cambia un collaboratore. Se resta attivo un fallback debole, l’attaccante non deve battere il metodo migliore: gli basta scegliere quello peggiore. Una passkey affiancata da password riutilizzata e SMS non rende sicuro l’account.
Per le automazioni il discorso è diverso. Un job che pubblica via REST non può appoggiare un dito su Touch ID. Qui servono token o credenziali applicative revocabili, con privilegi minimi e rotazione. Nel caso WordPress, le Application Password sono pensate proprio per l’accesso API delle integrazioni. La passkey protegge l’amministratore; non sostituisce il secret della macchina. Ho già approfondito perché le chiavi API in WordPress vanno tenute fuori dal database.
Cosa dimostra davvero Pass-ta-key
La ricerca pubblicata da Unit 42 il 3 agosto 2026 descrive tre attacchi contro le passkey sincronizzate di Google Password Manager in Chrome su Windows con TPM. In tutti i casi il punto di partenza è malware già presente sul dispositivo della vittima. I ricercatori mostrano come abusare dell’identità del device, della registrazione della chiave di user verification e del materiale usato per decifrare le passkey sincronizzate.
È una distinzione decisiva. L’attacco non rende nuovamente efficace il phishing di massa e non spezza la crittografia di WebAuthn. Sposta il bersaglio sull’endpoint, sui flussi di onboarding e sulla sincronizzazione cloud. La stessa specifica W3C avverte che codice malevolo eseguito nell’origine o un client compromesso possono invalidare le garanzie del protocollo.
Questo non assolve chi implementa il login. Unit 42 raccomanda di impostare userVerification = required e verificare davvero il flag UV nella risposta. La ricerca USENIX Security 2026 sullo stato delle passkey ha trovato due tipi di attacco con punteggio CVSS critico su 18 dei 103 siti valutati. Il protocollo può essere solido e l’integrazione sbagliata.
Passkey sincronizzata o chiave hardware?
Nemmeno tutte le passkey offrono lo stesso livello di garanzia. Quelle sincronizzate seguono l’utente tra più dispositivi e rendono più semplice il recupero. Le passkey device-bound, per esempio su una chiave hardware, non vengono copiate: riducono la superficie di sync, ma obbligano a registrare almeno un’autenticatrice di riserva.
La FIDO Alliance presenta la scelta come un compromesso tra assurance e usabilità. Per la maggior parte dei collaboratori di una PMI sceglierei passkey sincronizzate, con blocco schermo robusto e dispositivi gestiti. Per hosting, DNS, cloud, password manager e account owner userei due chiavi hardware registrate separatamente, conservandone una come recovery.
Applicazione concreta a WordPress e automazioni
La guida ufficiale WordPress contro gli attacchi brute force suggerisce passkey tramite un plugin WebAuthn mantenuto e almeno due autenticatrici per ogni amministratore. WordPress core non include ancora 2FA: plugin e identity provider diventano parte della superficie di sicurezza e vanno aggiornati, testati e rimossi se abbandonati.
- Accessi umani privilegiati: passkey obbligatoria, due autenticatrici e recovery documentata.
- Account ad alto impatto: chiavi hardware device-bound, niente fallback SMS.
- REST, n8n, Make e CI: Application Password o token dedicato, privilegi minimi, secret manager e revoca separata.
- Endpoint: aggiornamenti, EDR o almeno protezione antimalware, cifratura disco e niente account amministratore per il lavoro quotidiano.
- WebAuthn sviluppato in casa: validazione di origin, RP ID e flag UV, più audit del flusso di recovery.
La take finale
Tra passkey e password + MFA, per le persone scelgo passkey. È il metodo che elimina più attacchi comuni alla radice. Password + MFA resta un ponte per sistemi legacy e un fallback da controllare, non la destinazione.
Pass-ta-key aggiunge una correzione utile: passwordless non significa endpointless. Per una PMI la strategia giusta è passkey sincronizzata per l’uso quotidiano, chiave hardware per gli account critici e credenziali applicative separate per le automazioni. Mescolare questi tre ruoli è più pericoloso che scegliere la tecnologia sbagliata.