CIE vs CieID: perché la password è scaduta ma con l'app accedi lo stesso

Chi utilizza i servizi online della Pubblica Amministrazione italiana può imbattersi in un comportamento apparentemente contraddittorio: accedendo con CIE tramite codice fiscale e password è occasionalmente richiesto il cambio password perché scaduta, mentre utilizzando l’app CieID l’accesso avviene senza alcun problema.

Non si tratta di un bug né di un’incoerenza casuale. È invece il risultato di un’architettura di autenticazione stratificata, dove convivono modelli diversi: credential-based e token-based. Per comprenderlo, bisogna uscire dalla prospettiva “utente” e guardare il sistema da un altro punto di vista.

L’architettura reale della CIE: un Identity Provider centralizzato

La Carta d’Identità Elettronica (CIE) non è solo un documento fisico: è il punto di accesso a un sistema centrale di identità digitale gestito dal Ministero dell’Interno.

Come si spiega nella documentazione tecnica ufficiale (“Manuale tecnico CIE”), i portali della PA non autenticano direttamente l’utente bensì delegano l’autenticazione a un sistema centrale (CIE, appunto). In risposta, i portali – nel momento in cui l’utente prova ad accedere – ricevono in risposta un’asserzione firmata circa l’identità del richiedente.

Il modello adottato da Entra con CIE è quello della federazione delle identità, anche se la documentazione istituzionale non lo esplicita sempre in modo puntuale. All’interno dell’architettura CIE possiamo identificare chiaramente due ruoli:

• Service Provider (SP): il portale della PA che eroga il servizio.
• Identity Provider (IdP): il sistema centrale CIE (CieID Server).

L’intero meccanismo si basa su protocolli standard di federazione dell’identità, come SAML 2.0 od OpenID Connect (OIDC): questo significa che l’autenticazione avviene “fuori” dal portale e che il sito riceve soltanto una risposta firmata, cioè un’asserzione crittografica che certifica che l’utente è stato autenticato con un determinato livello di sicurezza. In altre parole, il portale non vede mai la password, né gestisce direttamente le credenziali, ma verifica solo che la risposta provenga dal sistema CIE e che sia valida. È lo stesso principio per cui, quando si accede con SPID, il sito non conosce la password SPID dell’utente: riceve semplicemente la conferma che l’identità è stata verificata dall’IdP.

Due modalità di autenticazione, due strade diverse

Il punto decisivo – spesso poco evidente anche leggendo la documentazione ufficiale – è che Entra con CIE non è un singolo meccanismo di login, ma un contenitore di modalità di autenticazione diverse, ciascuna con una proprio flusso tecnico e con proprie regole di validazione.

Pur partendo dalla stessa interfaccia (Entra con CIE), il sistema può attivare flussi profondamente differenti, con conseguenze concrete sul comportamento finale.

Guardate ad esempio questa pagina di autenticazione su un portale della PA: sopra compare il messaggio Hai l’app CieID? Accedi più velocemente. Subito sotto, invece, c’è il classico meccanismo di autenticazione con CIE basato su username (numero CIE, codice fiscale o email) e password personale.

Accesso con CIE tramite credenziali

L’accesso con username e password (livelli 1 e 2) è quanto di più vicino al modello tradizionale di autenticazione basato su credenziali. L’utente inserisce numero CIE, codice fiscale o email e password (conferma con un secondo fattore nel caso di livello 2).

A questo punto entra in gioco il sistema centrale CIE, che svolge una serie di verifiche: le credenziali sono ricevute e validate; la password sottoposta a tutte le policy previste dal sistema di identità (verifica di correttezza, controllo di scadenza, eventuale stato di blocco o sospensione, conformità alle regole di sicurezza). Solo nel caso in cui tutte queste verifiche abbiano esito positivo, il sistema procede alla fase successiva, cioè la generazione dell’asserzione di autenticazione che sarà poi inviata al portale.

Accesso tramite app CieID

Facendo riferimento all’app CieID (Android, iOS), il flusso cambia radicalmente.

Innanzi tutto, non si inseriscono più credenziali nel browser. Succede invece che il portale della PA genera una richiesta di autenticazione, il sistema operativo apre l’app CieID (deep link o QR), l’utente si autentica nell’app: PIN app o biometria, eventualmente via NFC con CIE fisica (livello 3). Ne abbiamo parlato nell’articolo sulla CIE obbligatoria dal 3 agosto 2026.

L’applicazione dialoga con il backend CIE (il sistema centrale della Carta d’Identità Elettronica); il backend verifica l’identità dell’utente controllando i dati forniti; successivamente viene prodotta un’asserzione firmata, cioè una dichiarazione digitale autenticata che certifica l’esito della verifica; infine il portale riceve questo risultato e avvia la sessione utente.

