• Guide, Sicurezza, Sistemi Operativi
• 19 Maggio 2026

Ogni volta che arriva una nuova funzionalità nel mondo IT, qualcuno sente il bisogno di organizzare un funerale.

È morta la VPN. È morto l’on-premises. È morto il file server. È morto Active Directory. È morto tutto, praticamente. Tranne il ticket aperto il lunedì mattina perché l’utente non riesce ad accedere alla cartella condivisa.

SMB over QUIC rientra perfettamente in questa categoria di tecnologie che rischiano di essere raccontate male. Da una parte può essere banalizzata come “SMB su Internet”, che suona più o meno come “pubblichiamo TCP/445 e speriamo nella benevolenza dell’universo”. Dall’altra può essere venduta come alternativa definitiva alla VPN, con la solita leggerezza con cui nel nostro settore si dichiara superato qualcosa che, nella realtà, continua a funzionare e a essere usato tutti i giorni.

La verità, come spesso accade, è meno comoda ma molto più interessante.

SMB over QUIC non è una VPN general purpose. Non nasce per portare un client dentro una rete aziendaleF e non sostituisce tutti gli scenari in cui oggi viene utilizzata una VPN. È invece una modalità moderna per consentire l’accesso a file share SMB attraverso reti non attendibili, come Internet, senza esporre il tradizionale traffico SMB su TCP/445.

In altre parole: non elimina la VPN. Elimina, in alcuni casi, la necessità di usare una VPN solo per aprire una share.

E questa distinzione è fondamentale.

Il problema storico: SMB e reti non attendibili

SMB è uno dei protocolli più importanti nell’ecosistema Windows. È alla base dell’accesso a file share, cartelle condivise, risorse di rete e molte operazioni quotidiane in ambienti aziendali.

Proprio per questo, SMB è anche uno di quei protocolli che gli amministratori hanno imparato a trattare con rispetto. E con una certa dose di prudenza.

Esporre direttamente SMB su Internet, in particolare TCP/445, non è mai stata una buona idea. Non perché SMB sia “il male”, ma perché è un protocollo potente, profondamente integrato con autenticazione, autorizzazioni, identità, sessioni utente e risorse aziendali.

Per anni la soluzione più comune è stata semplice: se un utente remoto deve accedere a una share, prima si connette in VPN e poi accede al file server come se fosse in rete aziendale.

Funziona. Ma non sempre è elegante.

La VPN, infatti, è spesso usata come grande scorciatoia infrastrutturale. Serve una share? VPN. Serve un gestionale? VPN. Serve un’applicazione legacy? VPN. Serve stampare su una stampante del 2011 che nessuno osa spegnere? VPN. A un certo punto la VPN smette di essere una scelta architetturale e diventa una botola: ci si butta dentro tutto.

SMB over QUIC prova a risolvere un problema più specifico: consentire l’accesso sicuro a SMB da reti non attendibili, usando QUIC su UDP/443 e TLS 1.3, senza richiedere l’esposizione di TCP/445.

Che cos’è SMB over QUIC

SMB over QUIC introduce un trasporto alternativo per SMB.

SMB resta SMB.

Cambiano il modo in cui il traffico viaggia sulla rete e il modello con cui il file server può essere raggiunto da client esterni.

Tradizionalmente SMB usa TCP/445. Con SMB over QUIC, invece, il traffico SMB viene trasportato all’interno di un tunnel QUIC cifrato con TLS 1.3, normalmente su UDP/443.

Questo significa che il client continua a usare un percorso UNC, continua ad accedere alla share, continua a incontrare autorizzazioni NTFS, permessi di condivisione, autenticazione e logiche SMB. L’esperienza applicativa non diventa improvvisamente “cloud native”. Non c’è una bacchetta magica. C’è SMB che viaggia su un trasporto più adatto a scenari moderni e reti non attendibili.

Dal punto di vista dell’utente, l’obiettivo è semplice: accedere alla share.

Dal punto di vista dell’amministratore, invece, il cambiamento è più interessante: non è necessario pubblicare TCP/445 verso Internet, il traffico SMB non è esposto direttamente alla rete sottostante e la connessione viene stabilita usando UDP/443, molto più compatibile con firewall, NAT e scenari di accesso remoto.

