Problemi del Day 2 delle passkey: 5 rischi dopo il lancio

1. Introduzione: Rischi delle passkey dopo il lancio#

Non implementare le passkey.

Almeno non a tutti i costi e non se non si dispone delle risorse per farlo correttamente.

Sì, le passkey sono la cosa migliore successa all'autenticazione dei consumatori in un decennio. Sì, eliminano il phishing. Sì, possono migliorare massicciamente l'UX. Ma le passkey implementate male possono anche causare molti danni.

L'implementazione di un server WebAuthn non è troppo complessa. La vera sfida è tutto ciò che ci gira intorno. Gestire le passkey in modo efficiente su larga scala richiede una pianificazione anticipata. È necessario pensare a tutti i problemi del "Day 2", le realtà operative che emergono solo dopo aver iniziato il lancio delle passkey.

Questo articolo copre cinque problemi del Day 2 che costantemente fanno fallire i progetti sulle passkey. Se non riesci a risolverli tutti, non sei pronto per rilasciare le passkey. Se ci riesci, costruirai un'autenticazione che è sia più sicura che più utilizzabile di qualsiasi cosa le password potrebbero mai offrire.

2. Quali sono i problemi del Day 2 delle passkey?#

Nell'ingegneria, il "Day 1" è quando costruisci e rilasci. Il "Day 2" è quando operi, mantieni e scali ciò che hai rilasciato. Per le passkey, il Day 1 può essere semplice:

• integrare un server WebAuthn nel tuo stack aziendale
• aggiungere i flussi frontend e lanciare.

La maggior parte dei team può far funzionare un'implementazione di base delle passkey in pochi giorni o settimane.

Il Day 2 è dove i progetti falliscono. È il momento in cui utenti reali su dispositivi reali con casi limite reali interagiscono con il tuo sistema di passkey. È quando scopri che la brillante demo che funzionava perfettamente sul tuo MacBook si rompe su un laptop Windows che esegue Chrome dietro un proxy aziendale. È quando il tuo team di supporto viene inondato di ticket "Non riesco più ad accedere".

Il divario tra una demo funzionante delle passkey e un'implementazione di livello produttivo delle passkey è enorme. Abbiamo già trattato le insidie dell'implementazione tecnica e i motivi strategici per cui i progetti sulle passkey falliscono. Questo articolo si concentra specificamente su ciò che accade dopo la messa in produzione da una prospettiva operativa.

3. Problema 1: Recupero e fallback sono difficili da proteggere#

Se non si progettano correttamente il recupero e il fallback, o si bloccano gli utenti su larga scala o si reintroducono silenziosamente gli stessi flussi soggetti a phishing che si volevano eliminare.

3.1 Rischio di blocco dell'account su larga scala#

Considera un utente che registra una passkey sul proprio iPhone, poi perde quell'iPhone. Di solito, gran parte di questi casi di recupero viene ora gestita dal gestore delle credenziali (molto probabilmente iCloud Keychain sugli iPhone). Finché l'utente ha accesso al proprio account Apple, ha a disposizione passkey sincronizzate per accedere su un nuovo dispositivo. Ma cosa succede se non ha più accesso a quell'account cloud? È qui che entra in gioco il percorso di recupero regolare.

Supponiamo che si assuma che la chiave privata sia ancora disponibile sul dispositivo da cui l'utente cerca di accedere, quindi si avvia la cerimonia di accesso WebAuthn. Questo comporterà un modal del sistema operativo / browser che chiede all'utente di "accedere con la tua passkey su un altro dispositivo". Fondamentalmente, l'utente è ora bloccato fuori dal proprio account. Non c'è nessun altro dispositivo in cui è archiviata la passkey. L'utente è enormemente confuso. Moltiplica questo per migliaia di utenti e hai una crisi di supporto.

La reazione comune è aggiungere i ripristini dell'account basati su e-mail come fallback. Ma questo vanifica lo scopo delle passkey: hai appena reintrodotto un canale di recupero soggetto a phishing. Un aggressore che può compromettere l'e-mail di un utente può ora aggirare completamente la tua implementazione di passkey resistente al phishing.

3.2 Progettare il fallback senza reintrodurre il phishing#

Secondo noi, l'approccio giusto è un recupero stratificato:

1. Passkey sincronizzate come strategia principale: assicurarsi che gli utenti creino passkey sincronizzate (tramite iCloud Keychain, Google Password Manager o un provider di passkey di terze parti) in modo che la perdita del dispositivo non significhi perdita di credenziali
2. Autenticazione cross-device come secondo livello: consentire agli utenti di autenticarsi da un altro dispositivo in cui è disponibile un'altra passkey scansionando un codice QR
3. Verifica dell'identità (IDV) come terzo livello: offrire un'IDV automatizzata con controlli di vitalità invece di ripiegare su password/OTP.
4. Credenziali verificabili digitali come quarto livello: è la versione più sicura, rispettosa della privacy e user-friendly del recupero dell'account. Ciò consente all'utente di utilizzare le proprie credenziali verificabili digitali (ad es. ID nazionale digitale o mDL) per verificare la propria identità utilizzando API standard (ad es. API per credenziali digitali). Questa tecnologia è abbastanza nuova e l'adozione non è elevata, ma giocherà un ruolo importante nei prossimi mesi e anni.

In generale, è necessario decidere quali livelli di recupero dell'account possono essere giustificati da una prospettiva di costi / attrito. Ad esempio, nel settore del retail / e-commerce, potresti semplicemente offrire i primi due livelli e accettare il rischio di phishing per motivi finanziari. In altri settori, in cui la sicurezza è più importante, si passa al livello 3 e 4.

Ogni livello aggiunge complessità. È necessario decidere quali livelli richiede il proprio caso d'uso, costruirli, testarli su tutte le combinazioni di dispositivi e monitorarne l'utilizzo. Questo è un lavoro significativamente maggiore rispetto all'integrazione iniziale di WebAuthn.

3.3 Cosa sbaglia la maggior parte dei team#

La maggior parte dei team semplifica eccessivamente il recupero (ripiegando su password o SMS OTP) o lo complica eccessivamente (ad es. richiedendo chiavi di sicurezza hardware per ogni recupero). Il giusto equilibrio dipende dal modello di minaccia, dalla base di utenti e dai requisiti normativi. Sbagliare significa compromettere la propria posizione di sicurezza o creare così tanto attrito che gli utenti abbandonano il flusso.

4. Problema 2: Casi limite cross-device e cross-ecosistema interrompono i flussi delle passkey#

I tuoi utenti non vivono in un mondo pulito solo Apple. Cambiano dispositivi, mescolano Windows con iOS, usano browser diversi e lavorano su configurazioni gestite dall'azienda. È qui che i flussi delle passkey si interrompono se non l'hai previsto.

4.1 La frammentazione dell'ecosistema è reale#

L'ecosistema delle passkey si estende su tre piattaforme principali (Apple, Google e Microsoft), più browser (Chrome, Safari, Firefox ed Edge), dozzine di provider di passkey / gestori di credenziali (ad es. 1Password, Bitwarden, Dashlane e altri) e innumerevoli combinazioni di sistema operativo/browser/dispositivo. Ogni combinazione può comportarsi in modo leggermente diverso, ad es.:

• Apple sincronizza le passkey per impostazione predefinita tramite iCloud Keychain su iOS, iPadOS e macOS ma non su Windows o Android
• Google sincronizza tramite Google Password Manager su Android e Chrome, ma l'esperienza su iOS è diversa (è necessario configurarla manualmente)
• Windows ha il proprio comportamento per le passkey che differisce significativamente dalle altre piattaforme
• I gestori di password gestiscono ciascuno la creazione e la selezione delle passkey in modo diverso, a volte entrando in conflitto con i prompt nativi della piattaforma

4.2 Flussi di autenticazione cross-device#

Quando un utente crea una passkey sul proprio iPhone ma vuole accedere su un laptop Windows, può utilizzare l'autenticazione cross-device (tipicamente tramite codice QR e Bluetooth). Questo flusso funziona ma è fragile:

• Richiede che il Bluetooth sia abilitato su entrambi i dispositivi
• I firewall aziendali e i criteri MDM possono interferire poiché in background viene configurato un tunnel
• L'UX varia drasticamente tra i browser
• Gli utenti spesso non capiscono cosa sta succedendo o perché stanno scansionando un codice QR

