Autenticazione basata sul dispositivo: come funziona, metodi e vantaggi per la sicurezza

L’autenticazione basata sul dispositivo verifica l’hardware che richiede l’accesso, come un laptop, uno smartphone, una chiave hardware o un sensore IoT, prima che la connessione venga accettata. L’autenticazione dell’utente dimostra chi sta chiedendo l’accesso; l’autenticazione del dispositivo dimostra che cosa lo sta chiedendo. La maggior parte delle architetture ha bisogno di entrambe, perché una password rubata fallisce su una macchina sconosciuta solo se la macchina viene verificata.

Il termine indica diversi meccanismi, con costi di sicurezza e di gestione del ciclo di vita molto differenti. Questa guida li distingue, spiega come funziona ciascuno, mostra dove è adatto e dove fallisce e si chiude con un piano per adottarlo. La guida è pubblicata da Hideez, fornitore di soluzioni per l’identità del personale, che descrive il proprio approccio solo nell’ultima sezione.

Che cos’è l’autenticazione basata sul dispositivo?

Che cos’è, dunque, l’autenticazione basata sul dispositivo? È un metodo che concede l’accesso verificando il dispositivo, non solo la persona. Il dispositivo dimostra la propria identità con un elemento crittografico, come un certificato o una chiave privata. L’autenticazione dell’utente, invece, verifica una password, un codice o un dato biometrico.

Si pensi a un laptop aziendale e alla VPN. Con il solo accesso tramite password, qualsiasi macchina che conosca le credenziali può connettersi, compresa quella di un attaccante. Con l’autenticazione del dispositivo, il gateway accetta il laptop solo se presenta un certificato X.509 registrato, la cui chiave privata resta nel TPM. Una password rubata da sola non basta più ad aprire la sessione. In pratica il termine comprende quattro approcci, e ciascuno dimostra qualcosa di diverso:

Regola decisionale: scelga il metodo il cui punto più debole è tollerabile per il Suo modello di minaccia, poi aggiunga un secondo livello.

Come funziona l’autenticazione basata sul dispositivo?

L’autenticazione del dispositivo dimostra che una richiesta proviene da una macchina o da un token specifico, non solo da un utente che conosce una password. Il server invia una sfida (challenge) e il dispositivo risponde con qualcosa che solo lui dovrebbe possedere. Ogni metodo segue questa sequenza:

1. Registrazione: il dispositivo viene registrato e associato a un utente tramite un cookie, un certificato o una chiave pubblica.
2. Challenge: il server chiede al dispositivo una prova.
3. Risposta: il dispositivo restituisce un cookie, un valore firmato o un report sulla postura.
4. Decisione: la policy di accesso concede, limita o nega la sessione.
5. Revoca: l’associazione viene rimossa quando il dispositivo viene smarrito o dismesso.

La robustezza dipende dall’identificatore usato al passaggio 3. Dal più debole al più forte:

• Indirizzo MAC: un identificatore, non un segreto, e facilissimo da falsificare.
• Segreto condiviso o cookie: può essere copiato e riutilizzato su un’altra macchina.
• Certificato con chiave esportabile: sicuro solo se la chiave privata non lascia il dispositivo.
• Chiave in un TPM o in un secure element: non esportabile, quindi la chiave resta sul chip.
• Credenziale FIDO2: vincolata all’origine, quindi un sito di phishing non può riutilizzarla.

A ogni livello corrisponde un attacco: falsificazione (spoofing), replay, estrazione della chiave e, al vertice, furto fisico.

Autenticazione basata sul dispositivo e autenticazione del dispositivo a confronto

Molte fonti usano le due espressioni come sinonimi, e nessun ente di normazione definisce una differenza tra loro. Questa guida adotta una distinzione operativa che aiuta nella scelta del metodo.