È per questo che Microsoft descrive SMB over QUIC come una sorta di “SMB VPN”. La definizione è efficace, ma va maneggiata con cautela. Perché una “SMB VPN” non è una VPN aziendale completa. È un modo per raggiungere SMB in maniera più sicura e controllata.

QUIC in breve: perché è rilevante

QUIC è un protocollo di trasporto moderno, standardizzato, costruito sopra UDP e progettato per migliorare diversi aspetti storicamente associati a TCP e TLS.

Nel caso di SMB over QUIC, gli aspetti rilevanti sono soprattutto:

• cifratura del traffico tramite TLS 1.3;
• handshake autenticato;
• migliore gestione di perdita pacchetti e congestione rispetto ad alcuni scenari TCP tradizionali;
• maggiore tolleranza ai cambiamenti di indirizzo IP o porta del client;
• utilizzo di UDP/443, spesso più facilmente attraversabile rispetto a TCP/445.

Il punto non è che QUIC renda automaticamente tutto più veloce in ogni scenario. Questo sarebbe il solito entusiasmo da brochure. Il punto è che QUIC nasce per reti moderne, mobili, discontinue, attraversate da NAT, firewall e cambi di connettività.

Esattamente il tipo di mondo in cui oggi vivono molti client aziendali.

Prerequisiti:

SMB over QUIC è interessante, ma non è una funzionalità da attivare con due clic distratti.

Per usarlo servono prerequisiti chiari.

Sul lato server è necessario Windows Server 2025 oppure Windows Server 2022 Datacenter: Azure Edition. La novità importante è che con Windows Server 2025 il tema diventa più concreto anche fuori dagli scenari strettamente legati ad Azure Edition, perché SMB over QUIC è disponibile sulle edizioni di Windows Server 2025.

Sul lato client è richiesto Windows 11.

Serve poi una PKI o un certificato rilasciato da una Certification Authority attendibile. Il certificato del server è un elemento centrale perché viene usato per stabilire il tunnel TLS 1.3. Non è un dettaglio decorativo, è parte dell’architettura di fiducia.

Il certificato deve includere i nomi DNS con cui i client raggiungeranno il file server. Il nome usato dal client deve corrispondere a quanto previsto dal certificato. Niente scorciatoie basate su indirizzi IP, soprattutto negli scenari con NAT o pubblicazione verso Internet.

A livello di rete, per impostazione predefinita SMB over QUIC utilizza UDP/443 in ingresso verso il file server. TCP/445 non deve essere esposto verso Internet. Questo è uno dei messaggi più importanti dell’intero articolo: SMB over QUIC non è una scusa elegante per pubblicare SMB male. È un modo per evitare proprio quel modello.

Serve infine ragionare sull’identità. Microsoft raccomanda l’uso in ambienti Active Directory, anche se esistono scenari con server in workgroup e credenziali locali. In un contesto aziendale reale, però, la parte identità va progettata con particolare attenzione, soprattutto se si vuole evitare di creare nuove dipendenze da NTLM.

Esempio di template di un certificato

Possiamo utilizzare una copia del template WebServer, configurato come segue:

Figura 1 – Nuovo template

Figura 2 – Configurazione template

Figura 3 – Definzione identifier certificato

Figura 4 – Configurazione Key Usage certificato

Figura 5 – Definizione permessi

Figura 6 – Procedura di Enroll

Figura 7 – Procedura di Enroll

Figura 8 – Scelta template certificato

Figura 9 – Configurazione CN e DNS

Figura 10 – Conclusione procedura di Enroll

Figura 11 – Verifica certificato

Figura 12 – Verifica Key Usage certificato installato

Attenzione: autenticazione, NTLM e KDC Proxy

Uno dei punti più importanti, e spesso meno compresi, riguarda l’autenticazione.

Quando un client si trova fuori dalla rete aziendale e non ha accesso a un Domain Controller, l’autenticazione può ricadere su NTLMv2. Il traffico resta comunque all’interno del tunnel QUIC cifrato, quindi non stiamo parlando di credenziali esposte sulla rete esterna in chiaro. Tuttavia, dal punto di vista architetturale, creare nuove dipendenze da NTLM non è esattamente il sogno di chi si occupa di sicurezza moderna.

