Nel gennaio 2026 l’FBI ha avviato l’operazione Winter SHIELD, e la prima azione raccomandata recita: adottare metodi resistenti al phishing, «chiavi di sicurezza conformi a FIDO2 o passkey legate al dispositivo», per l’autenticazione, l’accesso remoto e i sistemi critici (FBI). Le linee guida ENISA per l’attuazione di NIS2 dicono lo stesso per le VPN e i sistemi di amministrazione: «ove possibile, usare un’MFA resistente al phishing» (ENISA, giugno 2025). La stessa documentazione Microsoft descrive ormai l’MFA via SMS e tramite app di autenticazione come «esposta ad attacchi di phishing remoto» (Microsoft).
Se il vostro accesso remoto è un concentratore VPN che verifica gli accessi tramite RADIUS, probabilmente avete già notato il problema: non c’è alcun punto in cui inserire una passkey. Questo articolo spiega perché, quali sono le tre opzioni realistiche e da che cosa ciascuna di esse non protegge.
Che cosa fa davvero una passkey
Una passkey è una credenziale WebAuthn: una coppia di chiavi generata sul dispositivo dell’utente e registrata presso un singolo sito web. Quando l’utente accede, il browser chiede al dispositivo di firmare una sfida (challenge) inviata dal sito, e la firma copre l’origin, cioè l’origine della pagina che il browser sta effettivamente mostrando. Il sito verifica che l’origin nella firma sia il proprio. Una pagina di login falsa su un altro dominio ottiene una firma per l’origin sbagliato, e il sito reale la rifiuta. L’utente non deve accorgersi di nulla, perché il controllo lo fa il browser (W3C WebAuthn).
È questo che gli standard intendono per «resistente al phishing». L’attuale definizione del NIST è «la capacità del protocollo di autenticazione di impedire la divulgazione dei segreti di autenticazione … senza fare affidamento sulla vigilanza di chi si autentica» (“the ability of the authentication protocol to prevent the disclosure of authentication secrets … without relying on the vigilance of the claimant”), ed è esplicita su che cosa non supera la prova: password, codici monouso, approvazioni push e tutto ciò che l’utente deve ricopiare sono «non resistenti al phishing» (“not phishing-resistant”) (NIST SP 800-63B-4, 2025). La CISA classifica i metodi nello stesso ordine: FIDO/WebAuthn e PKI in cima, poi i codici monouso e il push con number matching, poi il push senza, infine gli SMS (CISA).
Per una VPN contano due aspetti del modo in cui una passkey soddisfa quella definizione. La protezione viene da un client browser o di piattaforma che sa con quale origin sta parlando, e da una sfida e una firma che viaggiano all’interno del protocollo di accesso.
Perché una VPN RADIUS non ha dove metterla
RADIUS, il protocollo con cui la maggior parte dei gateway VPN chiede a un server di autenticazione «questo accesso è valido?», è stato progettato per i modem dial-up. Un Access-Request trasporta un nome utente e una password offuscata con un keystream MD5, oppure una risposta CHAP. Se il server vuole di più, invia un Access-Challenge il cui testo il gateway «PUÒ mostrare» (“MAY display”) all’utente, che poi digita una risposta che torna indietro nel campo password (RFC 2865). Questo è tutto il vocabolario: stringhe digitate da una persona. Non c’è alcun campo per un’asserzione WebAuthn firmata, nessun origin da firmare perché un client VPN non ha una pagina, e nessuno user agent che lo faccia rispettare.
Da soli, dunque, nessuno di questi può usare le passkey per l’accesso VPN:
- MikroTik RouterOS: solo client RADIUS, niente SAML né OIDC (documentazione MikroTik).
- WireGuard: autentica i peer con chiavi pubbliche statiche e non ha alcun login utente, quindi nessuna delle opzioni qui sotto si applica; il problema, lì, è la distribuzione delle chiavi (wireguard.com).
- OpenVPN Access Server: con RADIUS, LDAP o PAM il secondo fattore è un codice temporizzato, e solo la sua modalità SAML può affidare l’accesso a un browser (documentazione OpenVPN).
FortiGate, Palo Alto GlobalProtect e Cisco Secure Client offrono le passkey per l’accesso VPN, e tutti e tre lo fanno nello stesso modo: il client VPN apre un browser, il browser accede a un identity provider SAML, la passkey viene usata lì, e l’IdP comunica al gateway che l’utente è autorizzato. FortiClient lo fa con l’opzione «external browser as user agent», Cisco ASA dalla versione 9.17 avvia il browser di sistema proprio per questo motivo, e GlobalProtect integra una vista browser nel client (Fortinet, Duo per Cisco ASA, Palo Alto). Il percorso RADIUS della stessa Microsoft lo dice chiaramente: l’estensione NPS non può fare number matching, e MS-CHAPv2 non può trasportare un codice temporizzato (Microsoft).
La passkey non tocca mai RADIUS. Il lavoro lo fa il browser, e il gateway si fida della parola dell’IdP.
Le tre opzioni realistiche
1. Mettere un identity provider SAML davanti alla VPN e usare lì le passkey
Questa via offre la resistenza al phishing in senso stretto per gli accessi VPN degli utenti e, se il vostro gateway e i vostri client la supportano, è la risposta giusta per la parte del problema che passa da un browser.
Che cosa costa: un identity provider che supporti le passkey e la licenza che ne consegue, versioni dei client abbastanza recenti per il SAML con browser esterno, la distribuzione delle passkey a ogni utente VPN e una procedura di recupero per i dispositivi smarriti. Che cosa lascia scoperto: ogni sistema che non può fare SAML, compreso, su molti dispositivi, l’accesso amministrativo al firewall stesso, MikroTik, WireGuard e tutto ciò che accede senza un browser.
2. Certificati
L’autenticazione con certificato client (EAP-TLS sulla VPN, o certificati macchina sul dispositivo) è l’altro metodo che il NIST considera resistente al phishing, attraverso quello che chiama channel binding (NIST). Non c’è nulla da digitare per l’utente e nulla da inoltrare.
Che cosa costa: un’autorità di certificazione, l’enrolment di ogni dispositivo, rinnovo e revoca che funzionino davvero, e qualcuno che si faccia carico di tutto questo. La CISA descrive l’MFA basata su PKI come un metodo che richiede «pratiche di gestione delle identità molto mature» e osserva che non è ampiamente supportato (CISA). E un certificato macchina dimostra quale dispositivo si è connesso, non chi era seduto davanti.
3. Mantenere RADIUS e aggiungere un’approvazione sul telefono che mostri l’accesso
La terza via lascia il gateway e il server RADIUS esattamente come sono e aggiunge un secondo passaggio nel percorso RADIUS: il vostro server RADIUS verifica prima la password, e solo dopo che ha accettato l’accesso l’utente riceve una richiesta di approvazione sul telefono. La richiesta indica il servizio, l’account e l’indirizzo IP di provenienza, e l’accesso riesce solo se l’utente approva. È ciò che fa l’auth-proxy Notakey; la guida all’installazione la illustra passo passo per FreeRADIUS, NPS e lo User Manager di MikroTik.
È la via più economica da mettere in opera, perché sul gateway non cambia nulla tranne la destinazione a cui invia RADIUS, e funziona su qualsiasi gateway che verifichi gli accessi tramite RADIUS, compresi quelli che non parleranno mai SAML. È anche la via che dobbiamo descrivere con la massima cautela.
Che cosa ferma. Una password trapelata, provata in massa o craccata non basta più per accedere. FortiBleed, la campagna del 2026 contro le VPN FortiGate, non ha avuto bisogno di altro (la nostra analisi). L’intercettazione degli SMS e il SIM swap non si applicano, perché non c’è alcun codice. Il push-bombing ha fatto entrare gli attaccanti nelle VPN di Cisco e di Uber nel 2022: hanno inviato richieste di approvazione finché qualcuno non ha toccato «sì» (Cisco Talos, Uber). Qui si scontra con una scheda che mostra quale account sta accedendo a quale servizio e da dove, e con un limitatore di frequenza sul server (come).
Che cosa non ferma. Non ferma un inoltro in tempo reale, in cui un portale VPN falso ritrasmette l’accesso reale della vittima e la vittima approva la propria sessione sulla connessione dell’attaccante. La scheda di approvazione mostra l’indirizzo IP di provenienza, quindi l’inoltro è visibile a un utente che guarda, ma la protezione dipende dal fatto che l’utente guardi, e la definizione del NIST esclude esattamente quel tipo di affidamento. L’approvazione push non è resistente al phishing nel senso della CISA, con o senza number matching, e lo diciamo sulla nostra pagina sulla sicurezza invece di appropriarci dell’etichetta.
Com’erano fatte davvero le violazioni
È utile verificare le opzioni rispetto al modo in cui VPN e accessi remoti sono stati davvero violati, piuttosto che rispetto a un modello di minaccia.
| Incidente | Come è entrato l’attaccante | Quale opzione lo avrebbe fermato |
|---|---|---|
| Colonial Pipeline, 2021 | Un account VPN legacy con una password e nessun secondo fattore (testimonianza) | Una qualsiasi delle tre |
| Change Healthcare, 2024 | Un portale di accesso remoto Citrix senza MFA (testimonianza) | Una qualsiasi delle tre |
| FortiBleed, 2026 | Password FortiGate provate in massa, trapelate e craccate (FBI/USSS) | Una qualsiasi delle tre |
| Cisco, Uber, 2022 | Password rubata, poi richieste push finché una non è stata accettata | Passkey, certificati; un’approvazione leggibile mostra la richiesta che nessuno ha avviato |
| Scattered Spider, 2023 | Pagine SSO false, SIM swap, push-bombing contro VPN e webmail (CISA AA23-320A) | Passkey e certificati, senza riserve; l’approvazione rende visibile l’inoltro |
| 0ktapus, 2022 | Pagine Okta false che inoltravano password e codici monouso in tempo reale (Cloudflare) | Solo passkey e certificati |
Tre dei sei casi non hanno richiesto alcun aggiramento dell’MFA: l’MFA non c’era. La lettura onesta della tabella è che il divario tra «solo password» e «un qualsiasi secondo fattore» resta il punto in cui si concentra la maggior parte dei danni, e che il divario tra un’approvazione leggibile e una passkey conta soprattutto per gli account che un attaccante determinato inoltrerà in tempo reale.
Come decidere
- Account amministrativi di firewall e gateway. Sono gli account che FortiBleed ha preso di mira e quelli a cui Winter SHIELD dice di dare la priorità. Se l’interfaccia di gestione supporta chiavi FIDO2 o un accesso SAML con passkey, usateli. Se parla solo RADIUS, un’approvazione sul telefono all’accesso amministrativo è molto meglio di una password da sola, e ancor più di una password condivisa.
- VPN utente su un gateway che può fare SAML con browser esterno. Mettete le passkey presso l’identity provider. È la risposta rigorosa, ed è disponibile oggi su FortiGate, GlobalProtect e Cisco.
- VPN utente su apparati solo RADIUS, come MikroTik o concentratori legacy. La scelta è tra certificati e approvazione sul telefono. I certificati vincono sulla resistenza al phishing se gestite già una PKI. Se non la gestite, un’approvazione leggibile fa sì che una password da sola non basti più per accedere e sostituisce già oggi i codici SMS e le richieste push alla cieca; gli accessi che passano da un browser potrete comunque spostarli in seguito sulle passkey.
- Qualunque cosa scegliate, guardate l’intero percorso. L’intrusione del 2022 in Cisco è partita da un account Google personale che sincronizzava una password di lavoro; la VPN è stata il secondo passo. Se l’MFA protegge la VPN ma non la webmail o il desktop remoto, l’attaccante si sposta semplicemente nella stanza accanto.
Notakey copre la terza via, e diciamo chiaramente dove si colloca nella scala della CISA. Se il vostro gateway parla RADIUS, la guida alla 2FA per VPN vi porta alla prima approvazione sul telefono in un pomeriggio, e l’appliance funziona sulla vostra infrastruttura o nel nostro cloud. Provate la demo dal vivo per vedere com’è un’approvazione leggibile sul vostro telefono, oppure richiedete una demo e mapperemo i vostri accessi VPN, quelli amministrativi al firewall e quelli al desktop remoto su un progetto pilota.