Microsoft ha pubblicato una comunicazione tecnica che merita l’attenzione di chiunque gestisca applicazioni Windows in produzione, sviluppi driver o semplicemente si occupi di mantenere aggiornato un parco macchine aziendale: entro la fine del 2026 l’intera infrastruttura di firma del codice di Windows passerà a chiavi più robuste, e nel 2027 comincerà la transizione verso la crittografia post-quantistica. Non è un cambiamento cosmetico: tocca la catena di fiducia che verifica ogni eseguibile, ogni driver e ogni aggiornamento che gira sul sistema operativo, e le applicazioni scritte con troppe assunzioni implicite sui certificati Microsoft rischiano di smettere di funzionare durante la transizione.

Cosa cambia concretamente

Il nucleo dell’annuncio riguarda l’irrobustimento degli algoritmi crittografici usati per firmare codice ed eseguibili Windows tramite Authenticode:

• SHA-256 → SHA-384 come algoritmo di hashing per le firme.
• RSA-2048 → RSA-3072 come dimensione minima delle chiavi asimmetriche.

A questo si aggiunge un evento concreto con una data precisa da segnare in calendario: il certificato Windows Production PCA 2011, che oggi rappresenta una delle radici della catena di fiducia per il codice firmato Microsoft, scade il 19 ottobre 2026. Microsoft lo sostituirà con una nuova Certification Authority che mantiene le stesse proprietà di sicurezza, ma con un’identità diversa — nuovo nome, nuovo thumbprint, nuova catena intermedia.

Guardando più avanti, la roadmap indica che nel 2027 Windows inizierà a introdurre firme post-quantistiche, probabilmente tramite costruzioni ibride che combinano un algoritmo classico con uno resistente agli attacchi di un futuro computer quantistico. Questo colloca Windows nello stesso solco che NIST, browser e altre piattaforme stanno già percorrendo dal 2024 in poi: la crittografia a chiave pubblica che oggi diamo per scontata ha una data di scadenza nota, e la firma del codice — che deve restare verificabile per decenni, non solo per la durata di una sessione TLS — è uno degli ambiti dove questa transizione è più urgente.

Chi rischia di rompersi, e perché

Il problema pratico non è la crittografia in sé: Windows gestisce la validazione delle firme in modo trasparente per la stragrande maggioranza del software. Il rischio reale riguarda quelle applicazioni — tipicamente software di sicurezza, EDR, tool di gestione IT, installer aziendali o soluzioni di patch management — che nel tempo hanno implementato controlli troppo specifici sulla catena di certificati Microsoft, invece di affidarsi alle API di sistema pensate per questo scopo. Microsoft lo mette nero su bianco: le applicazioni non devono fissare («pin»):

• Il thumbprint di un certificato specifico.
• Il nome o l’emittente atteso del certificato.
• Il numero di serie o l’autorità di certificazione intermedia.

Chi ha scritto anni fa un controllo del tipo «verifica che il certificato dell’eseguibile abbia esattamente questo thumbprint» per rafforzare (a torto) la sicurezza di un prodotto, si formerà una sorpresa sgradita quando quella catena cambierà a fine 2026. Lo stesso vale per script di allowlisting basati su AppLocker o Windows Defender Application Control (WDAC) configurati puntando a thumbprint statici invece che a regole basate sull’editore (publisher rule), che invece restano valide attraverso il cambio di CA perché si basano sul soggetto del certificato e non sulla singola istanza.

Come verificare oggi cosa succede sul proprio parco macchine

Prima di aspettare che il problema si manifesti in produzione a ottobre, vale la pena fare un giro di ricognizione. PowerShell offre gli strumenti giusti per ispezionare le firme digitali presenti sul sistema.

Controllare la firma di un singolo file

Get-AuthenticodeSignature -FilePath "C:\Program Files\App\servizio.exe" |
    Select-Object Path, Status, StatusMessage,
        @{N='Thumbprint';E={$_.SignerCertificate.Thumbprint}},
        @{N='Issuer';E={$_.SignerCertificate.Issuer}}

Fare una scansione massiva su una cartella o un intero volume

Get-ChildItem -Path "C:\Program Files" -Include *.exe,*.dll,*.sys -Recurse -ErrorAction SilentlyContinue |
    Get-AuthenticodeSignature |
    Where-Object { $_.Status -ne 'Valid' } |
    Select-Object Path, Status, StatusMessage |
    Export-Csv -Path "C:\Report\firme-non-valide.csv" -NoTypeInformation

Su un parco macchine ampio, questo script va eseguito idealmente tramite uno strumento di orchestrazione (Intune, System Center, Ansible o un semplice invoke remoto via PowerShell Remoting) e i risultati aggregati, così da individuare in anticipo software di terze parti che già oggi presenta anomalie nella catena di certificazione, prima ancora del cambio di CA.

Ispezionare la catena di certificazione completa

Per un’analisi più approfondita che mostri l’intera catena — utile per capire se un’applicazione dipende da un intermedio specifico — signtool (incluso nel Windows SDK) resta lo strumento di riferimento:

signtool verify /pa /v "C:\Program Files\App\servizio.exe"

Il flag /pa usa la Default Authentication Verification Policy, la stessa logica che Windows applica di norma, evitando falsi negativi legati a policy di verifica troppo permissive o troppo restrittive impostate manualmente.

Cosa fare, in pratica, prima di ottobre 2026

1. Contattare i fornitori di software critico (EDR, antivirus, backup, patch management, VPN client) e chiedere conferma esplicita che i loro prodotti sono stati testati contro la nuova gerarchia di certificati Microsoft.
2. Eliminare qualsiasi controllo hardcoded su thumbprint o issuer nei propri script di allowlisting, sostituendolo con publisher rule in WDAC/AppLocker basate sul soggetto del certificato (Subject/CN), che sopravvivono al cambio di CA.
3. Usare le API corrette nel proprio codice: se si sviluppano applicazioni che validano firme di terze parti, affidarsi a WinVerifyTrust o alle interfacce CryptoAPI/CNG standard, senza mai assumere un abbinamento fisso tra algoritmo di hash e dimensione della chiave.
4. Eseguire la scansione delle firme descritta sopra su un campione rappresentativo di macchine, per avere una baseline prima del cambio e poter confrontare rapidamente eventuali regressioni dopo.
5. Pianificare un test in un ambiente di staging quando Microsoft renderà disponibile la nuova gerarchia di certificati (attesa «nelle prossime settimane» secondo la comunicazione ufficiale), prima che diventi l’unica catena valida in produzione.

Conclusione

La transizione a RSA-3072/SHA-384 e, più avanti, alla crittografia post-quantistica è un passo necessario e per certi versi tardivo rispetto a dove si trovano già TLS e altri ambiti della crittografia applicata. Il vero lavoro per i sistemisti non sta nel comprendere la matematica dietro il cambiamento, ma nel dare la caccia — nel proprio ambiente — a quei pochi punti fragili dove qualcuno, in passato, ha scritto un controllo troppo rigido pensando di rendere più sicuro un sistema, e ottenendo invece l’effetto opposto: una dipendenza implicita da un dettaglio implementativo che Microsoft aveva sempre dichiarato soggetto a cambiamento. Chi farà l’inventario delle firme oggi arriverà a ottobre senza sorprese; chi non lo farà rischia un incidente di compatibilità nel giorno peggiore possibile, in produzione.

Fonte: Microsoft Support — «Preparing the Windows ecosystem for next-generation code signing», ripreso da Petri.com.