Per questo Microsoft raccomanda l’uso di Kerberos e supporta lo scenario con KDC Proxy.

Il KDC Proxy consente al client di ottenere ticket Kerberos comunicando attraverso HTTPS, rendendo possibile l’autenticazione Kerberos anche quando il client non ha accesso diretto ai Domain Controller interni.

In laboratorio si può anche far funzionare tutto rapidamente. In produzione bisogna chiedersi:

• come autenticano gli utenti?
• quali credenziali vengono usate?
• il file server raggiunge correttamente i Domain Controller?
• vogliamo accettare NTLM in questo scenario?
• abbiamo progettato KDC Proxy?
• come gestiamo lockout, password spray, MFA o passwordless?

Perché il problema non è montare una share. Quello lo si riesce a fare.

Il problema è farlo senza introdurre una nuova scorciatoia che tra sei mesi qualcuno dovrà chiamare “debito tecnico”, cioè quel nome particolare che diamo agli errori quando sono sopravvissuti abbastanza a lungo.

Configurazione di base con PowerShell

In Windows Server 2025 la configurazione di SMB over QUIC va affrontata tramite PowerShell. Questo è un aspetto importante anche dal punto di vista operativo, perché consente di documentare, automatizzare e rendere ripetibile la configurazione.

Uno schema semplificato può essere questo.

Sulla VM FS01:

Figura 13 – Configurazione accesso alla directory

Sul Client

La differenza tra “funziona” e “funziona come vogliamo noi” sta nella validazione.

Bisogna verificare che il client raggiunga la share tramite QUIC, che TCP/445 non sia accessibile dall’esterno, che il certificato sia corretto, che il nome DNS usato dal client corrisponda al certificato e che gli eventi lato client/server confermino il comportamento atteso.

Come verifichiamo che tutto è andato a buon fine?

L’auditing SMB over QUIC con evento 30832 nel log Microsoft-Windows-SMBClient/Connectivity è disponibile dal client Windows 11 versione 24H2. Su 23H2 (come nel caso del mio lab) l’assenza dell’evento è normale e non dimostra che QUIC non stia funzionando. Microsoft documenta anche che il client SMB usa TCP di default e usa QUIC se TCP fallisce oppure se lo forzi con /TRANSPORT:QUIC o New-SmbMapping -TransportType QUIC.

Uso, quindi, pktmon, già presente in Windows, per verificare la tipologia di pacchetto che sta transitando quando accedo via QUIC alla share:

Sul client:

Figura 14 – Verifica accesso tramite QUIC

Figura 15 – Esempio analisi pacchetti transitati

Figura 16 – Scrittura di un file in FS01 tramite QUIC

Il log mostra chiaramente che la connessione verso la VM FS01 è avvenuta tramite porta UDP 443.

Client Access Control

Un’altra funzionalità molto interessante è il controllo di accesso client per SMB over QUIC.

Questo meccanismo consente di restringere quali client possono stabilire connessioni SMB over QUIC verso il server, usando certificati client e liste di allow/deny.

Il punto è importante: non sostituisce l’autenticazione SMB e non cambia i permessi NTFS o di condivisione. Aggiunge però un ulteriore livello di controllo prima ancora che il client possa stabilire il tunnel QUIC.

In pratica, il server può richiedere al client una catena certificati valida e attendibile. Poi può verificare se quel certificato, o la CA che lo ha emesso, è autorizzato.

Esempio concettuale:

Sul client si può mappare il certificato:

Sul server si può concedere accesso a un certificato specifico usando il suo hash SHA256:

Oppure si può concedere accesso ai certificati emessi da una specifica CA:

Questo è molto interessante in scenari in cui vogliamo esporre il servizio solo a dispositivi gestiti, certificati e sotto controllo aziendale.

Naturalmente introduce anche un tema operativo: lifecycle dei certificati client, revoca, rinnovo, auditing, distribuzione, troubleshooting. La sicurezza non sparisce. Si sposta dove dovrebbe stare: nella progettazione.

Certificati

La gestione dei certificati è uno degli aspetti più delicati.

Il certificato server deve essere valido, attendibile dal client e coerente con il nome DNS usato per raggiungere il file server. Inoltre, il mapping SMB over QUIC è legato al thumbprint del certificato.

Questo significa che al rinnovo del certificato il thumbprint cambia e la configurazione deve essere aggiornata.