L’autenticazione del dispositivo identifica l’endpoint stesso. Risponde alla domanda “si tratta di una macchina nota?” e si applica a laptop, server e sensori IoT senza nessuno alla tastiera. Le prove tipiche sono un certificato X.509, una chiave custodita in un TPM o un segreto condiviso.

L’autenticazione basata sul dispositivo è più ampia. Comprende ogni schema in cui un dispositivo fa parte della prova di accesso, inclusi una chiave hardware o uno smartphone che rappresentano una persona. In questo caso il dispositivo funge da fattore di possesso.

La distinzione orienta la progettazione. Un certificato macchina non dice nulla su chi siede davanti al laptop, quindi occorre comunque affiancargli un fattore utente, di solito come passaggio MFA. Una chiave hardware dimostra il possesso da parte di una persona, ma non dice nulla sullo stato di salute del computer a cui è collegata. Consideri le due cose come livelli complementari.

Autenticazione basata sul dispositivo e autenticazione senza password a confronto

Il confronto tra autenticazione basata sul dispositivo e passwordless si riduce a che cosa viene eliminato e che cosa viene dimostrato. L’autenticazione senza password elimina la password dall’accesso. L’autenticazione basata sul dispositivo aggiunge un dispositivo a ciò che viene dimostrato. Le due si sovrappongono, ma non sono la stessa cosa.

• Entrambe: una passkey FIDO2 custodita su una chiave hardware o su uno smartphone. La password scompare e un dispositivo custodisce la credenziale.
• Senza password, senza vincolo al dispositivo: un codice o un link inviato via e-mail o SMS. La password scompare, ma nulla lega l’accesso a un dispositivo registrato, e il codice può essere inoltrato tramite un proxy di phishing.
• Basata sul dispositivo, ma non senza password: un certificato macchina per l’accesso Wi-Fi o VPN mentre l’utente continua a digitare una password nelle applicazioni, oppure un cookie del dispositivo attendibile che salta l’MFA ma mantiene la password.

Se il problema sono il riutilizzo delle password e il phishing, punti a un accesso senza password con credenziali vincolate all’origine. Se il problema sono le macchine non gestite che raggiungono la rete, un certificato del dispositivo o una verifica della postura sono la risposta più adatta. La maggior parte delle organizzazioni combina entrambi gli approcci.

Metodi comuni di autenticazione basata sul dispositivo

I quattro metodi seguenti sono le credenziali più usate per dimostrare il possesso da parte di persone e postazioni di lavoro. I cookie del dispositivo attendibile e le verifiche della postura, descritti sopra, restano utili come segnali aggiuntivi, e i loro limiti sono illustrati nella sezione dedicata ai rischi. Ogni metodo richiede cose diverse all’utente, al dispositivo e all’amministratore.

Chiavi di sicurezza hardware e autenticazione FIDO2

Le chiavi di sicurezza hardware sono piccoli autenticatori, collegati via USB, NFC o Bluetooth, che custodiscono chiavi private e firmano le challenge. Nell’autenticazione FIDO2 la chiave crea una coppia di chiavi distinta per ogni sito. La chiave privata non lascia mai il dispositivo, il server memorizza solo la chiave pubblica e la firma è vincolata all’origine del sito, quindi un sito di phishing su un altro dominio non può ottenere una risposta utilizzabile. La FIDO Alliance la descrive come crittografia a chiave pubblica in uno scambio challenge-response, senza alcun segreto condiviso che un attaccante possa intercettare.

L’utente sblocca la chiave con un PIN o un tocco, quindi un attaccante ha bisogno sia della chiave fisica sia del relativo PIN. Si tratta di credenziali vincolate al dispositivo in senso stretto: non lasciano mai l’hardware.

