Autenticazione WiFi senza password: Oltre le Pre-Shared Key

This guide provides IT managers, network architects, and venue operations directors with a practical roadmap for eliminating shared WiFi passwords and migrating to identity-based, certificate-driven authentication. It covers the security and compliance failures of PSK-based networks, the technical architecture of 802.1X and EAP-TLS, and the role of Identity PSK (iPSK) as a critical transition technology for IoT and legacy devices. Venue operators in hospitality, retail, and the public sector will find actionable migration strategies, real-world implementation scenarios, and measurable business outcomes to justify the investment.

📖 10 min di lettura📝 2,312 parole🔧 2 esempi❓ 4 domande📚 10 termini chiave

🎧 Ascolta questa guida

Visualizza trascrizione

Hello, and welcome to this Purple technical briefing. I am your host, and today we are tackling a fundamental shift in enterprise network security: the move away from Pre-Shared Keys, or PSKs, towards passwordless, identity-based WiFi authentication.

If you are managing the network for a hotel chain, a retail enterprise, a stadium, or a public-sector organisation, you already know the headache of the shared WiFi password. It is written on whiteboards, printed on menus, and shared endlessly. But beyond the operational friction, PSKs represent a significant security vulnerability at scale. Today, we will explore why PSKs are no longer fit for purpose in the enterprise, and how you can migrate to secure, certificate-based 802.1X authentication without disrupting your users.

Let us start with the context. Why is the industry moving away from the trusty WPA2-PSK?

The core issue is lack of identity. When everyone uses the same password to join a network, the network has no idea who is actually connecting. Is it a legitimate guest, an employee's personal device, or someone sitting in the car park who saw the password on a receipt? You simply cannot tell. This lack of identity attribution means you have no meaningful audit trail, which is a major red flag for compliance frameworks like PCI DSS and GDPR.

Furthermore, revocation is a nightmare. If a staff member leaves, or if you suspect a device is compromised, you cannot just kick that one device off. With a PSK, your only option is to change the password for everyone. In a busy hotel or a retail store with hundreds of connected point-of-sale devices, changing the WiFi password is a highly disruptive event. So, what happens? IT teams avoid changing it. The password stays the same for years, compounding the security risk.

This is where passwordless authentication comes in. And when we say passwordless in the context of enterprise WiFi, we are primarily talking about 802.1X with EAP-TLS, which uses digital certificates instead of passwords.

Let us dive into the technical deep-dive of how this works.

In an 802.1X architecture, the access point acts as an authenticator. When a device tries to connect, the access point does not just check a password; it passes the request to an authentication server, typically a RADIUS server. The RADIUS server then checks the device's credentials against an identity provider, like Azure Active Directory, Okta, or Google Workspace.

The gold standard here is EAP-TLS, which relies on certificates. Instead of typing a password, the device presents a unique digital certificate that was provisioned to it during an onboarding process. The RADIUS server verifies the certificate, and if it is valid, the device is allowed onto the network.

The benefits are immediate. First, every device has a unique identity. You know exactly who is on the network. Second, if a device is lost or an employee leaves, you simply revoke that specific certificate. The device is instantly blocked, and no one else on the network is affected. Third, it completely eliminates the risk of credential theft. You cannot phish a certificate the way you can phish a password.

However, migrating straight from a shared PSK to full 802.1X certificate-based authentication can be daunting. It requires a public key infrastructure, or PKI, and a mechanism to get those certificates onto every device. For managed corporate devices, you can push certificates via an MDM like Intune or Jamf. But what about BYOD, Bring Your Own Device, or IoT devices like smart TVs in hotel rooms or wireless barcode scanners in retail? These devices often do not support 802.1X supplicants.

This brings us to the implementation recommendations, and a crucial stepping stone: iPSK, or Identity PSK.

iPSK is a brilliant transition technology. It looks like a standard WPA2-PSK network to the connecting device. The device does not need any special software or certificates. But on the backend, the network uses a RADIUS server to assign a unique PSK to each individual device or user group.

For example, in a hotel, your property management system can integrate with your RADIUS server to automatically generate a unique WiFi password for each guest when they check in, tied to their room number and duration of stay. When they check out, that specific password expires. Or for IoT devices, you can generate a unique PSK for every smart thermostat, tying that device to a specific VLAN.

iPSK gives you the identity attribution and the targeted revocation of 802.1X, but with the universal compatibility of standard PSK. It is highly recommended as Phase 1 of your migration strategy.

So, what are the pitfalls to avoid during this migration?

The biggest pitfall is ignoring the user onboarding experience. If you are moving to full 802.1X for BYOD users, you need a seamless onboarding portal, often called a captive portal, that automatically provisions the certificate to the user's device with a few clicks. If the process is complex, your IT helpdesk will be overwhelmed with support tickets.

