C’è una conversazione che, negli ultimi mesi, si ripete quasi identica in ogni azienda che affianchiamo nel percorso di adeguamento alla NIS2. Il responsabile IT apre l’elenco degli applicativi, si ferma su una riga e dice: «Quello lì non possiamo toccarlo».

Quello lì è quasi sempre lo stesso tipo di sistema: un gestionale installato dieci o quindici anni fa, un portale fornitori scritto da una software house che nel frattempo ha cambiato prodotto, un’area riservata che funziona benissimo e che nessuno ha voglia di rimettere in discussione. Funziona, è in produzione, ci lavorano trenta persone tutti i giorni. E chiede solo username e password.

Il problema di come portare l’MFA su applicazioni legacy è oggi uno dei più concreti che un’organizzazione italiana si trova ad affrontare, ed è anche uno dei meno raccontati. Le linee guida parlano di autenticazione a più fattori come se fosse un interruttore da alzare; nella realtà di chi gestisce un parco applicativo stratificato, quell’interruttore su alcuni sistemi semplicemente non esiste.

In questo articolo mettiamo in fila le cinque strade percorribili per abilitare l’MFA su applicazioni legacy, con i loro costi reali, i tempi e i limiti. Nessuna è perfetta, e la scelta giusta dipende da tre o quattro condizioni che è bene chiarirsi prima di firmare qualsiasi preventivo.

Indice dei contenuti

• Il gestionale che risponde a tutta Internet
• Perché l’MFA su applicazioni legacy è un problema tecnico, non di buona volontà
• Cosa chiede davvero la NIS2 e cosa scade il 31 ottobre 2026
• Cinque soluzioni per portare l’MFA su applicazioni legacy
• Le cinque opzioni a confronto
• Sei domande per scegliere senza sbagliare
• Tre errori che vediamo più spesso
• Checklist operativa in dieci punti
• Domande frequenti

Il gestionale che risponde a tutta Internet

Partiamo da come si è arrivati fin qui, perché non è colpa di nessuno ed è una storia molto comune.

Un applicativo nasce per essere usato in ufficio, sulla rete interna. Poi arriva la necessità di farlo usare anche da casa, dalle filiali, dagli agenti, dal commercialista, dal manutentore esterno. La VPN è scomoda, va installata su ogni dispositivo, qualcuno non riesce a configurarla, il fornitore esterno non vuole un client aziendale sul proprio portatile. Così, quasi sempre in emergenza, si apre una porta sul firewall e si pubblica l’applicativo su Internet. Doveva essere temporaneo. Sono passati sei anni.

Il risultato è che oggi quella pagina di login è visibile da qualunque indirizzo IP del pianeta. Chiunque, da qualunque parte del mondo, può raggiungerla, vedere che tecnologia usa, capire di che prodotto si tratta, cercare le vulnerabilità note di quella versione e provare credenziali a ripetizione. Non serve un attaccante sofisticato: bastano scanner automatici che passano al setaccio interi blocchi di indirizzi ventiquattro ore al giorno.

I numeri dicono che non è uno scenario teorico. Il Rapporto Clusit 2026 ha registrato 507 attacchi gravi in Italia nel corso del 2025, il 42% in più rispetto all’anno precedente, pari al 9,6% degli incidenti mondiali a fronte di un peso economico molto inferiore. Il phishing e l’ingegneria sociale, cioè proprio le tecniche che portano al furto di credenziali, sono cresciuti del 66%.

E qui sta il punto: se l’unica difesa dell’applicativo è la coppia username e password, il furto di una credenziale equivale al furto dell’applicazione intera. Non c’è un secondo ostacolo. È questa la ragione per cui il tema dell’MFA su applicazioni legacy è diventato prioritario: non perché lo chieda una norma, ma perché su quei sistemi manca del tutto la seconda linea di difesa.

Perché l’MFA su applicazioni legacy è un problema tecnico, non di buona volontà

Quando si chiede a un’organizzazione perché non ha attivato l’autenticazione a più fattori su un certo applicativo, la risposta non è mai «non ci interessa». È quasi sempre una di queste quattro, e sono tutte legittime.