I costi sono operativi. Le chiavi vanno distribuite, e una chiave smarrita richiede un percorso di recupero che non diventi una backdoor debole: registri una seconda chiave per ogni utente, oppure verifichi l’identità prima di emettere una sostituzione, e revochi subito la chiave smarrita. Le certificazioni vengono rilasciate per singolo modello, quindi verifichi il modello esatto; Hideez Key 5, ad esempio, ha la certificazione FIDO2. Le chiavi hardware sono adatte a postazioni di lavoro condivise, ambienti in cui lo smartphone non è ammesso e account privilegiati.

Autenticazione tramite dispositivo mobile e passkey

Uno smartphone può dimostrare il possesso in tre modi: un’approvazione push, un codice monouso o una passkey. Un OTP è qualsiasi password monouso; il TOTP ne è la versione basata sul tempo, generata da un segreto condiviso e dall’orologio. Entrambi possono essere digitati in una pagina di phishing e inoltrati al sito reale in tempo reale. Una passkey non può essere inoltrata, perché è vincolata all’origine.

Le passkey sono credenziali FIDO, e la FIDO Alliance ne distingue due tipi. Le passkey sincronizzate vengono copiate sui dispositivi dell’utente tramite il servizio cloud del provider, il che introduce una dipendenza dall’account di sincronizzazione e dal relativo processo di recupero. Le passkey vincolate al dispositivo non lasciano mai un singolo dispositivo, e quelle custodite su chiavi di sicurezza hardware offrono il livello di garanzia più elevato. Nel flusso cross-device, uno smartphone effettua l’accesso su un laptop tramite un codice QR, mentre il Bluetooth conferma la vicinanza fisica.

Qualcuno può accedere a un’app di autenticazione? Solo con l’accesso fisico allo smartphone e al relativo metodo di sblocco, quindi imponga il blocco schermo e la biometria. I metodi basati sullo smartphone presuppongono inoltre un telefono personale, che molte camere bianche e molti magazzini vietano.

Autenticazione basata sulla prossimità

L’autenticazione basata sulla prossimità usa come segnale la vicinanza fisica di un token alla postazione di lavoro. L’NFC funziona a pochi centimetri: l’utente avvicina una chiave o un badge a un lettore, un gesto intenzionale difficile da attivare per errore. Il Bluetooth Low Energy funziona a qualche metro: la postazione stima la distanza dall’intensità del segnale, il che consente lo sblocco all’avvicinamento e il blocco all’allontanamento.

La stima è il punto debole. L’intensità del segnale varia con pareti, corpi e interferenze radio, quindi una soglia che funziona in una stanza può fallire in un’altra. Anche un attacco relay, in cui un attaccante inoltra il segnale tra un token lontano e la postazione, può ingannare uno sblocco basato solo sulla prossimità. La soluzione abituale è combinare la prossimità con un secondo segnale all’accesso, come un PIN o un tocco, e usare la prossimità soprattutto per il blocco, dove un’attivazione errata non comporta rischi.

Verifichi la soglia di distanza in ogni tipo di ambiente e imposti un breve ritardo di tolleranza, in modo che un rapido allontanamento non interrompa il lavoro.

Autenticazione del dispositivo basata su certificati

Nell’autenticazione del dispositivo basata su certificati, un’autorità di certificazione emette un certificato X.509 che lega una chiave pubblica all’identità di un dispositivo. Il dispositivo dimostra di possedere la chiave privata corrispondente firmando una challenge, di solito all’interno di un handshake TLS. Un gateway VPN, una rete Wi-Fi che usa l’802.1X o un’applicazione interna accettano solo gli endpoint che dispongono di un certificato emesso dalla Sua autorità.

I certificati possono essere usati per l’autenticazione? Sì, e sostituiscono la password per il dispositivo. Un certificato, però, non è automaticamente sicuro. Se la chiave privata è esportabile, può essere copiata su un’altra macchina. La conservi in un TPM o in un secure element, in modo che non possa lasciare il chip, e renda questo requisito obbligatorio al momento della registrazione.