Another pitfall is relying on legacy on-premise RADIUS servers. As you move to cloud-based identity providers like Azure Active Directory, your RADIUS infrastructure should also move to the cloud. Cloud RADIUS solutions integrate natively with modern identity providers and eliminate the need to maintain on-premise hardware.

Let us move to a quick rapid-fire Q and A based on common client questions.

Question one: Is WPA3 the answer to PSK vulnerabilities?

WPA3 does improve upon WPA2 by introducing SAE, Simultaneous Authentication of Equals, which protects against offline dictionary attacks. However, WPA3-Personal still relies on a shared password. It does not solve the identity, auditing, or revocation problems. For the enterprise, you need WPA3-Enterprise, which is 802.1X.

Question two: Can we use MAC Authentication Bypass, or MAB, instead of iPSK for IoT devices?

You can, but MAB is inherently insecure. MAC addresses are easily spoofed. iPSK is vastly superior because it requires a unique cryptographic key, not just a plain-text MAC address.

Question three: How does Purple help with this transition?

Purple's platform supports both advanced captive portal onboarding for BYOD devices and robust RADIUS integrations. We help venues bridge the gap between legacy networks and modern, identity-aware authentication, ensuring a seamless experience for guests while giving IT the security and analytics they need.

To summarise our next steps:

First, audit your current WiFi networks. Identify where shared PSKs are used.

Second, segment your devices. Differentiate between corporate managed devices, BYOD, IoT, and guest access.

Third, plan a phased migration. Use iPSK as a bridge for IoT and legacy devices, and target 802.1X with EAP-TLS for managed devices.

Fourth, upgrade to Cloud RADIUS to integrate seamlessly with your modern identity providers.

Moving beyond the shared password is no longer just a security best practice; it is an operational necessity for the modern enterprise. By adopting identity-based authentication, you secure your network, streamline your operations, and gain unprecedented visibility into your environment.

Thank you for joining this Purple technical briefing. For more detailed implementation guides, visit our resources at purple dot ai.

Executive Summary

La Pre-Shared Key (PSK) è stata il meccanismo predefinito per la sicurezza delle reti wireless nelle sedi aziendali per oltre due decenni. In un hotel di 200 camere, in una catena di vendita al dettaglio nazionale o in un centro congressi che ospita migliaia di visitatori, la password WiFi condivisa è un elemento familiare: stampata sulle chiavi elettroniche, visualizzata sugli schermi e sussurrata alle reception. Tuttavia, questa ubiquità nasconde una vulnerabilità critica: le PSK non forniscono alcuna identità, nessun audit trail e nessuna capacità di revoca significativa su larga scala.

Per i leader IT che operano in conformità con PCI DSS, GDPR o mandati di sicurezza interni, la password condivisa non è più una posizione difendibile. Questa guida presenta il business case e la roadmap tecnica per la migrazione all'autenticazione WiFi senza password, in particolare IEEE 802.1X con autenticazione basata su certificati EAP-TLS, supportata da Identity PSK (iPSK) come meccanismo di transizione per i dispositivi che non supportano i protocolli di autenticazione enterprise. Che si tratti di gestire il Guest WiFi in una struttura alberghiera o di proteggere una rete retail che si estende su centinaia di sedi, il percorso da seguire è chiaro, realizzabile e misurabile.

Approfondimento tecnico

Perché le PSK falliscono su scala enterprise

Il difetto fondamentale del WPA2-PSK in un ambiente enterprise è il completo disaccoppiamento dell'accesso alla rete dall'identità dell'utente. Quando ogni dispositivo utilizza la stessa chiave crittografica, la rete non può distinguere tra un dipendente legittimo, un dispositivo IoT compromesso o un attore di minacce esterno che ha ottenuto la password da una fotografia sui social media.

Ciò crea tre problemi aggravanti che diventano più gravi man mano che l'implementazione scala:

1. Nessuna attribuzione di identità. I log di rete in un'implementazione PSK registrano solo gli indirizzi MAC, non l'utente effettivo o il proprietario del dispositivo. Durante un incidente di sicurezza, questo acceca completamente i team IT. È possibile vedere che un dispositivo si sta comportando in modo anomalo; non è possibile determinare di chi sia il dispositivo o a quale funzione aziendale serva.

2. Il dilemma della revoca. Se un dipendente se ne va in circostanze difficili o un dispositivo viene segnalato come smarrito, l'unico rimedio disponibile in un modello PSK condiviso è cambiare la password per ogni singolo dispositivo sulla rete. In un ambiente Hospitality affollato — un hotel con 300 dispositivi del personale, 200 sensori IoT e 50 terminali point-of-sale — la rotazione delle password è un evento operativo di diverse ore che i team IT eviteranno a tutti i costi. Il risultato sono password che rimangono invariate per anni.