• L’applicativo non la prevede. È stato progettato prima che l’MFA diventasse uno standard e non ha alcun punto di aggancio: né SAML, né OIDC, né un plugin, né un webhook. L’autenticazione è cablata nel codice.
• Il codice non è vostro. Il fornitore che lo ha scritto non esiste più, oppure esiste ma ha smesso di sviluppare quel prodotto, oppure sviluppa ancora ma il preventivo per la modifica è fuori scala rispetto al valore residuo dell’applicativo.
• Toccarlo è rischioso. L’applicativo è al centro del ciclo attivo o della produzione. Mettere le mani sul modulo di autenticazione di un sistema che nessuno conosce più nel dettaglio significa rischiare un fermo, e il fermo costa più dell’incidente ipotetico.
• Gli utenti non sono tutti vostri. Agenti, fornitori, consulenti, clienti: persone che non hanno un account aziendale, non sono nel vostro Active Directory e a cui non potete installare né imporre nulla.

È esattamente per questo che il tema dell’MFA su applicazioni legacy richiede un ragionamento diverso da quello che si applica alle applicazioni moderne. Su un software SaaS recente si collega l’identity provider aziendale e si è finito in mezza giornata. Qui l’identity provider non ha nulla a cui collegarsi.

La conseguenza logica è che, se non si può aggiungere un controllo dentro l’applicazione, bisogna metterlo davanti. Tutte le soluzioni serie a questo problema, dalla più artigianale alla più industriale, condividono questa idea: spostare la verifica dell’identità a monte, in un punto che si può governare, lasciando l’applicativo esattamente com’è.

Cosa chiede davvero la NIS2 e cosa scade il 31 ottobre 2026

Fino a due anni fa questo era un tema di igiene informatica. Oggi, per molte organizzazioni italiane, è un obbligo con una data sopra.

Con il D.Lgs. 138/2024 l’Italia ha recepito la direttiva NIS2, e l’Agenzia per la Cybersicurezza Nazionale ha successivamente definito le cosiddette specifiche di base con la determinazione n. 164179 del 14 aprile 2025, poi aggiornata e integrata nel corso del 2025. Il quadro che ne esce è concreto: 37 misure articolate in 87 requisiti per i soggetti importanti, 43 misure e 116 requisiti per quelli essenziali.

Fra gli ambiti coperti ci sono il controllo degli accessi, la gestione delle identità digitali, l’autenticazione a più fattori, la registrazione e il monitoraggio degli eventi. Tutti e quattro toccano direttamente il tema dell’MFA su applicazioni legacy, perché è proprio su quei sistemi che i requisiti risultano più difficili da soddisfare.

Le date da segnare sono queste:

• Gennaio 2026  è operativo l’obbligo di notifica degli incidenti significativi al CSIRT Italia, con pre-notifica entro 24 ore e notifica completa entro 72 ore.
• 31 ottobre 2026  è il termine per l’attuazione delle misure di sicurezza di base per i soggetti inseriti nell’elenco NIS nel 2025. Per chi è entrato nell’elenco nel 2026 la scadenza è differita al 31 luglio 2027.
• Da novembre 2026 cominciano le verifiche e le attività ispettive dell’Agenzia.

Le sanzioni per la violazione degli obblighi sostanziali arrivano a 10 milioni di euro o al 2% del fatturato mondiale annuo per i soggetti essenziali, e a 7 milioni o all’1,4% per quelli importanti.

C’è però un effetto che riguarda molte più aziende di quante siano formalmente in perimetro, ed è quello che stiamo osservando più spesso sul campo. I soggetti NIS2 devono presidiare la sicurezza della propria catena di fornitura: di conseguenza girano ai propri fornitori questionari e clausole contrattuali che richiedono, fra le altre cose, autenticazione a più fattori e tracciamento degli accessi sui sistemi usati per erogare il servizio. Migliaia di PMI che non hanno alcun obbligo diretto si trovano così a doversi adeguare per non perdere un cliente. È, nella pratica, il motore principale della domanda che vediamo.