È un dettaglio operativo enorme. Perché in molti ambienti il certificato “scade una volta l’anno” fino al giorno in cui scade davvero, di solito durante una finestra temporale in cui tutti scoprono improvvisamente di essere esperti di PKI.

In un progetto reale, quindi, bisogna prevedere:

• monitoraggio della scadenza del certificato;
• procedura di rinnovo;
• aggiornamento del mapping SMB over QUIC;
• test post-rinnovo;
• documentazione operativa;
• ownership chiara tra team sistemi, sicurezza e networking.

SMB over QUIC non elimina la complessità dei certificati. La rende semplicemente parte esplicita dell’architettura.

Che, tutto sommato, è già un passo avanti rispetto al fingere che i certificati siano solo “file da importare”.

Dove SMB over QUIC ha davvero senso

SMB over QUIC ha senso quando il requisito è preciso: dare accesso a file share SMB da reti non attendibili, riducendo o eliminando la necessità di una VPN per quello specifico caso d’uso.

Gli scenari più interessanti sono:

• utenti remoti che devono accedere a file share aziendali specifiche;
• file server collocati in sedi periferiche o ambienti edge;
• organizzazioni che vogliono ridurre l’esposizione di TCP/445;
• ambienti in cui la VPN è usata solo per raggiungere alcune condivisioni;
• accesso controllato da dispositivi gestiti tramite certificati client;
• scenari in cui si vuole mantenere SMB senza spostare immediatamente tutto su piattaforme documentali cloud.

È particolarmente utile quando l’alternativa sarebbe una VPN molto ampia per un bisogno molto piccolo.

Se l’utente deve solo accedere a una share, dargli una VPN completa può essere eccessivo. È come dare le chiavi dell’edificio a qualcuno che deve solo ritirare una busta alla reception.

Magari funziona. Ma forse possiamo fare meglio.

Dove SMB over QUIC non è la risposta

SMB over QUIC non è una soluzione universale.

Non sostituisce una VPN quando il client deve accedere a più servizi interni, applicazioni legacy, sistemi client/server, interfacce amministrative, database, tool gestionali, jump server o ambienti complessi.

Non trasforma automaticamente un file server tradizionale in una piattaforma moderna di collaborazione documentale.

Non sostituisce SharePoint, OneDrive, Azure Files, Azure Virtual Desktop, Windows 365, soluzioni ZTNA o SASE quando quelle sono più adatte al requisito.

Non risolve problemi di governance del dato, classificazione, Data Loss Prevention, versioning, retention, backup, replica o controllo degli accessi mal progettato.

Non rende performante qualsiasi applicazione che usa file su rete. Se abbiamo un’applicazione legacy che apre migliaia di piccoli file, usa lock aggressivi o pretende latenze da LAN anni Novanta, SMB over QUIC non la farà diventare moderna. Al massimo le offrirà un viaggio più elegante verso la stessa sofferenza.

In sintesi: SMB over QUIC è un ottimo strumento per alcuni scenari.

Tabella di valutazione pratica

Aspetti di sicurezza da non ignorare

SMB over QUIC riduce un rischio importante: evita l’esposizione diretta di SMB su TCP/445 verso reti non attendibili.

Ma non cancella tutti i rischi.

Rimangono centrali:

• sicurezza degli account;
• permessi NTFS e permessi di condivisione;
• auditing degli accessi;
• hardening del file server;
• patching;
• protezione da brute force e password spray;
• monitoraggio degli eventi;
• gestione del ciclo di vita dei certificati;
• protezione del Domain Controller raggiunto dal file server;
• progettazione Kerberos/KDC Proxy;
• controllo dei dispositivi client autorizzati.

Inoltre, se l’accesso remoto ai file server viene semplificato, bisogna fare ancora più attenzione alla classificazione dei dati. Rendere più facile accedere a una share è utile solo se sappiamo davvero cosa c’è dentro quella share.

Perché il problema, spesso, non è aprire il canale. Il problema è scoprire che dentro quel canale passa la cartella “Documenti vecchi”, che contiene contratti, export Excel, backup manuali, password in un file chiamato “password nuove definitive.xlsx” e altre forme di archeologia aziendale.

VPN vs SMB over QUIC: confronto corretto