3. Mancata conformità. Il requisito 8.2 del PCI DSS impone che l'accesso ai sistemi nell'ambiente dei dati dei titolari di carta debba essere legato a un account utente individuale. Una password condivisa è, per definizione, non conforme. Allo stesso modo, il principio di responsabilizzazione del GDPR richiede alle organizzazioni di dimostrare il controllo su chi può accedere ai sistemi che elaborano dati personali. Una password WiFi condivisa non fornisce alcuna prova in tal senso.

L'architettura 802.1X

IEEE 802.1X è lo standard di controllo dell'accesso alla rete basato su porta che è alla base della sicurezza WiFi enterprise. Piuttosto che un semplice controllo della password sull'access point, l'802.1X introduce un framework di autenticazione a tre parti:

Ruolo	Componente	Funzione
Supplicant	Dispositivo client (laptop, telefono)	Presenta le credenziali per richiedere l'accesso alla rete
Authenticator	Wireless Access Point	Passa le credenziali al server di autenticazione; applica la decisione di accesso
Authentication Server	Server RADIUS	Convalida le credenziali tramite un Identity Provider; restituisce una decisione di accesso

L'access point funge da punto di applicazione delle policy, non da decisore. Questa separazione delle competenze è architettonicamente significativa: significa che la logica di autenticazione, i dati di identità e le policy di accesso risiedono tutti a livello centrale, non distribuiti su dozzine di access point. Per le implementazioni multi-sito, questo è trasformativo. Per un'esplorazione più approfondita delle opzioni di architettura RADIUS, consulta la nostra Cloud RADIUS vs On-Premise RADIUS: Guida decisionale per i team IT .

EAP-TLS: Il gold standard per l'autenticazione WiFi senza password

Mentre l'802.1X supporta più tipi di credenziali attraverso l'Extensible Authentication Protocol (EAP), la vera esperienza senza password si ottiene tramite EAP-TLS (Transport Layer Security). EAP-TLS si basa interamente su certificati digitali per l'autenticazione reciproca: il client presenta un certificato al server e il server presenta un certificato al client, stabilendo un rapporto di fiducia in entrambe le direzioni.

Il ciclo di vita del certificato funziona come segue:

Una Certificate Authority (CA) — interna (Microsoft AD CS) o basata su cloud (SCEP/NDES tramite Intune) — emette un certificato client univoco per ogni dispositivo gestito.
Il certificato viene fornito automaticamente al dispositivo tramite MDM (Intune, Jamf o simili).
Quando il dispositivo si connette all'SSID 802.1X, presenta questo certificato al server RADIUS.
Il server RADIUS convalida il certificato rispetto alla catena di fiducia della CA e controlla la Certificate Revocation List (CRL) o il responder OCSP.
Se valido, il server RADIUS restituisce un Access-Accept, includendo opzionalmente gli attributi di assegnazione VLAN.

Questa architettura elimina completamente il furto di credenziali. Non c'è nessuna password da intercettare, replicare o rubare tramite phishing. La revoca è chirurgica: la rimozione di un certificato dalla CRL o la disabilitazione dell'account utente nell'Identity Provider (Azure AD, Okta, Google Workspace) blocca istantaneamente quel dispositivo specifico senza influire su nessun altro utente.

Identity PSK (iPSK): La tecnologia di transizione critica

L'ostacolo più significativo alla completa adozione dell'802.1X è il panorama eterogeneo dei dispositivi nelle sedi aziendali. Smart TV, terminali POS wireless, telecamere IP, Sensori ambientali e dispositivi medici o industriali legacy spesso non dispongono del software supplicant necessario per elaborare i certificati EAP-TLS. Forzare questi dispositivi su un SSID PSK condiviso comprometterebbe l'intera migrazione.

Identity PSK (iPSK) — commercializzata anche come Multiple PSK (MPSK) o Dynamic PSK (DPSK) da vari fornitori — risolve questo problema in modo elegante. Dal punto di vista del dispositivo, si sta connettendo a una rete WPA2/WPA3-Personal standard utilizzando una password. Dal punto di vista della rete, il server RADIUS ha assegnato una chiave crittografica univoca all'indirizzo MAC o al gruppo di utenti di quel dispositivo specifico. L'access point applica questa mappatura, garantendo che la chiave di ciascun dispositivo conceda l'accesso solo al segmento di rete autorizzato per quel dispositivo.

Per un ambiente Retail , questo significa che ogni scanner di codici a barre wireless può avere la propria iPSK univoca, assegnata a una VLAN IoT dedicata. Se uno scanner viene rubato, viene revocata solo la sua chiave specifica. Il resto della rete non subisce conseguenze.

Guida all'implementazione

Fase 1: Discovery e segmentazione

Prima di modificare qualsiasi configurazione di rete, conduci un audit completo dei dispositivi utilizzando la tua piattaforma di WiFi Analytics . L'obiettivo è categorizzare ogni dispositivo connesso in uno dei tre gruppi:

