Per quanto tempo un sistema dovrebbe considerare affidabile un utente dopo l’autenticazione?

Quando un utente accede a un sistema, la sua identità viene verificata. Se le credenziali e gli altri meccanismi di autenticazione sono validi, il sistema concede l’accesso e crea una sessione.

Ma l’autenticazione conferma l’identità in un momento preciso. L’utente può poi continuare a lavorare per diverse ore senza doversi autenticare nuovamente.

Questo solleva una questione importante per la sicurezza del software: per quanto tempo una sessione dovrebbe essere considerata affidabile dopo l’autenticazione dell’utente?

Il login è l’inizio dell’accesso, non la fine del controllo

Dopo un login riuscito, il sistema crea generalmente una sessione che consente all’utente di continuare a lavorare senza dover inserire le proprie credenziali per ogni operazione.

Questo è essenziale per garantire una buona esperienza d’uso. Ma una sessione attiva rappresenta anche la continuità di una decisione presa in precedenza: il sistema presume che la persona che sta utilizzando la sessione sia ancora la stessa che si è autenticata inizialmente.

Più a lungo questa fiducia rimane valida, più diventa importante gestirla correttamente.

Il NIST affronta questo aspetto nell’ambito della gestione delle sessioni e definisce la riautenticazione periodica come un modo per confermare la presenza continuativa dell’utente all’interno di una sessione autenticata.

Una sessione attiva non significa sempre che la situazione sia rimasta la stessa

Prendiamo un esempio semplice.

Un utente effettua il login alle 8:00 dal proprio dispositivo di lavoro. Diverse ore dopo, la sessione è ancora attiva. Tecnicamente, il sistema può considerarla ancora valida, ma il tempo trascorso, un periodo di inattività o il contesto di accesso possono modificare il livello di rischio.

È proprio per questo che esistono meccanismi come scadenza della sessione, timeout per inattività e riautenticazione.

Il NIST distingue due limiti principali: un limite complessivo alla durata della sessione e un limite relativo ai periodi di inattività. Quando questi limiti vengono raggiunti, la sessione deve terminare oppure l’utente deve autenticarsi nuovamente, in base alle policy del sistema.

Non tutti gli utenti e tutte le operazioni presentano lo stesso livello di rischio

Una delle sfide della gestione delle sessioni è che una singola regola non è necessariamente adatta a ogni situazione.

Consultare informazioni generali e gestire privilegi critici non comportano lo stesso livello di rischio. Allo stesso modo, un utente standard e un amministratore con ampi privilegi non hanno necessariamente bisogno della stessa policy di sessione.

Per questo la gestione moderna degli accessi sta diventando sempre più granulare. Il 15 settembre 2026, Google Cloud ha annunciato il completamento dell’introduzione di una durata predefinita delle sessioni di 16 ore per i clienti che non avevano configurato una durata personalizzata, mentre i nuovi controlli consentono di applicare policy più specifiche in base ai gruppi e alle applicazioni. Google cita, ad esempio, la possibilità di impostare una sessione di due ore per gli utenti con privilegi elevati e una sessione standard di 16 ore per gli sviluppatori.

Sicurezza ed esperienza utente devono funzionare insieme

Un sistema potrebbe richiedere agli utenti di autenticarsi continuamente, ma questo renderebbe rapidamente l’esperienza d’uso poco pratica. D’altra parte, una sessione che rimane attiva senza limiti può aumentare l’esposizione al rischio se il dispositivo o la sessione finiscono nelle mani di un’altra persona.

L’obiettivo, quindi, non è semplicemente ridurre il più possibile la durata delle sessioni.

È necessario stabilire quando ha senso che il sistema continui a considerare valida l’autenticazione esistente e quando sia invece necessaria una nuova verifica.

Gli standard moderni considerano questa una decisione legata al contesto, prendendo in considerazione fattori come il tipo di applicazione, il dispositivo, l’ambiente in cui viene utilizzato il sistema e il livello di sicurezza richiesto.

La fiducia digitale ha anche una dimensione temporale

La sicurezza dell’identità viene spesso discussa in relazione al momento del login: password, MFA, passkey e altri metodi di autenticazione.

Ma un sistema deve gestire anche ciò che accade dopo l’autenticazione.

Quanto tempo è trascorso? La sessione è rimasta inattiva? Quale livello di accesso ha l’utente? Sta cercando di eseguire un’operazione che richiede un livello di sicurezza più elevato?

Queste decisioni rendono la gestione delle sessioni parte dell’architettura degli accessi, anziché un semplice timer che disconnette automaticamente l’utente.

In ALSoft, la gestione delle identità e degli accessi viene considerata parte integrante della progettazione della sicurezza di un sistema lungo l’intero percorso dell’utente, dall’autenticazione iniziale al controllo continuo degli accessi.

Come spiega Ermal Beqiri, fondatore di ALSoft:

«La sicurezza non termina quando un utente effettua il login. Un sistema deve anche sapere quando è il momento di verificarne nuovamente l’identità. Questo equilibrio tra accesso e controllo è parte integrante della progettazione di un sistema sicuro.»

Un login riuscito conferma che il sistema ha considerato affidabile l’utente in quel momento. La gestione delle sessioni determina per quanto tempo questa fiducia rimane valida.