SMS OTP vs app di autenticazione: come scegliere l'MFA giusto

Perché la scelta del metodo MFA si trasforma in dolore per il supporto

La maggior parte delle persone nota l'MFA solo quando fallisce. Un codice arriva in ritardo, un telefono non ha segnale o un'app viene cancellata durante l'aggiornamento del dispositivo. L'utente resta bloccato nella schermata di accesso e ciò che dovrebbe essere un'ulteriore sicurezza si trasforma in «non posso fare il mio lavoro».

Per questo SMS OTP vs app di autenticazione non è solo un argomento di sicurezza. È una decisione di prodotto che cambia la tua coda di supporto, il rischio di abbandono e quanto spesso il team finisce per fare controlli d'identità manuali.

Quando l'MFA fallisce, gli utenti di solito fanno una di tre cose: riprovano qualche volta, abbandonano il flusso o contattano il supporto in panico perché pensano che il loro account sia stato compromesso. Anche quando la causa è semplice, il tono emotivo è spesso urgente, il che rallenta e rende più costosi i ticket.

Per prevedere il carico di supporto prima del rilascio, concentrati su quattro aree: affidabilità nel mondo reale (messaggistica e cambi dispositivo), rischio di phishing e takeover, attrito per l'utente (configurazione e ogni accesso) e i tipi di ticket che vedrai nella pratica.

I codici SMS sono comuni nelle app consumer perché sembrano familiari e richiedono quasi nessuna configurazione. Le app di autenticazione sono diffuse in ambito aziendale e negli strumenti admin perché eliminano la dipendenza dall'operatore e riducono alcuni rischi legati alle telecomunicazioni.

Deliverability SMS: cosa si rompe nella vita reale

L'SMS sembra semplice, ma “inviato” non è la stessa cosa di “ricevuto e utilizzabile”. È qui che i team restano sorpresi dal volume di supporto.

A volte l'SMS è istantaneo: stesso paese, segnale forte e un operatore che non rallenta il traffico di verifica. Altre volte si trascina. Gli operatori ritardano i messaggi durante i picchi, applicano filtri antispam o limitano gli invii ripetuti. Il risultato è un codice che arriva dopo la scadenza, o più codici che arrivano insieme e l'utente prova quello più vecchio.

L'uso internazionale aggiunge spigoli. Alcuni paesi hanno copertura limitata per certe rotte. Alcuni operatori bloccano i messaggi di verifica per default. Il roaming può instradare il traffico in modi che aggiungono minuti. Se i tuoi utenti viaggiano, vedrai ticket “funziona a casa, fallisce all'estero”.

I numeri di telefono cambiano più spesso di quanto i team pensino. Gli utenti cambiano SIM, perdono l'accesso o inseriscono un errore una sola volta e non se ne accorgono. I numeri riciclati sono peggio: un numero inattivo viene riassegnato e un futuro login via SMS può arrivare alla persona sbagliata.

I flussi di resend sono il punto dove la frustrazione esplode. Se gli utenti possono toccare “Reinvia” senza limiti chiari e senza feedback comprensibile, crei loop di resend: tanti invii, arrivi ritardati e confusione su quale codice sia valido.

Quello che vale la pena monitorare (e mostrare negli strumenti admin) è semplice: tentativi di invio per login, conferme di consegna quando il provider le segnala, tempo al codice (ora di invio vs ora di invio del codice), motivi di errore del provider (bloccato, numero non valido, limitato) e trigger di resend/blocco.

Esempio: un cliente a Singapore prova ad accedere mentre è in roaming in Germania. Tappa “Reinvia” due volte, riceve tre messaggi insieme e inserisce il primo codice. Se logghi tempo-al-codice e conteggio dei resend, il ticket diventa una rapida triage invece di un lungo avanti e indietro.

Affidabilità delle app di autenticazione: dove si inceppano gli utenti

Le app di autenticazione sono di solito più consistenti dell'SMS perché generano codici temporanei sul dispositivo, anche offline. Nessun ritardo dell'operatore, nessun messaggio bloccato, nessuna sorpresa da roaming.