Dispositivi gestiti: Laptop, tablet e telefoni aziendali registrati in un MDM. Questi sono candidati per l'EAP-TLS 802.1X completo.
Dispositivi BYOD: Dispositivi personali dei dipendenti o smartphone degli ospiti. Questi richiedono un portale di onboarding senza attriti per il provisioning di certificati o credenziali univoche.
Dispositivi Headless/IoT: Smart TV, terminali POS, stampanti, sensori e qualsiasi dispositivo senza interfaccia utente o supplicant 802.1X. Questi sono candidati per l'iPSK.

Questa segmentazione guida ogni successiva decisione architettonica. Non saltarla.

Fase 2: Implementare iPSK per dispositivi IoT e legacy

Configura il tuo server RADIUS per supportare l'iPSK creando mappature MAC-to-PSK per tutti i dispositivi headless. La maggior parte delle piattaforme RADIUS di livello enterprise (incluse le soluzioni cloud RADIUS) supporta questa funzionalità in modo nativo. Assegna ogni gruppo di dispositivi a una VLAN appropriata tramite gli attributi RADIUS (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID).

Per le sedi con ampi parchi IoT — come un hotel con centinaia di dispositivi smart nelle camere — integra il tuo server RADIUS con il Property Management System (PMS) o il Building Management System (BMS) per automatizzare il provisioning iPSK quando vengono messi in servizio nuovi dispositivi.

Fase 3: Implementare 802.1X per i dispositivi gestiti

Per i dispositivi gestiti tramite MDM, la migrazione dovrebbe essere completamente trasparente per l'utente finale. Configura il tuo MDM per distribuire simultaneamente quanto segue:

Il certificato client (emesso dalla tua CA tramite SCEP o NDES).
Il profilo WiFi che specifica l'SSID 802.1X, EAP-TLS come metodo di autenticazione e il certificato del server RADIUS per la convalida del server.

Una volta distribuito il profilo, i dispositivi si autenticheranno automaticamente al nuovo SSID 802.1X in background. Mantieni in esecuzione l'SSID PSK legacy in parallelo durante il periodo di transizione, monitorando l'adozione tramite i log RADIUS.

Fase 4: Portale di onboarding BYOD

Per i dispositivi personali dei dipendenti e l'accesso degli ospiti, implementa un portale di onboarding di rete. L'esperienza utente dovrebbe essere: connessione a un SSID di onboarding temporaneo → autenticazione con SSO aziendale → il portale fornisce automaticamente il certificato e il profilo WiFi → il dispositivo si connette senza interruzioni all'SSID 802.1X. Questo processo non dovrebbe richiedere alcuna conoscenza tecnica da parte dell'utente. Consulta Soluzioni WiFi moderne per l'Hospitality che i tuoi ospiti meritano per i principi di progettazione del portale applicabili alle implementazioni rivolte agli ospiti.

Fase 5: Dismissione dell'SSID PSK legacy

Una volta che il monitoraggio conferma che tutti i dispositivi sono migrati all'SSID 802.1X o a un SSID abilitato per iPSK, pianifica la dismissione della rete PSK condivisa legacy. Comunica in anticipo la data di transizione agli stakeholder e mantieni un piano di rollback per le prime 48 ore.

Best Practice

Non fare mai affidamento sul MAC Authentication Bypass (MAB) per la sicurezza. Sebbene il MAB sia ampiamente utilizzato per l'onboarding IoT, non fornisce alcuna vera sicurezza. Gli indirizzi MAC vengono trasmessi in chiaro e sono facilmente falsificabili. Qualsiasi utente malintenzionato in grado di osservare l'indirizzo MAC di un dispositivo può impersonarlo. Preferisci sempre l'iPSK, che applica una chiave crittografica univoca, rispetto al MAB.

Automatizza la gestione del ciclo di vita dei certificati. I certificati scadono. Un certificato client scaduto è indistinguibile da uno revocato dal punto di vista della rete: il dispositivo perde semplicemente la connettività. Implementa avvisi proattivi nelle tue piattaforme PKI e MDM per rinnovare i certificati ben prima della loro data di scadenza. Un certificato di 90 giorni con una finestra di rinnovo di 30 giorni è una configurazione comune e sensata.

Convalida il certificato del server RADIUS sui client. Una configurazione spesso trascurata è quella di istruire il supplicant a convalidare il certificato del server RADIUS. Senza questo passaggio, i dispositivi sono vulnerabili agli attacchi rogue AP, in cui un utente malintenzionato crea un server RADIUS falso per raccogliere le credenziali. Configura sempre la CA attendibile e il nome del certificato del server nel profilo WiFi distribuito dall'MDM.

Implementa l'assegnazione dinamica delle VLAN dal primo giorno. Sfrutta gli attributi di autorizzazione RADIUS per segmentare utenti e dispositivi nelle VLAN appropriate in base alla loro identità o all'appartenenza a un gruppo. I dispositivi del personale, i dispositivi degli ospiti, i dispositivi IoT e i terminali POS non dovrebbero mai condividere un dominio di broadcast. Questo limita i movimenti laterali in caso di compromissione.

