Passkeys in azienda: guida tecnica alla migrazione FIDO2 per il CISO italiano
Nel febbraio 2026, Microsoft ha registrato oltre 600 milioni di attacchi alle identità al giorno secondo il Microsoft Digital Defense Report 2025. La maggior parte sfrutta una sola debolezza strutturale: le password. Le passkeys non sono l’ennesimo upgrade alla MFA, sono la sua sostituzione.
Il problema che le passkeys risolvono davvero
La MFA basata su TOTP (Google Authenticator, Microsoft Authenticator) e su SMS OTP ha rappresentato per anni lo standard de facto per la protezione degli account aziendali. Come già analizzato su ICT Security Magazine nell’approfondimento sull’autenticazione multifattoriale nell’era della cyber-vulnerabilità, il paradigma passwordless rappresenta l’evoluzione naturale dell’MFA. Nel 2026, tuttavia, quella stessa MFA è diventata un bersaglio primario degli attaccanti.
Gli attacchi Adversary-in-the-Middle (AiTM) – implementati attraverso piattaforme Phishing-as-a-Service come EvilProxy e Tycoon 2FA – intercettano i token TOTP in tempo reale, trasmettendoli al servizio legittimo prima della scadenza. Il Microsoft Digital Defense Report 2025 documenta una crescita rapida di queste tecniche, che rendono la MFA tradizionale inefficace contro attaccanti motivati.
Le passkeys eliminano il problema alla radice. Il meccanismo si basa su crittografia asimmetrica: il dispositivo dell’utente genera una coppia di chiavi, conserva la chiave privata in un enclave sicuro (TPM su Windows, Secure Enclave su iOS/macOS, TEE su Android) e invia al servizio solo la chiave pubblica. Al momento dell’autenticazione, il server invia una challenge; il dispositivo la firma con la chiave privata dopo che l’utente si è verificato tramite biometrica o PIN locale. Nessuna password, nessun codice OTP, nessun segreto condiviso trasmesso in rete. Senza un segreto da intercettare, l’attacco AiTM non ha superficie su cui agire.
Come funziona tecnicamente una passkey
- Registrazione: il dispositivo genera una coppia RSA/EC (chiave pubblica e privata). La pubblica viene inviata al server (Relying Party). La privata non lascia mai il dispositivo.
- Autenticazione: il server invia una challenge casuale. Il dispositivo sblocca la chiave privata tramite biometrica o PIN, firma la challenge e invia la firma.
- Verifica: il server verifica la firma con la chiave pubblica in suo possesso. Nessuna password, nessun OTP, nessun segreto condiviso.
Standard di riferimento: WebAuthn (W3C) + CTAP2 (FIDO Alliance) = FIDO2
Dove siamo: lo stato del mercato nel 2026
I numeri certificano che la transizione è in corso, non solo annunciata. Secondo la ricerca FIDO Alliance e HID condotta su 400 executive in aziende con oltre 500 dipendenti, l’87% delle organizzazioni ha già effettuato il deployment delle passkeys enterprise o è in fase di rollout attivo, una crescita di 14 punti percentuali rispetto all’anno precedente. Due terzi dichiarano che il deployment è una priorità alta o critica.
Sul fronte consumer, il 75% degli utenti globali è oggi consapevole delle passkeys (FIDO Alliance, 2025), e quasi la metà dei 100 siti web più visitati al mondo le supporta già come metodo di accesso, più del doppio rispetto al 2022. Bitwarden ha registrato un incremento del 550% nelle creazioni giornaliere di passkeys nel 2025, segnale che l’adozione cross-provider è diventata mainstream.
Passkeys sincronizzate vs. device-bound: la scelta che determina il livello di sicurezza
Prima di avviare qualsiasi progetto di migrazione, il CISO deve comprendere una distinzione fondamentale che determina il livello di assurance raggiungibile.
Passkeys sincronizzate (synced passkeys)
Vengono conservate nel cloud keychain del produttore del sistema operativo (iCloud Keychain su Apple, Google Password Manager, Windows/Microsoft) e sincronizzate tra tutti i dispositivi associati allo stesso account. Sono comode per gli utenti – cambio dispositivo senza procedure di re-enrollment – e soddisfano il livello AAL2 secondo il NIST SP 800-63-4 nella versione finale del luglio 2025. Sono adatte per applicazioni SaaS, portali self-service e accessi a sistemi non critici.
Passkeys device-bound (hardware-bound)
La chiave privata è legata a un singolo dispositivo e non può essere esportata. Su Windows, il TPM (Trusted Platform Module) garantisce questo binding; su iOS/macOS è il Secure Enclave. I token hardware FIDO2 (YubiKey, Titan Key) offrono la soluzione più robusta: soddisfano l’AAL3 e sono la scelta appropriata per amministratori di sistema, accesso a infrastrutture critiche, ambienti DORA e NIS2 ad alta rilevanza.
Quasi la metà delle organizzazioni (47%) adotta un approccio ibrido: passkeys sincronizzate per il workforce standard, device-bound per i ruoli privilegiati. È la strategia raccomandata in contesti enterprise italiani, in particolare per soggetti NIS2 e operatori DORA. Questo si integra naturalmente con i principi di Zero Trust e gestione delle identità nell’architettura moderna già discussi su ICT Security Magazine.
Integrazione con gli IdP usati in Italia: Microsoft Entra ID, Okta, Active Directory
La domanda più frequente che i team IT italiani si pongono è concreta: come si integra tutto questo con l’infrastruttura esistente?
Microsoft Entra ID (Azure AD)
È il percorso più lineare per le organizzazioni Microsoft-centric. L’implementazione si articola su tre step: abilitare Windows Hello for Business tramite policy Intune o Group Policy; configurare i metodi di autenticazione FIDO2 nel portale Entra ID; impostare in Conditional Access la policy di “phishing-resistant authentication strength”, che accetta solo platform passkeys o chiavi FIDO2 hardware, escludendo TOTP e SMS. Il risultato è un’organizzazione in cui solo dispositivi conformi con passkey registrate possono accedere alle risorse aziendali.
Come confermato da Security Boulevard nel deployment playbook 2026, per le organizzazioni con Microsoft Entra ID è sufficiente impostare la Conditional Access per richiedere “phishing-resistant authentication strength”: questo esclude automaticamente OTP e SMS, accettando solo platform passkeys o chiavi FIDO2 esterne.
Okta Workforce Identity
Okta supporta passkeys FIDO2 nativamente dal 2024 con Okta FastPass, che permette autenticazione passwordless basata su certificato device con biometrica. Per le organizzazioni con Okta, la migrazione è guidata dall’Okta Authenticator Enrollment Policy: si definisce un gruppo pilota, si abilita FastPass come metodo preferito, si monitorano i drop-off tramite le dashboard e si estende progressivamente. L’integrazione con MDM (Jamf, Intune) automatizza il provisioning sui dispositivi gestiti.
Active Directory on-premise con federazione
Lo scenario più complesso, comune nelle PMI e nella PA italiana che mantengono AD on-premise. La soluzione è la federazione con un IdP cloud (Entra ID in modalità ibrida, o Okta con AD Agent) che agisce da Relying Party FIDO2 verso l’esterno mentre continua a sincronizzare le identità con l’AD locale. Le passkeys vengono gestite dall’IdP cloud; AD rimane la fonte di verità per le identità. Non è il percorso più semplice, ma è percorribile con pianificazione adeguata.
Attenzione: il recovery è il punto debole più sottovalutato
La migrazione passkeys fallisce principalmente per un motivo: non è stato progettato un processo di recovery robusto. Se un utente perde il dispositivo o viene bloccato fuori dall’account cloud, il canale di recupero di fallback (spesso email o SMS) diventa immediatamente il punto più debole dell’intera architettura. Prima di avviare il rollout, definire: (1) Temporary Access Pass per bootstrap su nuovo dispositivo; (2) verifica identità in-person o ad alta assurance per AAL3; (3) escrow delle chiavi recovery su sistema separato per device-bound.
Roadmap di migrazione: i sei passi operativi
Una migrazione passkeys di successo non si pianifica come un progetto IT, ma come un programma di change management con componenti tecniche. I dati di eBay (2025), citati nel deployment playbook di Security Boulevard, mostrano che il 75% degli enrollment avviene tramite prompt automatico contestuale, chi non costruisce quel momento di onboarding lascia il 75% dell’adozione sul tavolo.
Passo 1: Assessment e inventario IdP
Mappare tutti i sistemi di autenticazione in uso: IdP primario, MFA secondario, sistemi legacy non federati, VPN, PAM. Identificare i sistemi che non supportano FIDO2 natively e che richiederanno un percorso alternativo o bridge.
Passo 2: Definire i livelli di assurance per ruolo
Classificare gli utenti per profilo di rischio: workforce standard (AAL2 con synced passkeys), utenti con accesso a dati sensibili (AAL2 device-bound), amministratori e ruoli privilegiati (AAL3 con hardware key). Questa mappa guida le Conditional Access policy e le decisioni di procurement.
Passo 3: Pilota su gruppo ad alto impatto
Iniziare con 50/200 utenti del team IT o security: utenti tecnici che tollerano le inevitabili frizioni iniziali e forniscono feedback qualificato. Misurare: tempo medio di enrollment, tasso di adoption spontanea, numero di ticket help desk, tasso di successo all’autenticazione nelle prime 30 sessioni.
Passo 4: Costruire l’enrollment flow contestuale
Il momento del prompt è cruciale. Configurare il sistema IdP per presentare l’invito all’enrollment di passkey subito dopo un login tradizionale riuscito, con un messaggio che spiega il beneficio in una riga. Non nascondere l’opzione nelle impostazioni dell’account: i dati mostrano che l’enrollment proattivo vale tre volte quello organico.
Passo 5: Rollout progressivo e disabilitazione delle password
Estendere per coorti (reparto finance, poi operations, poi marketing). Per ogni coorte: abilitare le passkeys, attendere 4/6 settimane di adozione organica, poi disabilitare il login con password per gli utenti che hanno già una passkey registrata. Non disabilitare mai in modo massiccio.
Passo 6: Monitoraggio e metriche di maturità
KPI principali: percentuale utenti con almeno una passkey attiva; percentuale accessi mensili completati con passkey vs. password; numero di reset password mensili (deve scendere); tempo medio alla prima autenticazione (deve scendere). Il calo delle richieste di reset password è il segnale più immediato del ROI.
Implicazioni normative: NIS2, DORA e l’EU Digital Identity Wallet
La migrazione verso le passkeys non è solo una scelta di sicurezza: nel contesto normativo italiano ed europeo del 2026, è sempre più una risposta a obblighi espliciti o impliciti.
Il D.Lgs. 138/2024, che recepisce la direttiva NIS2, richiede alle organizzazioni in scope di adottare misure tecniche proporzionate al rischio, tra cui l’autenticazione a più fattori o forme di autenticazione continua. Le passkeys soddisfano questi requisiti combinando possesso (dispositivo) e inerenza (biometrica), superando strutturalmente l’autenticazione basata su password e OTP che rimane vulnerabile agli attacchi AiTM.
Il Regolamento DORA (in vigore dal 17 gennaio 2025) impone alle entità finanziarie standard più stringenti di gestione del rischio ICT, incluso il controllo degli accessi ai sistemi critici. I Threat-Led Penetration Test (TLPT) richiesti da DORA testeranno la resistenza dell’autenticazione agli attacchi simulati: le passkeys device-bound sono l’unica soluzione che supera strutturalmente i test AiTM.
L’EU Digital Identity Wallet, il cui deployment è previsto entro fine 2026 secondo la roadmap eIDAS 2.0, si basa su standard FIDO2/WebAuthn per l’autenticazione. Le organizzazioni che avranno completato la migrazione a passkeys enterprise saranno quelle meglio posizionate per integrare il wallet come metodo di verifica dell’identità forte.
Il momento è adesso, non tra sei mesi
Il 2026 è l’anno in cui la migrazione passkeys smette di essere una best practice e diventa una necessità operativa. Gli attacchi AiTM hanno reso la MFA tradizionale una difesa insufficiente contro avversari motivati. Le normative europee richiedono autenticazione forte. L’ecosistema tecnologico – IdP, browser, sistemi operativi, dispositivi mobili – è finalmente allineato su standard comuni.
Per il CISO italiano, il percorso più pragmatico è: partire dall’IdP principale già presente in azienda (quasi certamente Entra ID o Okta), avviare un pilota sul team IT entro 30 giorni, misurare scrupolosamente, poi estendere. Non serve un progetto pluriennale: le piattaforme IAM moderne rendono il deployment un progetto da 2/3 sprint.
La domanda non è più “se” passare alle passkeys. È “come farlo senza interrompere la produttività e con un piano di recovery solido”. Chi inizia oggi ha un vantaggio significativo rispetto a chi aspetterà la prossima notifica ACN.