L’onere è il ciclo di vita: emissione, rinnovo, scadenza e revoca. Certificati scaduti o orfani causano interruzioni del servizio, e un certificato mai revocato continua a funzionare dopo lo smarrimento del dispositivo. Censisca le date di scadenza prima del rollout e imposti avvisi con largo anticipo. Un indirizzo MAC, al contrario, è un identificatore trasmesso in chiaro e può essere copiato, quindi lo usi al massimo per l’inventario.

Vantaggi principali dell’autenticazione basata sul dispositivo

I vantaggi dipendono dal metodo scelto e da quanto bene viene gestito il ciclo di vita. Tre emergono per le organizzazioni che vanno oltre le sole password.

Protezione più forte contro phishing e furto di credenziali

Le credenziali vincolate all’origine eliminano il principale punto debole delle password: non esiste alcun segreto condiviso da carpire con il phishing, riutilizzare o divulgare. Una falsa pagina di login su un altro dominio non riceve nulla che il sito reale accetterebbe, e una violazione del database del server espone solo chiavi pubbliche. Il credential stuffing, che si basa su credenziali riutilizzate, non ha nulla su cui fare leva. Il NIST SP 800-63B-4, in versione definitiva da luglio 2025, definisce i requisiti tecnici per i livelli di garanzia degli autenticatori; verifichi con il Suo team di compliance a quale livello fa riferimento una normativa o un contratto.

La protezione ha dei limiti. Copre la credenziale, non l’endpoint. Un malware su un computer compromesso può sfruttare una sessione già autenticata, e un cookie del dispositivo attendibile può essere rubato e riutilizzato. Affianchi ai metodi basati sul dispositivo una protezione degli endpoint e non applichi la fiducia basata sui cookie agli account privilegiati. La resistenza al phishing dipende anche dalla registrazione: una credenziale registrata tramite un processo di recupero debole ne eredita la debolezza.

Accesso più rapido e comodo per gli utenti

Un tocco su una chiave o su un sensore è più rapido che digitare una password lunga e poi un codice. Meno password significano anche meno richieste di reset della password per password dimenticate all’helpdesk, almeno per le applicazioni coperte dal nuovo metodo. Un cookie del dispositivo attendibile riduce le richieste MFA ripetute sulle applicazioni a basso rischio, ed è questo il suo principale vantaggio in termini di usabilità.

Sulle postazioni di lavoro condivise, il cambio rapido di utente al cambio turno mantiene brevi le code. La comodità ha però delle condizioni. La registrazione richiede tempo, un utente senza chiave ha bisogno di un percorso di recupero che non richieda ore, e un lettore poco affidabile annulla rapidamente il vantaggio. Misuri i tempi di accesso e le richieste all’helpdesk durante un progetto pilota, invece di dare per scontato un miglioramento. Passkey e chiavi funzionano inoltre nei flussi del browser che gli utenti già conoscono, il che riduce la formazione e mantiene basso l’attrito nell’adozione. Tenga conto del carico di supporto della prima settimana, perché gli utenti dimenticano le chiavi a casa e digitano male il PIN.

Maggiore controllo sugli accessi aziendali

I metodi basati sul dispositivo legano ogni accesso a un dispositivo registrato e identificato, così gli amministratori possono sapere quale dispositivo ha effettuato l’accesso, quando e con quale policy. La registrazione può essere limitata a una rete attendibile o a un utente verificato. Le policy possono richiedere un PIN, limitare l’accesso a determinate applicazioni, stabilire regole diverse per amministratori e utenti ordinari o bloccare i dispositivi che non superano una verifica della postura.

