Per-Device PSK por proveedor: comparación de iPSK, DPSK, MPSK y PPSK (y soporte de WPA3)

Per-Device PSK by Vendor: iPSK, DPSK, MPSK and PPSK Compared, and WPA3 Support. A Purple Technical Briefing. Introduction and Context. Welcome to the Purple technical briefing series. I'm going to walk you through one of the most practically important - and frequently misunderstood - topics in enterprise WiFi right now: per-device pre-shared keys. Specifically, we're going to compare how each of the major vendors implements this capability, what they call it, how it actually works under the hood, and - critically - what happens when you try to move to WPA3. If you're an IT manager, network architect, or venue operations director running WiFi across a hotel estate, a retail chain, a stadium, or a public-sector campus, this briefing is for you. You've probably already encountered the alphabet soup: iPSK, DPSK, MPSK, PPSK. They all refer to the same concept - giving each device or user its own unique password on a single SSID - but the implementations differ significantly, and those differences matter when you're planning your next infrastructure refresh. Let's start with the fundamentals, then work through each vendor, and finish with the WPA3 question that everyone is wrestling with right now. Technical Deep-Dive. So what is per-device PSK, and why does it exist? Traditional WPA2-Personal uses a single shared passphrase for an entire SSID. Everyone on your guest network uses the same password. That creates two problems. First, you can't revoke access for one device without changing the password for everyone. Second, you have no per-device visibility or policy enforcement. Per-device PSK solves both. Each device or user gets a unique credential. You can revoke one without touching the others. You can assign different VLANs, bandwidth policies, or access schedules per key. It's the middle ground between the simplicity of WPA2-Personal and the complexity of full 802.1X enterprise authentication. Now let's look at how each vendor implements this. Cisco Meraki calls it iPSK - Identity Pre-Shared Key. Meraki supports two modes. Without RADIUS, you configure up to five unique PSKs directly in the Meraki dashboard, each mapped to a VLAN. It's quick to set up and requires no external infrastructure. With RADIUS - typically Cisco ISE - you can scale to thousands of keys. The client associates, the AP sends the MAC address and a PSK hint to the RADIUS server, the server returns the correct per-device key, and the standard WPA2 four-way handshake completes using that key as the Pairwise Master Key. The key insight here is that the RADIUS server is doing the lookup, not the AP. The AP just facilitates the exchange. HPE Aruba calls it MPSK - Multiple Pre-Shared Key. Aruba Central and Aruba Instant support MPSK in two modes: MPSK Local, where keys are stored on the controller or AP cluster, and MPSK with ClearPass, Aruba's RADIUS and policy engine. ClearPass can hold tens of thousands of keys, assign dynamic VLANs, and apply role-based policies per key. The authentication flow is essentially the same as Meraki's RADIUS mode - MAC-based lookup returns the per-device key before the four-way handshake. Ruckus - now part of CommScope - calls it DPSK, Dynamic Pre-Shared Key. This is arguably the most mature implementation in the market. Ruckus DPSK has been available since the early SmartZone days. In local mode, the DPSK service runs on the controller and holds the key database. In RADIUS mode, it integrates with Cloudpath, Ruckus's own network access control platform. What makes Ruckus notable is DPSK3 - their WPA3 extension of DPSK, which we'll come back to shortly. DPSK3 is available on Wi-Fi 6, 6E, and 7 access points running firmware 7.0 or later, and it operates in WPA2 slash WPA3 mixed mode. Juniper Mist calls it PPSK - Private Pre-Shared Key - or sometimes Multi-PSK. Mist stores keys in the cloud, in the Mist organisation or site key database, with a limit of 5,000 keys per site. Keys can be assigned per user, per device, or per group. Mist also integrates with its Access Assurance service - the cloud-native NAC - which adds RADIUS-based PSK lookup. Critically, Juniper has announced WPA3 RADIUS PSK support through Access Assurance, allowing a single WPA3-Personal SSID to serve multiple passphrases. This is one of the more forward-looking implementations in the market. Extreme Networks - which acquired Aerohive - calls it PPSK, Private Pre-Shared Key, through ExtremeCloud IQ. Extreme's implementation supports local key storage on the AP itself, which is useful for branch or remote sites with limited connectivity. It also supports RADIUS-based lookup via ExtremeCloud IQ's cloud RADIUS service. MAC binding is available, which ties a PPSK to a specific device MAC address for additional security. Fortinet calls it MPSK, Multiple Pre-Shared Key, managed through FortiAP and the FortiGate wireless controller. Fortinet's implementation is notable because it explicitly supports WPA3-SAE and WPA3-SAE Transition security modes in its MPSK profiles - as of FortiAP firmware 8.0. You can create an MPSK profile with WPA3-SAE keys, assign them to a VAP, and enable dynamic VLAN assignment per key. This is one of the cleaner WPA3 MPSK implementations available today. Ubiquiti UniFi calls it Private Pre-Shared Keys, or Private PSK. UniFi's implementation is local only - keys are stored in the UniFi Network controller, not in an external RADIUS server. You can assign different VLANs per key and set client limits per key. The significant limitation: as of mid-2026, UniFi Private PSK only works on WPA2 networks on 2.4 GHz and 5 GHz. WPA3 and 6 GHz are not supported. For smaller deployments this is fine, but it's a constraint worth knowing before you commit to a UniFi estate at scale. Now, the WPA3 question. This is where it gets technically interesting. WPA2-Personal uses a four-way handshake. The client and AP derive a Pairwise Transient Key from a shared Pairwise Master Key, which itself is derived from la frase de contraseña. Debido a que la derivación de PMK ocurre después de la búsqueda de RADIUS, el AP puede sustituir una clave por dispositivo en ese punto. Al estándar no le importa, solo ve una PMK válida. WPA3-Personal reemplaza el protocolo de enlace de cuatro vías con SAE (Simultaneous Authentication of Equals). SAE es un protocolo basado en Diffie-Hellman. Ambas partes se comprometen a un elemento de contraseña compartido derivado de la frase de contraseña antes de que se complete la asociación. La diferencia crítica: la contraseña debe ser conocida por ambas partes antes de que comience el intercambio SAE. No hay ningún punto en el protocolo donde un servidor RADIUS pueda inyectar una clave diferente por dispositivo. El AP y el cliente ya están realizando un intercambio criptográfico con un único valor compartido. Es por esto que WPA3 actualmente solo permite una clave por SSID en su forma estándar. No es una limitación de firmware. Es una restricción del protocolo. Las soluciones alternativas se dividen en tres categorías. Primero, el modo de transición WPA3, también llamado modo mixto WPA2 barra diagonal WPA3. El SSID anuncia tanto WPA2-PSK como WPA3-SAE. Los clientes WPA2 utilizan el protocolo de enlace de cuatro vías y pueden recibir claves por dispositivo a través de RADIUS. Los clientes WPA3 utilizan SAE con una única contraseña compartida. Este es el enfoque más implementado hoy en día y es compatible con Cisco Meraki, HPE Aruba, Ruckus y otros. Segundo, extensiones propietarias. Ruckus DPSK3 es el ejemplo más claro. Al ejecutarse en modo mixto WPA2 barra diagonal WPA3 con Cloudpath como backend de RADIUS, DPSK3 permite que los dispositivos compatibles con WPA3 utilicen SAE mientras el sistema gestiona la vinculación de claves por dispositivo a través de la integración con Cloudpath. El Access Assurance WPA3 RADIUS PSK de Juniper adopta un enfoque similar. El MPSK de Fortinet con modo de transición WPA3-SAE le permite mezclar claves WPA2-Personal y WPA3-SAE en el mismo perfil MPSK. Tercero, migrar a 802.1X. Para endpoints gestionados (laptops corporativas, dispositivos del personal, cualquier cosa a la que se le pueda instalar un certificado), WPA3-Enterprise con EAP-TLS es la respuesta ideal. Es totalmente compatible con WPA3 y 6 GHz, proporciona identidad por dispositivo y se integra con Microsoft Entra ID, Okta y Google Workspace. La desventaja es la complejidad de la implementación y la necesidad de una infraestructura de certificados. Recomendaciones de implementación y errores comunes. Entonces, ¿qué debería hacer realmente? Si gestiona una propiedad hotelera con una combinación de dispositivos de huéspedes, sensores IoT y dispositivos del personal, la respuesta pragmática en 2026 es un diseño de SSID híbrido. Mantenga un SSID WPA2-Personal con PSK por dispositivo para IoT heredado y dispositivos de huéspedes. Ejecute un SSID WPA3-Enterprise para los dispositivos del personal que usted controla. Utilice el modo de transición en su SSID de huéspedes principal para admitir clientes WPA2 y WPA3 sin fragmentar su número de SSID. Si utiliza Ruckus y cuenta con hardware Wi-Fi 6 o más reciente, vale la pena evaluar DPSK3 en modo mixto WPA2 barra diagonal WPA3 con Cloudpath. Le ofrece lo más cercano a un PSK por dispositivo nativo de WPA3 disponible hoy en día. Si utiliza Fortinet, el perfil MPSK con transición WPA3-SAE es sencillo de configurar y le ofrece una ruta de migración limpia. Si utiliza UniFi, sea explícito con sus partes interesadas en que el PSK privado es exclusivo para WPA2. Para los recintos que implementen Wi-Fi 6E o Wi-Fi 7 con radios de 6 GHz, necesitará una estrategia de autenticación diferente para esa banda. El mayor error que vemos es que los equipos asumen que habilitar WPA3 en un SSID con PSK por dispositivo existente funcionará sin más. No será así. Realice pruebas en un sitio piloto primero. Verifique las versiones de firmware de sus AP; DPSK3 requiere la versión de firmware 7.0 o posterior en Ruckus, por ejemplo. Y verifique la compatibilidad de su servidor RADIUS; Ruckus DPSK3 en modo mixto requiere específicamente Cloudpath, no un servidor RADIUS genérico. Un segundo error común es la proliferación descontrolada de claves. El PSK por dispositivo es excelente para la rendición de cuentas, pero solo si tiene un proceso para revocar las claves cuando los dispositivos se retiran de servicio. Sin una gestión del ciclo de vida, terminará con miles de claves huérfanas y sin un registro de auditoría. Integre el aprovisionamiento de sus claves con su flujo de trabajo de gestión de dispositivos desde el primer día. Preguntas y respuestas rápidas. ¿Puedo usar PSK por dispositivo en un SSID de 6 GHz? No. 6 GHz exige exclusivamente WPA3, y WPA3 no admite de forma nativa PSK por dispositivo. Utilice 802.1X o un SSID independiente de 2.4 barra diagonal 5 GHz para los dispositivos que requieran PSK por dispositivo. ¿El PSK por dispositivo cumple con los requisitos de PCI DSS? El PSK por dispositivo en WPA2 puede cumplir con los requisitos de segmentación de red de PCI DSS 4.0 si cada clave se asocia a una VLAN aislada. Sin embargo, PCI DSS recomienda encarecidamente 802.1X para entornos de datos de titulares de tarjetas. Verifique con su QSA. ¿Cuál es el número máximo de claves por SSID? Varía significativamente. Cisco Meraki con ISE admite implementaciones muy grandes. Ruckus DPSK admite decenas de miles de claves. Juniper Mist tiene un límite de 5,000 por sitio. UniFi está limitado efectivamente por la memoria del controlador. Siempre consulte la documentación del proveedor para su versión específica de firmware. ¿Cómo encaja Purple en esto? Purple funciona como una capa de nube sobre su hardware existente. Nos integramos con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Para implementaciones de Guest WiFi y Staff WiFi, Purple gestiona la capa de identidad (autenticación, captura de datos, gestión de consentimiento) y devuelve la asignación de VLAN o política correspondiente a su hardware a través de RADIUS o API. Usted conserva su infraestructura de PSK por dispositivo existente; Purple añade la capa de identidad y analítica por encima. Resumen y próximos pasos. Vamos a resumir esto. El PSK por dispositivo, ya sea que lo llame iPSK, DPSK, MPSK o PPSK, es una función madura y bien respaldada por todos los principales proveedores de WiFi empresarial. Las implementaciones difieren en dónde se almacenan las claves, cómo escalan y cómo se integran con RADIUS. El protocolo SAE de WPA3 crea una restricción técnica real para el PSK por dispositivo. El estándar no lo admite de forma nativa. Las respuestas prácticas hoy en día son el modo de transición, las extensiones propietarias como DPSK3 o la migración a 802.1X para los dispositivos que lo admitan. El resumen proveedor por proveedor: Cisco Meraki iPSK funciona bien con ISE en modo RADIUS; el soporte de WPA3 es a través del modo de transición. HPE Aruba MPSK con ClearPass es altamente escalable; WPA3 MPSK está en desarrollo activo. Ruckus DPSK3 es la solución PSK por dispositivo WPA3 más madura disponible. Juniper Mist Access Assurance añade WPA3 RADIUS PSK. Fortinet MPSK es compatible explícitamente con WPA3-SAE en sus perfiles MPSK. Extreme PPSK es sólido para los modos local y RADIUS. UniFi Private PSK es exclusivo para WPA2 y de modo local. Para sus próximos pasos: realice una auditoría de su implementación actual de PSK por dispositivo, identifique qué dispositivos son compatibles con WPA3 y diseñe una estrategia de SSID híbrido que sirva para ambos. Si está planeando una renovación de hardware, priorice los AP de Wi-Fi 6 o Wi-Fi 7 con soporte confirmado para DPSK3 o WPA3 MPSK. Si desea comprender cómo Purple se integra con su proveedor de hardware específico para añadir gestión de identidad y analíticas sobre su implementación de PSK por dispositivo, visite purple.ai o hable con su equipo de cuenta. Eso es todo por esta sesión informativa. Gracias por escuchar.