Se gestisci una web app con utenti registrati, il tema IT Wallet per aziende ti riguarda prima di quanto sembri. La risposta breve è questa: entro il 24 dicembre 2026 ogni Stato membro UE deve mettere a disposizione dei cittadini almeno un portafoglio di identità digitale europeo (EUDI Wallet). Dal 24 dicembre 2027 le aziende private obbligate, per legge o per contratto, a usare l’autenticazione forte dovranno accettarlo se l’utente lo chiede. Oggi, in Italia, un’azienda privata non può ancora chiedere dati all’IT Wallet, perché mancano le regole per chi riceve i dati (i cosiddetti relying party). Quindi non c’è niente da integrare domani mattina. C’è però molto da progettare, se non vuoi riscrivere il login in fretta nel 2027.
In questo articolo spiego cosa sappiamo, cosa non sappiamo ancora e come imposto l’autenticazione nelle web app che sviluppo e gestisco end-to-end, perché l’arrivo del wallet diventi un modulo in più e non un rifacimento.
Cosa cambia e quando: le date da segnare
Il quadro normativo è il regolamento europeo eIDAS 2 (Regolamento UE 2024/1183), che aggiorna le regole sull’identità digitale. Le scadenze rilevanti per chi sviluppa o possiede una piattaforma sono due:
- 24 dicembre 2026: ogni Stato membro deve fornire almeno un EUDI Wallet. In Italia la strada è l’IT Wallet, già avviato dentro l’app IO per alcuni documenti digitali.
- 24 dicembre 2027: i soggetti privati tenuti all’autenticazione forte del cliente devono accettare il wallet come metodo di accesso, su richiesta dell’utente.
Una sintesi aggiornata delle tempistiche e della situazione italiana è nella guida di Didit su IT Wallet per le imprese. Dal lato tedesco, utile per chi lavora anche con clienti in Germania, c’è l’analisi di Taylor Wessing sull’arrivo dell’EUDI Wallet. Il punto in comune è che le date europee sono fissate, mentre i dettagli operativi nazionali stanno ancora arrivando.
Chi sarà davvero obbligato ad accettarlo
Qui conviene essere precisi, perché è facile fare allarmismo. L’obbligo del 2027 riguarda chi deve già autenticare i clienti in modo forte per legge o per contratto. Pensa ai servizi di pagamento e bancari, agli operatori che devono identificare con certezza l’utente o ai servizi che hanno firmato accordi in cui l’autenticazione forte è un requisito.
La PMI con un gestionale interno, un portale clienti o una piattaforma di prenotazioni, nella maggior parte dei casi, non rientra in questo obbligo. Ma questo non chiude il discorso, per tre motivi pratici:
- I tuoi clienti potrebbero chiedertelo, soprattutto se lavori con soggetti regolati e i loro contratti di fornitura si irrigidiscono.
- Il wallet può servire anche oltre il login: verifica dell’età, attributi professionali, dati anagrafici già validati al posto di moduli compilati a mano.
- Gli utenti si abitueranno, come è successo con SPID e CIE. Un accesso che oggi è un’opzione rara domani potrebbe essere atteso.
Se la tua piattaforma rientra in un settore regolato, la valutazione va fatta con il tuo consulente legale. Io posso dirti cosa serve lato tecnico, non se sei obbligato.
La situazione in Italia oggi
Allo stato attuale, aggiornato a inizio ottobre 2026 secondo la fonte citata sopra, le aziende private non possono ancora richiedere attributi all’IT Wallet: non risultano pubblicate le regole per i relying party privati. Non si sa quindi ancora con precisione:
- come avverrà la registrazione di un’azienda come relying party;
- quali attributi si potranno richiedere e con quali giustificazioni;
- quali costi o requisiti tecnici di certificazione saranno previsti.
Chi oggi ti vende un’integrazione IT Wallet pronta per un’azienda privata, in Italia, ti sta vendendo qualcosa che non può ancora andare in produzione. Quello che si può fare adesso è preparare l’architettura.
Autenticazione modulare: come preparare la web app
Il problema tipico delle web app nate in fretta è che il login è cucito addosso al modello utente: email e password nella stessa tabella dell’account, controlli sparsi nel codice, nessuna separazione tra chi sei e cosa puoi fare. Aggiungere un nuovo metodo di accesso diventa allora un intervento invasivo.
L’impostazione che uso separa tre livelli.
1. Account e identità sono due cose diverse
Un account (il profilo nella tua piattaforma, con ruoli, dati e storico) può avere più identità collegate: email e password, una passkey, un accesso SSO aziendale e, in futuro, un wallet. Nel database questo si traduce in una tabella di identità esterne collegate all’account, ciascuna con il proprio fornitore e identificativo. Aggiungere il wallet significherà aggiungere un tipo di identità, non riscrivere gli utenti.
2. Un livello di autenticazione basato su standard
Gli EUDI Wallet si basano su protocolli aperti della famiglia OpenID per la presentazione delle credenziali verificabili. Se la tua web app già parla OpenID Connect, magari tramite un identity broker separato dall’applicazione, sei molto più vicino al traguardo. Lo stesso livello che oggi gestisce le passkey per l’accesso senza password o il single sign-on aziendale potrà ospitare il wallet come ulteriore metodo.
3. Autorizzazione indipendente dal metodo di login
Ruoli e permessi non devono dipendere da come l’utente è entrato. Se il controllo dei permessi è centralizzato, come descrivo nell’articolo su utenti, ruoli e permessi nelle web app, il nuovo metodo di accesso non tocca la logica di business.
Minimizzazione dei dati e GDPR: il wallet aiuta, se lo usi bene
Un vantaggio concreto del modello wallet è la divulgazione selettiva: l’utente può condividere solo l’attributo richiesto, per esempio la maggiore età, senza consegnare l’intero documento. Per una PMI questo significa meno dati personali da custodire e meno rischio in caso di incidente.
Il rischio opposto è chiedere tutto perché “tanto è disponibile”. In fase di progettazione conviene già oggi definire:
- quali attributi servono davvero alla tua piattaforma e perché;
- dove vengono salvati e per quanto tempo;
- cosa finisce nei log (l’evento di autenticazione sì, i dati anagrafici no).
Come lo gestisco nei progetti end-to-end
Quando sviluppo una web app, come quelle che costruisco e gestisco su apicco.app, tandemops.app o indelio.eu, mi occupo anche dell’infrastruttura su cui gira: container Docker gestiti con Portainer, reverse proxy Nginx, certificati SSL, backup e aggiornamenti. Questo conta per l’autenticazione, perché un identity broker o un nuovo servizio di verifica è un componente in più da ospitare, aggiornare e monitorare, non solo codice da scrivere.
Il mio approccio pratico per chi ha una piattaforma esistente è:
- Audit del login attuale: dove vivono le credenziali, come sono legate all’account, quali metodi sono supportati.
- Disaccoppiamento: separare identità e account, centralizzare i controlli dei permessi, se non è già fatto.
- Metodi moderni già disponibili: passkey e 2FA oggi, che portano benefici immediati di sicurezza.
- Predisposizione per il wallet: un punto di estensione pronto, da attivare quando le regole italiane per i relying party saranno pubblicate.
In questo modo la spesa di oggi produce valore subito, e il lavoro del 2027 si riduce a un’integrazione mirata.
Domande frequenti
La mia azienda deve integrare l’IT Wallet entro il 2026?
No. La scadenza del 24 dicembre 2026 riguarda gli Stati, che devono fornire il wallet ai cittadini. L’obbligo di accettarlo per i privati parte dal 24 dicembre 2027 e solo per chi è tenuto all’autenticazione forte per legge o contratto.
IT Wallet sostituisce SPID e CIE?
Sono strumenti diversi e oggi convivono. Per un’azienda privata la domanda pratica non è quale sostituirà l’altro, ma se la web app è in grado di supportare più metodi di identificazione senza modifiche invasive.
Posso già fare un test di integrazione?
Puoi lavorare sugli standard tecnici e sull’architettura. In Italia, però, finché non sono pubblicate le regole per i relying party privati, non è possibile richiedere dati reali all’IT Wallet da parte di un’azienda privata.
Quanto costa predisporre la web app?
Dipende da come è costruito il login attuale. Se identità, account e permessi sono già separati, l’intervento è contenuto; se sono intrecciati nel codice, serve prima un refactoring. Un audit iniziale permette di stimarlo con precisione.
Se hai una web app, un portale clienti o un gestionale e vuoi capire quanto è pronto il tuo sistema di accesso per passkey, SSO e wallet digitali, oppure devi sviluppare una nuova piattaforma con un’architettura pensata per durare, contattami per parlare del tuo progetto di sviluppo web o app. Partiamo da come funziona oggi e decidiamo insieme cosa fare adesso e cosa rimandare a quando le regole saranno definitive.