La revoca è l’altra metà del controllo. Quando un laptop, una chiave o uno smartphone vengono smarriti, rimuoverne l’associazione ne interrompe l’accesso senza dover cambiare tutte le password dell’utente. Lo verifichi: revochi un dispositivo pilota e misuri quanto tempo impiega la revoca a diventare effettiva. I log di registrazioni, accessi e revoche forniscono inoltre agli auditor evidenze su come vengono gestite le credenziali, il che supporta la conformità senza garantirla. Esamini regolarmente gli stessi log per individuare i dispositivi che non effettuano l’accesso da mesi e andrebbero dismessi. Assegni un responsabile a ogni policy, in modo che le eccezioni vengano riesaminate anziché accumularsi.

Casi d’uso dell’autenticazione basata sul dispositivo

Gli stessi meccanismi si applicano in modo diverso a seconda di chi usa il dispositivo, dove e con quali vincoli. Tre casi d’uso ne mostrano la varietà.

Accesso senza password alle applicazioni aziendali

Una passkey o una chiave hardware può sbloccare l’identity provider, che a sua volta fa accedere l’utente alle applicazioni aziendali tramite single sign-on su SAML o OpenID Connect (OIDC). Un unico accesso sicuro sostituisce molte password, e le applicazioni non richiedono alcuna modifica. Inizi dalle applicazioni che contengono i dati più sensibili, poi ampli il perimetro man mano che gli utenti acquisiscono familiarità con il metodo.

Pianifichi le eccezioni. Le applicazioni legacy che non supportano nessuno dei due protocolli richiedono un gateway o un agente di iniezione delle credenziali, altrimenti mantengono le proprie password. Decida quale identity provider ospita la policy, ad esempio Microsoft Entra ID o Keycloak, e verifichi che accetti l’autenticatore scelto prima del rollout. Mantenga un percorso di recupero documentato, perché il passwordless senza recupero trasforma una chiave smarrita in un blocco dell’account. Testi l’accesso su ogni browser e sistema operativo usato dal personale. Per gli account amministrativi, richieda innanzitutto autenticatori resistenti al phishing, poi estenda l’obbligo al resto del personale.

Postazioni di lavoro condivise e personale operativo

Ciò che è possibile verificare dipende da chi controlla il dispositivo. Su un endpoint gestito, un agente segnala la postura del dispositivo. Su un dispositivo BYOD o di un collaboratore esterno non c’è alcun agente, quindi l’unico segnale affidabile è la prova crittografica che l’utente possiede una credenziale.

• Laptop gestito: verifica della postura più certificato o chiave FIDO2.
• BYOD: autenticatore FIDO2 o passkey; la postura è sconosciuta.
• Collaboratore esterno: credenziale a tempo, revocata alla scadenza del contratto.
• Postazione kiosk condivisa: un autenticatore hardware per utente, con blocco della sessione all’allontanamento.

Una verifica della postura descrive lo stato di un dispositivo, mentre un autenticatore FIDO2 dimostra il possesso, non lo stato di salute. Per l’accesso alle postazioni di lavoro condivise il vincolo è spesso lo smartphone: camere bianche, aree sterili e magazzini escludono le notifiche push e la registrazione tramite QR, quindi un metodo basato su tocco o badge diventa la soluzione di base più pratica. Anche guanti e camici sterili rendono poco pratico digitare password, e un cambio turno richiede un cambio rapido di utente.

Accesso di prossimità e blocco automatico della postazione

Negli ambienti sanitari, industriali e logistici, l’autenticazione alla postazione di lavoro avviene molte volte per turno, spesso con i guanti o con le mani occupate. Digitare ogni volta una password è lento, e chi lo trova troppo lento lascia le sessioni aperte o condivide le credenziali.

L’accesso di prossimità risolve entrambi gli aspetti. Un tocco o un avvicinamento avvia la sessione, e il blocco automatico la chiude quando l’operatore si allontana, così uno schermo incustodito non resta aperto per la persona successiva. Combini un breve timer di inattività con il blocco basato sulla prossimità, in modo che uno qualsiasi dei due eventi chiuda la sessione. Questo agevola anche gli audit: ogni sessione ha così un inizio chiaro, una fine chiara e un utente identificato.

