Quando un’email ufficiale non basta: il caso Revolut solleva interrogativi sul futuro dell’identità digitale
Un recente incidente di sicurezza che ha coinvolto Revolut solleva una questione che va ben oltre una singola azienda o un singolo istituto finanziario: come possiamo verificare in modo affidabile, nel mondo digitale, non solo da dove proviene una richiesta di dati sensibili, ma anche chi la sta realmente inviando, se quella persona è autorizzata a presentarla e a quali dati ha effettivamente diritto di accedere? Il caso dimostra che un canale di comunicazione può apparire legittimo senza che ciò dimostri necessariamente anche l’identità e l’autorità della persona che si trova dall’altra parte.
Che cosa è successo?
Nel settembre 2026 Revolut ha confermato un incidente di sicurezza nel quale una terza parte non autorizzata ha utilizzato un indirizzo e-mail appartenente al dominio legittimo di un’autorità pubblica per inviare richieste fraudolente di informazioni sui clienti.
Secondo Revolut, l’incidente ha riguardato un caso esterno di impersonificazione. Una volta individuato l’abuso, la società ha bloccato l’indirizzo e ha informato l’autorità pubblica interessata, le forze dell’ordine e le autorità di regolamentazione competenti. Revolut ha inoltre sottolineato che i propri sistemi e i fondi dei clienti non sono stati compromessi.
Tuttavia, informazioni sensibili relative a un numero limitato di clienti sono state comunicate a una parte non autorizzata. Secondo le informazioni rese pubbliche, i dati potrebbero aver incluso informazioni personali e di contatto, copie di documenti di identità e, per alcuni clienti, altri dati relativi ai conti e alle transazioni.
Questa è una distinzione importante.
Non stiamo parlando di una violazione confermata dei sistemi centrali di Revolut, ma di un diverso tipo di problema di sicurezza: la richiesta è arrivata attraverso un canale di comunicazione che appariva legittimo, mentre la persona che si trovava dietro quella richiesta non era autorizzata a ricevere le informazioni richieste.
La vera domanda non è soltanto: «Da dove proviene il messaggio?»
Da tempo la comunicazione digitale si basa sulla verifica di domini, certificati, account, dispositivi e altri elementi tecnici.
Ma la legittimità del canale di comunicazione, da sola, non risponde a tre domande fondamentali:
Chi sta richiedendo i dati?
Questa persona è autorizzata a richiederli?
Quali dati ha effettivamente il diritto di ricevere?
È proprio qui che il caso Revolut assume un significato più ampio.
Se qualcuno comunica attraverso un sistema legittimo o da un dominio legittimo, ciò non significa necessariamente che disponga anche dell’autorità necessaria per compiere una determinata azione.
“Nel mondo digitale del futuro non sarà sufficiente verificare da dove proviene una richiesta. Sarà necessario verificare anche chi la invia, con quale autorizzazione e a quali dati ha il diritto di accedere.”
— Istituto 1. april
L’identità digitale non è un servizio finanziario
In questo contesto è importante distinguere due elementi diversi.
Revolut è principalmente una piattaforma finanziaria e un fornitore di servizi finanziari. L’identità digitale, invece, è un’infrastruttura che consente di dimostrare l’identità, gli attributi, le autorizzazioni o i diritti di una persona o di un’organizzazione.
Non sono la stessa cosa.
Un servizio finanziario può gestire:
conti bancari e pagamenti,
carte e trasferimenti di denaro,
transazioni finanziarie,
finanze personali.
Un sistema di identità digitale, invece, può servire a dimostrare:
chi è una persona,
quale ruolo ricopre,
se dispone di una determinata autorizzazione,
se ha il diritto di accedere a un determinato servizio o dato.
Uno gestisce le finanze. L’altra dimostra chi sei oppure che cosa sei autorizzato a fare.
Che cosa dovrebbe verificare un sistema del futuro?
Immaginiamo che un’autorità pubblica abbia bisogno di determinate informazioni da un istituto finanziario.
Il processo attuale può comprendere comunicazioni ufficiali, un indirizzo e-mail istituzionale, documentazione e procedure interne di verifica.
Un sistema di identità digitale più avanzato potrebbe richiedere anche ulteriori prove crittografiche:
IDENTITY VERIFIED
ORGANIZATION VERIFIED
ROLE VERIFIED
AUTHORITY VERIFIED
REQUEST SCOPE VERIFIED
Solo successivamente:
DATA ACCESS AUTHORIZED
Ciò significa che il sistema non verificherebbe soltanto se la richiesta proviene da una determinata istituzione.
Verificherebbe anche se la persona specifica è effettivamente autorizzata a presentare quella specifica richiesta.
Ed è qui che inizia la questione QEI
All’Istituto 1. april, nell’ambito del concetto in fase di sviluppo QEI – Quantized Encrypted Identity, stiamo studiando proprio come l’identità digitale del futuro potrebbe consentire una verifica crittografica più forte, riducendo al tempo stesso la divulgazione non necessaria di dati personali.
In questa fase QEI non è un sistema implementato e pertanto non affermiamo che avrebbe potuto impedire lo specifico incidente che ha coinvolto Revolut.
Il caso rappresenta tuttavia un utile punto di partenza per una domanda di ricerca:
Una futura infrastruttura di identità digitale potrebbe verificare non soltanto l’identità di una persona, ma anche il suo ruolo attuale, la sua autorizzazione e l’ambito consentito di una specifica richiesta?
Per esempio:
WHO ARE YOU?
→ identità digitale verificata
WHO DO YOU REPRESENT?
→ collegamento verificato con un’istituzione
WHAT IS YOUR ROLE?
→ ruolo verificato
ARE YOU AUTHORIZED?
→ autorizzazione verificata crittograficamente
WHAT MAY YOU ACCESS?
→ ambito dei dati consentito
Solo a quel punto il sistema deciderebbe se concedere l’accesso.
Non «fidarsi del dominio», ma «verificare l’autorizzazione»
Questo rappresenterebbe un cambiamento importante nella sicurezza digitale.
Invece di:
«Il messaggio proviene da un dominio ufficiale, quindi ci fidiamo.»
il sistema potrebbe applicare il principio:
«Il canale è stato verificato. Ora verifichiamo anche la persona, il suo ruolo, la sua autorizzazione e l’ambito della richiesta.»
Anche un canale di comunicazione compromesso o utilizzato impropriamente non costituirebbe quindi, da solo, una prova sufficiente per consentire l’accesso a informazioni sensibili.
Divulgare soltanto ciò che è necessario
Un altro elemento importante riguarda la quantità di dati.
Quando si risponde a una richiesta di informazioni, la domanda non dovrebbe essere soltanto se l’accesso è autorizzato, ma anche:
a quali dati è autorizzato l’accesso?
Se un funzionario dispone dell’autorizzazione legale per ottenere una specifica informazione, ciò non significa necessariamente che debba avere accesso all’intero profilo della persona.
Questo principio è collegato a uno degli elementi centrali del concetto QEI:
dimostrare l’attributo necessario o consentire l’accesso necessario con la minima divulgazione possibile di dati.
Invece di:
AUTHORIZED = ACCESS TO EVERYTHING
potrebbe valere il principio:
AUTHORIZED FOR PURPOSE X = ACCESS ONLY TO DATA REQUIRED FOR PURPOSE X
Un approccio di questo tipo è collegato ai principi di minimizzazione dei dati, limitazione delle finalità e Privacy by Design.
Ma QEI non deve diventare un nuovo punto centrale di sorveglianza
Esiste però anche un’importante avvertenza.
Se un sistema di identità digitale verificasse identità, istituzione, ruolo e autorizzazione, un’infrastruttura progettata in modo inadeguato potrebbe trasformarsi anche in un sistema estremamente potente di sorveglianza centralizzata.
La domanda quindi non è soltanto:
Come possiamo aumentare la verifica?
Altrettanto importante è chiedersi:
Come possiamo aumentare la verifica senza aumentare la sorveglianza non necessaria dell’individuo?
Per questo motivo lo sviluppo di un’architettura di questo tipo deve comprendere protezione crittografica, divulgazione minima dei dati, chiara separazione delle autorizzazioni, tracciabilità degli accessi e valutazioni indipendenti sotto il profilo della sicurezza e del diritto.
Il caso Revolut è un avvertimento per l’intero ecosistema digitale
Il caso non riguarda quindi soltanto una singola società finanziaria.
Una problematica simile può presentarsi ovunque le organizzazioni trattino informazioni sensibili e ricevano richieste da altre istituzioni:
banche, compagnie di assicurazione, operatori di telecomunicazioni, strutture sanitarie, registri pubblici, fornitori di servizi digitali e molti altri sistemi.
La digitalizzazione aumenta la velocità con cui i dati possono essere scambiati.
Ma uno scambio di dati più rapido deve essere accompagnato anche da una verifica più forte di chi ha effettivamente il diritto di riceverli.
“Un canale di comunicazione verificato non equivale ancora a un’identità verificata del mittente. Un’identità verificata non equivale ancora a un’autorizzazione verificata. La fiducia digitale del futuro dovrà essere in grado di dimostrare tutte e tre.”
— Istituto 1. april
Dall’identità all’autorizzazione verificabile
Il caso Revolut dimostra perché la prossima generazione dell’identità digitale non dovrebbe rispondere soltanto alla domanda:
«Chi sei?»
Dovrebbe rispondere anche a:
«Chi rappresenti?»
«Qual è il tuo ruolo?»
«Che cosa sei autorizzato a richiedere?»
«Quali dati hai il diritto di ricevere?»
E forse, soprattutto:
«La tua autorizzazione è valida proprio adesso, per questa specifica richiesta?»
È un ambito che desideriamo approfondire nell’ambito della ricerca e dello sviluppo di QEI.
Non con l’obiettivo di sostituire i sistemi europei o nazionali di identità digitale esistenti.
Ma per studiare se la fiducia digitale del futuro possa essere costruita in modo tale che il sistema possa verificare di più sull’autorizzazione a compiere un’azione, rivelando al tempo stesso meno informazioni sull’individuo.
Nota: QEI – Quantized Encrypted Identity è un concetto di sviluppo e ricerca dell’Istituto 1. april. QEI non è attualmente un sistema implementato o certificato. Il caso Revolut viene utilizzato in questo articolo come punto di partenza per una discussione di ricerca sulla verifica dell’identità digitale, dei ruoli e delle autorizzazioni; l’articolo non afferma che QEI avrebbe impedito questo specifico incidente.