La domanda “SMB over QUIC sostituisce la VPN?” è comoda, ma rischia di essere formulata male.

La domanda corretta è:

“Per quali scenari stiamo usando oggi la VPN?”

Se la VPN serve per dare accesso generico alla rete aziendale, SMB over QUIC non è un sostituto.

Se la VPN serve solo per raggiungere alcune file share, allora SMB over QUIC può diventare un’alternativa molto interessante.

La VPN estende il perimetro di rete.

SMB over QUIC espone in modo più controllato un servizio specifico.

La VPN tende a dire: prima entra, poi vediamo cosa devi fare.

SMB over QUIC dice: puoi raggiungere questa risorsa, con questo protocollo, attraverso questo trasporto, con queste condizioni.

È, di nuovo, una differenza enorme.

E infatti il valore di SMB over QUIC non è “fare quello che faceva la VPN”. Il valore è evitare di usare una VPN quando il requisito non richiede davvero una VPN.

Una possibile architettura di riferimento

Una progettazione sensata potrebbe prevedere:

• file server Windows Server 2025 dedicato o chiaramente identificato per accesso SMB over QUIC;
• pubblicazione controllata di UDP/443 verso il file server;
• nessuna esposizione di TCP/445 da Internet;
• certificato server pubblico o rilasciato da CA aziendale attendibile dai client;
• nome DNS pubblico coerente con il certificato;
• accesso del file server ai Domain Controller interni;
• KDC Proxy per favorire Kerberos;
• restrizione ai soli dispositivi gestiti tramite certificati client, ove opportuno;
• auditing SMB e monitoraggio degli eventi;
• permessi NTFS e share rivisti prima della pubblicazione;
• documentazione della procedura di rinnovo certificati;
• test periodici di connettività, autenticazione e revoca accesso.

Questa architettura non è complicata in modo eccessivo, ma richiede disciplina.

E la disciplina, nel mondo IT, è quella cosa che tutti apprezzano moltissimo subito dopo aver finito di ignorarla.

Cosa controllare prima di portarlo in produzione

Prima di considerare SMB over QUIC in produzione, farei almeno queste verifiche:

• quali share devono essere accessibili da remoto;
• chi deve accedervi;
• da quali dispositivi;
• con quale metodo di autenticazione;
• se è richiesto Kerberos;
• se serve KDC Proxy;
• come vengono gestiti certificati server e client;
• cosa succede alla scadenza del certificato;
• come viene revocato un dispositivo compromesso;
• quali eventi vengono raccolti nel SIEM;
• quali alert vengono generati;
• come vengono gestiti accessi anomali, tentativi ripetuti e password spray;
• se le share contengono dati compatibili con l’accesso remoto;
• se esistono alternative più adatte, come SharePoint, OneDrive, Azure Files, AVD o Windows 365.

Questa checklist serve a evitare l’errore più comune: valutare una tecnologia solo perché è tecnicamente possibile abilitarla.

Molte cose sono tecnicamente possibili.

Anche chiamare “definitivo” un file Excel. Ma non per questo è una buona idea.

Conclusione

SMB over QUIC è una funzionalità molto interessante, soprattutto con Windows Server 2025.

Ha un valore concreto perché consente di ripensare alcuni scenari di accesso remoto alle file share senza ricorrere automaticamente alla VPN. Riduce la necessità di esporre SMB tradizionale, usa un trasporto moderno, sfrutta TLS 1.3 e si integra con il mondo SMB che molte aziende usano ancora quotidianamente.

Ma non è una sostituzione universale della VPN. È una risposta precisa a un problema preciso.

Dove il problema è “devo accedere a una share SMB da una rete non attendibile”, SMB over QUIC può essere una soluzione elegante e concreta.

Dove il problema è “devo portare un client dentro l’intera rete aziendale”, allora siamo in un altro film.

La vera maturità tecnica sta qui: non usare una tecnologia moderna per sembrare moderni, ma usarla quando riduce davvero complessità, esposizione e attrito operativo.

SMB over QUIC non uccide la VPN. Uccide, semmai, l’abitudine di usare la VPN anche quando serve solo aprire una cartella condivisa.

E nel 2026, per molte infrastrutture, questa sarebbe già una piccola rivoluzione.

Stay tuned!