«Devi aggiornare la passkey»: quando il falso helpdesk apre la porta al cloud aziendale

Quando la sicurezza diventa un’esca

«Buongiorno, siamo dell’assistenza informatica. Devi aggiornare subito l’accesso, altrimenti il tuo account verrà bloccato». È una richiesta credibile, soprattutto mentre l’azienda introduce nuovi strumenti di sicurezza. Proprio questa familiarità può trasformare una telefonata apparentemente ordinaria nell’inizio di un incidente.

Il 9 settembre 2026 Microsoft Security Research ha descritto intrusioni cloud osservate da maggio, nelle quali gli attaccanti usavano riferimenti a passkey e accesso unico per convincere le persone a seguire procedure fraudolente. Secondo Microsoft, l’esca poteva indirizzare verso pagine di phishing con intermediazione dell’autenticazione oppure verso flussi di autorizzazione tramite codice dispositivo. Il riferimento alle passkey era un pretesto: il rapporto non dimostra una compromissione del protocollo crittografico delle passkey. [1]

Proteggere l’intero ciclo di vita dell’account

Il punto tecnico confermato. Le linee guida NIST distinguono l’autenticazione resistente al phishing dai codici che l’utente può digitare su un sito contraffatto. Un codice temporaneo inserito manualmente non offre, da solo, quella resistenza. Occorre però distinguere la protezione del singolo accesso dalla sicurezza dell’intero ciclo di vita dell’account. [2]

La nostra analisi operativa parte da qui. Un’azienda dovrebbe verificare almeno quattro percorsi: accesso ordinario, registrazione di un nuovo autenticatore, recupero dell’account e assistenza agli utenti. Proteggere il primo lasciando ambigui gli altri significa conservare margini di manovra per l’ingegneria sociale.

Consideriamo uno scenario ipotetico. Un’impiegata riceve una chiamata durante la chiusura mensile. L’interlocutore conosce il nome del responsabile IT e cita una migrazione realmente in corso. Chiede di aprire un collegamento e completare una verifica. La pressione nasce dalla combinazione di urgenza, informazioni plausibili e timore di interrompere il lavoro. La risposta organizzativa deve rendere semplice interrompere quella sequenza.

Un’assistenza riconoscibile e verificabile

La prima misura proposta è un canale di assistenza riconoscibile. Ogni richiesta che modifica credenziali, metodi di autenticazione o autorizzazioni dovrebbe poter essere verificata aprendo autonomamente il portale aziendale o richiamando un numero già noto. Il recapito contenuto nel messaggio sospetto non dovrebbe diventare la fonte della verifica. Anche l’helpdesk deve conoscere questa regola e applicarla senza eccezioni informali.

La seconda misura riguarda la pianificazione delle migrazioni. Prima di introdurre passkey o nuovi sistemi di accesso, conviene comunicare tempi, schermate previste e azioni richieste. Un avviso utile spiega anche come riconoscere una richiesta anomala. «Stiamo migliorando la sicurezza» è troppo generico; «la registrazione avverrà dal portale interno e sarà associata a questa campagna» offre un riferimento controllabile.

La terza misura è una revisione tecnica dei percorsi alternativi. Per ogni applicazione critica, suggeriamo di registrare il metodo principale, le alternative consentite e chi può modificarle. Le eccezioni dovrebbero avere responsabile, motivazione e data di riesame. Un progetto pilota può coinvolgere prima amministratori, assistenza e un piccolo gruppo operativo, così da individuare problemi reali prima dell’estensione.

Monitoraggio, esercitazioni e indicatori

Occorre poi preparare il monitoraggio. La nostra proposta è collegare gli eventi di autenticazione con i cambiamenti dell’account e con gli accessi ai dati. Un’attività insolita acquista significato quando viene letta nella sua sequenza. Prima di acquistare nuovi strumenti, l’azienda dovrebbe sapere quali registri possiede, chi li consulta e quanto rapidamente può avviare un’indagine.

Anche la risposta va provata. In un’esercitazione interna si può simulare la segnalazione di una falsa telefonata, verificando chi prende in carico il caso, quali evidenze conserva e come coinvolge il responsabile della sicurezza. L’obiettivo proposto è misurare la capacità di riconoscere e contenere l’evento, senza trasformare la simulazione in una valutazione punitiva del dipendente.

Per la direzione, tre indicatori possono rendere concreto il progetto: copertura dei metodi resistenti al phishing sugli account prioritari, numero di eccezioni ancora aperte e tempo necessario a gestire una segnalazione. Sono indicatori suggeriti da DM Web Solution, da adattare all’organizzazione.

La decisione aziendale consiste quindi nel progettare insieme tecnologia e assistenza. Un accesso robusto, accompagnato da procedure comprensibili e verificabili, permette alle persone di lavorare con maggiore fiducia e offre al reparto IT una base migliore per riconoscere gli abusi.