Abbiamo visto questi casi limite in prima persona su migliaia di combinazioni di dispositivi. Se stai costruendo le passkey internamente, devi testarle e gestirle tutte. Se non ci riesci, i tuoi utenti riscontreranno errori che il tuo team di supporto non saprà spiegare.

4.3 Incoerenze di browser e sistema operativo#

Anche sullo stesso dispositivo, browser diversi si comportano in modo diverso. Chrome su macOS mostra modal delle passkey diversi rispetto a Safari su macOS. Firefox ha un suo comportamento. I client hints e il rilevamento dello user agent diventano fondamentali per fornire i flussi giusti all'utente giusto, ma analizzarli correttamente in tutte le combinazioni è un onere di manutenzione che non finisce mai.

5. Problema 3: Le app native moltiplicano la complessità delle passkey#

Il test e il QA delle passkey sono già una sfida per le app web (lo trattiamo in dettaglio nel Problema 5: Le modifiche alla piattaforma interrompono le passkey silenziosamente). Ma se il tuo prodotto ha anche app iOS e Android native, la complessità si moltiplica a causa delle decisioni architetturali e del comportamento specifico della piattaforma che i team solo web non affrontano mai.

5.1 Decisioni tra nativo e WebView#

La prima decisione è se implementare le passkey in modo nativo o tramite una WebView. Ogni approccio ha dei compromessi:

Solo su iOS, puoi scegliere tra WKWebView, SFSafariViewController, SFAuthenticationSession e ASWebAuthenticationSession, ognuna con caratteristiche di supporto delle passkey diverse. Su Android, i Chrome Custom Tabs si comportano in modo diverso dalle WebView standard. Queste sono decisioni che i team solo web non devono mai prendere e ogni scelta crea una propria superficie di manutenzione.

5.2 Comportamento specifico della piattaforma nelle app native#

Oltre alla decisione architetturale, iOS e Android gestiscono le passkey in modo diverso a livello di sistema operativo:

• iOS integra profondamente le passkey nel gestore delle credenziali di sistema, con comportamenti di compilazione automatica specifici che possono cambiare a ogni versione di iOS
• Android instrada le richieste di passkey tramite l'API Credential Manager, che interagisce con più provider di passkey contemporaneamente
• Gli stati di errore, i comportamenti di timeout e i prompt utente differiscono tra le piattaforme. L'annullamento dello stesso utente emerge come NotAllowedError sul web, ma come SimpleAuthenticationServices.AuthorizationError su iOS e User cancelled the operation sul Credential Manager di Android.
• I cicli di revisione degli app store aggiungono ritardi quando è necessario rilasciare correzioni urgenti per le regressioni delle passkey

5.3 Superficie di QA triplicata#

Se gestisci sia un'app web che app native, non stai solo raddoppiando lo sforzo di QA, ma lo stai triplicando. Web, iOS e Android si comportano ciascuno come ambienti di passkey separati che richiedono test e monitoraggio end-to-end indipendenti. E a differenza del web, dove puoi implementare una correzione all'istante, le correzioni per le app native sono bloccate dai cicli di revisione degli app store.

6. Problema 4: L'adozione è un problema di prodotto, non un problema tecnico#

"Passkey supportate" non significa "passkey utilizzate". Se non hai una strategia di lancio e di misurazione, la tua adozione deluderà e il progetto sarà etichettato internamente come un fallimento.

6.1 Perché la bassa adozione uccide il tuo progetto#

Se gli utenti non passano alle passkey, il progetto è già fallito. Le password rimangono dominanti, i costi degli SMS OTP restano alti, i rischi di phishing persistono e la tua organizzazione non vede alcun ritorno su un investimento ingegneristico significativo.

Il business case per l'adozione delle passkey è forte, ma solo se l'adozione avviene effettivamente. Abbiamo visto aziende lanciare passkey con ottime implementazioni tecniche che hanno ottenuto un'adozione inferiore al 5% perché nessuno ha pensato al lancio e alla strategia di adozione.

6.2 L'adozione richiede un lavoro di prodotto deliberato#

Guidare l'adozione delle passkey è una sfida di prodotto che richiede:

• Registrazione progressiva: spingere gli utenti a creare passkey nei momenti giusti (ad es. dopo un accesso riuscito, durante le revisioni della sicurezza dell'account)
• Comunicazione chiara con gli utenti: spiegare cosa sono le passkey e perché sono migliori, in un linguaggio comprensibile agli utenti non tecnici
• Prompt consapevole del dispositivo: offrire la creazione della passkey solo quando il dispositivo dell'utente lo supporta effettivamente in modo ottimale, evitando esperienze frustranti su configurazioni non supportate
• Infrastruttura di misurazione: monitorare i tassi di creazione delle passkey, i tassi di successo dell'accesso, i tassi di fallback e i tassi di abbandono per identificare e risolvere i colli di bottiglia

6.3 Come si presenta una "buona" adozione#

In base alla nostra esperienza con implementazioni di passkey su larga scala, ecco a cosa dovrebbero puntare le aziende:

Se i tuoi numeri di adozione sembrano quelli della colonna "debole" dopo tre mesi, il progetto è nei guai. Senza analisi per misurare questo aspetto, non lo saprai nemmeno.

7. Problema 5: Le modifiche alla piattaforma interrompono le passkey silenziosamente#

Gli aggiornamenti del sistema operativo e del browser modificano i prompt, il comportamento di compilazione automatica e i flussi di fallback. Se non disponi di un monitoraggio continuo, otterrai regressioni e ticket di supporto senza preavviso.

7.1 Perché le passkey sono unicamente colpite dalle modifiche alla piattaforma#

A differenza delle password (che sono solo stringhe convalidate dal tuo server), le passkey dipendono da una profonda integrazione con il sistema operativo, il browser e il gestore delle credenziali. Quando Apple rilascia una nuova versione di iOS, i prompt di creazione delle passkey potrebbero avere un aspetto diverso. Quando Chrome aggiorna la sua logica di compilazione automatica, il tuo flusso di accesso potrebbe interrompersi. Quando un gestore di password rilascia una nuova versione, potrebbe iniziare a intercettare le richieste di passkey in modi imprevisti.

Un esempio recente è il bug di iOS 26.2 in cui isUserVerifyingPlatformAuthenticatorAvailable() restituisce false su tutti i browser non Safari (Chrome, Edge, Firefox), richiedendo una logica di rilevamento consapevole della piattaforma che utilizzi getClientCapabilities() come soluzione alternativa.

7.2 Il monitoraggio non è facoltativo#

Per assicurarti di essere a conoscenza di tutti i potenziali bug e monitorare l'adozione, devi configurare il tuo stack di osservabilità dell'autenticazione. Ti consigliamo di disporre almeno di quanto segue:

• Analisi dell'autenticazione in tempo reale: monitorare i tassi di successo e fallimento per combinazione di sistema operativo, browser e provider di passkey
• Monitoraggio consapevole della versione: rilevare quando una nuova versione del sistema operativo o del browser causa un picco di errori o fallback. Distinguere tra errori previsti (le interruzioni dell'utente che emergono come NotAllowedError) ed errori imprevisti (picchi di AbortError dovuti a bug di concorrenza o nuovi errori delle passkey del Credential Manager dopo un aggiornamento Android)
• Avvisi: essere avvisati prima che gli utenti inizino a inviare ticket di supporto
• Capacità di risposta rapida: la possibilità di inviare correzioni o disabilitare rapidamente le passkey per le combinazioni di dispositivi interessate

Questa è l'infrastruttura di analisi dell'autenticazione che la maggior parte dei team non costruisce finché non ha già avuto un incidente. A quel punto, il danno alla fiducia degli utenti e alla credibilità interna del progetto è già fatto.

7.3 Costo di manutenzione continuo#

Il vero costo dell'implementazione delle passkey non è la build iniziale. È la manutenzione continua:

• Monitoraggio delle modifiche alla piattaforma su iOS, Android, Windows, macOS e su tutti i principali browser
• Test di ogni aggiornamento per individuare eventuali regressioni
• Aggiornamento dell'SDK frontend in caso di modifiche alle API del browser
• Mantenimento della compatibilità con un ecosistema in crescita di provider di passkey
• Documentazione e comunicazione delle modifiche al team di supporto

8. Quando (non) dovresti rilasciare le passkey#

Alla luce di questi problemi del Day 2, ecco una valutazione onesta di quando dovresti e non dovresti rilasciare le passkey.

8.1 Non rilasciare le passkey se#

• Non hai una chiara strategia di fallback e recupero
• Non hai effettuato test sulle combinazioni di dispositivi effettivamente utilizzate dai tuoi utenti
• Hai app native ma nessun piano per un QA continuo specifico della piattaforma
• Non hai un'infrastruttura di analisi per misurare l'adozione
• Non puoi impegnare risorse ingegneristiche per la manutenzione continua
• Stai implementando le passkey esclusivamente per spuntare una casella di conformità senza un'adeguata pianificazione

Andare all-in per motivi normativi senza un'adeguata pianificazione può far lievitare significativamente i costi. Un sistema di passkey mal implementato è peggio di nessun sistema di passkey: erode la fiducia degli utenti, genera un sovraccarico di supporto e fornisce agli stakeholder interni un motivo per chiudere il progetto.

8.2 Rilascia le passkey se#

• Hai pianificato tutti e cinque i problemi del Day 2 sopra descritti
• Hai le capacità di prodotto, ingegneristiche, di sicurezza e di analisi per supportare un lancio continuo
• Hai preventivato il budget per la manutenzione continua, non solo per la build iniziale
• Hai una strategia di lancio graduale con chiari obiettivi di adozione
• Stai collaborando con un partner come Corbado che gestisce la complessità operativa per te

8.3 Decisione tra Build vs. Buy#

I problemi del Day 2 descritti in questo articolo sono esattamente il motivo per cui molte aziende scelgono di acquistare piuttosto che costruire la propria infrastruttura per le passkey. Costruire un server WebAuthn è la parte facile. Gestire un sistema di passkey di livello produttivo su migliaia di combinazioni di dispositivi, con recupero, monitoraggio e analisi di adozione adeguati, è ciò che separa una demo da un'implementazione reale.

9. Come Corbado risolve i problemi del Day 2 delle passkey#

Corbado esiste specificamente perché i problemi del Day 2 sono difficili. La nostra piattaforma gestisce la complessità operativa in modo da non doverla costruire e mantenere da soli.

9.1 Recupero e fallback#

Corbado fornisce flussi di recupero pronti all'uso con livelli di sicurezza adattivi. Dalle strategie di passkey sincronizzate all'autenticazione cross-device alla verifica dell'identità automatizzata. La logica di recupero è integrata e continuamente aggiornata.

9.2 Compatibilità cross-device#

I nostri SDK frontend sono pre-testati su migliaia di combinazioni di sistema operativo, browser e provider di passkey. Il rilevamento dei dispositivi, la gestione della Conditional UI e il routing di fallback avvengono automaticamente. Quando una nuova versione del browser interrompe qualcosa, lo correggiamo nel nostro SDK prima che i tuoi utenti se ne accorgano.

9.3 Supporto per app native#

Corbado supporta implementazioni di passkey sia native che WebView con SDK che astraggono le differenze della piattaforma. Tu ti concentri sull'UX della tua app mentre noi gestiamo l'infrastruttura delle passkey su iOS e Android.

9.4 Analisi dell'adozione#

La nostra dashboard di analisi traccia ogni metrica importante: tassi di creazione delle passkey, tassi di successo degli accessi, tassi di fallback e ripartizioni a livello di dispositivo. Ottieni informazioni fruibili per guidare l'adozione, non solo dati grezzi.

9.5 Monitoraggio delle modifiche alla piattaforma#

Corbado monitora continuamente le modifiche del sistema operativo e del browser che interessano le passkey. I nostri SDK vengono aggiornati in modo proattivo. La tua implementazione di passkey rimane stabile anche quando il panorama della piattaforma cambia.

10. Conclusione#

Le passkey sono il gold standard dell'autenticazione. Questo non è in discussione. Ma il percorso da "passkey supportate" a "passkey che funzionano in modo affidabile su larga scala" è lastricato di problemi del Day 2 che la maggior parte dei team sottovaluta.

I cinque problemi che abbiamo trattato (recupero, casi limite cross-device, complessità delle app native, adozione e modifiche alla piattaforma) non sono rari. Sono le sfide operative fondamentali di qualsiasi implementazione di passkey in produzione. Ignorarli non li farà sparire. Significa solo che i tuoi utenti li scopriranno per primi.

La mia raccomandazione onesta: se non hai il know-how e le risorse per gestire le passkey correttamente, non rilasciarle. O investi nelle capacità (prodotto, ingegneria, sicurezza e analisi) o collabori con un partner che ha già risolto questi problemi. Il risultato peggiore è un'implementazione di passkey a metà che viene annullata perché nessuno ha pianificato il Day 2.

Chi siamo

Corbado è la Passkey Intelligence Platform per i team CIAM che gestiscono l'autenticazione consumer su larga scala. Ti aiutiamo a vedere ciò che i log IDP e gli strumenti di analytics generici non mostrano: quali dispositivi, versioni di OS, browser e gestori di credenziali supportano i passkey, perché gli enrollment non si trasformano in login, dove il flusso WebAuthn fallisce e quando un aggiornamento di OS o browser interrompe silenziosamente il login — tutto senza sostituire Okta, Auth0, Ping, Cognito o il tuo IDP interno. Due prodotti: Corbado Observe aggiunge osservabilità per i passkey e qualsiasi altro metodo di login. Corbado Connect introduce passkey gestiti con analytics integrato (insieme al tuo IDP). VicRoads gestisce i passkey per oltre 5M di utenti con Corbado (+80 % di attivazione passkey). Parla con un esperto di Passkey →

Domande frequenti#

Quali sono i 5 problemi del Day 2 che causano il fallimento dei progetti sulle passkey dopo il lancio?#

I cinque problemi operativi sono flussi di recupero e fallback insicuri, casi limite nell'ecosistema cross-device, complessità delle app native, bassa adozione da parte degli utenti e regressioni silenziose causate dagli aggiornamenti del sistema operativo e del browser. La maggior parte dei team si concentra sull'integrazione iniziale di WebAuthn e sottovaluta queste sfide post-lancio, motivo per cui molti progetti di passkey vengono ritirati o abbandonati silenziosamente all'interno.

Come gestisco l'autenticazione cross-device con passkey per gli utenti aziendali su Windows che si sono registrati su iPhone?#

Gli utenti possono autenticarsi tramite un flusso cross-device con codice QR e Bluetooth, ma questo richiede che il Bluetooth sia abilitato su entrambi i dispositivi e può essere bloccato dai criteri MDM e dai firewall aziendali. L'UX varia significativamente tra i browser e spesso gli utenti non capiscono perché stanno scansionando un codice QR, rendendo il routing del fallback consapevole del dispositivo e una comunicazione chiara fondamentali per le implementazioni aziendali.

Quali metriche di adozione delle passkey dovrei puntare a monitorare dopo il lancio?#

Una forte adozione significa un tasso di creazione delle passkey superiore al 60% degli utenti idonei e un tasso di accesso con passkey superiore al 40% di tutti gli accessi. Tassi inferiori al 10% di creazione e al 5% di accesso dopo tre mesi indicano un lancio fallimentare. Misurare questo aspetto richiede un'infrastruttura dedicata che tenga traccia dei tassi di creazione, dei tassi di successo degli accessi, dei tassi di fallback e degli abbandoni suddivisi per combinazione di dispositivo e sistema operativo.

Dovrei costruire le passkey nativamente nella mia app mobile o usare una WebView?#

L'implementazione nativa offre un'UX di prim'ordine ma richiede codebase iOS e Android separati con gestione delle API specifiche della piattaforma e pipeline di QA indipendenti. Gli approcci WebView condividono la logica web ma introducono incoerenze nel supporto delle passkey a seconda del tipo di WebView. Solo su iOS, la scelta tra WKWebView, SFSafariViewController e ASWebAuthenticationSession comporta caratteristiche di supporto delle passkey diverse che devono essere valutate prima di impegnarsi in un'architettura.

Perché il recupero dell'account con passkey è più difficile di quanto sembri e qual è l'approccio giusto?#

Un recupero semplificato come i ripristini basati su e-mail reintroduce i canali soggetti a phishing, mentre un recupero eccessivamente rigido come le chiavi di sicurezza hardware obbligatorie crea abbandono. L'approccio consigliato è stratificato: passkey sincronizzate come strategia principale, autenticazione cross-device con codice QR come secondo livello, verifica dell'identità automatizzata con controlli di vitalità come terzo e credenziali verificabili digitali come quarto. Quali livelli implementare dipende dal modello di minaccia, dalla base di utenti e dai requisiti normativi.