Non è più la conformità a spingere l’adeguamento: è il cliente che chiede al fornitore di dimostrare come protegge gli accessi ai sistemi con cui lo serve.

Cinque soluzioni per portare l’MFA su applicazioni legacy

Vediamo ora le strade realmente percorribili per implementare l’MFA su applicazioni legacy, dalla più invasiva alla meno invasiva. Le abbiamo ordinate così perché nella nostra esperienza il fattore che determina il successo di un progetto di questo tipo non è la potenza della tecnologia scelta, ma quanto poco si è dovuto toccare ciò che già funzionava.

1. Modificare l’applicativo

La soluzione teoricamente più pulita: si chiede al fornitore di integrare l’autenticazione a più fattori, o si affida la modifica a una software house.

Quando ha senso: quando l’applicativo è ancora strategico, il fornitore è attivo e collaborativo, e avete davanti diversi anni di vita utile del sistema. In quel caso l’investimento si ammortizza.

I limiti: preventivi che partono da qualche migliaio di euro e superano facilmente le cinque cifre, tempi nell’ordine dei mesi, e la necessità di rifare i test funzionali su tutto il flusso di accesso. Molto spesso, poi, la risposta del fornitore è semplicemente no, perché quella versione non è più in manutenzione evolutiva.

2. Chiudere tutto dietro una VPN

Si toglie l’applicativo da Internet e si obbliga chiunque a entrare prima nella rete aziendale, con MFA sul concentratore VPN.

Quando ha senso: quando gli utenti sono pochi, tutti interni, tutti con dispositivi aziendali gestiti.

I limiti: sono quelli che hanno portato ad aprire la porta sul firewall la prima volta. Serve un client su ogni dispositivo, con tutto il carico di supporto che comporta; i soggetti esterni raramente accettano di installarlo; e soprattutto la VPN concede accesso alla rete, non alla singola applicazione. Chi entra per usare il gestionale si ritrova, dal punto di vista della rete, dentro casa vostra. Per il principio del privilegio minimo è esattamente il contrario di ciò che si vorrebbe.

3. Una piattaforma ZTNA con agent e connector

Le soluzioni Zero Trust Network Access moderne risolvono il difetto principale della VPN: pubblicano la singola applicazione anziché la rete. Funzionano installando un connector all’interno dell’infrastruttura, che stabilisce un tunnel in uscita verso la piattaforma, e spesso un agent sul dispositivo dell’utente.

Quando ha senso: in organizzazioni strutturate, con un identity provider aziendale già in uso, un parco dispositivi gestito e un team IT in grado di seguire la piattaforma.

I limiti: il connector va installato, aggiornato e monitorato, e non sempre l’infrastruttura che ospita l’applicativo lo consente  (si pensi a un hosting gestito da terzi o a un server che il fornitore non vuole vedere modificato). Il costo è tipicamente a utente, quindi cresce con il numero di persone, e gli utenti esterni privi di identità aziendale restano un caso scomodo da gestire.

4. Un reverse proxy con autenticazione, costruito internamente

La strada di chi ha competenze sistemistiche in casa: si mette davanti all’applicativo un proxy ( NGINX, Apache, o un progetto open source dedicato all’autenticazione a monte ) che verifica l’identità prima di inoltrare la richiesta.

Quando ha senso: quando avete personale con quelle competenze, tempo per la manutenzione e un solo applicativo da proteggere.

I limiti: il software è gratuito, il presidio no. Servono aggiornamenti, rinnovo dei certificati, gestione delle sessioni, hardening, monitoraggio e reperibilità: perché quel proxy diventa il punto attraverso cui passa tutto, e se si ferma si ferma l’applicativo. Molte organizzazioni scoprono a distanza di un anno che il costo vero non era la messa in opera, ma il mantenimento.

5. Un gateway di accesso in cloud, senza client e senza tunnel

