In ogni progetto post-quantum c'è un momento rassicurante. La libreria è aggiornata, lo scambio di chiavi dice ML-KEM-768, il ticket viene chiuso. Fatto.

Solo che no. Hai sostituito una serratura. Non hai controllato le finestre, né il sigillo sulle lettere, né se qualcuno tenesse un inventario delle altre serrature.

Nel settore si è iniziato a chiamarla la differenza tra migrazione PQC e trasformazione PQC. La migrazione cambia gli algoritmi. La trasformazione cambia gli algoritmi e ricostruisce la verifica, la visibilità e la fiducia intorno a essi. La maggior parte dei fornitori si ferma alla prima.

La migrazione è l'algoritmo. La trasformazione è tutto il resto.

La migrazione è necessaria e non la sminuiamo. RSA ed ECC cadranno davanti a un computer quantistico crittograficamente rilevante, e i FIPS 203 (ML-KEM) e FIPS 204 (ML-DSA) del NIST sono i sostituti. Se non hai iniziato, inizia.

Ma un algoritmo è un componente, non una postura di sicurezza. Uno scambio di chiavi quantum-safe protegge la riservatezza di un messaggio. Non dice nulla su se il messaggio sia autentico, se il token che ha autorizzato la richiesta sia stato contraffatto, o se il certificato all'altro capo della connessione sia stato emesso da qualcuno che ha rotto ECDSA l'anno scorso.

La trasformazione pone quattro domande invece di una: È riservato? È verificabile? So dove vive tutta la mia crittografia? E di chi, in ultima analisi, mi fido?

La cifratura non ferma un man-in-the-middle. La verifica sì.

Harvest Now, Decrypt Later riguarda la riservatezza: un attaccante registra testo cifrato oggi e lo legge quando l'hardware lo permetterà. ML-KEM chiude quella porta. Ne abbiamo già scritto, e resta il problema più urgente per chiunque conservi dati con una lunga vita utile.

Ma lo stesso computer quantistico che rompe la cifratura RSA rompe anche le firme RSA ed ECDSA. È un attacco diverso con una conseguenza diversa. Invece di leggere i tuoi dati più tardi, l'attaccante si spaccia per te adesso. Pensa a cosa, in uno stack tipico, è protetto solo da una firma classica:

Access token e JWT — ne contraffai uno e non hai bisogno di rubare alcuna password.
Certificati TLS — un certificato contraffatto è un man-in-the-middle con il lucchetto valido.
Firma di codice e firmware — una firma contraffatta distribuisce malware come aggiornamento ufficiale.
Webhook, risposte API e log di audit — l'integrità di tutto ciò che viene dopo.

Se hai aggiornato la cifratura e lasciato le firme su ECDSA, hai sigillato la busta e lasciato il sigillo di ceralacca falsificabile. ML-DSA (FIPS 204) e SLH-DSA (FIPS 205) esistono esattamente per questo lato del problema. Una vera trasformazione protegge entrambi i lati.

Non puoi migrare ciò che non vedi

Chiedi a un CISO dove viene usato RSA nella sua organizzazione e la risposta onesta è "in più posti di quanti ne conosciamo". È negli header JWT, nelle chiavi SSH, nelle chiavi KMS cloud, nelle firme PDF, nei registry di container, negli SDK dei fornitori e in quel tool interno del 2017.

Per questo ogni roadmap PQC seria — inclusa la roadmap coordinata dell'UE del giugno 2025 — mette l'inventario prima della migrazione. Il primo traguardo non è "essere quantum-safe". È "conoscere il proprio patrimonio crittografico": quali algoritmi, quali dimensioni di chiave, quali sistemi, quale vita utile dei dati. Senza, migrerai il 60% visibile e verrai violato attraverso il 40% che nessuno ha elencato.

L'inventario crittografico non è glamour. È anche il passo che decide se una trasformazione è reale o cosmetica.

Com'è fatta una trasformazione completa

Messe insieme, quattro componenti — ognuna è necessaria, nessuna basta da sola:

Riservatezza — incapsulamento di chiavi ML-KEM attorno ad AES-256-GCM per dati a riposo e in transito. È la difesa contro HNDL.
Verifica — firme ML-DSA o SLH-DSA su token, documenti, artefatti e messaggi, così che manomissione e impersonificazione falliscano anche contro un avversario quantistico.
Ancore di fiducia — chiavi generate da entropia quantistica reale, emesse e verificate da un'infrastruttura sotto una giurisdizione su cui puoi contare. Zero-trust significa che ogni livello è post-quantum, non solo il trasporto.
Inventario — una vista aggiornata di quali algoritmi, chiavi e sistemi sono in gioco, così che la migrazione sia misurabile e nulla venga dimenticato.

Dove si trova QuantumAPI — onestamente

Ecco cosa è in produzione oggi. QuantumAPI cifra e decifra con ML-KEM-512/768/1024 che incapsula AES-256-GCM, e firma e verifica con ML-DSA-44/65/87 e SLH-DSA. QuantumID emette access token che portano una prova ML-DSA-65 accanto alla firma classica, così i client predisposti per la PQC possono verificare entrambe. QuantumVault conserva segreti, chiavi e certificati sotto la stessa cifratura ibrida ML-KEM, e il suo motore transit firma con ML-DSA. Le chiavi sono generate da hardware quantistico reale, con fallback automatico. Tutto gira su infrastruttura europea, sotto giurisdizione UE, fatturato a consumo — mai per utente.

Ed ecco cosa non è ancora rilasciato. Una dashboard di inventario crittografico, per vedere il tuo patrimonio di algoritmi a colpo d'occhio, è nella nostra roadmap e non nel prodotto. Le risposte API firmate sono pianificate, non attive. Preferiamo dirtelo piuttosto che mettere una spunta in una tabella.

Se stai pianificando un progetto post-quantum, pianifica una trasformazione, non una migrazione. Parti da entrambi i lati — cifratura e verifica — e pretendi un inventario da chiunque lavori con te. Puoi provare oggi gli endpoint di cifratura e firma con il piano gratuito su quantumapi.eu, e la documentazione su docs.quantumapi.eu mostra esattamente cosa fa ogni algoritmo.