EAP-TLS vs PEAP: sicurezza, certificati e idoneità
Published
Il consiglio più comune sul confronto eap tls vs peap è semplice, ma errato. Scegliere EAP-TLS perché è "più sicuro" e lasciare PEAP ai team che non si sono ancora aggiornati significa ignorare la domanda fondamentale che determina se una WLAN con più sedi continuerà a funzionare. Siete in grado di rilasciare, rinnovare e revocare un certificato per ogni dispositivo che dovrebbe utilizzarlo?
Non applicherei un unico metodo all'intera struttura. EAP-TLS appartiene ai dispositivi che è possibile registrare e rinnovare. PEAP, quasi sempre con EAP-MSCHAPv2 interno, appartiene ai casi in cui esiste già una password di directory e la registrazione dei certificati non è pratica. Il metodo più complesso non è sempre quello eseguibile. Un certificato scaduto nel retroufficio di un hotel blocca il personale mentre i relativi account rimangono validi. Un profilo PEAP che omette la verifica del server può consegnare una password di directory a un access point canaglia. Entrambi i fallimenti sono operativi. Assegna il metodo alla popolazione specifica invece di cercare una soluzione unica per tutta la rete.
Sommario
- EAP-TLS e PEAP a confronto
- Come si autentica ciascun metodo e dove si verificano le fughe di password
- Requisiti dei certificati prima del rollout
- Ciclo di vita dei certificati e impegno di rollout
- Revoca, velocità di roaming e supporto client
- Assegnare ciascuna popolazione e verificare la suddivisione
Confronto diretto tra EAP-TLS e PEAP
La differenza pratica tra EAP-TLS e PEAP risiede nelle credenziali supportate da ciascun endpoint e nel lavoro necessario per mantenerle utilizzabili. Utilizzare EAP-TLS per i dispositivi che è possibile iscrivere e rinnovare. Utilizzare PEAP dove gli utenti dispongono già di password di directory e l'iscrizione dei certificati non è pratica. Nessuno dei due metodi rappresenta la soluzione unica per ogni gruppo di utenti.
| Criterio | EAP-TLS | PEAP |
|---|---|---|
| ID tipo EAP | 13 | 26 |
| Credenziale client | Certificato client X.509 | Nome utente e password, di solito EAP-MSCHAPv2 o EAP-GTC |
| Credenziale server | Certificato server RADIUS | Certificato server RADIUS sul tunnel TLS esterno |
| Autenticazione reciproca | Certificati client e server | Certificato server più autenticazione utente o dispositivo interna |
| Password in transito | Nessuna | Sì, all'interno del tunnel TLS |
| Cosa può rubare un AP malevolo se il client ignora i controlli del server | Nulla di simile a una password; l'autenticazione fallisce in modo sicuro | Password di directory |
| Revoca di un singolo dispositivo | Revocare o far scadere quel certificato | Disabilitare l'account o reimpostare una password che potrebbe essere riutilizzata |
| Lavoro di PKI | Certificati server e client, rinnovo e ripristino | Solo certificato server |
| Migliore scelta iniziale | Personale gestito da MDM e dispositivi con privilegi | Endpoint non gestiti che non possono iscrivere certificati |
Un articolo tecnico di Authentik del 2025 identifica l'EAP-TLS come tipo EAP ID 13 e il PEAP come tipo ID 26. Questi ID identificano i metodi per il server RADIUS e per il supplicant. Non determinano quali persone o dispositivi debbano utilizzarli.
Cosa modificano effettivamente le righe
Le credenziali del client definiscono il confine operativo. EAP-TLS presenta un certificato client X.509. PEAP utilizza nome utente e password, comunemente tramite EAP-MSCHAPv2 o EAP-GTC. Ciò rende la registrazione e il rinnovo dei certificati il carico di lavoro determinante, piuttosto che una classificazione teorica dei metodi.
Anche i controlli di affidabilità differiscono. EAP-TLS autentica sia il certificato del client che quello del server. PEAP convalida il certificato del server RADIUS sul tunnel TLS esterno, quindi autentica l'utente o il dispositivo con un metodo interno.
L'esposizione della password dipende dalla configurazione del supplicant. L'EAP-TLS non trasmette alcuna password in rete. Il PEAP trasporta una password all'interno del suo tunnel, quindi un client che salta i controlli del server può rivelare una password di directory a un access point canaglia. Con l'EAP-TLS, un certificato client mancante o non attendibile causa il fallimento dell'autenticazione.
L'offboarding dipende anche da ciò che viene gestito. Un certificato dispositivo può essere revocato o lasciato scadere senza dover reimpostare la password di directory della persona. Disabilitare un account o modificare una password riutilizzata potrebbe influire su altri accessi collegati a quella credenziale.
Il compromesso operativo è chiaro: EAP-TLS richiede certificati client, rinnovo e un percorso di ripristino, mentre PEAP richiede il certificato del server e un'attenta configurazione del supplicant. Assegna EAP-TLS al personale registrato e ai dispositivi con privilegi; mantieni PEAP per gli endpoint non gestiti che non possono aderire alla gestione dei certificati. I team che gestiscono infrastrutture serverless per piattaforme di tesseramento possono avere popolazioni distinte di membri, personale e dispositivi, ma il modello di hosting non sceglie il metodo di autenticazione. Le credenziali devono corrispondere a chi è possibile gestire.
Come si autentica ciascun metodo e dove si verificano le fughe di password
EAP-TLS non è automaticamente la risposta giusta per ogni utente. La decisione chiave è se il tuo team è in grado di emettere, rinnovare e revocare i certificati in modo affidabile per ciascun gruppo di utenti. PEAP mantiene l'onboarding più semplice per gli utenti non gestiti, ma la sua password dipende dalla corretta configurazione del supplicant.
Entrambi i metodi utilizzano l'802.1X. Il supplicant è il dispositivo che richiede l'accesso, l'authenticator è l'access point o lo switch che inoltra la richiesta e il server RADIUS la accetta o la rifiuta. Condividono il framework EAP, non una credenziale.
L'indice delle specifiche IETF EAP descrive EAP-TLS, definito in IETF RFC 5216, come un'autenticazione client e server basata su certificati, con autenticazione reciproca, negoziazione della suite di cifratura protetta dall'integrità e derivazione della chiave. La specifica è stata pubblicata nel marzo 2008. In pratica, EAP-TLS richiede un certificato client emesso tramite PKI, insieme al certificato del server RADIUS.
Due sequenze, un unico framework
EAP-TLS autentica entrambi gli endpoint in un unico scambio TLS:
- Il supplicant avvia EAP con l'autenticatore, che inoltra la richiesta al RADIUS.
- I certificati del server e del client vengono verificati durante lo scambio TLS.
- Lo scambio protegge la negoziazione delle cipher suite e deriva le chiavi, senza inviare una password che possa essere soggetta a phishing, replay o attacchi brute-force.
- Un certificato client mancante o non attendibile comporta il rifiuto del dispositivo. Non è possibile ripiegare sull'inserimento di una password.
Il protocollo PEAP crea un tunnel TLS esterno che autentica il server, per poi eseguire un metodo interno, comunemente EAP-MSCHAPv2 o EAP-GTC. Poiché il metodo interno può utilizzare un nome utente e una password, gli endpoint generalmente non richiedono certificati client. L'indice delle specifiche IETF EAP descrive inoltre il quadro normativo utilizzato da questi metodi.
Gli utenti non vedono il tunnel esterno di PEAP. L'identità interna, solitamente un nome utente e una password o un token, viene inviata solo dopo che TLS è stato stabilito. Ciò rende PEAP familiare per i supplicant basati su directory, lasciando però una password esposta se il client non verifica correttamente il tunnel.
PEAP con EAP-TLS interno è un caso particolare più articolato, che combina un metodo basato su certificati con un tunnel TLS esterno. Una distribuzione denominata “PEAP” indica solitamente PEAP-MSCHAPv2.
Dove il supplicant determina il risultato
Un approfondimento sui metodi EAP aziendali per il wireless ne spiega la differenza: EAP-TLS utilizza l'autenticazione reciproca X.509. Il server RADIUS convalida il certificato del client e il client convalida il certificato del server. Nessuna password può essere oggetto di phishing, replay o attacchi brute-force. L'approfondimento precisa inoltre che il NIST richiede che sia la stazione wireless sia il server di autenticazione possiedano certificati validi.
Con PEAP, il client deve convalidare la catena del certificato RADIUS e il nome del server previsto. Se manca uno dei due controlli, un access point canaglia può richiedere una password di directory. Un profilo supplicant impostato su "non convalidare" non protegge la password.
Regola pratica: Fissa il nome del server RADIUS e la CA emittente nel profilo WiFi. Senza questi controlli, PEAP può trasmettere una password a un server canaglia.
Le risposte MS-CHAPv2 intercettate possono essere violate offline dopo che un malintenzionato le ha ottenute attraverso un tunnel canaglia. La convalida del tunnel è il controllo principale; il metodo interno non protegge un profilo che accetta un server non attendibile. Lo stesso rischio legato alle password va oltre il WiFi. I report sulle credenziali compromesse nelle piccole imprese australiane sottolineano perché una password di directory riutilizzata rimanga un bersaglio di valore per un malintenzionato.
Assegnate EAP-TLS ai dispositivi gestiti e agli utenti di cui potete gestire il ciclo di vita dei certificati. Utilizzate PEAP dove gli utenti o i dispositivi non possono ricevere e rinnovare i certificati in modo affidabile, ma imponete la convalida della CA e del nome del server tramite il profilo del supplicant. Il compromesso operativo è diretto: i certificati richiedono lavoro di registrazione e ripristino, mentre le password costringono a gestire la riutilizzazione e le modifiche degli account. Il metodo migliore dipende da chi si è in grado di gestire, non dal dichiarare un unico vincitore per ogni SSID.
Requisiti dei certificati prima del rilascio
Conferma questi sei elementi in laboratorio prima del primo inserimento in produzione. Una catena mancante o un nome errato sembreranno un problema di "WiFi non funzionante," e non un errore di certificato.
- Certificato del server RADIUS. Emettilo dalla tua CA privata. Inserisci il nome che il profilo supplicant associa nel subject o SAN. Imposta l'uso dell'autenticazione server e fornisci la catena intermedia completa con il certificato. Una CA pubblica che firma qualsiasi nome corrispondente è il modello di trust errato per un nome RADIUS interno.
- Certificato client. Uno per dispositivo o utente, con uso dell'autenticazione client. Inserisci un'identità univoca nel SAN, come un nome principale utente o un seriale del dispositivo. Archivia la chiave privata nel TPM o nella secure enclave quando la piattaforma lo supporta.
- Trust anchor. Installa la CA root o di emissione interna tramite il profilo MDM. Non puntare i dispositivi su una root pubblica sperando che il controllo del nome sia sufficiente.
- Validità e rinnovo. Definisci una durata per il certificato del server e per i certificati client. Crea una finestra di sovrapposizione in modo che il sostituto venga installato prima della scadenza del vecchio certificato.
- Revoca. Fornisci al server RADIUS un endpoint CRL o OCSP raggiungibile. Decidi, per iscritto, se l'autenticazione ha esito negativo o prosegue quando tale endpoint è offline. Testa il caso offline. Non scoprirlo durante un'interruzione della rete WAN.
- Canale di registrazione. Distribuisci i certificati con SCEP o un PKCS#12 tramite l'MDM. Verificalo su un dispositivo, compreso il rinnovo, prima di distribuirlo a un gruppo.
Supponiamo che una clinica utilizzi Okta per l'identità del personale e Intune per i laptop. Il nome RADIUS nel profilo deve corrispondere al certificato, e il gruppo Okta che deve accedere alla VLAN clinica deve essere lo stesso gruppo utilizzato dall'MDM per la registrazione. Le nostre note sull'autenticazione WiFi con Okta spiegano questo passaggio di identità senza trasformare il laboratorio in uno SSID protetto da password.
Connetti un laptop di test, revoca il suo certificato e verifica che l'associazione successiva fallisca prima di intervenire su un ambiente operativo reale.
Ciclo di vita dei certificati e impegno di implementazione
La sicurezza dell'EAP-TLS si trasforma in un'interruzione del servizio quando un certificato scade, o quando un client non riesce a raggiungere le informazioni di revoca, mentre l'account utente è ancora perfettamente valido. È questa la vera questione da porsi. Dire che "i certificati sono più difficili" non equivale a progettare un'architettura.
NIST Special Publication 800-120 inquadra lo stesso problema. EAP-TLS richiede affidabilità in emissione, distribuzione, rinnovo, gestione della catena di attendibilità e verifica della revoca. Un dispositivo con un certificato scaduto o un servizio di revoca irraggiungibile può perdere l'accesso alla rete anche quando l'identità dell'utente rimane valida. PEAP autentica in genere il server nella fase TLS esterna e un nome utente e password tramite un metodo interno come MS-CHAPv2, saltando il ciclo di vita del client. La maggiore semplicità iniziale sposta il carico sulla reimpostazione delle password e sui profili errati.
Evitare che i certificati diventino la causa dei disservizi
La risposta in fase di progettazione è l'automazione, non un manuale operativo più lungo.
- Iscrizione tramite MDM. Inviare il profilo, l'ancora di attendibilità e il certificato insieme. La configurazione manuale del WiFi è il motivo per cui i controlli sul nome del server vengono deselezionati.
- Sovrapposizione del rinnovo. Installare il nuovo certificato prima che quello vecchio scada. Un fine settimana in cui ogni laptop smette di funzionare contemporaneamente è dovuto a una sovrapposizione troppo breve.
- Testare la revoca offline. Verificare se il RADIUS si blocca in modalità di chiusura (fail closed) o di apertura (fail open) quando non è possibile recuperare la CRL o l'OCSP.
- Mantenere un percorso di ripristino. Un endpoint con errori necessita di una via di ritorno che non sia "chiedere in prestito la password PEAP di qualcuno." Una porta helpdesk cablata o un SSID di ripristino con ambito ristretto è preferibile a un segreto condiviso scritto su una lavagna.
Purple Access accetta i certificati EAP-TLS da Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru e Addigy, distribuiti tramite SCEP, con una configurazione che richiede da cinque a dieci minuti una sola volta per l'organizzazione anziché per singolo dispositivo. La rete sicura è senza password e basata su certificati, e a un dispositivo che non soddisfa i requisiti di postura viene rifiutato l'accesso all'autenticazione tramite Conditional Access. Si tratta di un accesso vincolato alla conformità, non di una seconda richiesta di password.
PEAP rimane la scelta più semplice quando l'infrastruttura PKI è poco sviluppata, quando i collaboratori esterni non possono essere inclusi nel sistema MDM o quando gli ambienti BYOD misti non accettano un certificato. Il settore sanitario, l'istruzione, l'accoglienza e altre realtà con più sedi si trovano spesso ad affrontare tutte e tre le sfide contemporaneamente. Utilizzate EAP-TLS per i dispositivi aziendali gestiti, per il personale e per i dispositivi ad alto rischio. Mantenete un'alternativa rigorosamente controllata per i terminali non gestiti o temporanei. La decisione chiave riguarda l'identità a livello di sede, non lo slogan secondo cui TLS è superiore alle password.
Se è la stessa infrastruttura RADIUS a costituire l'elemento fragile, un backend in cloud elimina il rischio del singolo server nell'armadio della sede centrale. Il nostro approfondimento su RADIUS-as-a-Service è il punto di riferimento per verificare raggiungibilità e ridondanza prima di attribuire la colpa al metodo EAP.
La breve procedura mostrata di seguito illustra la registrazione del certificato insieme a un metodo interno basato su password, offrendo il confronto che gli helpdesk vedono quando il rinnovo è in ritardo.
Velocità di roaming in caso di revoca e supporto client
Supporto e velocità sono problemi di consultazione. I supplicant attuali di Windows, macOS, iOS, Android e ChromeOS supportano entrambi i metodi. Ciò che differisce è la modalità di errore.
EAP-TLS non funziona quando il profilo, la CA emittente o le date di validità sono errati. PEAP non funziona quando il metodo interno, il formato dell'identità o il controllo del nome del server non corrispondono ai criteri RADIUS. Nessuno dei due errori significa che l'access point "non supporta la modalità enterprise."
La revoca presenta la stessa suddivisione. La disabilitazione del certificato di un singolo dispositivo isola quel laptop senza toccare gli altri accessi dell'utente. La reimpostazione di una password di directory impatta su ogni client non gestito che la sta ancora utilizzando. L'interruzione immediata e specifica per singolo dispositivo è il vantaggio dell'EAP-TLS. I blocchi improvvisi dovuti a certificati scaduti ne rappresentano il costo.
Handshake, non nomi di brand
Un documento ACM sulla latenza dell'autenticazione wireless rileva che le prestazioni dipendono dal numero di handshake, dal roaming, dalla convalida del certificato e dalla latenza del backend, piuttosto che dal nome del metodo. Il formato standard EAP-TLS completa l'autenticazione del certificato client e server nel suo scambio TLS. PEAP stabilisce un tunnel TLS e poi esegue l'autenticazione interna, aggiungendo una fase distinta. La documentazione tecnica Cisco citata in quel documento rileva che PEAP con EAP-TLS interno comporta due handshake TLS e può risultare lento quando si verifica una riautenticazione completa durante il roaming.
Misura questi parametri separatamente. Non decretare un vincitore basandoti su un singolo tempo medio di accesso.
- Tempo di associazione all'IP al 95° percentile
- Latenza di autenticazione completa rispetto al ripristino del roaming
- Tempo di round-trip RADIUS
- Tasso di errore di autenticazione
- Errori di rinnovo del certificato
Il ripristino della sessione, il caching PMK o lo standard 802.11r, la raggiungibilità locale del RADIUS e una catena di certificati breve incidono su questi numeri molto più della sostituzione di una cipher suite. PEAP può sembrare semplice il primo giorno ma generare ritardi a causa di continui scambi di password e interventi sugli utenti. EAP-TLS può sembrare istantaneo dopo la registrazione per poi bloccarsi del tutto alla scadenza di un certificato.
| Sintomo | Metodo più probabile | Causa usuale | Soluzione pratica |
|---|---|---|---|
| Richiesta di password ripetuta vicino a un AP sconosciuto | PEAP | Il supplicant non convalida il nome del server o la catena | Distribuire un profilo che vincola il nome RADIUS e la CA |
| Accesso interrotto su un laptop dopo una modifica del ruolo | EAP-TLS | Certificato revocato o dispositivo rimosso dall'MDM | Confermare la revoca e re-iscrivere solo quel dispositivo |
| Intera squadra bloccata di lunedì | EAP-TLS | Certificati scaduti contemporaneamente o finestra di rinnovo troppo breve | Pianificare il rinnovo prima della scadenza e mantenere un percorso di ripristino |
| Il roaming risulta lento solo durante la riautenticazione completa | PEAP con EAP-TLS interno | Due handshake TLS | Preferire il ripristino, la memorizzazione nella cache PMK o l'802.11r; evitare EAP-TLS interno a meno che non sia richiesto |
| Rifiuti casuali solo in una sede | Entrambi | Round-trip RADIUS o recupero della catena, non il nome EAP | Misurare RTT e il 95° percentile da associazione a IP prima di cambiare metodo |
Un roaming lento in una sede è di solito dovuto alla distanza del server RADIUS o al recupero della catena, non è la prova che sia stato scelto il tipo EAP errato.
Assegnare ogni gruppo di utenti e dimostrare la separazione
Un singolo edificio può ospitare i laptop del personale, un ospite in sala conferenze, il Mac di un esterno e un registratore di cassa. Non dovrebbero condividere lo stesso tipo di credenziale. Mappa ciascun gruppo, avvia un progetto pilota in una sede accanto alla rete esistente e valuta i ticket oltre al registro di autenticazione prima di replicare la configurazione.
| Popolazione | Utilizzare | Non utilizzare | Motivo |
|---|---|---|---|
| Personale gestito da MDM e utenti con privilegi | EAP-TLS su SSID WPA-Enterprise | PSK condiviso o PEAP | Identità basata su certificato, VLAN per gruppo, l'accesso termina quando l'account viene disabilitato |
| Ospiti per brevi soggiorni e visitatori | Captive Portal o Passpoint su una VLAN ospiti | Iscrizione PEAP o EAP-TLS alla reception | Nessun ciclo di vita del certificato e nessuna password di directory da sottoporre a phishing |
| Laptop non gestiti e fornitori esterni | PEAP-MSCHAPv2 solo con convalida del server forzata | EAP-TLS se non è possibile iscriverli o rinnovarli | Le password esistono già, ma il profilo deve verificare il certificato RADIUS |
| Stampanti, TV, casse, CCTV e sensori | PSK per dispositivo con VLAN dedicata | EAP-TLS o una password PEAP condivisa | Questi dispositivi di solito non possono memorizzare certificati e una chiave condivisa è difficile da ruotare |
| Sede mista in un unico edificio | Suddivisione per identità su VLAN separate | Un solo SSID e un solo metodo per tutti | Personale, ospiti e dispositivi falliscono in modi diversi e non dovrebbero condividere lo stesso tipo di credenziale |
Chi continua a usare le password e chi deve evitarlo
Il personale gestito e gli utenti con privilegi ottengono l'EAP-TLS su uno SSID WPA-Enterprise. Il personale addetto alle pulizie, alla reception e alle operations può autenticarsi con i certificati di un MDM tramite SCEP, accedere a una VLAN in base al gruppo di directory e perdere l'accesso quando l'account viene disabilitato. Una PSK condivisa o una password PEAP ricrea proprio il problema che stavi cercando di eliminare.
Gli ospiti e i visitatori rimangono su un Captive Portal o Passpoint, su una VLAN ospiti. Non registrare i certificati alla reception e non inserirli su PEAP. Non c'è alcun ciclo di vita da gestire e c'è una password di directory che non vuoi venga sottoposta a phishing. Un profilo Passpoint può riconnettersi alla visita successiva senza aprire un nuovo ticket.
I laptop non gestiti e i fornitori esterni possono rimanere su PEAP-MSCHAPv2, ma solo se il profilo impone la convalida del server. Se non puoi registrarli o rinnovarli, l'EAP-TLS li lascerà bloccati. Se non puoi imporre il controllo del server, il rischio legato alla password supera la comodità, e tali utenti non dovrebbero affatto stare sullo SSID del personale.
Stampanti, TV, casse, EPOS, CCTV, sensori e controlli accessi ottengono una PSK per singolo dispositivo e una propria VLAN. In genere questi dispositivi non possono memorizzare certificati. Una password PEAP condivisa ripresenta il problema della chiave condivisa. Il requisito PCI DSS v4.0.1 Req 2.3.2 impone che le chiavi wireless vengano modificate quando chiunque le conosca lasci l'azienda, il che rende impraticabile l'uso di una chiave condivisa. xPSK è la soluzione adatta per questi dispositivi. Le TV delle camere, i termostati e le casse devono essere associati a VLAN vincolate da chiavi che gli ospiti non vedono mai.
Provalo su un unico sito
Applica il nuovo progetto sugli access point già presenti nella sede, accanto alla rete attuale. Valuta i risultati in base ai ticket e alle evidenze di audit, non su un login di prova.
È necessario un registro di autenticazione che memorizzi ogni accettazione e rifiuto con identità, dispositivo, stato di registrazione MDM, metodo, access point, SSID, sede, VLAN, ruolo, motivo e orario. Questo stesso registro costituisce la prova per i controlli di accesso e registrazione della norma ISO 27001 e per i requisiti 8 e 10 di PCI-DSS. Senza MDM, occorre prima blindare i profili PEAP e pianificare i certificati solo per la popolazione gestita.
Possiamo gestire questa suddivisione come tre reti per struttura. Gli ospiti utilizzano il Captive Portal, compresa una verifica della camera tramite PMS dove presente. Il personale utilizza EAP-TLS o Passpoint. I dispositivi IoT utilizzano chiavi per singolo dispositivo. RADIUS basato su cloud invia ciascun dispositivo alla rete e alla VLAN corrette in base all'identità, e rifiuta un utente in uscita il cui account è stato disabilitato. Il percorso di migrazione da una password del personale condivisa è lo stesso descritto nella nostra guida per migrare il WiFi del personale multi-sede su 802.1X.
Inizierei il progetto pilota con l'SSID del personale gestito e le chiavi per dispositivo per i registratori di cassa, lasciando i collaboratori esterni su un profilo PEAP convalidato fino a quando l'iscrizione non sarà effettiva. Un unico metodo per tutti appare più ordinato in un diagramma, ma genera tre diversi tipi di errore sul campo.
Purple Access gestisce il WiFi del personale basato su certificati e chiavi per singolo dispositivo per gli apparati sugli access point già in tuo possesso, trasformando la scelta tra EAP-TLS e PEAP in una decisione basata sugli utenti anziché in un rischio per l'intera infrastruttura. Puoi testare reti aperte, sicure e xPSK in un'unica sede, per poi valutare i ticket e il registro delle autenticazioni prima di un'implementazione più ampia. Visita Purple Access per mappare le reti del personale, degli ospiti e dei dispositivi.