La configurazione è semplice sulla carta: scansiona un codice QR una volta, poi digita il codice a 6 cifre al login. Nella vita reale le persone si bloccano in quel primo minuto, soprattutto quando passano tra laptop e telefono e non sono sicure di cosa guardare.

La maggior parte dei problemi non riguarda l'app in sé. Riguarda il telefono e le aspettative dell'utente:

• L'orologio del telefono è sbagliato, quindi i codici non combaciano (le impostazioni manuali dell'ora sono una causa comune).
• L'app di autenticazione è stata cancellata durante la pulizia, quindi l'account sembra «bloccato».
• Il telefono è stato perso o ripristinato e non c'è un metodo di backup.
• L'utente ha aggiornato il telefono e ha supposto che i codici si sarebbero trasferiti automaticamente.
• L'utente si è registrato con un telefono di lavoro e non può più accedervi dopo aver cambiato lavoro.

L'usabilità conta più di quanto i team pensino. Cambiare app a metà login, copiare codici e correre contro un conto alla rovescia può essere stressante. Prompt chiari aiutano: dì esattamente dove trovare il codice, mostra cosa fare se fallisce e supporta l'autofill dove la piattaforma lo permette.

Aspettative multi-dispositivo e cosa monitorare

Gli utenti spesso chiedono più dispositivi (telefono più tablet, personale più lavoro). Se non lo permetti, dillo durante l'iscrizione, non dopo che sono bloccati fuori.

Alcuni segnali catturano l'attrito presto: tasso di completamento della registrazione (chi inizia ma non finisce), errori di codice ripetuti (spesso sincronizzazione dell'ora), percorsi di recupero usati (telefono perso, nuovo dispositivo, app cancellata), abbandono dopo il prompt MFA e tag di supporto per causa.

Resistenza al phishing e rischio di takeover

Il phishing è dove si vede il vero divario.

Con SMS OTP, un attacco comune è il relay in tempo reale. Un utente finisce su una pagina di login falsa, inserisce la password e poi riceve un codice SMS. L'attaccante usa lo stesso codice sul sito reale mentre l'utente guarda ancora la pagina falsa. Il codice è valido, quindi il login riesce.

L'SMS porta anche rischi telecom. Lo SIM swap e gli attacchi di portabilità permettono a qualcuno di prendere il controllo di un numero di telefono e ricevere i messaggi OTP senza che l'utente se ne accorga fino a quando è troppo tardi. Per account ad alto valore, questo è devastante: un attaccante può resettare password e continuare a riprovare finché non riesce.

Le app di autenticazione sono migliori contro il SIM swap perché non c'è un numero di telefono da rubare. Ma i codici possono comunque essere phishingati usando lo stesso pattern di relay in tempo reale se il tuo login accetta qualsiasi codice valido senza controllare il contesto.

Se vuoi una protezione più forte rispetto ai codici digitati, le approvazioni push possono aiutare, specialmente con il number matching o dettagli chiari come il nome dell'app e la città. La push può comunque essere abusata tramite fatica da approvazione, ma alza la soglia rispetto al digitare un codice a 6 cifre.

Modi pratici per ridurre il rischio di takeover con entrambi i metodi:

• Usa regole step-up per azioni sensibili (cambiare email, dettagli di pagamento, nuovo dispositivo).
• Riesamina l'MFA quando cambiano IP o dispositivo e non lasciare sessioni ad alto rischio attive a lungo.
• Mantieni le schermate di login coerenti con chiari segnali di prodotto così gli utenti notano più rapidamente le pagine false.
• Limita la velocità dei retry sospetti e sfida pattern insoliti (viaggi impossibili, fallimenti rapidi).
• Rendi il recupero più difficile da abusare, specialmente per utenti ad alto valore.

Attrito per l'utente: dove le persone abbandonano il flusso

Le persone raramente mollano perché «odiano la sicurezza». Mollano perché il login è lento, confuso o imprevedibile.

La differenza più grande nell'attrito è il tempo. L'SMS fa aspettare. L'app di autenticazione chiede di impostare qualcosa.

