Se negli ultimi mesi hai aperto le impostazioni di sicurezza di Google, Apple, Microsoft o di altri servizi online, probabilmente hai incontrato un invito a creare una passkey. Il messaggio sembra semplice: niente più password, basta il volto, l’impronta digitale o il PIN del dispositivo.
Il meccanismo reale è però diverso, e vale la pena capirlo. La passkey non è la tua impronta digitale e non è nemmeno il PIN del telefono. È una credenziale crittografica che consente a un sito o a un’app di verificare che possiedi la chiave corretta senza chiederti di trasmettere una password.
È proprio questa differenza a rendere il sistema particolarmente resistente al phishing, al credential stuffing e al furto delle credenziali dai database. La FIDO Alliance descrive queste credenziali come basate su coppie di chiavi crittografiche che possono essere sincronizzate fra più dispositivi oppure rimanere legate a un singolo autenticatore.
Questo non significa che ogni account diventi automaticamente invulnerabile. Nel 2026 la distinzione importante è un’altra: un protocollo di autenticazione molto robusto può convivere con dispositivi compromessi, procedure di recovery deboli o implementazioni imperfette.
Vediamo quindi cosa succede realmente durante creazione e login, cosa cambia rispetto a password e 2FA e quali limiti è utile conoscere.
Cosa sono le passkey
Una passkey è una credenziale digitale associata a uno specifico account e a uno specifico sito o applicazione. Al posto di basarsi su un segreto che tu e il servizio dovete conoscere, utilizza la crittografia a chiave pubblica.
Durante la registrazione vengono generate due componenti matematicamente collegate: una chiave pubblica e una chiave privata. Il servizio conserva la prima. La seconda rimane sotto il controllo del dispositivo, dell’autenticatore o del gestore di credenziali che utilizzi.
La chiave pubblica non deve rimanere segreta. Quella privata, invece, è ciò che permette di dimostrare il possesso della credenziale.
Questo cambia alla radice il modello tradizionale di autenticazione: il sito non deve conservare un’informazione segreta che possa essere utilizzata direttamente per impersonarti. La documentazione Google dedicata alle passkey descrive proprio questo modello: il server registra la chiave pubblica, mentre quella privata resta dalla parte dell’utente.
Una passkey non è la tua impronta digitale o Face ID
Qui nasce uno degli equivoci più comuni.
Quando durante l’accesso il telefono ti chiede Face ID, Touch ID, l’impronta digitale o il PIN, quel controllo serve ad autorizzare localmente l’uso della credenziale. Non stai inviando l’impronta al sito sul quale vuoi entrare.
La distinzione è semplice:
passkey = credenziale crittografica
biometria o PIN = metodo con cui il dispositivo verifica che tu possa usare quella credenziale
Per questo dire che “è il Face ID al posto della password” può essere comodo per descrivere l’esperienza utente, ma è tecnicamente incompleto. La biometria sblocca localmente l’operazione; non diventa il segreto condiviso con il servizio.
Cosa c’entrano FIDO2 e WebAuthn
Non stiamo parlando di una tecnologia proprietaria di Google, Apple o Microsoft.
Il sistema si basa sull’ecosistema di standard FIDO e, sul Web, sulla Web Authentication API, o WebAuthn. Questa specifica definisce il modo in cui un sito può creare e utilizzare credenziali crittografiche associate a una determinata Relying Party, cioè al servizio che richiede l’autenticazione.
La specifica WebAuthn Level 3 del W3C descrive public-key credentials legate alla Relying Party che le ha create. Una credenziale destinata a un servizio non può quindi essere semplicemente riutilizzata su un’origine arbitraria.
Non serve conoscere l’API per utilizzare questo metodo di accesso. Il concetto importante è un altro: browser e sistema operativo partecipano alla verifica del sito sul quale stai tentando di autenticarti.
Come funziona una passkey, dalla creazione al login
Per capire perché offre proprietà diverse da una password conviene seguire il processo completo.
Creazione: il dispositivo genera una chiave pubblica e una privata
Quando un sito supporta questo tipo di autenticazione, normalmente parti da un account già esistente oppure dalla procedura di registrazione.
Il servizio chiede al browser o al sistema operativo di creare una nuova credenziale. L’autenticatore — che può essere il dispositivo, un credential manager o una chiave hardware compatibile — genera una coppia crittografica specifica per quell’account.
La chiave pubblica viene registrata sul server. La privata rimane sotto il controllo dell’autenticatore o del provider che la gestisce.
Nel caso delle credenziali sincronizzate questo non significa necessariamente che la chiave privata esista soltanto sul primo telefono che l’ha generata: può essere protetta e resa disponibile anche sugli altri dispositivi autorizzati.
Accesso: il servizio invia una challenge e il dispositivo la firma
Quando torni sul sito, non devi dimostrare di conoscere un testo segreto.
Il server genera invece una challenge, cioè un valore nuovo per quella specifica richiesta di autenticazione. Dopo la verifica locale richiesta dal dispositivo — per esempio tramite impronta, volto o PIN — la chiave privata viene utilizzata per produrre una firma crittografica.
Il server controlla quindi la firma con la chiave pubblica registrata in precedenza.
Il modello mentale è questo:
server → challenge → dispositivo → firma → server → verifica
La parte privata della coppia crittografica non deve essere trasmessa al servizio. È sufficiente dimostrare matematicamente di averne il controllo.
Perché la chiave privata non deve essere inviata al sito
Con una password, entrambe le parti devono lavorare a partire dallo stesso segreto: tu lo conosci e il servizio conserva una rappresentazione che gli permette di verificarlo.
Con la crittografia a chiave pubblica questo segreto condiviso non esiste.
Se un aggressore sottrae dal database del servizio la chiave pubblica, non ottiene ciò che gli serve per firmare una nuova challenge.
Questo non rende irrilevante una violazione del server: potrebbero essere esposti molti altri dati o esistere vulnerabilità applicative. Ma il database delle credenziali non contiene l’equivalente di un insieme di password da recuperare e riutilizzare.
Perché la credenziale riconosce il sito corretto
La seconda differenza decisiva riguarda il phishing.
Con una password, se una pagina falsa è abbastanza convincente da farti digitare le credenziali, l’attaccante può raccoglierle e tentare di utilizzarle sul servizio autentico.
Nel modello WebAuthn, invece, la credenziale viene associata all’identità del servizio per il quale è stata creata. Browser e sistema operativo verificano questa relazione prima di consentirne l’utilizzo.
È qui che nasce la phishing resistance: non dipende soltanto dalla tua capacità di riconoscere un dominio falso. È il protocollo a impedire che la chiave venga utilizzata arbitrariamente su un sito differente.
Passkey vs password e 2FA: cosa cambia davvero
Password, autenticazione a due fattori e credenziali FIDO possono portarti alla stessa schermata finale — “accesso riuscito” — ma arrivano a quel risultato con modelli di sicurezza differenti.
| Metodo | Cosa possiede o conosce l’utente | Cosa conserva il servizio | Resistenza al phishing |
|---|---|---|---|
| Password | Un segreto testuale | Dati necessari a verificarlo | Bassa: può essere inserita su un sito falso |
| Password + OTP | Password + codice o secondo fattore | Credenziale password + configurazione MFA | Migliore della sola password, ma molti OTP restano phishable |
| Passkey | Controllo della chiave privata + eventuale verifica locale | Chiave pubblica | Alta grazie al binding con il servizio |
| Credenziale device-bound | Chiave legata a uno specifico autenticatore | Chiave pubblica | Alta; può offrire proprietà aggiuntive in scenari enterprise |
Questo confronto non significa che “qualsiasi passkey è sempre superiore a qualsiasi MFA”. Nel mondo enterprise entrano in gioco requisiti di assurance, gestione dei dispositivi, attestation, recovery e policy organizzative.
Per un normale account consumer, però, la differenza rispetto a password e OTP tradizionali è sostanziale.
Cosa cambia in caso di violazione del server
Immagina un servizio con un milione di utenti.
Se utilizza password e un aggressore ottiene materiale utile per attacchi offline, può tentare di recuperare quelle più deboli. Le stesse combinazioni potrebbero inoltre essere state riutilizzate su altri servizi.
Con una credenziale basata su coppia di chiavi, ogni account dispone invece di materiale crittografico specifico. La parte conservata sul server è pubblica e non consente da sola di autenticarsi.
Vengono quindi ridotte due classi di problemi storicamente importanti: furto di password riutilizzabili e credential stuffing basato su credenziali recuperate altrove.
Una passkey può sostituire anche la verifica in due passaggi?
Spesso sì, ma bisogna formulare bene la risposta.
Quando il sistema richiede anche la user verification, l’utilizzo della chiave viene autorizzato attraverso il meccanismo di sblocco del dispositivo. Questo può evitare la sequenza tradizionale password + SMS o TOTP.
Non significa però che ogni organizzazione possa sostituire automaticamente qualsiasi configurazione MFA con qualsiasi implementazione FIDO. Nei contesti regolamentati o ad alta sicurezza può essere importante sapere dove è custodita la credenziale, se è sincronizzabile o device-bound e quali garanzie offre l’autenticatore.
Per un account personale il vantaggio è più semplice: puoi ottenere un accesso molto resistente al phishing evitando contemporaneamente di digitare password e codici temporanei.
Perché le passkey sono resistenti al phishing
La definizione “phishing-resistant” rischia di sembrare marketing finché non se ne comprende il meccanismo.
La protezione deriva principalmente da due proprietà: non esiste una password che puoi consegnare volontariamente all’attaccante e la credenziale è legata al servizio corretto.
Non esiste una password da consegnare all’attaccante
Una pagina di phishing può chiederti una password. Può chiederti un codice OTP. Può persino tentare di convincerti ad approvare una notifica.
Con questo modello, però, non possiedi una stringa segreta che puoi copiare e incollare nella pagina.
L’interazione passa attraverso browser, sistema operativo e credential manager. Viene quindi eliminato il classico scenario nel quale l’attaccante convince l’utente a consegnargli direttamente la credenziale.
Il browser e il sistema operativo verificano il servizio per te
La protezione più interessante è però il binding con il sito.
Prima di utilizzare la chiave, il sistema verifica che la richiesta provenga dalla Relying Party appropriata. In altre parole, la validità dell’autenticazione non dipende soltanto da ciò che vedi sullo schermo.
Anche il National Cyber Security Centre britannico raccomanda questo approccio come alternativa più sicura alle password, evidenziandone la resistenza al phishing e l’impossibilità di intercettare e riutilizzare la credenziale nello stesso modo di una password tradizionale.
Le passkey sono davvero sicure? I limiti che contano nel 2026
Sì: eliminano o riducono in modo sostanziale alcune delle debolezze fondamentali delle password.
La risposta non dovrebbe però trasformarsi in “non possono essere compromesse”.
La sicurezza di un account non coincide con la sola sicurezza del protocollo di autenticazione. Comprende anche sistema operativo, browser, credential manager, sincronizzazione, recovery, sessioni già attive e condizioni del dispositivo.
Phishing-resistant non significa invulnerabile
È utile separare tre livelli.
Protocollo: come WebAuthn/FIDO verifica la credenziale.
Implementazione: come un provider la conserva, sincronizza e recupera.
Endpoint: il computer o lo smartphone sul quale browser e credential manager vengono eseguiti.
WebAuthn può continuare a impedire l’utilizzo della chiave su un dominio di phishing mentre un malware già presente sul computer attacca un livello completamente diverso.
Non è una contraddizione. Significa semplicemente che nessun protocollo di login rende irrilevante la sicurezza del dispositivo che lo esegue.
Cosa hanno mostrato gli attacchi Pass-Ta-Key del 2026
Un esempio particolarmente utile arriva dalla ricerca pubblicata da Unit 42 nell’agosto 2026.
Nel lavoro Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, i ricercatori hanno documentato tre tecniche denominate Pass-Ta-Key, Silver Pass-Ta-Key e Golden Pass-Ta-Key contro uno specifico scenario di credenziali sincronizzate.
Il perimetro è fondamentale: la ricerca riguarda Google Password Manager in Chrome su Windows con TPM e parte dalla presenza di malware sul dispositivo della vittima.
Non dimostra che WebAuthn sia stato “rotto” e non dimostra che tutte le implementazioni siano vulnerabili nello stesso modo.
Mostra invece qualcosa di più utile: un aggressore che possiede già un punto d’appoggio sull’endpoint può cercare di abusare dei meccanismi con cui il provider riconosce i dispositivi, effettua onboarding, recupera materiale crittografico o gestisce la user verification.
È la distinzione che conta: eliminare il furto della password come strategia non elimina ogni possibile superficie d’attacco.
Un dispositivo già compromesso cambia il threat model
Se sul computer viene eseguito malware con capacità sufficienti, il problema non è più semplicemente “l’attaccante conosce la mia password?”.
L’endpoint stesso non è affidabile.
Un malware può tentare di accedere a sessioni esistenti, dati locali, processi del browser, meccanismi del credential manager o flussi di autenticazione.
Questo non riduce il valore del protocollo. Cambia la domanda.
Se una password può essere sottratta anche tramite un sito di phishing remoto, il nuovo modello chiude in gran parte quel vettore. Se invece il computer è già compromesso, devi affrontare endpoint security, non cercare una password ancora più complessa.
Recovery e metodi di fallback possono diventare l’anello debole
C’è poi un problema meno spettacolare ma molto concreto.
Un account può utilizzare una credenziale FIDO per il login quotidiano e continuare ad avere una password, una procedura di recupero o altri metodi alternativi.
In quel caso la sicurezza reale dipende anche da quei percorsi.
Se l’accesso principale è estremamente resistente al phishing ma la procedura “non riesco più ad accedere” permette di tornare facilmente a un metodo molto più debole, l’attaccante proverà a colpire il percorso più semplice.
Quando abiliti questo sistema, quindi, controlla anche quali metodi di accesso e recupero rimangono disponibili sull’account.
Passkey sincronizzate e device-bound: non sono la stessa cosa
La stessa esperienza utente può nascondere due modelli con implicazioni differenti.
Le synced passkeys possono essere rese disponibili su più dispositivi attraverso un credential manager. Le device-bound passkeys restano invece legate a uno specifico autenticatore.
La distinzione diventa particolarmente importante in ambito professionale e viene analizzata anche nelle linee guida FIDO per l’adozione enterprise.
Synced passkey: praticità, backup e utilizzo su più dispositivi
Una credenziale sincronizzata è pensata per ridurre l’attrito.
La crei su un dispositivo e il provider può renderla disponibile anche sugli altri dispositivi autorizzati appartenenti allo stesso ecosistema o credential manager.
Il vantaggio è evidente: cambiare telefono non significa necessariamente registrare da zero una nuova chiave per ogni servizio.
Il trade-off è altrettanto importante: una parte della sicurezza dipende ora anche dal sistema che gestisce sincronizzazione, autorizzazione di nuovi dispositivi e recovery.
Device-bound passkey: quando la credenziale rimane legata al dispositivo
Nel modello device-bound la chiave resta associata allo specifico autenticatore sul quale è stata generata.
L’esempio più intuitivo è una chiave di sicurezza hardware FIDO.
Per alcune aziende questa caratteristica è utile perché limita ulteriormente la portabilità della credenziale e permette di costruire policy più rigide sul possesso del dispositivo. Per un utente consumer, però, può aumentare la complessità in caso di perdita o sostituzione dell’autenticatore.
Non esiste quindi una risposta universale “synced è migliore” oppure “device-bound è migliore”.
Il primo modello privilegia continuità e facilità d’uso. Il secondo può offrire proprietà utili quando il controllo stretto dell’autenticatore fa parte del requisito di sicurezza.
Cosa succede se perdi il telefono o cambi dispositivo
La paura più comune è comprensibile: se non conosco più una password da digitare, cosa succede quando il telefono si rompe?
La risposta dipende da dove viene custodita la credenziale e da come funziona il provider scelto.
Dove vengono realmente conservate le passkey
La gestione può avvenire attraverso il sistema operativo, un credential manager oppure un autenticatore hardware.
Apple salva queste credenziali nell’app Password e può sincronizzarle tramite Portachiavi iCloud. La documentazione Apple per iPhone descrive anche l’utilizzo sugli altri dispositivi associati allo stesso Apple Account.
Su Windows puoi salvarle sul dispositivo oppure utilizzare un credential manager sincronizzato. La documentazione Microsoft contempla entrambe le possibilità.
È qui che il tema incontra quello dei password manager e gestori di credenziali: molti strumenti nati per custodire password stanno diventando anche provider di credenziali passwordless.
Recupero e sincronizzazione non significano che la chiave privata sia pubblica
“Sincronizzata nel cloud” non significa “salvata in chiaro su un server”.
I provider implementano meccanismi crittografici specifici per proteggere il materiale durante sincronizzazione e recovery. Apple, per esempio, documenta l’uso della crittografia end-to-end nel Portachiavi iCloud.
Rimane comunque corretto considerare il provider parte del tuo modello di fiducia. Il modo in cui protegge nuovi dispositivi, recupero dell’account e sincronizzazione conta tanto più quanto più la credenziale diventa portabile.
Usare una credenziale presente sul telefono per accedere da un altro dispositivo
Non è sempre necessario copiarla o sincronizzarla sul computer dal quale vuoi effettuare l’accesso.
Gli standard FIDO supportano anche flussi cross-device nei quali lo smartphone autorizza l’accesso su un altro dispositivo nelle vicinanze.
In pratica potresti vedere un QR code, utilizzare il telefono per completare l’autenticazione e lasciare la chiave sul dispositivo originale.
Questo può essere particolarmente utile su computer temporanei o non tuoi.
Cambiare gestore: cosa sta cambiando nel 2026
La portabilità fra credential manager è stata uno dei punti più delicati della prima fase di diffusione.
La situazione sta evolvendo grazie alle Credential Exchange Specifications della FIDO Alliance, che definiscono un formato standard per trasferire credenziali fra gestori compatibili.
Nel giugno 2026 anche Google ha documentato il supporto all’importazione e all’esportazione di password e credenziali passwordless fra Google Password Manager e provider compatibili con Credential Exchange, nelle proprie note di rilascio.
Questo non significa ancora portabilità universale fra qualsiasi combinazione di piattaforme e password manager. Prima di spostare un archivio conviene quindi verificare il supporto effettivo dei due provider coinvolti.
Come creare e iniziare a usare una passkey
La posizione esatta dei menu cambia da servizio a servizio, ma il flusso concettuale è abbastanza uniforme.
Accedi normalmente all’account, apri le impostazioni dedicate a sicurezza o metodi di accesso e scegli l’opzione per creare una nuova credenziale. Se il sistema propone più provider, seleziona dove conservarla. Infine conferma l’operazione attraverso il metodo di sblocco del dispositivo.
Al login successivo, browser o sistema operativo potranno proporti direttamente quel metodo di autenticazione.
Il dettaglio importante è che non devi creare manualmente una chiave né inventare un nuovo codice. La componente crittografica viene generata dall’autenticatore.
Utilizzo su Google e Android
Su Google e Android la credenziale può essere associata a Google Password Manager oppure, nelle configurazioni supportate, a un credential manager compatibile.
Durante l’accesso ti viene chiesto di utilizzare il metodo di sblocco configurato sul dispositivo, come impronta, riconoscimento del volto, PIN o pattern.
La biometria serve quindi a sbloccare localmente l’operazione: non sostituisce la chiave crittografica e non viene trasformata in una password inviata al servizio.
Utilizzo su iPhone, iPad e Mac
Nell’ecosistema Apple il sistema è integrato nell’app Password e nel Portachiavi iCloud.
Quando un sito o un’app compatibile propone di creare una nuova credenziale, puoi confermare l’operazione e successivamente utilizzare Face ID, Touch ID oppure il codice del dispositivo per autorizzarne l’uso.
Un servizio può inoltre continuare a mantenere sia una password sia un metodo passwordless per lo stesso account. La transizione, quindi, non è necessariamente “tutto o niente”.
Utilizzo su Windows e account Microsoft
Windows 11 integra la gestione di queste credenziali nelle impostazioni dell’account e Microsoft supporta sia chiavi salvate sul dispositivo sia credential manager sincronizzati.
Per gli account personali puoi aggiungere un nuovo metodo dalle opzioni avanzate di sicurezza. Negli account aziendali o scolastici, invece, le possibilità disponibili possono dipendere dalle policy definite dall’organizzazione.
Questo è un buon esempio della differenza fra consumer ed enterprise: la stessa tecnologia può essere sottoposta a regole molto differenti a seconda del livello di controllo richiesto.
Quando conviene usare una passkey
Per un normale account personale la risposta oggi è abbastanza chiara: se il servizio offre questo metodo attraverso un ecosistema o credential manager di cui ti fidi, in genere conviene abilitarlo.
Il vantaggio non è semplicemente evitare di ricordare una password. Cambia il meccanismo stesso di autenticazione: viene eliminato il segreto condiviso, non puoi riutilizzare la stessa credenziale su servizi diversi e il login viene legato al sito corretto.
Per gli account personali: usarla quando il servizio la supporta
Email, account cloud, social network, servizi finanziari e identità principali sono particolarmente interessanti perché la compromissione di uno di questi account può consentire il reset di molti altri.
Questo metodo non sostituisce la necessità di proteggere smartphone e computer. Ma riduce fortemente l’esposizione agli attacchi che partono dal furto, dal riutilizzo o dal phishing della password.
Quando non eliminare ancora i metodi di recupero alternativi
Prima di rimuovere completamente password, dispositivi fidati o altre opzioni, chiediti cosa succederebbe se perdessi contemporaneamente l’accesso ai tuoi dispositivi principali.
Verifica come funziona il recovery del credential manager e dell’account e, se il servizio permette di registrare più autenticazioni sicure, valuta una configurazione ridondante.
Il problema non è avere “più metodi” in assoluto. È evitare che quello di emergenza diventi molto più facile da attaccare di quello principale.
Per aziende e account sensibili: synced e device-bound richiedono valutazioni diverse
In ambito aziendale la domanda cambia ancora.
Non basta sapere che il login utilizza FIDO/WebAuthn. Bisogna stabilire se la credenziale può essere sincronizzata, quali dispositivi possono riceverla, come avviene il recovery, quali verifiche locali sono ammesse, quali garanzie offre l’autenticatore e cosa richiedono le policy interne.
Per un account personale la sincronizzazione può rappresentare un enorme miglioramento dell’usabilità. Per un sistema aziendale ad alto rischio, invece, la portabilità potrebbe richiedere controlli ulteriori.
Il punto non è scegliere la tecnologia “più sicura in assoluto”, ma far coincidere il modello della credenziale con il rischio che devi gestire.
Conclusione
Le passkey rappresentano un cambiamento più profondo di quanto faccia pensare l’esperienza “tocca Face ID e accedi”.
La vera differenza è sotto la superficie: il servizio non ti chiede più di dimostrare di conoscere un segreto condiviso, ma di dimostrare crittograficamente il controllo di una chiave privata associata a quel servizio.
Da questo meccanismo derivano i vantaggi principali. Una password può essere indovinata, riutilizzata, sottratta da un database o inserita su una pagina di phishing. Una credenziale FIDO non funziona nello stesso modo: la chiave privata non viene consegnata al sito e l’autenticazione è vincolata alla Relying Party per la quale è stata creata.
Per questo, per la maggior parte degli account personali, sceglierei una passkey quando il servizio la supporta e il credential manager utilizzato offre un sistema di recovery che comprendo e considero adeguato.
Il limite da ricordare è altrettanto importante. Phishing-resistant non significa invulnerabile. Dispositivo, browser, provider, sincronizzazione e procedure di recupero restano parti del sistema di sicurezza.
La conseguenza pratica è semplice: passare dalle password alle passkey è un miglioramento reale, ma va accompagnato dalla stessa attenzione che dovresti già dedicare alla sicurezza dei dispositivi e al recupero degli account.