L’ultima strada è la stessa idea del punto precedente, erogata come servizio e senza nulla da installare da nessuna parte. Il funzionamento è semplice da spiegare a chiunque: l’applicativo resta dov’è e continua a rispondere sulla sua porta, ma sul firewall si autorizzano in ingresso soltanto gli indirizzi IP del gateway. Da quel momento l’applicazione smette di essere visibile al resto di Internet.

Gli utenti raggiungono un indirizzo dell’azienda, superano i controlli sul gateway (verifica dell’identità con secondo fattore, controllo che l’indirizzo e-mail sia effettivamente abilitato a quel servizio, filtri per indirizzo IP e per Paese di provenienza, limiti di frequenza ) e solo dopo vengono inoltrati all’applicativo, che continua a chiedere le proprie credenziali esattamente come prima.

Quando ha senso: quando l’applicativo è web, avete il controllo del firewall e un indirizzo IP pubblico stabile, e volete un risultato in tempi brevi senza aprire un progetto. È anche l’unica opzione praticabile quando fra gli utenti ci sono soggetti esterni a cui non potete installare né imporre nulla.

I limiti, che è giusto dire: copre il traffico web, non protocolli come RDP o SSH; richiede che qualcuno possa modificare le regole del firewall di origine, il che non è scontato con certi hosting condivisi; e una volta chiuso il perimetro il gateway diventa un passaggio obbligato, quindi vanno pretesi livelli di servizio, ridondanza e una procedura di emergenza documentata. Sono domande da fare al fornitore prima di firmare, non dopo.

Le cinque opzioni a confronto

Confronto delle cinque strade praticabili per portare l’MFA su applicazioni legacy.

La tabella non dice quale sia la soluzione migliore, perché non esiste in assoluto. Dice però una cosa utile sull’MFA su applicazioni legacy: le opzioni si differenziano molto meno sul risultato finale, in tutti i casi arrivate ad avere un secondo fattore e un registro degli accessi, e moltissimo sull’impatto delle scelte, spesso ciò che fa naufragare la maggior parte di questi progetti, non la tecnologia.

Sei domande per scegliere senza sbagliare

Prima di valutare qualsiasi prodotto per l’MFA su applicazioni legacy, rispondete a queste sei domande. Nella nostra esperienza determinano la scelta molto più di qualunque confronto per funzionalità.

1. Chi sono gli utenti? Se sono tutti dipendenti con account aziendale, avete più opzioni. Se fra loro ci sono fornitori, agenti o clienti, le soluzioni che presuppongono un identity provider o un agent si escludono da sole.
2. Chi controlla il firewall dell’applicativo? Se la risposta è «un fornitore che risponde in tre settimane», tenetene conto nella pianificazione. Se è «nessuno, è un hosting condiviso», alcune strade non sono percorribili.
3. Quanta vita residua ha l’applicativo? Investire cinque cifre in una modifica su un sistema che sarà dismesso fra due anni è denaro speso male. Un servizio a canone, che si spegne il giorno della dismissione, è più coerente.
4. Quanti applicativi avete nella stessa condizione? Quasi mai è uno solo. Se sono cinque, una soluzione che si replica in mezz’ora ciascuno ha un valore completamente diverso da una che richiede un progetto per volta.
5. Che cosa dovete dimostrare, e a chi? Un auditor, un cliente che vi ha mandato il questionario fornitori, un assicuratore: ognuno chiede evidenze diverse. Verificate che la soluzione produca i registri e i report che vi serviranno, non solo che funzioni.
6. Che cosa succede se il nuovo componente si ferma? È la domanda che quasi nessuno fa in fase di valutazione e che tutti si fanno la prima volta che succede. Pretendete una risposta scritta: livelli di servizio, ridondanza, procedura di ripristino.

Tre errori che vediamo più spesso

Sono i tre inciampi che ricorrono con più frequenza nei progetti di MFA su applicazioni legacy, e hanno in comune il fatto di non emergere subito: si manifestano mesi dopo, di solito nel momento peggiore.

Considerare l’OTP via e-mail come un traguardo