Allineati al WPA3-Enterprise per le nuove implementazioni. Per le nuove implementazioni di access point, specifica WPA3-Enterprise (modalità a 192 bit) nei requisiti di approvvigionamento. Questo fornisce algoritmi crittografici conformi alla CNSA Suite ed elimina le vulnerabilità legacy. Consulta Definizione di Wireless Access Point: La tua guida definitiva per il 2026 per indicazioni sulla selezione dell'hardware. Per considerazioni sull'integrazione SD-WAN, vedi I principali vantaggi della SD-WAN per le aziende moderne .

Risoluzione dei problemi e mitigazione dei rischi

Interruzioni per scadenza dei certificati

Questa è la causa più comune di fallimento delle implementazioni 802.1X dopo il lancio. Sintomi: i dispositivi perdono improvvisamente la connettività WiFi in massa, in genere in una data specifica. Causa principale: i certificati del client o del server RADIUS sono scaduti.

Mitigazione: Implementa un monitoraggio che avvisi il team IT quando un qualsiasi certificato nella catena (CA root, intermedio, server o una percentuale significativa di certificati client) si trova a meno di 60 giorni dalla scadenza. Automatizza il rinnovo dei certificati client tramite MDM/SCEP.

Alta disponibilità del server RADIUS

Se il server RADIUS è irraggiungibile, nessun dispositivo può autenticarsi e l'intera rete wireless diventa inaccessibile. In un ambiente alberghiero o retail, si tratta di un guasto operativo critico.

Mitigazione: Implementa come minimo due server RADIUS (primario e secondario) configurati come coppia di failover. Per il cloud RADIUS, assicurati che il provider offra un'architettura geograficamente ridondante con uno SLA che soddisfi i tuoi requisiti operativi. Configura tutti gli access point per tentare la connessione al server RADIUS secondario entro 3-5 secondi dal timeout del primario.

Errata configurazione del supplicant sui dispositivi BYOD

Quando gli utenti configurano manualmente i propri dispositivi per l'802.1X (invece di utilizzare un portale di onboarding automatizzato), spesso selezionano il tipo EAP sbagliato, saltano la convalida del certificato del server o inseriscono stringhe di identità errate. Questo genera un volume elevato di ticket per l'helpdesk.

Mitigazione: Elimina completamente la configurazione manuale. Tutti i dispositivi BYOD devono essere integrati tramite il portale automatizzato, che distribuisce un profilo WiFi completo e convalidato. Disabilita l'opzione che consente agli utenti di aggiungere manualmente l'SSID 802.1X.

Rotazione dell'indirizzo MAC dei dispositivi IoT

I moderni sistemi operativi mobili (iOS 14+, Android 10+) utilizzano indirizzi MAC randomizzati per impostazione predefinita, il che interrompe le mappature MAC-to-PSK dell'iPSK.

Mitigazione: Per i dispositivi BYOD gestiti dall'azienda, utilizza l'MDM per disabilitare la randomizzazione del MAC sull'SSID aziendale. Per i dispositivi IoT consumer, configura il dispositivo in modo che utilizzi un indirizzo MAC persistente nelle sue impostazioni di rete. Per i dispositivi degli ospiti, utilizza un flusso di onboarding separato che fornisca una credenziale univoca anziché fare affidamento sulla mappatura dell'indirizzo MAC.

ROI e impatto sul business

Il business case per la migrazione all'autenticazione WiFi senza password è convincente sotto molteplici aspetti:

Area di impatto	Status Quo PSK	Post-migrazione
Costo di rotazione delle password	4-8 ore di tempo IT per rotazione, moltiplicato per il numero di sedi	Zero — nessuna password condivisa da ruotare
Sicurezza nell'offboarding	Manuale, dirompente, spesso in ritardo	Automatizzata, istantanea, zero interruzioni per gli altri
Risposta agli incidenti	Impossibile attribuire il traffico a un utente specifico	Piena attribuzione dell'identità, isolamento istantaneo del dispositivo
Livello di conformità	Non conforme al Req. 8.2 del PCI DSS	Conforme; audit trail completo disponibile
Volume di ticket all'helpdesk	Alto — condivisionione delle password, confusione nella rotazione	Basso — onboarding automatizzato, nessuna password da dimenticare

Per una catena retail di 50 sedi che ruota una PSK condivisa trimestralmente, il solo risparmio operativo — eliminando quattro eventi annuali di rotazione delle password in 50 sedi — può rappresentare centinaia di ore di tempo IT all'anno. Il valore della mitigazione del rischio di conformità è più difficile da quantificare ma significativamente più impattante: una violazione del PCI DSS relativa a controlli di accesso inadeguati può comportare multe, sanzioni dai circuiti di carte di credito e costi di riparazione che fanno impallidire il costo della migrazione.