Prima dell’implementazione, verifichi tre situazioni: il cambio rapido di utente al cambio turno, un operatore che lascia il token sulla scrivania e un token con la batteria scarica. Ciascuna richiede un esito definito, come un blocco, un intervento del supervisore o un token di riserva.

Rischi e limiti di sicurezza dell’autenticazione basata sul dispositivo

La sicurezza dell’autenticazione basata sul dispositivo varia a seconda del metodo, perché ciascuno fallisce in un punto diverso e richiede controlli specifici. Elenchi prima ciò di cui l’attaccante ha bisogno, poi assegni a ogni rischio un controllo, un responsabile e un test.

• Cookie del dispositivo attendibile: basta rubare il cookie una volta, e funziona da qualsiasi macchina.
• Verifica della postura: falsificare lo stato segnalato o compromettere l’agente che lo segnala.
• Certificato: estrarre una chiave privata esportabile o usare un certificato mai revocato.
• OTP: inoltrare il codice tramite un proxy di phishing.
• Autenticatore FIDO2: disporre del dispositivo fisico e superarne il PIN.

Il piano di mitigazione associa a ogni rischio un controllo, un responsabile e un test:

• Dispositivo smarrito: revocare l’associazione (team di gestione delle identità e degli accessi). Revocare un dispositivo pilota e misurare i tempi dell’effetto.
• Chiave esportabile: imporre l’archiviazione nel TPM (team endpoint). Tentare un’esportazione.
• Certificato scaduto: inviare un avviso prima della scadenza (responsabile PKI). Testare in staging con un certificato a breve durata.
• Recupero debole: verificare l’utente prima di emettere i codici (helpdesk). Richiedere il recupero fingendosi un impostore.
• Cookie di sessione rubato: ridurre la durata della sessione e vincolare le sessioni al dispositivo, se la piattaforma lo consente (responsabile dell’applicazione). Riutilizzare un cookie intercettato da un’altra macchina in un ambiente di test.

Ogni metodo aggiunge inoltre un ciclo di vita da gestire, e una credenziale forte con un processo di recupero debole è sicura solo quanto il recupero stesso.

Come implementare l’autenticazione basata sul dispositivo in un’organizzazione

L’implementazione consiste soprattutto nella gestione del ciclo di vita. La conduca come una sequenza e assegni un responsabile a ogni passaggio:

1. Provisioning: scegliere il metodo per ogni segmento del parco dispositivi e preparare le credenziali.
2. Associazione all’utente: registrare ogni dispositivo a nome di una persona verificata.
3. Applicazione delle policy: definire quali applicazioni richiedono quale metodo.
4. Monitoraggio: registrare nei log registrazioni, accessi ed errori di policy.
5. Recupero: definire come un utente riottiene l’accesso dopo uno smarrimento.
6. Revoca: rimuovere rapidamente l’associazione e verificare quanto velocemente funziona.
7. Dismissione: ritirare le credenziali quando i dispositivi escono dal servizio.

Mappi i controlli sui framework utilizzati dai Suoi auditor. I metodi basati sul dispositivo supportano la conformità producendo evidenze verificabili; da soli non rendono un’organizzazione conforme.

• NIST SP 800-53: IA-3 (identificazione e autenticazione dei dispositivi) corrisponde ai certificati e agli autenticatori vincolati all’hardware. IA-5 (gestione degli autenticatori) corrisponde a emissione, policy sui PIN e revoca.
• NIST SP 800-207: i principi sulla postura dei dispositivi corrispondono alle verifiche della postura eseguite prima di ogni decisione di accesso.
• ISO/IEC 27001:2022: A.5.15 (controllo degli accessi), A.5.16 (gestione delle identità) e A.8.5 (autenticazione sicura) corrispondono a registrazione, revoca e applicazione dell’MFA.
• NIS2 e PCI DSS 4.0: questi framework trattano l’MFA e il ciclo di vita degli autenticatori.