Il codice monouso inviato per posta elettronica è enormemente meglio della sola password, ed è spesso il modo più rapido per coinvolgere utenti esterni che non si vogliono far registrare da nessuna parte. Ma è un fattore debole: se la casella di posta dell’utente è compromessa, cade anche il secondo fattore. Va bene come punto di partenza e come opzione di ripiego; il percorso deve prevedere il passaggio a un’app di autenticazione con codici temporanei o, meglio ancora, alle passkey. Se state valutando una soluzione, chiedete se e quando questo passaggio è supportato.

Proteggere l’ingresso principale e lasciare aperte le porte di servizio

Capita spesso: si mette un controllo davanti al portale, ma l’applicativo resta raggiungibile anche tramite un secondo nome DNS, un vecchio indirizzo IP, una porta alternativa lasciata aperta per il manutentore, o un ambiente di test dimenticato che punta allo stesso database. Il controllo a monte funziona solo se è l’unica via di ingresso. Prima di dichiarare chiuso il progetto, fate una scansione dall’esterno e verificate che non esistano percorsi alternativi.

Dimenticarsi dei log fino al giorno dell’audit

Il secondo fattore risponde a un requisito; il registro di chi ha fatto cosa e quando ne risponde a un altro, ed è quello che vi verrà chiesto per primo in caso di incidente o di verifica. Definite fin dall’inizio quanto a lungo conservare gli accessi, chi può consultarli, e come sono trattati gli indirizzi IP degli utenti  (che sono dati personali, con tutto ciò che ne consegue in termini di informativa e di tempi di conservazione).

Checklist operativa in dieci punti

Se volete affrontare l’MFA su applicazioni legacy con ordine, questa è la sequenza che consigliamo ai nostri clienti.

1. Fate l’inventario di tutto ciò che, dell’azienda, risponde su Internet. Non fidatevi della memoria: usate una scansione dall’esterno sugli indirizzi pubblici e sui domini.
2. Per ciascun servizio segnate chi lo usa, quanti sono, se sono interni o esterni, e chi lo manutiene.
3. Marcate quali supportano nativamente l’autenticazione a più fattori e quali no. La seconda lista è il vostro perimetro di lavoro.
4. Ordinate quella lista per impatto: che cosa succede se qualcuno entra in quel sistema con credenziali rubate.
5. Verificate, per i primi tre della lista, chi ha il controllo del firewall e se l’indirizzo IP pubblico è stabile.
6. Scegliete la strada in base alle sei domande della sezione precedente, non in base al primo prodotto che vi viene mostrato.
7. Partite da un solo servizio, possibilmente non il più critico, e misurate quanto tempo serve davvero.
8. Verificate dall’esterno che non esistano vie di accesso alternative a quel servizio.
9. Definite conservazione dei log, titolarità del trattamento e informativa agli utenti prima di andare in produzione.
10. Documentate tutto in un documento breve: che cosa avete protetto, come, con quali misure e con quali evidenze. È ciò che vi chiederanno, e averlo già pronto vale mezza giornata di lavoro risparmiata a ogni questionario fornitori.  La sequenza consigliata: prima l’inventario di ciò che è esposto, poi la scelta della soluzione.

Domande frequenti sull’MFA su applicazioni legacy

Si può aggiungere l’MFA a un’applicazione senza modificarne il codice?

Sì, ed è la strada che nella maggior parte dei casi conviene. Il controllo dell’identità viene spostato a monte, in un componente che si interpone fra l’utente e l’applicazione: l’applicativo non viene toccato e continua a gestire la propria autenticazione come ha sempre fatto. È il principio su cui si basano i reverse proxy autenticanti, le piattaforme ZTNA e i gateway di accesso in cloud, ed è oggi l’approccio standard all’MFA su applicazioni legacy.

La NIS2 rende l’autenticazione a più fattori obbligatoria?

