Cosa sono i passkey e le security key?
Nel 2021, Colonial Pipeline ha ricondotto un incidente ransomware a una password VPN compromessa e l’azienda ha pagato circa 4,4 milioni di dollari di riscatto, secondo un comunicato del DOJ. Questa è la realtà operativa dell’accesso iniziale basato su credenziali: gli attaccanti non hanno bisogno di zero-day quando possono effettuare phishing, riutilizzare o eseguire credential stuffing contro l’autenticazione basata su password.
Sia i passkey che le security key fisiche esistono per colmare questa lacuna. Utilizzano la stessa base crittografica, ma la differenza su come memorizzano e gestiscono le credenziali è rilevante quando si protegge un’azienda.
Un passkey è una credenziale di autenticazione FIDO che sostituisce le password con coppie di chiavi crittografiche. Secondo la FIDO Alliance, i passkey consentono agli utenti di accedere ad app e siti web utilizzando lo stesso processo che usano per sbloccare il proprio dispositivo: biometria, un PIN o un pattern. I passkey sono disponibili in due forme:
- Passkey sincronizzati memorizzano le credenziali in un gestore di credenziali supportato dal cloud e le sincronizzano tra i tuoi dispositivi.
- Passkey vincolati al dispositivo bloccano la chiave privata su un singolo dispositivo. Non lascia mai quell’hardware.
In pratica, il modello di archiviazione è ciò che determina la maggior parte dei compromessi aziendali.
Una security key hardware (chiamata anche autenticatore roaming) è un dispositivo hardware esterno che comunica con browser e sistemi operativi tramite USB, NFC o Bluetooth utilizzando il protocollo FIDO2 CTAP (Client-to-Authenticator Protocol). Pensa a YubiKey, smartcard e token simili. Questi sono, per definizione, vincolati al dispositivo: la chiave privata è memorizzata in un modulo di sicurezza hardware e non può essere esportata o copiata.
Entrambe le tecnologie condividono la stessa base crittografica. Ogni credenziale è unica, vincolata a uno specifico dominio di servizio e basata sulla crittografia a chiave pubblica standard. I dati biometrici non lasciano mai il tuo dispositivo. Il server memorizza solo la chiave pubblica. Questo design condiviso è ciò che rende entrambe le opzioni rilevanti per lo stesso problema di sicurezza centrale.
.jpg)
Come i passkey e le security key si collegano alla cybersecurity
Il DBIR Verizon 2025 riporta che l’abuso di credenziali guida una quota importante degli accessi iniziali: il 22% delle violazioni coinvolge l’abuso di credenziali come metodo di accesso iniziale, secondo il DBIR Verizon. Questo è coerente con quanto si osserva sul campo: una volta che un attaccante dispone di credenziali valide, stai combattendo contro i tuoi stessi percorsi di accesso.
Sia i passkey che le security key sono progettate per resistere al phishing. Come definito nelle specifiche WebAuthn, ogni asserzione di autenticazione è vincolata a uno specifico dominio web, quindi un sito di phishing su un dominio diverso non può ottenere un’asserzione valida. Questo blocca il phishing delle credenziali, il credential stuffing e gli attacchi adversary-in-the-middle a livello di protocollo, motivo per cui agenzie e settori regolamentati stanno adottando MFA resistente al phishing.
Per questo motivo, OMB M-22-09 ora impone che le agenzie federali utilizzino solo autenticazione resistente al phishing. La domanda per la tua organizzazione non è se adottare l’autenticazione FIDO2, ma quale modello di implementazione si adatta al tuo profilo di rischio. La tabella seguente mette a confronto le principali differenze.
Passkey vs. Security Key a colpo d’occhio
| Caratteristica | Passkey (sincronizzato) | Security key fisica |
| Archiviazione delle credenziali | Gestore di credenziali cloud (Apple Keychain, Google Password Manager) | Modulo di sicurezza hardware su token fisico |
| Esportabilità della chiave | Sincronizzata tra dispositivi tramite cloud | Non esportabile; vincolata all’hardware |
| Livello di garanzia NIST | AAL2 | AAL3 |
| Resistenza al phishing | Sì (vincolo di dominio FIDO2) | Sì (vincolo di dominio FIDO2) |
| Attestazione del dispositivo | Non supportata (la sincronizzazione cloud interrompe la chain-of-trust) | Supportata (certificato del produttore integrato nell’hardware) |
| Modello di recupero | Recupero account cloud tramite provider | Chiave di backup fisica o nuova registrazione mediata da admin |
| Esperienza utente | Trasparente, funziona su dispositivi sincronizzati | Richiede il token fisico a ogni accesso |
| Costo hardware | Nessuno (basato su software) | Acquisto token per utente e gestione del ciclo di vita |
| Supporto multipiattaforma | Dipende dall’ecosistema del provider | Universale (USB, NFC, BLE su qualsiasi piattaforma FIDO2) |
| Utilizzo ideale | Forza lavoro generale, ambienti BYOD | Admin privilegiati, settori regolamentati, conformità AAL3 |
Lo stack di protocollo, il modello di archiviazione e il supporto all’attestazione di ciascuna opzione determinano il livello di garanzia. Ecco come si suddividono questi componenti.
Come funziona l’autenticazione FIDO2
Sia i passkey che le security key si basano sullo stesso stack di protocollo FIDO2, ma differiscono su come memorizzano, proteggono e gestiscono il materiale crittografico sottostante. Comprendere questi componenti aiuta ad abbinare il tipo di credenziale giusto al livello di rischio appropriato.
Stack di protocollo FIDO2
FIDO2 è composto da due componenti principali definiti dalle specifiche FIDO:
- W3C Web Authentication (WebAuthn): L’API del browser che abilita l’autenticazione FIDO su siti web e applicazioni.
- Client-to-Authenticator Protocol (CTAP): Il protocollo che consente agli autenticatore esterni di comunicare con browser e sistemi operativi abilitati FIDO2.
Questi due livelli forniscono il vincolo di origine e la prova crittografica che rendono possibile un accesso forte e resistente al phishing.
Architettura di archiviazione delle credenziali
Il modello di archiviazione è la differenza principale tra passkey e security key. Ogni approccio gestisce la chiave privata in modo diverso:
- Security key hardware memorizzano le chiavi private in moduli di sicurezza hardware dedicati (HSM), spesso utilizzando un chip Trusted Platform Module (TPM). Secondo la documentazione Microsoft Entra, il materiale della chiave non è esportabile. Non è possibile copiarlo, eseguirne il backup o sincronizzarlo.
- Passkey sincronizzati utilizzano un sistema operativo o una piattaforma di sincronizzazione di terze parti per replicare le chiavi crittografiche tra dispositivi. La guida FIDO Alliance per le aziende segnala che ciò crea una dipendenza dalla piattaforma di sincronizzazione del provider di passkey e dai suoi controlli di sicurezza.
Questa distinzione nell’archiviazione determina tutte le decisioni successive su attestazione, conformità e recupero.
Attestazione
L’attestazione del dispositivo è una tecnica integrata nei protocolli FIDO e WebAuthn che consente all’autenticatore di verificare crittograficamente la chain-of-trust dal produttore del dispositivo. Secondo il white paper sull’attestazione della FIDO Alliance, ciò richiede un certificato del produttore integrato nell’elemento sicuro dell’autenticatore.
I passkey sincronizzati non possono fornire la provenienza del dispositivo perché la sincronizzazione cloud interrompe questa chain crittografica. Se si applica l’attestazione nella piattaforma di identità, solo le credenziali vincolate al dispositivo sono idonee.
Allineamento alla conformità
NIST SP 800-63B-4 traccia una linea chiara. AAL2 richiede autenticazione resistente al phishing e sia i passkey sincronizzati che le security key possono essere idonei. AAL3 richiede una chiave di autenticazione non esportabile, escludendo quindi i passkey sincronizzati.
Questi componenti si riflettono direttamente su ciò che accade durante l’accesso e su dove i due tipi di credenziali si comportano in modo diverso.
Registrazione, autenticazione e dove divergono
Il flusso di autenticazione per passkey e security key segue lo stesso schema FIDO2. La differenza emerge su come ciascuno gestisce archiviazione, portabilità e recupero delle credenziali.
Registrazione (entrambi i metodi)
Durante l’iscrizione, l’autenticatore genera una coppia unica di chiavi pubblica/privata vincolata al dominio del servizio. La chiave privata rimane sull’autenticatore e il server memorizza solo la chiave pubblica.
Autenticazione (entrambi i metodi)
- Il server invia una challenge crittografica.
- Esegui una verifica locale: scansione dell’impronta digitale, riconoscimento facciale, PIN o pressione di un pulsante fisico.
- L’autenticatore firma la challenge con la chiave privata.
- Il server valida la firma utilizzando la chiave pubblica memorizzata.
Questo flusso condiviso è il motivo per cui entrambi gli approcci bloccano gli attacchi di phishing a livello di protocollo.
Portabilità
Con una security key fisica, porti con te un token che autentica su dispositivi illimitati. Collegalo a qualsiasi browser compatibile FIDO2 o avvicinalo tramite NFC e accedi.
Con i passkey sincronizzati, le credenziali vengono replicate automaticamente tra dispositivi all’interno dell’ecosistema del provider: Apple, Google o un gestore di terze parti. Ti autentichi sul laptop e lo stesso passkey funziona sul telefono senza dover portare altro. Tuttavia, la portabilità tra ecosistemi rimane incoerente. Un flusso che funziona su Chrome/Windows può comportarsi diversamente su Safari/macOS e le differenze di UX a livello di browser restano un punto di attrito per le aziende.
Confini di sicurezza
Per le credenziali vincolate al dispositivo, un attaccante ha bisogno delle tue credenziali, dell’accesso fisico al token hardware e della capacità di bypassare l’autenticazione locale.
Per le credenziali sincronizzate, il confine di sicurezza si sposta sul provider cloud. Se un attaccante compromette l’account cloud tramite social engineering o manipolazione del reset del provider, può sincronizzare le credenziali su un dispositivo controllato dall’attaccante.
Questo spostamento del confine è dove entra in gioco la pianificazione operativa. Entrambi i tipi di credenziali comportano compromessi che devono essere considerati prima dell’adozione aziendale, e questi compromessi contano solo se le piattaforme, i browser e i provider di identità che utilizzi supportano effettivamente il tipo di credenziale scelto.
Dove sono supportati oggi passkey e security key
Nel 2025, l’adozione di passkey e security key ha raggiunto un punto di svolta pratico sia negli ecosistemi consumer che enterprise.
- Sistemi operativi e browser. Apple (iOS 16+, macOS Ventura+), Google (Android 9+) e Microsoft (Windows 10/11 tramite Windows Hello) supportano nativamente la creazione e l’autenticazione con passkey. Tutti i principali browser, inclusi Chrome, Safari, Edge e Firefox, supportano WebAuthn. Secondo la FIDO Alliance, oltre il 95% dei dispositivi iOS e Android sono ora pronti per i passkey e più di un miliardo di utenti ha attivato almeno un passkey.
- Provider di identità. Gli IdP aziendali hanno aggiunto il supporto FIDO2 in modo diffuso. Microsoft Entra ID supporta passkey vincolati al dispositivo su security key FIDO2 e in Microsoft Authenticator, con supporto ai passkey sincronizzati in anteprima. Okta supporta sia passkey che security key FIDO2 come autenticatori resistenti al phishing, con enforcement dell’attestazione e controlli di policy basati su AAGUID. Anche Cisco Duo, Ping Identity e altri principali IdP supportano la registrazione FIDO2 per entrambi i tipi di credenziali. Questo significa che il tuo IdP difficilmente sarà il blocco.
- Security key hardware funzionano universalmente su piattaforme compatibili FIDO2 tramite USB, NFC o Bluetooth. I principali produttori come Yubico forniscono chiavi multiprotocollo (YubiKey 5 Series) che supportano FIDO2, PIV/Smart Card e OTP, coprendo sia le esigenze di autenticazione moderne che legacy in un unico token.
- Lacune di portabilità multipiattaforma. I passkey sincronizzati incontrano ancora attriti nel passaggio tra ecosistemi. Un passkey creato in Apple Keychain non si sincronizza nativamente con Google Password Manager o un dispositivo Windows. La FIDO Alliance sta affrontando questo aspetto con il Credential Exchange Protocol (CXP), una bozza di specifica sviluppata da Apple, Google, Microsoft, 1Password, Bitwarden e Dashlane per standardizzare il trasferimento sicuro e cifrato dei passkey tra provider. CXP dovrebbe raggiungere una bozza pubblica per la revisione nel 2026. Fino ad allora, gestori di password di terze parti come 1Password e Bitwarden offrono l’esperienza passkey multipiattaforma più coerente.
Per la pianificazione aziendale, il punto chiave è che il supporto della piattaforma non è più una barriera all’adozione. L’attrito residuo riguarda la portabilità tra ecosistemi per i passkey sincronizzati e la preparazione organizzativa su onboarding, recupero e enforcement delle policy. Queste sfide operative meritano un’analisi più approfondita.
Sfide e limitazioni da considerare
Nessun metodo di autenticazione elimina tutti i rischi. Nell’implementare passkey e security key su larga scala, incontrerai un insieme ristretto di sfide ricorrenti:
- I workflow di recupero diventano un controllo di prima linea. Se gli attaccanti possono influenzare il tuo help desk o il processo di reset del provider, possono bypassare anche il flusso di accesso più sicuro.
- La perdita della chiave diventa un problema di disponibilità. Un token perso può bloccare un utente a meno che non siano predisposti backup e workflow amministrativi.
- Le differenze di piattaforma creano attrito. La frammentazione di browser e sistemi operativi può generare UX WebAuthn incoerente e aumentare il carico di supporto.
- Il ciclo di vita comporta overhead reale. Emissione, sostituzione e revoca aggiungono lavoro, soprattutto se si estende la copertura dei token oltre gli utenti privilegiati.
Questi non sono rischi teorici. Nel 2023, MGM Resorts ha reso noto un incidente cyber guidato da social engineering con un impatto negativo stimato di 100 milioni di dollari, secondo un filing MGM. Fattori di accesso forti aiutano, ma è comunque necessario rafforzare le operazioni di identità, inclusi service desk e processi di fallback. La buona notizia è che ciascuno di questi vincoli corrisponde a una pratica di deployment specifica che puoi implementare prima dell’enforcement.
Best practice per il deployment di passkey e security key
Che tu stia implementando passkey, security key o entrambi, queste pratiche aiutano ad allineare il deployment a rischio, usabilità e realtà operativa:
- Segmenta per rischio e livello di garanzia. Assegna una security key hardware ad amministratori privilegiati, dirigenti e ruoli regolamentati dove AAL3 o l’attestazione di alto livello sono rilevanti. Usa passkey sincronizzati per la forza lavoro generale dove AAL2 è sufficiente.
- Rendi routine l’onboarding e i backup. Richiedi la configurazione del passkey durante l’onboarding del dispositivo e registra più autenticatore per utente così da avere un backup che non costringa gli utenti a tornare a fattori facilmente soggetti a phishing.
- Rafforza il recupero account e i fallback. Considera il recupero account come un controllo: rafforza la verifica dell’identità per i reset tramite help desk, limita i metodi di fallback e monitora l’uso anomalo dei fallback.
- Implementa a fasi e monitora in modo continuo. Avvia con i gruppi ad alto rischio, espandi a ondate, poi applica enforcement quando il supporto utenti e i workflow di reset sono solidi. Mantieni visibilità continua su viaggi insoliti, cambi di dispositivo rischiosi e nuove registrazioni sospette.
Seguendo queste quattro pratiche, riduci i blocchi e limiti le opzioni dell’attaccante senza rallentare gli utenti. Da qui, puoi costruire un modello di segmentazione chiaro su quale tipo di credenziale assegnare e dove.
Come scegliere tra passkey e security key
La scelta tra passkey e security key non dovrebbe essere esclusiva. La maggior parte delle aziende adotta un modello ibrido perché popolazioni diverse richiedono livelli di garanzia e percorsi di recupero differenti.
Utilizza questa segmentazione per chiarire la scelta:
- Security key hardware: da usare quando serve AAL3, chiavi non esportabili e forte attestazione del dispositivo per accessi privilegiati.
- Passkey sincronizzato: da usare quando AAL2 è sufficiente e si desidera un minore overhead IT per l’accesso della forza lavoro generale.
- Policy ibrida: usa security key per amministratori e ruoli regolamentati, e passkey sincronizzati per il resto degli utenti.
- Design orientato al recupero: considera i percorsi di reset e fallback come parte del set di controlli, non come un ripensamento, perché possono annullare la MFA resistente al phishing.
Una volta definita la segmentazione, il passo successivo è assicurarsi di poter individuare e bloccare attività guidate dall’identità anche dopo l’accesso.
Singolarità™ Identità
Rilevate e rispondete agli attacchi in tempo reale con soluzioni olistiche per Active Directory ed Entra ID.
Richiedi una demoPunti chiave
Passkey e security key fisiche offrono entrambe autenticazione resistente al phishing tramite crittografia FIDO2, ma rispondono a esigenze aziendali diverse. I passkey sincronizzati privilegiano l’esperienza utente e la scalabilità per la forza lavoro generale a livello AAL2.
Le security key vincolate al dispositivo forniscono credenziali non esportabili, supporto all’attestazione hardware e allineamento AAL3 per utenti privilegiati e ambienti regolamentati. Per la maggior parte delle aziende, verranno implementate entrambe in un modello basato sul rischio, aggiungendo visibilità sulle minacce all’identità per rilevare ciò che i soli controlli di autenticazione non possono bloccare.
Domande frequenti
Una passkey è una credenziale di autenticazione FIDO2 che utilizza la crittografia a chiave pubblica invece di un segreto condiviso come una password. Quando registri una passkey, il tuo dispositivo genera una coppia di chiavi univoca: la chiave privata rimane sul dispositivo (o si sincronizza tramite un provider cloud), mentre il server memorizza solo la chiave pubblica.
L'autenticazione avviene tramite scansione biometrica, PIN o sblocco del dispositivo. Poiché la credenziale è vincolata a un dominio specifico e non viene mai trasmessa, blocca il phishing e il credential stuffing a livello di protocollo.
AAL2 e AAL3 sono livelli di assurance dell'autenticazione definiti dal NIST che stabiliscono quanto si può considerare affidabile un accesso. AAL2 richiede un'autenticazione resistente al phishing, ma può consentire credenziali sincronizzate che si spostano tra dispositivi sotto il controllo di un provider.
AAL3 alza il livello richiedendo una chiave supportata da hardware, non esportabile, e requisiti più rigorosi per il verificatore. In pratica, ciò rende le passkey sincronizzate adatte per AAL2, mentre le security key o altri autenticatori vincolati al dispositivo vengono utilizzati per AAL3.
Gli attacchi di redazione delle passkey prendono di mira il livello dell'interfaccia utente nascondendo o sopprimendo i prompt delle passkey, inducendo gli utenti a utilizzare password, SMS o altri metodi di fallback più deboli. Gli attaccanti possono farlo tramite proxy adversary-in-the-middle, pagine di accesso manipolate o estensioni del browser dannose che alterano ciò che l'utente visualizza.
Per ridurre il rischio, minimizza i fallback, applica regole di accesso condizionale e limita le policy delle estensioni. È inoltre consigliabile generare alert su improvvisi picchi nell'utilizzo dei fallback, che spesso indicano coercizione attiva.
Un'implementazione graduale inizia solitamente con attività fondamentali: confermare il supporto WebAuthn, definire le policy AAL2 rispetto ad AAL3 e creare playbook resilienti per il reset e la ri-registrazione. Distribuire le security key prima ai ruoli privilegiati e ad alto rischio, quindi implementare le passkey sincronizzate a ondate per il resto del personale.
Applica policy solo FIDO una volta che l'adozione e la prontezza del supporto sono stabili. Mantieni i fattori legacy solo il tempo necessario per evitare blocchi durante la transizione, poi dismettili.
Sì, ma sono necessarie delle misure di controllo. Conserva le passkey aziendali all'interno di container gestiti o profili di lavoro affinché le chiavi rimangano nel contesto gestito e non in un cloud personale. Limita la creazione di passkey a browser e app gestiti dove possibile e verifica la presenza di credenziali aziendali registrate su account personali.
Anche il modello di recupero dell'account è importante: se i reset ricadono su passaggi facilmente soggetti a ingegneria sociale, le passkey sincronizzate perdono gran parte della loro assurance.
Si utilizzano entrambi perché nessun singolo autenticatore bilancia garanzia, usabilità e operatività per ogni ruolo. Fornire chiavi di sicurezza agli utenti privilegiati, agli amministratori e ai ruoli regolamentati che richiedono chiavi non esportabili e una forte prova della provenienza dell'autenticatore.
Utilizzare passkey sincronizzate per la forza lavoro generale dove AAL2 è sufficiente e la facilità d'uso favorisce l'adozione. Quindi applicare politiche coerenti di fallback e di nuova registrazione su entrambi i gruppi affinché gli attaccanti non possano degradare gli utenti verso fattori più deboli.


