---
url: 'https://www.corbado.com/it/blog/fallback-recupero-passkey'
title: 'Fallback e recupero delle passkey: l''approccio identifier-first'
description: 'Leggi la nostra guida per product manager e sviluppatori sulle strategie di fallback e recupero per l''autenticazione tramite passkey, per garantire un accesso sicuro e continuo agli utenti.'
lang: 'it'
author: 'Vincent Delitz'
date: '2026-05-24T16:12:25.556Z'
lastModified: '2026-05-24T16:16:25.552Z'
keywords: 'passkey recovery, passkey fallback, recupero passkey, fallback passkey, autenticazione, identifier-first'
category: 'Passkeys Strategy'
---

# Fallback e recupero delle passkey: l'approccio identifier-first

## Key Facts

- Quasi il 95% dei dispositivi è predisposto per le passkey, eppure **strategie di fallback e recupero** efficaci rimangono essenziali per gli scenari in cui le passkey sono inaccessibili o vengono perse.
- L'**approccio identifier-first** determina automaticamente la disponibilità della passkey dopo che gli utenti hanno inserito il proprio identificatore, eliminando l'iniziativa dell'utente ed evitando stati di errore a vicolo cieco che generano confusione.
- Le **passkey sincronizzate** vengono perse meno frequentemente dei numeri di telefono cellulare, rendendo i costi di recupero delle passkey sincronizzate sul cloud inferiori al tradizionale recupero MFA basato su SMS OTP su un periodo di 36 mesi.
- L'**identificazione tramite selfie con controlli di vitalità (liveness check)** abilita il recupero MFA intelligente per i settori regolamentati, verificando la presenza fisica e facendo corrispondere gli utenti a un documento d'identità fotografato per prevenire le frodi.

## 1. Introduzione