L’autenticazione a più fattori rientra fra le misure di base definite dall’Agenzia per la Cybersicurezza Nazionale per i soggetti in perimetro NIS, insieme al controllo degli accessi e alla registrazione degli eventi. Il termine per l’attuazione delle misure di base è il 31 ottobre 2026 per i soggetti inseriti nell’elenco nel 2025. Chi non è in perimetro non ha un obbligo diretto, ma spesso si trova a doverla adottare comunque perché richiesta contrattualmente dai propri clienti soggetti alla normativa.

Il codice via e-mail o via SMS è sufficiente come secondo fattore?

È molto meglio della sola password e in alcuni contesti è l’unica opzione praticabile, per esempio con utenti esterni occasionali. Va però considerato un fattore debole, perché dipende dalla sicurezza di un canale che non controllate. Per gli account con privilegi elevati e per i sistemi che trattano dati critici è opportuno prevedere codici generati da un’app di autenticazione o, meglio, le passkey.

Quanto costa mettere in sicurezza un gestionale esposto su Internet?

Dipende dalla strada scelta e la forbice è ampia. La modifica dell’applicativo parte tipicamente da qualche migliaio di euro una tantum. Le piattaforme ZTNA hanno un costo per utente al mese, quindi crescono con il numero di persone. Un reverse proxy costruito internamente non ha costo di licenza ma ha un costo di presidio continuativo che va stimato onestamente. I gateway di accesso in cloud hanno un canone per servizio protetto, che è la formula più prevedibile quando gli utenti sono molti o variabili.

Quanto tempo serve per proteggere un applicativo?

Se la strada scelta richiede di modificare il software, si ragiona in mesi. Se richiede di installare un componente sull’infrastruttura, in settimane. Se richiede soltanto una regola di firewall e un record DNS, si ragiona in ore. La differenza non è nel risultato finale ma in quanto va toccato per ottenerlo.

Che differenza c’è fra una VPN e un gateway di accesso applicativo?

La VPN concede accesso alla rete: chi entra può, dal punto di vista della raggiungibilità, vedere molto più della singola applicazione per cui è entrato. Un gateway di accesso pubblica invece la singola applicazione e nient’altro, senza richiedere alcun software sul dispositivo dell’utente. Per il principio del privilegio minimo, e per la gestione di utenti esterni, la seconda impostazione è quasi sempre preferibile.

In sintesi

Il problema dell’MFA su applicazioni legacy non si risolve convincendo qualcuno a fare qualcosa che non vuole fare: si risolve accettando che certi applicativi non si toccheranno mai e spostando il controllo dove il controllo è possibile, cioè davanti.

Le cinque strade che abbiamo descritto per l’MFA su applicazioni legacy portano tutte allo stesso risultato sostanziale: un secondo fattore prima dell’accesso e un registro di chi entra, ma con costi, tempi e attrito radicalmente diversi. La scelta giusta è quella che, nella vostra situazione specifica, richiede di modificare il minor numero di cose che oggi funzionano.

E vale la pena ricordare che la scadenza del 31 ottobre 2026 non riguarda soltanto chi è formalmente in perimetro NIS2: riguarda, di fatto, chiunque fornisca servizi a un’organizzazione che lo è.

Vuoi capire da dove partire?

In Mirium affianchiamo aziende ed enti nell’analisi della propria superficie esposta, nei progetti di MFA su applicazioni legacy e nella messa in sicurezza degli accessi applicativi, con un approccio che parte sempre dall’inventario di ciò che è realmente raggiungibile dall’esterno.

Per i casi in cui l’applicativo non può essere modificato abbiamo sviluppato Gate443, un gateway di accesso in cloud che si configura con una regola di firewall e un record DNS: nessun software da installare sui dispositivi degli utenti, nessun connector sull’infrastruttura, nessuna modifica all’applicazione. Include verifica dell’identità con secondo fattore, filtri per indirizzo IP e per Paese, limiti di frequenza, ban automatici e registro degli accessi con conservazione configurabile.

Scopri come funziona Gate443 oppure scrivici per una valutazione gratuita della tua superficie esposta: in mezz’ora di call capiamo insieme quali dei tuoi servizi sono raggiungibili da Internet e quale strada ha senso per ciascuno.