Con l'SMS il flusso al primo accesso è familiare: inserisci il numero, ricevi un codice, lo digiti. L'attrito cresce quando il messaggio non arriva veloce, arriva su un numero vecchio o su un dispositivo che l'utente non ha in mano.

Con un'app di autenticazione, il flusso iniziale ha più passaggi: installare un'app, scansionare un QR, salvare un'opzione di backup e poi inserire un codice. Durante la registrazione o il checkout questo può sembrare troppo.

I momenti più comuni di abbandono sono prevedibili: aspettare 30–90 secondi per un SMS e poi ricevere più codici; errori di digitazione nello switch tra app; cambi di dispositivo (nuovo telefono, telefono ripristinato, telefono di lavoro che non può installare app); problemi di viaggio (roaming, nuova SIM, numero che non riceve messaggi all'estero); e casi in cui l'utente non controlla in modo affidabile il dispositivo del «secondo fattore».

«Ricordami questo dispositivo» riduce l'attrito, ma è facile esagerare. Se non chiedi mai di nuovo, il rischio di takeover aumenta quando qualcuno ruba un laptop. Se chiedi troppo spesso, gli utenti abbandonano o scelgono opzioni di recupero più deboli. Un compromesso pratico è richiedere nuovamente su nuovi dispositivi, dopo azioni sensibili o dopo una finestra temporale ragionevole.

Monitora il funnel. Se il passo 1 (inserisci telefono) va bene ma il passo 2 (inserisci codice) cala bruscamente, sospetta ritardi SMS o confusione sui codici. Se l'abbandono avviene subito dopo la schermata QR, la configurazione è troppo pesante per quel momento.

Ticket di supporto da aspettarsi (e come triaggiarli)

La maggior parte del lavoro di supporto sull'MFA non riguarda la «sicurezza». Riguarda persone bloccate nel momento peggiore: un accesso durante il cambio turno, un reset password prima di una demo o un admin che cerca di inserire un nuovo assunto.

Se confronti SMS OTP vs app di autenticazione, pianifica la coda di supporto attorno ai modi in cui falliscono, non al percorso felice.

Temi comuni dei ticket

Vedrai gli stessi pattern ripetutamente.

Per SMS: «codice non arriva», «arriva in ritardo», «arriva doppio», numero sbagliato, numeri cambiati, blocchi dell'operatore, problemi di roaming e short code filtrati.

Per app di autenticazione: telefono perso, nuovo dispositivo, app reinstallata, «i codici non combaciano», confusione su quale app/account/profilo contiene il codice.

Gli admin apriranno anche ticket di policy e audit: «Utente bloccato, resettare MFA» e «Chi ha resettato l'MFA per questo account?». Questi richiedono un processo chiaro e una traccia documentata.

Cosa raccogliere prima di iniziare il troubleshooting

Un buon modulo di triage fa risparmiare tempo su ogni ticket. Chiedi identificatore account e metodo MFA, timestamp e timezone dell'ultimo tentativo (e se è stato ricevuto un codice), ultimo accesso riuscito con metodo, dettagli del dispositivo (modello e versione OS) e se il dispositivo è cambiato di recente. Per SMS cattura paese e operatore se noti.

Con queste informazioni il supporto può scegliere rapidamente il passo successivo: reinviare (con guardrail), verificare il numero di telefono, aspettare i rate limit o avviare un reset MFA sicuro.

Risposte del supporto che riducono i giri di andata e ritorno

Mantieni le risposte semplici e non accusatorie. Una macro semplice copre la maggior parte dei casi:

“Conferma per favore l'ora in cui hai provato (con il tuo fuso orario) e se hai ricevuto qualche SMS. Se hai cambiato telefono o reinstallato l'app di autenticazione recentemente, indica quando. Se sei bloccato, possiamo resettare l'MFA dopo aver verificato la tua identità.”

Passo dopo passo: scegliere e distribuire l'MFA giusto

Inizia con una domanda onesta: cosa stai proteggendo e da chi? Una newsletter consumer ha un profilo di rischio diverso da payroll, dati sanitari o un pannello admin.

Annota anche i vincoli degli utenti: paesi serviti, frequenza di viaggio, se portano un secondo dispositivo e se possono installare app.

Un piano di rollout che evita incendi nel supporto:

1. Definisci il tuo modello di minaccia e i vincoli. Se phishing e takeover sono preoccupazioni principali, favorisci metodi più difficili da ingannare. Se molti utenti non hanno smartphone o non possono installare app, pianifica alternative.

2. Scegli un metodo di default più un backup. I default dovrebbero funzionare per la maggior parte delle persone dal giorno uno. I backup salvano il supporto quando i telefoni si perdono, i numeri cambiano o gli utenti viaggiano.

3. Progetta registrazione e recupero prima del lancio. Il recupero non dovrebbe dipendere sulla stessa cosa che può fallire (per esempio solo SMS). Decidi come gestirai dispositivo perso, nuovo numero e «non ho mai ricevuto un codice».

4. Distribuisci gradualmente e spiega il motivo in parole semplici. Inizia con i ruoli ad alto rischio (admin, finance) o con una piccola percentuale di utenti.

5. Forma il supporto e traccia i fallimenti. Dai agli agenti un semplice albero decisionale e regole chiare per i controlli d'identità. Monitora fallimenti di consegna, blocchi, tempo di registrazione e richieste di recupero.

Errori comuni e trappole da evitare

La maggior parte dei rollout MFA fallisce per ragioni semplici: la policy è troppo rigida, il recupero è debole o l'interfaccia lascia l'utente nel dubbio.

Una trappola frequente è fare dell'SMS l'unica via di ritorno in un account. I numeri cambiano, le SIM vengono scambiate e alcuni utenti non possono ricevere messaggi mentre viaggiano. Se l'SMS è sia il secondo fattore che il metodo di recupero, alla fine creerai account «bloccati per sempre».

Un altro errore comune è permettere agli utenti di cambiare il loro numero di telefono usando solo una password e un codice SMS inviato al nuovo numero. Questo trasforma una password rubata in un takeover pulito. Per le modifiche sensibili (telefono, email, impostazioni MFA) aggiungi un passo più forte: verifica il fattore esistente, richiedi un recente controllo di sessione o usa un flusso di revisione manuale per i casi ad alto rischio.

Le trappole che generano più dolore evitabile nel supporto tendono ad essere:

• Regole di resend e rate-limit che puniscono utenti reali (troppo rigide) o aiutano gli attaccanti (troppo permissive). Mira a cooldown brevi, testo di conto alla rovescia chiaro e limiti duri con un fallback sicuro.
• Nessuna opzione di recupero oltre il fattore primario. Codici di backup, un secondo dispositivo di autenticazione o un reset assistito dal supporto prevengono i vicoli ciechi.
• Mancanza di strumenti admin per i reset e assenza di traccia d'audit. Il supporto deve vedere quando MFA è stato abilitato, cosa è cambiato e chi l'ha fatto.
• Messaggi di errore che incolpano l'utente. «Codice non valido» senza contesto porta a retry infiniti. Dì cosa provare dopo.
• Trattare i fallimenti ripetuti come «errore utente» invece che come problema di prodotto. Se un certo operatore, paese o modello di dispositivo si correla con i fallimenti, è un pattern risolvibile.

Checklist rapida prima di impegnarti

Metti alla prova il flusso di login come farebbero gli utenti reali: stanchi, in viaggio, cambiando telefono o bloccati cinque minuti prima di una riunione. Il metodo migliore è quello che i tuoi utenti possono completare in modo affidabile e che il tuo team può supportare senza scorciatoie rischiose.

Fatti queste domande:

• Un utente può completare l'MFA senza servizio cellulare o mentre viaggia (modalità aereo, roaming bloccato, SIM cambiata, numero cambiato)?
• Hai un percorso di recupero sicuro e semplice (codici di backup, dispositivi attendibili, recupero limitato nel tempo o un reset verificato dal supporto)?
• Il supporto può verificare l'identità rapidamente senza chiedere dati sensibili (no password complete, no numeri di carta completi) e c'è un playbook documentato per i reset?
• Logghi i tentativi MFA falliti e allerti sui pattern di abuso (molti retry, molti account dallo stesso IP, fallimenti ripetuti dopo reset password)?
• Il testo a schermo è inequivocabile su da dove viene il codice e cosa fare dopo?

Se la risposta è “forse” sul recupero, fermati. La maggior parte dei takeover avviene durante i reset, e la maggior parte degli utenti arrabbiati appare quando il recupero è confuso.

Un test pratico: chiedi a qualcuno fuori dal tuo team di impostare l'MFA, poi di perdere il telefono e provare a rientrare usando solo i passaggi documentati. Se diventa una chat con ingegneria, vedrai lo stesso nei ticket reali.

Scenario esempio: un portale clienti con utenti globali

Un team di 6 persone gestisce un portale clienti usato da 1.200 utenti attivi negli USA, India, Regno Unito e Brasile. Danno accesso anche a 40 contractor che vanno e vengono. I reset password già creano rumore, quindi aggiungono l'MFA sperando di ridurre i takeover senza sovraccaricare il supporto.

Partono con SMS OTP di default. La prima settimana tutto sembra ok finché un ritardo di un operatore colpisce una regione durante le ore di punta. Gli utenti richiedono un codice, aspettano, richiedono di nuovo e poi ricevono tre codici insieme. Alcuni provano il più vecchio, falliscono e si bloccano. Il supporto riceve un'ondata di ticket: «Nessun codice ricevuto», «Il mio codice è sempre sbagliato», «Sto viaggiando e il mio numero è cambiato». Anche senza un outage, i problemi di deliverability emergono per numeri VoIP, utenti in roaming e filtri antispam rigidi.

Aggiungono le app di autenticazione come opzione e notano un pattern diverso. La maggior parte degli accessi è fluida, ma i fallimenti sono più sporadici: un utente aggiorna il telefono e l'app non trasferisce i codici, qualcuno cancella l'autenticatore o un contractor salta il passo “scansiona QR” e resta bloccato. I ticket tipici diventano: «Nuovo telefono, non riesco ad accedere», «I codici non combaciano» e «Ho perso il dispositivo».

Una configurazione che riduce le sorprese spesso somiglia a questa:

• Default su un'app di autenticazione per i nuovi utenti, con SMS come backup (non l'unico metodo).
• Offri codici di recupero e un chiaro flusso per dispositivo perso che attiva controlli manuali.
• Richiedi step-up per azioni rischiose come cambiare dettagli di pagamento o aggiungere un nuovo admin.
• Per i contractor, usa tempi di sessione più brevi e ricontrolla su nuovi dispositivi.