Oltre alla sicurezza, le reti identity-aware sbloccano una significativa intelligenza operativa. Quando ogni dispositivo ha un'identità, la tua piattaforma di WiFi Analytics può fornire dati più ricchi sui tipi di dispositivi, sui tempi di permanenza e sui modelli di utilizzo della rete. Questi dati confluiscono direttamente nell'ottimizzazione delle sedi, nelle decisioni sul personale e nel tipo di esperienze personalizzate che gli hub di Trasporto e le grandi strutture sono sempre più tenuti a offrire.

Andare oltre la password condivisa non è semplicemente un aggiornamento di sicurezza. È un investimento fondamentale nella maturità operativa e nella resilienza della tua infrastruttura di rete.

Termini chiave e definizioni

Pre-Shared Key (PSK)

A single password shared among all users and devices to authenticate to a WiFi network using WPA2-Personal or WPA3-Personal.

The legacy default for venue WiFi. Operationally simple to deploy but fundamentally insecure at enterprise scale due to the absence of per-user identity and the impossibility of targeted revocation.

IEEE 802.1X

An IEEE standard for port-based network access control that provides an authentication mechanism for devices attempting to connect to a LAN or WLAN, requiring each device to authenticate individually against a central authentication server.

The foundational standard for enterprise WiFi security. IT teams encounter this when replacing shared passwords with identity-based access control, and it is a prerequisite for EAP-TLS deployment.

EAP-TLS (Extensible Authentication Protocol — Transport Layer Security)

An 802.1X authentication method that uses digital certificates on both the client device and the authentication server for mutual authentication, with no password involved.

The gold standard for passwordless WiFi. Considered the most secure EAP method because it eliminates credential theft entirely — there is no password to phish, replay, or brute-force.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol providing centralised Authentication, Authorisation, and Accounting (AAA) management for network access. In WiFi deployments, the RADIUS server sits between the access point and the Identity Provider.

The core infrastructure component of any 802.1X deployment. IT teams must decide between on-premise RADIUS (e.g., Microsoft NPS) and cloud RADIUS solutions, a decision that significantly impacts integration complexity and operational overhead.

Identity PSK (iPSK)

A WiFi authentication feature that assigns a unique pre-shared key to each individual device or user group via a RADIUS server, while presenting as a standard WPA2/WPA3-Personal network to connecting devices.

The critical transition technology for securing IoT and legacy devices that cannot support 802.1X supplicants. Provides per-device identity and revocation without requiring any changes to the connecting device.

Supplicant

The software component on a client device (laptop, smartphone) that implements the EAP protocol and communicates with the authenticator (access point) to present credentials during 802.1X authentication.

IoT devices, legacy POS terminals, and many consumer electronics lack a supplicant, which is the primary reason they cannot use standard 802.1X and require alternatives such as iPSK.

MAC Authentication Bypass (MAB)

A network access method that grants connectivity based solely on a device's MAC (Media Access Control) address, without any cryptographic credential.

Widely used as a fallback for headless devices but inherently insecure, as MAC addresses are broadcast in plain text and easily spoofed. Should be replaced by iPSK wherever possible.

Dynamic VLAN Assignment

A RADIUS authorisation feature that instructs the access point to place an authenticated device into a specific Virtual LAN (VLAN) based on the user's identity, group membership, or device type, as determined by the RADIUS server.

Essential for network segmentation in multi-tenant or mixed-use environments. Ensures that guest devices, corporate laptops, IoT sensors, and POS terminals are automatically isolated from each other without requiring separate physical SSIDs for each segment.

Certificate Revocation List (CRL)

A regularly published list maintained by a Certificate Authority (CA) that identifies certificates that have been revoked before their scheduled expiry date.

The mechanism by which RADIUS servers verify that a client certificate has not been revoked. IT teams must ensure RADIUS servers can reach the CRL distribution point; an inaccessible CRL can cause authentication failures or security gaps depending on the configured fail-open/fail-closed policy.

EAP-PEAP (Protected Extensible Authentication Protocol)

An 802.1X authentication method that creates an encrypted TLS tunnel and then authenticates the user with a username and password inside that tunnel.

A common stepping stone from PSK to full certificate authentication. More secure than PSK but still relies on passwords, making it vulnerable to credential theft. EAP-TLS is the preferred end-state for passwordless deployments.

Casi di studio

A 300-room luxury hotel currently uses a single shared WPA2-PSK for all back-of-house staff devices: tablets for housekeeping, wireless POS terminals for food and beverage, and maintenance laptops. The IT Director needs to secure this network to comply with PCI DSS within the current quarter but cannot afford any downtime for operational staff. How should they approach the migration?

The migration should proceed in four steps, running the new and legacy networks in parallel throughout the transition.

Step 1 — Deploy Cloud RADIUS. Implement a cloud-based RADIUS server integrated with the hotel's Azure Active Directory. This provides the authentication backbone without requiring on-premise hardware.