Le passkey sono diventate una reale alternativa ai metodi di autenticazione tradizionali, con [i dispositivi predisposti per le passkey che raggiungono quasi il 95%](https://state-of-passkeys.io/). Tuttavia, anche i sistemi più avanzati richiedono efficaci strategie di fallback e recupero per affrontare gli scenari in cui le passkey non sono accessibili (fallback) o vengono addirittura perse (recupero). Questa guida ha lo scopo di esplorare i vari scenari in cui sono necessari fallback e recuperi e discutere come si presentano le possibili soluzioni.

Quando si pensa ai metodi di fallback e recupero, è importante che la loro forza corrisponda a quella del metodo di autenticazione primario. Questa guida distinguerà tra diversi utilizzi delle passkey, concentrandosi in particolare sui contesti in cui le passkey vengono utilizzate come MFA autonomo, per adattare i metodi di fallback e recupero in modo appropriato.

**Domande chiave:**

- **Quali scenari di fallback esistono?** Quali sono i potenziali scenari di fallback che potrebbero verificarsi con i sistemi di passkey e come dovrebbero essere gestiti per mantenere la sicurezza?
- **Come dovrebbe essere gestito il recupero?** A seconda dei modelli di utilizzo delle passkey, in particolare negli ambienti che utilizzano l'MFA, come dovrebbero essere progettati i processi di recupero per garantirne la sicurezza?

Attraverso l'esplorazione di queste domande, questa guida fornirà ai product manager e agli sviluppatori gli approfondimenti necessari per progettare, implementare e gestire in modo efficace i sistemi di passkey, assicurando che la sicurezza non vada a scapito dell'esperienza utente.

## 2. Definizioni: identificatore, livello di sicurezza, fallback e recupero

Prima di immergersi nelle strategie di fallback e recupero, è importante stabilire una chiara comprensione di alcuni termini fondamentali che utilizzeremo.

### 2.1 Identificatore: e-mail, numero di telefono e nome utente

Nella maggior parte dei sistemi aziendali e per i consumatori, l'autenticazione si basa su tre identificatori primari: **e-mail**, **numero di telefono** e **nome utente**.

La stragrande maggioranza dei sistemi utilizza l'**e-mail** come identificatore primario, in particolare nelle applicazioni basate sul web. Le piattaforme incentrate sui dispositivi mobili o sulle app, tuttavia, preferiscono spesso utilizzare il **numero di telefono** come identificatore per la facilità di precompilazione di un OTP (codice di accesso monouso) basato su SMS, che può essere inserito automaticamente. In alcuni casi, agli utenti può anche essere richiesto di impostare un **nome utente** in aggiunta a questi identificatori, principalmente per le piattaforme che richiedono un nome visualizzato univoco. C'è anche una tendenza crescente, soprattutto nelle piattaforme più grandi, a consentire l'uso sia dell'**e-mail** che del **numero di telefono** per una maggiore flessibilità.

Durante la registrazione iniziale, questi identificatori vengono in genere verificati tramite un link di conferma / OTP (per l'**e-mail**) o un OTP (per il **numero di telefono**), garantendo che l'identificatore appartenga alla persona corretta. Nel caso in cui l'accesso venga perso, dimostrare il controllo sull'**e-mail** o sul **numero di telefono** precedentemente verificati è solitamente sufficiente per ripristinare l'accesso all'account. Poiché questi identificatori sono le forme di comunicazione più affidabili con gli utenti, i **numeri di telefono** vengono spesso raccolti per scopi MFA (autenticazione a più fattori), essendo l'SMS un secondo fattore di uso comune.

I **nomi utente** vengono spesso impiegati per fornire un ulteriore livello di identità utente nei sistemi in cui sono richiesti identificatori rivolti al pubblico, come social media, forum o determinate piattaforme professionali. Anche se non svolgono lo stesso ruolo funzionale nell'autenticazione delle **e-mail** o dei **numeri di telefono**, i nomi utente forniscono agli utenti un'identità riconoscibile in contesti pubblici o peer-to-peer. Tuttavia, introducono un'ulteriore complessità in quanto gli utenti possono spesso dimenticarli e, nella maggior parte dei casi, è richiesto un altro identificatore insieme al nome utente. Pertanto, in questo articolo, non ci concentreremo sui nomi utente.

Altre opzioni 2FA, come le app di autenticazione (che generano codici TOTP), non si basano su un identificatore, ma sono spesso più complesse da configurare per un utente medio. Anche le **passkey** hanno introdotto la possibilità di lavorare senza un identificatore (autenticazione senza nome utente), una funzionalità che sta diventando sempre più popolare nello spazio crittografico. Tuttavia, sia per le soluzioni per consumatori che per quelle aziendali, la necessità di comunicare con gli utenti (spesso tramite **e-mail**) per scopi di fallback o recupero rende i sistemi senza nome utente meno pratici.

### 2.2 Livello di sicurezza: autenticazione a fattore singolo (SFA) e autenticazione a più fattori (MFA)

I sistemi di **autenticazione a fattore singolo (SFA)** sono quelli che si basano su una forma di autenticazione per verificare l'identità dell'utente. Comunemente, questo singolo fattore è una password, ma può anche essere un social login, un OTP via e-mail o qualsiasi metodo che richieda solo un tipo di prova. La maggior parte dei sistemi sul web oggi sono sistemi SFA. Tuttavia, c'è un noto compromesso con la sicurezza. Quando si integrano le passkey, queste fungono in genere da componente aggiuntivo o da sostituzione per le password tradizionali, migliorando la comodità del sistema. È comune che tali sistemi consentano ancora opzioni di fallback come OTP via e-mail o social login, il che migliora l'esperienza utente riducendo le password, ma non eleva la sicurezza del sistema oltre la SFA.

L'**autenticazione a più fattori (MFA)** comporta due o più fattori indipendenti per la verifica dell'identità di un utente; questo è ciò che la rende più sicura della SFA. Questi fattori possono includere qualcosa che l'utente conosce (password o PIN), qualcosa che l'utente ha (un token di sicurezza o un'app per smartphone) e qualcosa che l'utente è (verifica biometrica come impronte digitali o riconoscimento facciale). I sistemi MFA sono progettati per proteggere da vulnerabilità specifiche da cui i sistemi SFA non possono difendersi, come attacchi di phishing o violazioni di password. Quando si utilizzano le passkey all'interno di un sistema MFA, esse vengono generalmente impiegate come opzione MFA autonoma. In questi casi, è fondamentale che eventuali metodi di fallback o recupero mantengano lo stesso livello di sicurezza delle passkey.

### 2.3 Fallback e recupero

I **fallback** sono utilizzati in tutti i sistemi in cui coesistono più metodi di autenticazione. Vengono utilizzati quando i metodi primari non sono disponibili - spesso l'utente ha la possibilità di scegliere all'inizio come registrarsi (ad es. social login rispetto a password). Un fallback potrebbe comportare strategie di autenticazione alternative come OTP via e-mail, password, social login con e-mail corrispondenti, notifiche push di app native, codici QR o chiavi di sicurezza. Ciascuno di questi metodi di fallback varia in base alla qualità della sicurezza e la selezione dell'opzione di fallback appropriata è fondamentale per bilanciare la comodità per l'utente con i requisiti di sicurezza.

Negli ambienti che utilizzano le passkey come parte di un sistema di autenticazione a più fattori (MFA), questi metodi di fallback devono essere considerati con attenzione per garantire che forniscano una sicurezza a più fattori paragonabile a quella delle passkey. I processi di **recupero** diventano importanti quando gli utenti perdono l'accesso a **tutte le misure di autenticazione stabilite** che soddisfano gli standard di sicurezza richiesti (SFA o MFA). Ciò è meno critico nei sistemi a fattore singolo, in cui possono essere disponibili più opzioni di recupero, come il ripristino di una password tramite un OTP via e-mail, che convalida di fatto il controllo dell'utente su un identificatore associato. Tuttavia, il recupero è particolarmente impegnativo nei sistemi 2FA/MFA perché questi sistemi si basano intrinsecamente su più fattori per la verifica. Negli scenari in cui un utente cambia sistema operativo mobile - ad es. dall'iPhone al telefono Android - e perde le passkey associate e il numero di telefono - i fattori rimanenti (ad es. solo una password) non possono soddisfare i requisiti 2FA. In questi casi, il recupero potrebbe necessitare della creazione di nuove prove di identità, il che può comportare richieste di supporto manuale o soluzioni più innovative che tratteremo in seguito.

## 3. Fallback dell'accesso con passkey: accesso manuale rispetto all'accesso automatico

**Quando si implementa una soluzione con passkey, una delle prime decisioni da prendere è l'approccio per l'accesso con passkey**. A seconda del caso d'uso, l'accesso manuale potrebbe essere sufficiente per le piattaforme più piccole, ma per le aziende più grandi orientate alla UX (User Experience), si consiglia un approccio identifier-first, che offre l'accesso con passkey dopo che l'identificatore primario (molto probabilmente l'e-mail) è stato inserito.

### 3.1 Accesso manuale con passkey: approccio avviato dall'utente

![accesso manuale passkey](https://www.corbado.com/website-assets/manual_passkey_login_ca7554d1ba.jpg)

#### 3.1.1 Cos'è l'approccio avviato dall'utente?

Sulle piattaforme più piccole o sulle piattaforme che non si concentrano su un elevato tasso di accesso con passkey, l'approccio avviato dall'utente prevede un pulsante separato "Accedi con passkey". In questo approccio, la **responsabilità** dell'utilizzo delle passkey è interamente affidata all'utente. Dopo aver aggiunto una passkey al proprio account, l'utente deve ricordarsi di fare clic su "Accedi con passkey" per accedere utilizzandola.

![mygov passkeys manual](https://www.corbado.com/website-assets/mygov_passkeys_manual_f5311f61e4.png)

Lo screenshot mostra l'implementazione delle passkey di [https://my.gov.au](https://my.gov.au), che utilizza l'approccio di accesso manuale con passkey. Sebbene questo approccio sia più facile da implementare perché il backend non ha bisogno di determinare se un accesso con passkey è possibile, in genere porta a tassi di accesso con passkey molto più bassi. Questo perché si basa pesantemente sull'iniziativa dell'utente e i consumatori potrebbero non ricordare o non essere sicuri su quale piattaforma o cloud storage risiedano le loro passkey. Questo approccio fa pensare l'utente. Diamo un'occhiata alle possibili opportunità di fallback che esistono con questo approccio nella sezione successiva.

#### 3.1.2 Fallback

I fallback sono essenziali in qualsiasi sistema in cui vi siano possibilità di fallimento dell'accesso con passkey. Nell'approccio di accesso manuale con passkey, le finestre di dialogo e i fallback non possono essere gestiti individualmente perché tutte le opzioni di accesso vengono visualizzate contemporaneamente e le passkey vengono scelte a discrezione dell'utente. Ciò porta a diverse sfide:

- **Errori non intuitivi:** I messaggi di errore che gli utenti incontrano quando le passkey non sono disponibili o sono impostate in modo errato sono spesso poco chiari e possono causare confusione. Gli utenti potrebbero non capire perché non sono in grado di utilizzare la passkey o cosa sia andato storto, portando alla frustrazione.
- **Vicoli ciechi:** Gli utenti possono trovarsi in vicoli ciechi da cui non possono procedere. Se le passkey mancano o sono inaccessibili, agli utenti potrebbe non essere fornita alcuna indicazione chiara su come procedere o ripristinare l'accesso, inducendoli ad abbandonare il processo di accesso.
- **Mancanza di guida:** In queste situazioni, il sistema non può fornire istruzioni utili per guidare gli utenti verso un metodo di autenticazione alternativo. Gli utenti vengono lasciati da soli a capire come risolvere il problema, il che riduce la qualità dell'esperienza utente.

![mygov passkey errors](https://www.corbado.com/website-assets/mygov_passkey_errors_a31da4283e.png)

L'esempio precedente mostra quanto siano confusi i messaggi di errore di Windows 11 quando le passkey non vengono trovate sull'autenticatore di piattaforma. Il sistema potrebbe presupporre che la passkey risieda su una chiave di sicurezza o su un altro dispositivo. Questo processo può creare confusione per gli utenti che non hanno familiarità con tali flussi di autenticazione, in particolare se non hanno mai utilizzato una chiave di sicurezza prima o non hanno mai creato una passkey.

![mygov passkey not exists](https://www.corbado.com/website-assets/mygov_passkey_not_exists_be8a954d92.png)

**Se non vengono trovate passkey sull'autenticatore di piattaforma, il sistema operativo e il browser presumono che debbano esistere altrove, portando a ulteriore confusione se l'utente non ha ancora creato una passkey.** La Conditional UI può aiutare visualizzando le passkey esistenti, ma questo è utile solo se le passkey esistono effettivamente. Per la migliore esperienza con le passkey, il backend dovrebbe decidere se attivare un accesso con passkey dopo che l'utente ha fornito il suo identificatore primario.

### 3.2 Accesso automatico con passkey: approccio identifier-first

![accesso automatico passkey](https://www.corbado.com/website-assets/automatic_passkey_login_4786c4413f.jpg)

#### 3.2.1 Cos'è l'approccio identifier-first?

Nell'approccio identifier-first, agli utenti viene richiesto di fornire il proprio identificatore primario, come un'e-mail o un numero di telefono, prima che il sistema determini se è possibile un accesso con passkey. **Dopo che l'identificatore è stato verificato, il sistema suggerisce automaticamente il metodo di accesso più appropriato, incluse le passkey se sono disponibili e accessibili**. Questo approccio è più intuitivo per l'utente perché elimina la necessità per gli utenti di ricordarsi di selezionare l'opzione "Accedi con passkey" e aumenta il tasso di adozione semplificando il processo.

![accesso identifier first google](https://www.corbado.com/website-assets/google_identifier_first_sign_in_4d53b85a52.png)_Accesso identifier-first di Google_

![accesso passkey google](https://www.corbado.com/website-assets/google_passkey_sign_in_df2e4978c5.png)_Accesso con passkey di Google_

**Gli screenshot qui sopra mostrano il comportamento di accesso per un account Google in cui una passkey è associata su un dispositivo macOS.** Anche Google segue l'approccio identifier-first e ha stabilito che l'accesso con passkey sarà molto probabilmente possibile:

1. **Supporto della piattaforma passkey:** La piattaforma sottostante supporta un autenticatore di piattaforma, pertanto l'accesso può essere possibile.
2. **La passkey è accessibile:** La passkey sarà molto probabilmente accessibile su questo client (macOS) perché è stata creata su un sistema macOS.

Di conseguenza, viene avviato automaticamente un accesso con passkey, guidando l'utente verso la migliore esperienza possibile. Questo segue la strategia "don't make me think".

> Una buona progettazione delle passkey e dell'autenticazione non trasferisce la responsabilità all'utente, ma suggerisce la strategia di autenticazione ottimale per l'account specifico a seconda dell'ambiente client.

#### 3.2.2 Mancanza di supporto della piattaforma passkey o accessibilità della passkey

Il sistema determina se è possibile un accesso con passkey. Nel caso in cui:

- **Non esista alcuna passkey:** L'utente non ha ancora creato una passkey per il suo account.
- **Le passkey non siano accessibili:** Le passkey che l'utente ha creato molto probabilmente non sono disponibili su questo client (ad esempio, l'utente ha solo una passkey macOS e ora effettua l'accesso da Windows).
- **L'autenticazione con passkey non sia supportata:** Il client corrente non supporta gli autenticatori di piattaforma ed è anche molto improbabile che supporti l'autenticazione cross-device tramite codice QR.

![accesso senza conditional ui google](https://www.corbado.com/website-assets/google_no_conditional_ui_sign_in_7e1fa02c4d.png)

La decisione sarà che un accesso riuscito con passkey è improbabile e **pertanto le opzioni di fallback verranno fornite automaticamente senza attivare un accesso con passkey**. Questo approccio è molto più intuitivo per l'utente perché elimina la necessità per gli utenti di ricordarsi di selezionare l'opzione "Accedi con passkey", migliora il tasso di adozione semplificando il processo ed evita lo scenario peggiore in cui all'utente viene mostrato un vicolo cieco confuso.

Nell'esempio precedente, il fallback per l'accesso avviene tramite una password per poi continuare a richiedere ulteriori fattori di autenticazione in base allo stato e alla sicurezza dell'account, perché il client è un dispositivo Windows 11, che difficilmente avrà accesso alle passkey di macOS. A seconda dei requisiti di sicurezza del tuo sistema di autenticazione, hai il pieno controllo su quale metodo di autenticazione attivare in un caso del genere (ad es. l'ultima opzione di autenticazione riuscita non tramite passkey).

#### 3.2.3 Interruzioni della procedura con passkey

Quando un utente si trova di fronte a una schermata di autenticazione durante un accesso web, potrebbe essere sorpreso o sopraffatto, soprattutto se è una delle prime volte che utilizza l'autenticazione basata su passkey. Ciò può portare gli utenti a interrompere il processo di autenticazione, non a causa di un guasto, ma semplicemente perché non sono sicuri di cosa stia accadendo. È fondamentale pianificare questo comportamento e trattare la prima interruzione come un evento normale anziché come un errore:

![prima interruzione passkey google](https://www.corbado.com/website-assets/google_passkey_first_abort_9024d11904.png)

La prima schermata di interruzione dovrebbe spiegare chiaramente cosa sta accadendo in modo calmo e rassicurante, consigliando all'utente di riprovare il processo (vedi l'esempio di Google qui sopra). Questa schermata dovrebbe essere progettata per ridurre al minimo l'ansia, trattando l'interruzione come una parte regolare e prevista dell'esperienza utente. Molti utenti potrebbero interrompere semplicemente perché non hanno riconosciuto la schermata di autenticazione o non avevano familiarità con il processo. Pertanto, un nuovo tentativo dovrebbe essere il suggerimento predefinito.

Se si verifica una **seconda interruzione**, tuttavia, la situazione dovrebbe essere trattata in modo diverso. La seconda interruzione potrebbe indicare che qualcosa è andato veramente storto - che si tratti di un problema con l'autenticatore di piattaforma, dell'incapacità dell'utente di trovare una passkey appropriata o di un guasto tecnico nella procedura WebAuthn. A questo punto, il sistema dovrebbe presentare una schermata diversa spiegando che si è verificato un problema e suggerendo un po' di più le opzioni di fallback:

![seconda interruzione passkey google](https://www.corbado.com/website-assets/google_passkey_second_abort_b0487ba1bc.png)

**La seconda schermata di interruzione dovrebbe incoraggiare l'utente a passare a un metodo di autenticazione alternativo**. Dovrebbe garantire che l'utente possa ancora accedere correttamente senza causare ulteriore frustrazione. Come possiamo vedere nella schermata precedente, Google suggerisce ancora "Riprova", ma allo stesso tempo mostra all'utente che probabilmente qualcosa è andato storto.

### 3.3 Confronto degli approcci di implementazione delle passkey

La tabella seguente aiuta a confrontare i diversi approcci riassumendone le caratteristiche più importanti:

![confronto approcci implementazione passkey](https://www.corbado.com/website-assets/passkey_falback_comparison_table_1f62928641.jpg)

Gli approcci "fai da te" seguono di solito l'**approccio di accesso manuale con passkey** e si basano sulla Conditional UI e sul fatto che l'utente opti per le passkey, il che si traduce in tassi di accesso con passkey molto bassi e utenti frustrati. L'**approccio identifier-first** richiede l'istituzione di una logica dei dispositivi ben ponderata in aggiunta alla Conditional UI, che è dove Corbado può aiutarti. Costruire la tua logica dei dispositivi e [passkey intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) non è raccomandato, in quanto questo set di regole richiede costanti ritocchi e adeguamenti a nuovi dispositivi, nuove funzionalità WebAuthn e sincronizzazione cloud (es. passkey di Google Password Manager).

## 4. Recupero delle passkey

**Il recupero delle passkey è un aspetto cruciale per il mantenimento della sicurezza e dell'esperienza utente quando gli utenti perdono l'accesso alle proprie passkey.** Questo è particolarmente importante nei sistemi che si basano sull'MFA. Nei casi MFA, i processi di recupero devono garantire che la sicurezza sia preservata, consentendo agli utenti di riottenere l'accesso ai propri account. L'approccio di recupero deve essere personalizzato in base al livello di autenticazione utilizzato nel sistema.

### 4.1 Recupero a fattore singolo e recupero a più fattori

Per mantenere la sicurezza nei sistemi SFA, il recupero comporta generalmente la prova del controllo su un identificatore come un indirizzo e-mail o un numero di telefono cellulare.

- **OTP via e-mail:** Un OTP viene inviato all'indirizzo e-mail registrato dell'utente. Una volta verificato, ciò consente all'utente di riottenere l'accesso e creare una nuova passkey.
- **OTP via SMS:** Simile al recupero tramite e-mail, un OTP viene inviato al numero di telefono cellulare registrato. L'utente può utilizzare questo OTP per riottenere l'accesso al proprio account.

Sebbene questi metodi siano semplici, si basano sull'aggiornamento costante delle informazioni di contatto dell'utente. Pertanto, è essenziale chiedere regolarmente agli utenti di verificare la propria e-mail e il numero di telefono durante gli accessi di routine.

Nei sistemi di **autenticazione a più fattori**, il recupero diventa più complesso. Poiché l'MFA si basa su più fattori indipendenti (ad es. passkey, social login e OTP), gli utenti non dovrebbero perdere l'accesso solo perché un fattore (come una passkey) non è disponibile.

- **Utilizzo di fattori alternativi:** Se la passkey viene persa, l'utente può autenticarsi utilizzando due altri fattori, come una password + OTP via SMS o un'app di autenticazione. Una volta autenticato, può creare una nuova passkey.
- **Utilizzo di altre passkey:** Nel caso in cui l'utente disponga di altri dispositivi con passkey, potrebbe utilizzarli per riottenere l'accesso con suggerimenti appropriati (ad es. richiedendo l'uso di una passkey da un iPhone).
- **Creazione di nuove passkey:** Dopo l'autenticazione con il metodo di recupero, l'utente dovrebbe essere guidato a creare una nuova passkey per garantire che la configurazione MFA rimanga intatta.

Sia per i sistemi SFA che per quelli MFA, la chiave è garantire che i processi di recupero siano solidi e sicuri riducendo al minimo gli attriti per l'utente.

### 4.2 Recupero MFA intelligente: digitalizzare i costi di recupero MFA

Nei sistemi che gestiscono dati personali sensibili, nei settori regolamentati o nei [servizi governativi](https://www.corbado.com/passkeys-for-public-sector), l'OTP standard via e-mail e l'OTP tramite numero di cellulare potrebbero non essere sempre sufficienti o disponibili per il recupero. In tali casi, i **meccanismi di recupero MFA intelligenti** offrono metodi avanzati per il recupero dell'account che mantengono standard di sicurezza elevati offrendo agli utenti un'esperienza fluida.

Uno dei metodi più efficaci è l'**identificazione tramite selfie con un controllo di vitalità (liveness check)**. Questo processo richiede all'utente di scattare foto del proprio documento d'identità. Inoltre, un controllo di vitalità del selfie assicura che il selfie venga scattato in tempo reale, confermando che l'utente è fisicamente presente e corrisponde al documento d'identità fotografato, impedendo così frodi utilizzando immagini statiche o documenti d'identità rubati. A seconda della tecnologia utilizzata, un controllo di vitalità viene effettuato registrando un breve video in cui viene modificata la distanza dalla fotocamera o la testa viene girata di 180 gradi (ad es. Face ID di Apple).

Questo metodo può essere particolarmente utile quando anche i metodi di recupero tradizionali come e-mail o OTP via SMS non sono disponibili o sono obsoleti. Ad esempio, ecco un esempio in cui si scatta un selfie a cui fa seguito un controllo di vitalità da onfido:

![liveness check onfido](https://www.corbado.com/website-assets/liveness_check_onfido_7109eb3d96.png)_Esempio: identificazione con selfie con liveness check da onfido_

- **I sistemi governativi, i settori regolamentati o i grandi servizi commerciali** dispongono di dati personali che possono essere utilizzati per verificare le informazioni disponibili sul documento d'identità. Nel caso in cui, ad esempio, la data di nascita non sia disponibile, le informazioni raccolte tramite il documento d'identità possono essere utilizzate come fattore nel processo di recupero manuale.

Inoltre, altri metodi di **recupero intelligente** possono includere:

- **Recupero cross-device:** Se un utente dispone di un dispositivo secondario attendibile, può recuperare il proprio account scansionando un codice QR.
- **Ambienti noti:** Gli utenti che hanno ancora accesso allo stesso dispositivo che avevano utilizzato con successo in passato possono fornire ulteriori fattori di garanzia utilizzando questo dispositivo e fornendo quindi la prova che stanno agendo dallo stesso dispositivo, provider e posizione per aiutare il processo di recupero manuale. Un approccio che Google utilizza per il [recupero dell'account Gmail](https://gmailaccountrecovery.blogspot.com/).
- **API Digital Credentials:** Con la crescente adozione dei portafogli d'identità, si prevede che la verifica diretta attraverso questa API svolgerà un ruolo crescente nel recupero dell'account sicuro e intuitivo.

I metodi di recupero MFA intelligenti mirano a offrire agli utenti modi sicuri e intuitivi per riottenere l'accesso ai propri account, specialmente quando si tratta di informazioni altamente sensibili o regolamentate. Questi approcci assicurano che anche nei casi in cui non siano disponibili i metodi tradizionali come il recupero tramite e-mail o telefono, gli utenti possano comunque ripristinare il proprio accesso in modo sicuro ed efficiente. Il recupero intelligente aiuta a ridurre i costi del recupero MFA.

### 4.3 Frequenze di recupero MFA: numero di telefono rispetto alla passkey

È importante tenere presente che poiché le passkey sono sincronizzate nel cloud, i costi di recupero MFA sono molto inferiori su un periodo di 36 mesi, poiché il cambio del numero di telefono cellulare è molto più frequente del passaggio da Apple ad Android o viceversa. In caso di cambio del contratto telefonico le passkey verranno ripristinate.

**Pertanto, perdere l'accesso alle passkey sincronizzate accadrà meno frequentemente rispetto alla perdita dell'accesso al numero di cellulare, che causa la maggior parte dei disagi di recupero per i sistemi MFA tradizionali orientati ai consumatori.**

Tuttavia, con la crescita della base di utenti, tali casi causano ancora costi di supporto manuale significativi e dovrebbero essere gestiti con una soluzione digitale, che esamineremo nella sezione successiva.

## 5. Raccomandazioni per Product Manager e Sviluppatori

Quando si integrano le passkey nel sistema di autenticazione, è fondamentale pianificare attentamente sia le opzioni di fallback che le strategie di recupero per mantenere un elevato livello di sicurezza garantendo al contempo un'esperienza utente continua. Per massimizzare la percentuale di successo dell'accesso con passkey, considera le seguenti raccomandazioni:

- **Scegli l'approccio identifier-first:** Questo approccio è più user-friendly e riduce gli attriti nel processo di accesso. Chiedendo agli utenti di inserire prima il loro identificatore primario (ad es. e-mail o numero di telefono), il sistema può determinare automaticamente se è possibile un accesso con passkey. Questo assicura un'esperienza di accesso fluida e intuitiva senza fare affidamento sull'utente per scegliere manualmente un'opzione passkey.
- **Utilizza schermate di interruzione esplicative per una migliore esperienza utente:** Mentre la sicurezza dovrebbe essere la massima priorità, è essenziale progettare un processo che aiuti l'utente ad adottare le passkey. Assicurati che le prime interruzioni della procedura siano trattate come normali e fornisci indicazioni chiare per riprovare.
- **Mantieni sicure le opzioni di fallback e recupero:** Assicurati che i metodi di fallback (come OTP via e-mail e/o OTP via SMS) corrispondano al livello di sicurezza del metodo di autenticazione primario. Ad esempio, in un sistema MFA che utilizza passkey, il fallback dovrebbe richiedere anch'esso più fattori per mantenere lo stesso standard di sicurezza.
- **Automatizza i prompt di recupero regolari:** Chiedi regolarmente agli utenti di verificare le proprie informazioni di contatto (indirizzo e-mail o numero di telefono) durante l'accesso per garantire che le opzioni di recupero rimangano aggiornate quando utilizzano le passkey. Questo riduce le possibilità che gli utenti vengano bloccati fuori dai loro account a causa di metodi di recupero obsoleti.
- **Considera metodi di recupero intelligenti per maggiore sicurezza e minori costi di supporto del recupero:** Per i settori regolamentati o i sistemi che hanno accesso ai dati personali per effettuare controlli tramite l'identificazione online, considera metodi di recupero avanzati come l'identificazione tramite selfie con controlli di vitalità. Questo metodo può fornire ulteriori livelli di sicurezza mantenendo il processo di recupero intuitivo e di facile utilizzo a seconda dei requisiti di sicurezza.

Massimizzare il tasso di accesso con passkey dipende da quanto bene si implementano questi elementi. Garantire opzioni di fallback e recupero fluide darà agli utenti fiducia nell'utilizzo delle passkey come metodo di autenticazione primario.

## 6. Cosa può fare Corbado per te: componenti dell'interfaccia utente e passkey intelligence

Corbado fornisce tutto il necessario per implementare l'approccio identifier-first per progetti completamente nuovi che necessitano di un sistema di autenticazione nuovo di zecca e per i progetti esistenti che necessitano di aggiungere le passkey a un sistema di autenticazione preesistente.

### 6.1 Componenti dell'interfaccia utente per diversi casi d'uso

Entrambi i prodotti offrono componenti dell'interfaccia utente che possono essere adattati alle tue esigenze:

1. **Corbado Complete: inizia il tuo progetto con l'autenticazione passkey-first**\
   Questo è il nostro sistema di autenticazione completo, che include un approccio identifier-first senza interruzioni per semplificare il processo di accesso. Corbado Complete abilita un'esperienza sicura e facile da usare determinando automaticamente se l'accesso con passkey è possibile dopo che l'utente ha fornito il proprio identificatore. Questo riduce gli attriti e assicura un'esperienza di accesso fluida, che è cruciale per massimizzare l'adozione delle passkey.
2. **Corbado Connect: aggiungi passkey senza migrazione a nessuna app**\
   Per le aziende che hanno già processi di autenticazione stabiliti e desiderano aggiungere passkey come potenziamento, Corbado Connect offre una soluzione aggiuntiva per le strategie a fattore singolo e a più fattori. Questo approccio integra la tua infrastruttura esistente integrando perfettamente le passkey come opzione sicura e conveniente, consentendo agli utenti di autenticarsi tramite passkey senza dover stravolgere l'attuale sistema. Ad esempio, Corbado Connect può essere integrato perfettamente in Amazon Cognito.

Allineiamo rigorosamente i nostri metodi con i leader del settore come Google e altri attori di primo piano nel grande spazio tecnologico, appositamente studiati per le aziende orientate ai consumatori.

### 6.2 La Passkey Intelligence abilita l'approccio identifier-first

Il nostro obiettivo non è solo massimizzare l'adozione delle passkey (ovvero, la creazione di passkey), ma anche garantire che queste passkey vengano utilizzate attivamente per guidare alti tassi di accesso (e quindi aumentare la sicurezza e ridurre i costi degli SMS OTP). I nostri componenti dell'interfaccia utente sono costruiti tenendo presente l'approccio identifier-first e sono direttamente connessi alla nostra [Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence), che decide la disponibilità e l'accessibilità della passkey in base all'ambiente del client e alle passkey esistenti. Supportano tutte le funzionalità di fallback e recupero discusse. Le seguenti schermate mostrano la nostra logica di interruzione e nuovo tentativo:

![prima interruzione passkey corbado](https://www.corbado.com/website-assets/corbado_passkey_first_abort_537bf2c410.png)_Prima interruzione passkey_

![seconda interruzione passkey corbado](https://www.corbado.com/website-assets/corbado_passkey_second_abort_a167225e5e.png)_Seconda interruzione passkey_

Concentrandoci sia sull'adozione delle passkey che sul loro utilizzo, ti aiutiamo a raggiungere un equilibrio tra sicurezza ed esperienza utente, garantendo che gli utenti continuino a interagire con le passkey in modo fluido.

## 7. Conclusione

In questa guida, abbiamo esplorato le varie strategie di fallback e recupero a seguito dell'integrazione delle passkey in un sistema di autenticazione. Le domande chiave poste nell'introduzione sono state affrontate in tutto il testo:

- **Quali scenari di fallback esistono?** Possono verificarsi diversi scenari di fallback, come la mancanza di supporto per le passkey o il fatto che le passkey non siano accessibili su un particolare dispositivo. Per mantenere la sicurezza e fornire una UX fluida, le opzioni di fallback come e-mail o OTP via SMS dovrebbero essere disponibili quando l'accesso con passkey non è possibile.
- **Come dovrebbe essere gestito il recupero?** I processi di recupero dovrebbero essere progettati per corrispondere al livello di sicurezza del sistema di autenticazione. Nei sistemi SFA, e-mail o SMS OTP possono essere sufficienti, mentre nei sistemi MFA, è necessario utilizzare fattori alternativi per riottenere l'accesso e creare una nuova passkey. In ambienti altamente regolamentati o sensibili, metodi di recupero intelligenti come l'identificazione tramite selfie con controlli di vitalità forniscono ulteriore sicurezza.

Seguendo le best practice delineate in questa guida, i product manager e gli sviluppatori possono progettare solidi sistemi di autenticazione basati su passkey che forniscano agli utenti un'esperienza di accesso sicura e continua. La sicurezza non deve necessariamente andare a scapito dell'esperienza utente: entrambe possono essere raggiunte con una progettazione e una pianificazione ponderate.

## Domande frequenti

### Come gestisce l'approccio identifier-first l'accesso con passkey quando una passkey non è accessibile sul dispositivo corrente?

Quando è probabile che una passkey sia inaccessibile (ad esempio una passkey macOS a cui si accede da un dispositivo Windows), il sistema ignora automaticamente la richiesta della passkey e presenta invece opzioni di fallback come password o OTP. Questo evita vicoli ciechi confusi attivando l'accesso con passkey solo quando il successo è probabile, seguendo una strategia 'don't make me think'.

### Cosa dovrebbe succedere quando un utente interrompe una procedura di autenticazione con passkey a metà flusso?

La prima interruzione dovrebbe essere trattata come un evento normale, con una schermata rassicurante che incoraggia l'utente a riprovare, poiché molti utenti annullano semplicemente perché non hanno familiarità con la schermata di autenticazione. Se si verifica una seconda interruzione, il sistema dovrebbe proporre opzioni di autenticazione di fallback, poiché ciò potrebbe indicare un problema reale con l'autenticatore di piattaforma o la disponibilità della passkey.

### Quali opzioni di recupero esistono per i sistemi MFA quando un utente perde l'accesso alla propria passkey?

Nei sistemi MFA, gli utenti possono effettuare il recupero autenticandosi con due fattori alternativi, come una password più un OTP via SMS, oppure utilizzando una passkey da un altro dispositivo attendibile, per poi creare una nuova passkey. Per i settori regolamentati in cui i metodi di recupero tradizionali non sono disponibili, metodi intelligenti come l'identificazione tramite selfie con controlli di vitalità forniscono un ulteriore percorso di recupero sicuro.

### Perché l'approccio manuale con il pulsante "Accedi con passkey" porta a un'adozione inferiore rispetto all'approccio identifier-first?

L'approccio manuale attribuisce agli utenti l'intera responsabilità di ricordare e selezionare da soli l'opzione passkey, il che in genere si traduce in tassi di accesso con passkey molto più bassi. Gli utenti possono anche incontrare messaggi di errore poco chiari quando le passkey non vengono trovate sull'autenticatore di piattaforma, il che porta a frustrazione e a tentativi di accesso abbandonati.