Due modelli a confronto: quando la password è centrale e quando è irrilevante

Il punto centrale sta in ciò che il portale riceve e, di conseguenza, in ciò che è in grado di controllare. Nel caso dell’accesso con CIE tramite username e password, il sistema di autenticazione lavora su una credenziale esplicita: la password è trasmessa, verificata e sottoposta a tutte le policy previste (validità, scadenza, blocchi). La password è in questo caso un elemento attivo del processo e rappresenta l’oggetto su cui si applicano le regole di sicurezza; se risulta scaduta, l’autenticazione non può essere completata e l’accesso è negato.

Con l’utilizzo dell’app CieID, invece, l’approccio cambia: la password non entra mai nel processo e quindi non può essere verificata né, tantomeno, bloccare l’accesso. Non si tratta di un bypass delle policy, ma di una conseguenza diretta del fatto che, in un modello basato su asserzioni, l’oggetto su cui applicare la policy semplicemente non è presente.

In questo secondo caso, basta digitare il PIN oppure confermare l’identità tramite biometria per accedere immediatamente, senza bisogno di confermare alcuna password o cambiarla periodicamente.

Il ruolo dell’app CieID: molto più di un’interfaccia

Ridurre CieID a un semplice frontend è estremamente riduttivo e tecnicamente fuorviante. L’app svolge una funzione strutturale all’interno del sistema di autenticazione CIE, collocandosi tra l’utente e l’infrastruttura centrale come componente attivo del processo di identificazione.

Dal punto di vista architetturale, CieID realizza una forma di binding tra identità digitale e dispositivo, che rappresenta uno degli elementi chiave dei moderni sistemi di autenticazione forte.

Durante la fase di attivazione, l’app associa in modo persistente un dispositivo fisico (lo smartphone) all’identità dell’utente, creando un contesto fidato che può essere riutilizzato nei login successivi. Questo “collegamento stretto” non è puramente logico, ma si appoggia a meccanismi di sicurezza del dispositivo stesso (secure storage, keystore, protezione biometrica), che contribuiscono a garantire l’integrità del processo.

Una volta attivata, l’app gestisce in locale la fase di autenticazione dell’utente, utilizzando un fattore di conoscenza (PIN dell’app) oppure un fattore biometrico (impronta digitale o riconoscimento facciale, se disponibile). Tale autenticazione locale non conclude il processo, ma serve a sbloccare l’uso dell’identità digitale. L’app, infatti, agisce come intermediario verso il backend CIE, instaurando una comunicazione sicura in cui è trasmessa una richiesta di autenticazione, dimostrato il possesso del dispositivo associato, utilizzati canali protetti (TLS) e identificativi di sessione.

Nel caso di autenticazione di livello 3, entra in gioco anche la CIE fisica tramite NFC, con accesso ai certificati presenti sul chip e operazioni crittografiche basate su PKI (Public Key Infrastructure).

CieID implementa un modello concettualmente vicino ai sistemi passwordless moderni, come FIDO2/WebAuthn: l’identità non è dimostrata tramite una password, ma attraverso una combinazione di possesso del dispositivo, autenticazione locale e validazione server-side. Con la differenza che, nel caso CIE, il sistema è integrato con un’infrastruttura statale e con una smart card fisica.

Codice sorgente CieID e implicazioni di sicurezza

Il fatto che CieID non sia open source, nonostante quanto previsto dall’art. 69 del Codice dell’Amministrazione Digitale (CAD), va letto alla luce del ruolo tecnico che l’app svolge.

Non si tratta di una semplice applicazione di servizio, ma di un componente inserito in una infrastruttura di autenticazione nazionale che gestisce:

• flussi crittografici tra dispositivo e backend;
• accesso a credenziali hardware (chip CIE via NFC);
• processi di identificazione forte con livelli di garanzia elevati (livello 2 e 3);
• meccanismi di associazione identità-dispositivo.

Posto che la sicurezza tramite segretezza è un concetto che non dovrebbe mai essere perseguito, l’esposizione integrale del codice sorgente potrebbe, almeno in teoria, facilitare analisi approfondite dei flussi di autenticazione. Per questo motivo e per altri sui quali è possibile fare soltanto ipotesi, è plausibile che il mancato rilascio del codice rientri nelle eccezioni previste dal CAD per ragioni di sicurezza pubblica, pur in un quadro normativo che, in linea generale, promuove apertura e riuso.

La scelta operata nel caso di CieID contribuisce certamente a una percezione di minore trasparenza rispetto ad altri progetti della PA, ma non altera la natura del sistema: il funzionamento architetturale resta deducibile dalle specifiche pubbliche, dai protocolli adottati (SAML e OIDC) e dal comportamento osservabile nei flussi di autenticazione.