Step 2 — Implement iPSK for POS Terminals and IoT. For the wireless POS terminals that cannot support 802.1X supplicants, configure the RADIUS server to issue unique iPSKs based on each terminal's MAC address. Assign all POS devices to a dedicated VLAN isolated from the general staff network. This immediately addresses PCI DSS segmentation requirements without touching the devices themselves.

Step 3 — MDM Deployment for Tablets and Laptops. Use the hotel's MDM (Intune) to silently push EAP-TLS certificates and the new 802.1X WiFi profile to the housekeeping tablets and maintenance laptops. Devices will automatically migrate to the new SSID without any user action required.

Step 4 — Monitor and Decommission. Run the legacy PSK SSID alongside the new 802.1X and iPSK SSIDs for two weeks. Monitor RADIUS authentication logs to confirm all devices have migrated. Once confirmed, disable the legacy SSID.

Expected outcome: PCI DSS compliance achieved within six weeks; zero operational downtime; IT team gains full device identity visibility and per-device revocation capability.

Note di implementazione: This scenario illustrates the critical importance of the phased approach. A direct cutover from PSK to 802.1X in a live hospitality environment would cause immediate operational disruption. By using iPSK for devices that cannot be migrated and MDM automation for those that can, the IT team achieves the security objective without the operational risk. The parallel SSID strategy provides a safety net throughout the transition. Note also that the PCI DSS benefit is achieved at Step 2 — before the full 802.1X migration is complete — because iPSK provides the individual device identity and segmentation that the standard requires.

A national retail chain with 500 locations uses a shared WPA2-PSK for the corporate back-office WiFi network. When an area manager leaves the company, IT must coordinate a password change across all stores, which frequently results in store managers being locked out and losing access to inventory management systems during trading hours. The CISO wants to eliminate this risk entirely. What is the recommended architecture?

The solution is a full 802.1X deployment with EAP-TLS, integrated with the company's Okta Identity Provider.

Architecture:

Deploy a cloud RADIUS service integrated with Okta via RADIUS proxy or native RADIUS protocol.
Use Intune to push client certificates and the 802.1X WiFi profile to all corporate-managed Windows laptops and tablets across all 500 locations.
Configure the RADIUS server to perform dynamic VLAN assignment based on Okta group membership (e.g., Store Manager, Area Manager, IT Admin).

Offboarding Integration:

When HR deactivates a departing employee's Okta account, the RADIUS server immediately rejects any new authentication attempts from that user's certificate.
The employee loses WiFi access across all 500 locations simultaneously, within seconds of account deactivation.
All other employees remain connected without interruption.

BYOD Consideration:

For employees who access the corporate WiFi on personal devices, deploy a self-service onboarding portal authenticated via Okta SSO. The portal provisions a unique certificate to the personal device, which is also tied to the Okta account and revoked automatically on offboarding.

Note di implementazione: This scenario demonstrates the transformative operational impact of tying WiFi authentication to the central Identity Provider. The key insight is that the security event — employee departure — is now handled entirely within the existing HR and IT offboarding workflow. IT does not need to take any WiFi-specific action; the revocation is automatic and immediate. This eliminates the coordination overhead across 500 sites and removes the window of risk between an employee's departure and their network access being terminated. The dynamic VLAN assignment adds a further security layer, ensuring that different employee roles are segmented appropriately even within the corporate network.

Analisi degli scenari

Q1. A university campus needs to secure the wireless network in student dormitories. Students bring a mix of laptops, smartphones, gaming consoles, and smart speakers. The university wants to ensure each student's devices are isolated from other students' devices, but cannot install MDM profiles on personal equipment. Which authentication strategy should be deployed, and how should device isolation be achieved?

💡 Suggerimento:Gaming consoles and smart speakers lack 802.1X supplicants. Consider how iPSK combined with dynamic VLAN assignment can achieve per-student isolation without requiring MDM.

Mostra l'approccio consigliato

Deploy an iPSK solution integrated with a self-service onboarding portal. Students authenticate to the portal using their university SSO credentials and register the MAC addresses of their devices (including consoles and smart speakers, which lack 802.1X supplicants). The RADIUS server generates a unique iPSK for each student and maps all registered MAC addresses to that student's key. Dynamic VLAN assignment places all devices using a given student's iPSK into a personal micro-segment or private VLAN (PVLAN), preventing lateral communication between students' devices. For laptops and smartphones that support 802.1X, the onboarding portal can optionally provision a certificate and WiFi profile for EAP-TLS, providing stronger security for those devices while maintaining iPSK compatibility for consoles and smart speakers.

Q2. A hospital is auditing its wireless network for HIPAA compliance. They discover that 50 wireless infusion pumps are connected using a shared WPA2-PSK because the vendor states the pumps do not support EAP-TLS. The security team proposes moving the pumps to MAC Authentication Bypass (MAB) on an open (unencrypted) network segment to remove the shared password from the clinical environment. Is this the correct approach? If not, what should they do instead?