Prossimi passi: implementare l'MFA senza rallentare il prodotto

Scegli un metodo MFA di default che si adatti alla maggior parte dei tuoi utenti, poi aggiungi un backup.

Per un pubblico consumer, l'SMS è spesso il default più semplice, con un'app di autenticazione disponibile per chi viaggia, usa numeri VoIP o vuole più sicurezza. Per un prodotto orientato al workforce o con molti admin, un'app di autenticazione è spesso il default migliore, riservando l'SMS al recupero.

Prima del rollout, scrivi un playbook di supporto semplice e decidi cosa loggare. Non ti serve una montagna di dati. Ti serve abbastanza per rispondere a: l'abbiamo inviato, l'ha ricevuto l'utente e cosa è successo durante la verifica.

Log che ripagano di solito: metodo MFA e timestamp, risposta del provider di consegna (accepted, queued, failed), conteggio dei tentativi di verifica con ultimo motivo d'errore e ultimo metodo MFA riuscito e data.

Rendi il supporto più veloce con una piccola schermata: stato MFA utente, fallimenti recenti e un flusso di reset controllato con traccia di audit.

Se stai costruendo un portale senza troppo sviluppo, AppMaster (appmaster.io) può aiutarti ad assemblare backend, web app e app mobile attorno a questi flussi, incluse le viste admin e il logging degli eventi che riducono le incertezze quando arrivano i ticket.

Rilascia in pilot prima, osserva le metriche di fallimento per una settimana, poi espandi. Monitora tasso di completamento, tasso di resend, tempo per completare l'MFA e volume ticket per 1.000 login. Affina il flusso, aggiorna il playbook e poi scala.