Faccia verificare al Suo Data Protection Officer o al responsabile della compliance la formulazione esatta delle clausole rispetto al Suo perimetro prima che entri in un fascicolo di audit. Poi inizi in piccolo: avvii un progetto pilota con un solo metodo e un solo team, su un mix reale di dispositivi gestiti e non gestiti, verifichi la revoca su un dispositivo smarrito e ampli il perimetro.

Come scegliere una piattaforma di autenticazione basata sul dispositivo

Una piattaforma di autenticazione basata sul dispositivo va valutata in base al ciclo di vita che gestisce, non solo alla schermata di accesso. Confronti i candidati secondo questi criteri:

• Metodi supportati: chiavi hardware, passkey, certificati e prossimità, così che ogni segmento del parco dispositivi disponga di un metodo adeguato.
• Registrazione e revoca: chi può registrare un dispositivo, come viene prima dimostrata l’identità e quanto rapidamente una revoca diventa effettiva.
• Recupero: un percorso documentato per un autenticatore smarrito che non indebolisca il modello di sicurezza.
• Modello di implementazione: self-hosted, cloud privato o cloud multi-tenant, in base ai vincoli sui dati e sulla loro residenza.
• Integrazione: protocolli standard (SAML, OIDC, WS-Federation) e connettori pubblicati verso la Sua directory e il Suo identity provider.
• Uso offline e condiviso: comportamento quando la rete non è disponibile e cambio rapido di utente sulle postazioni condivise.
• Evidenze: certificazioni per i modelli specifici di autenticatore e log di audit esportabili.

Chieda a ogni fornitore di dimostrare revoca e recupero su un gruppo pilota, non solo la registrazione.

Autenticazione basata sul dispositivo con Hideez

Hideez Workforce Identity utilizza smartphone, passkey e chiavi di sicurezza hardware per autenticare i dipendenti nelle applicazioni aziendali e sulle postazioni di lavoro Windows. Gli amministratori gestiscono utenti, autenticatori registrati e policy di accesso tramite Hideez Enterprise Server, disponibile nel cloud, in un cloud privato oppure on-premise. Hideez è membro certificato della FIDO Alliance e possiede la certificazione ISO 27001.

I dipendenti possono usare l’app mobile Hideez Authenticator o una chiave di sicurezza FIDO2 come Hideez Key 5. Nell’autenticazione FIDO2, l’autenticatore dimostra il possesso di una credenziale crittografica senza trasmettere una password riutilizzabile. Tramite Passwordless SSO, quell’accesso consente di raggiungere le applicazioni collegate tramite SAML o OpenID Connect. L’integrazione con Active Directory e Microsoft Entra ID permette alle organizzazioni di mantenere la directory dei dipendenti esistente.

Sui computer Windows, Hideez consente l’accesso senza password e l’accesso basato sulla prossimità. Uno smartphone o una Hideez Key possono attivare il blocco automatico della sessione quando il dipendente si allontana. Ciò è utile sulle postazioni di lavoro condivise, dove i dipendenti si alternano spesso e possono dimenticare di bloccare lo schermo. Le chiavi hardware offrono un’alternativa negli ambienti in cui gli smartphone personali sono soggetti a restrizioni.

Hideez Key 5 può inoltre ospitare una credenziale di accesso fisico per lettori di porte e tornelli compatibili, permettendo ai dipendenti di usare lo stesso dispositivo per l’autenticazione alla postazione di lavoro e per l’accesso all’edificio.

Per scoprire come Hideez funzionerebbe con i Suoi dispositivi e le Sue applicazioni, richieda una demo. Potrà poi avviare un progetto pilota gratuito per testare l’accesso, il blocco automatico della postazione e la gestione degli autenticatori nel Suo ambiente. Per domande su compatibilità o opzioni di implementazione, contatti il team commerciale di Hideez.