💡 Suggerimento:Evaluate the security implications of removing encryption versus the risk of MAC address spoofing. Consider what iPSK provides that MAB does not.

Mostra l'approccio consigliato

No. Moving to MAB on an open network is a significant security regression. It removes over-the-air encryption entirely, meaning all traffic from the infusion pumps — including any clinical data — is transmitted in plain text and can be intercepted by anyone within radio range. Additionally, MAC addresses are trivially spoofed, meaning an attacker could impersonate a pump to gain access to the clinical network segment. The correct approach is iPSK. The infusion pumps will connect to what appears to be a standard WPA2-PSK network, maintaining over-the-air encryption. The RADIUS server assigns a unique, complex PSK to each pump's MAC address. This provides individual device identity (each pump is distinguishable in logs), targeted revocation (a single pump can be isolated without affecting others), and maintained encryption — all without requiring any changes to the pump firmware or vendor support.

Q3. You have successfully deployed 802.1X with EAP-TLS for 2,000 corporate-managed laptops. You manually tested one laptop and it connected perfectly. You then used your MDM to push the WiFi profile to all 2,000 devices. The following morning, the helpdesk receives hundreds of calls reporting that no laptops can connect to the corporate WiFi. What are the two most likely root causes, and how do you diagnose and resolve each?

💡 Suggerimento:EAP-TLS requires two things from the client: a valid client certificate to present to the server, and the ability to validate the server's certificate. Consider whether the MDM push may have delivered the WiFi profile without the necessary certificates.

Mostra l'approccio consigliato

The two most likely root causes are: (1) The MDM pushed the WiFi profile but failed to provision the client certificates to the devices. The profile instructs the supplicant to use EAP-TLS, but without a client certificate to present, authentication fails immediately. Diagnose by checking the MDM deployment report for certificate provisioning status and reviewing the RADIUS server logs for 'no certificate presented' errors. Resolve by ensuring the MDM certificate profile (SCEP or PKCS) is deployed as a dependency before the WiFi profile. (2) The devices do not trust the RADIUS server's certificate. The WiFi profile specifies EAP-TLS but does not include the trusted CA certificate for server validation, causing the supplicant to reject the RADIUS server's certificate. Diagnose by checking supplicant logs on an affected device for 'server certificate validation failed' errors. Resolve by adding the root CA certificate (or the specific RADIUS server certificate) to the trusted certificates section of the MDM WiFi profile. The manual test succeeded because the test device may have had the CA certificate already installed from a previous configuration, or server validation was not enforced during the manual test.

Q4. A conference centre hosts 200 events per year, ranging from day-long trade shows to week-long residential conferences. Each event has a different organiser who requires branded WiFi for their attendees. Currently, the venue creates a new shared PSK for each event. The venue's IT manager wants to move to a more scalable, secure model. What architecture would you recommend?

💡 Suggerimento:Consider the temporary, event-scoped nature of access and the need for branding. Think about how iPSK combined with a captive portal can serve both requirements.

Mostra l'approccio consigliato

Implement a dynamic iPSK model integrated with the venue's event management system. For each event, the system automatically generates a unique iPSK scoped to the event's duration. Attendees receive this key via the event registration confirmation or the organiser's branded onboarding portal. The RADIUS server maps the event's iPSK to a dedicated VLAN for that event, ensuring complete isolation between concurrent events. When the event ends, the iPSK is automatically expired, requiring no manual cleanup. For organisers who require a branded captive portal experience, deploy a portal layer on top of the iPSK SSID that presents the organiser's branding before granting full network access. This model eliminates the manual PSK management overhead, provides per-event network isolation, and gives the IT team a complete audit trail of which devices connected to which event.

Punti chiave

✓Shared PSKs provide zero identity attribution — the network cannot distinguish between a legitimate user and a threat actor, making audit trails and compliance impossible.
✓IEEE 802.1X with EAP-TLS is the enterprise standard for passwordless WiFi, replacing passwords with unique digital certificates that cannot be phished, replayed, or shared.
✓Identity PSK (iPSK) is the essential transition technology for IoT and legacy devices that lack 802.1X supplicants — it provides per-device identity and targeted revocation without requiring any changes to the connecting device.
✓Never use MAC Authentication Bypass (MAB) as a security control — MAC addresses are trivially spoofed; always prefer iPSK for headless device authentication.
✓Automate certificate lifecycle management via MDM and PKI integration; expired certificates are the most common cause of post-deployment 802.1X outages.
✓Migration should be phased: discover and segment devices first, bridge IoT to iPSK, migrate managed devices to EAP-TLS via MDM, then decommission the legacy PSK SSID.
✓Moving to identity-based authentication unlocks downstream benefits beyond security: richer WiFi analytics, automated offboarding, dynamic network segmentation, and a defensible compliance posture under PCI DSS and GDPR.