EAP-TLS frente a PEAP: seguridad, certificados y adecuación
Published
El consejo más habitual sobre eap tls vs peap es sencillo e incorrecto. Elegir EAP-TLS porque es "más seguro" y dejar PEAP para los equipos que no se han al día pasa por alto la pregunta que determina si una WLAN multisede sigue funcionando un lunes. ¿Puede emitir, renovar y revocar un certificado para cada dispositivo que vaya a utilizarlo?
Yo no aplicaría un solo método a todo el parque de dispositivos. EAP-TLS corresponde a dispositivos que se pueden inscribir y renovar. PEAP, casi siempre con EAP-MSCHAPv2 interno, corresponde a entornos donde ya existe una contraseña de directorio y la inscripción de certificados no es viable. El método más complejo no siempre es el que se puede ejecutar. Un certificado caducado en la oficina central de un hotel deja fuera al personal aunque sus cuentas sigan siendo válidas. Un perfil PEAP que omite la comprobación del servidor puede entregar una contraseña de directorio a un punto de acceso no autorizado. Ambos fallos son operacionales. Asigne el método al grupo de usuarios en lugar de buscar una solución única para toda la red.
Índice de contenidos
- EAP-TLS y PEAP frente a frente
- Cómo autentica cada método y por dónde se filtran las contraseñas
- Requisitos de certificados antes del despliegue
- Ciclo de vida de los certificados y esfuerzo de despliegue
- Revocación, velocidad de itinerancia y soporte de clientes
- Asigne cada población y demuestre la división
EAP-TLS y PEAP frente a frente
La diferencia práctica entre EAP-TLS y PEAP reside en la credencial que puede admitir cada punto final y el trabajo necesario para mantenerla operativa. Utilice EAP-TLS para los dispositivos que pueda inscribir y renovar. Utilice PEAP cuando los usuarios ya dispongan de contraseñas de directorio y la inscripción de certificados no sea viable. Ninguno de los dos métodos es la respuesta adecuada para todos los grupos de usuarios.
| Criterio | EAP-TLS | PEAP |
|---|---|---|
| ID de tipo EAP | 13 | 26 |
| Credencial de cliente | Certificado de cliente X.509 | Nombre de usuario y contraseña, normalmente EAP-MSCHAPv2 o EAP-GTC |
| Credencial de servidor | Certificado de servidor RADIUS | Certificado de servidor RADIUS en el túnel TLS externo |
| Autenticación mutua | Certificados de cliente y servidor | Certificado de servidor más autenticación interna de usuario o dispositivo |
| Contraseña en tránsito | Ninguna | Sí, dentro del túnel TLS |
| Qué puede robar un AP falso si el cliente omite las comprobaciones del servidor | Nada similar a una contraseña; la autenticación falla de forma segura | Contraseña de directorio |
| Revocación de un dispositivo | Revocar o expirar ese certificado | Deshabilitar la cuenta o restablecer una contraseña que podría reutilizarse |
| Trabajo de PKI | Certificados de servidor y cliente, renovación y recuperación | Solo certificado de servidor |
| Mejor caso de uso inicial | Personal y dispositivos con privilegios gestionados por MDM | Endpoints no gestionados que no pueden inscribir certificados |
Un artículo técnico de Authentik de 2025 identifica EAP-TLS como EAP tipo ID 13 y PEAP como tipo ID 26. Estos ID identifican los métodos para RADIUS y el suplicante. No determinan qué personas o dispositivos deben utilizarlos.
Lo que cambian realmente estas filas
Las credenciales del cliente definen el límite operativo. EAP-TLS presenta un certificado de cliente X.509. PEAP utiliza un nombre de usuario y contraseña, habitualmente a través de EAP-MSCHAPv2 o EAP-GTC. Esto hace que la inscripción y renovación de certificados sea la carga de trabajo determinante, más que una clasificación teórica de métodos.
Las comprobaciones de confianza también difieren. EAP-TLS autentica tanto el certificado del cliente como el del servidor. PEAP valida el certificado del servidor RADIUS en el túnel TLS externo y, a continuación, autentica al usuario o dispositivo con un método interno.
La exposición de la contraseña depende de la configuración del suplicante. EAP-TLS no envía contraseñas por la red. PEAP transmite la contraseña dentro de su túnel, por lo que un cliente que omite las comprobaciones del servidor puede revelar una contraseña del directorio a un punto de acceso no autorizado. Con EAP-TLS, la falta de un certificado de cliente o uno que no sea de confianza hace que la autenticación falle.
La desvinculación de usuarios también depende de lo que se esté gestionando. Un certificado de dispositivo se puede revocar o dejar caducar sin restablecer la contraseña de directorio de una persona. Deshabilitar una cuenta o cambiar una contraseña reutilizada puede afectar a otros inicios de sesión vinculados a esa credencial.
El compromiso operativo es claro: EAP-TLS requiere certificados de cliente, renovación y una vía de recuperación, mientras que PEAP requiere el certificado del servidor y una configuración cuidadosa del suplicante. Asigne EAP-TLS al personal registrado y a los dispositivos con privilegios; mantenga PEAP para puntos finales no gestionados que no puedan unirse a la gestión de certificados. Los equipos que ejecutan infraestructura sin servidor para plataformas de miembros pueden tener diferentes grupos de miembros, personal y dispositivos, pero el modelo de alojamiento no elige el método de autenticación. La credencial debe coincidir con lo que se puede gestionar.
Cómo autentica cada método y dónde se filtran las contraseñas
EAP-TLS no es automáticamente la respuesta correcta para todos los usuarios. La decisión clave es si su equipo puede emitir, renovar y revocar certificados de forma fiable para cada grupo. PEAP mantiene la incorporación más sencilla para usuarios no gestionados, pero su contraseña depende de una configuración correcta del suplicante.
Ambos métodos utilizan 802.1X. El suplicante es el dispositivo que solicita el acceso, el autenticador es el punto de acceso o conmutador que retransmite dicha solicitud, y el servidor RADIUS la acepta o rechaza. Comparten el marco EAP, no una credencial.
El índice de especificaciones IETF EAP describe EAP-TLS, definido en el IETF RFC 5216, como una autenticación de cliente y servidor basada en certificados, con autenticación mutua, negociación de suites de cifrado con integridad protegida y derivación de claves. La especificación se publicó en marzo de 2008. En la práctica, EAP-TLS requiere un certificado de cliente emitido a través de PKI, junto con el certificado del servidor RADIUS.
Dos secuencias, un mismo marco
EAP-TLS autentica ambos extremos en un solo intercambio TLS:
- El suplicante inicia EAP con el autenticador, que retransmite la solicitud a RADIUS.
- Los certificados del servidor y del cliente se verifican durante el intercambio TLS.
- El intercambio protege la negociación de la suite de cifrado y deriva las claves, sin enviar ninguna contraseña que pueda ser objeto de phishing, ataque de repetición o fuerza bruta.
- Un certificado de cliente ausente o no confiable implica el rechazo del dispositivo. No es posible recurrir a la introducción de una contraseña.
PEAP crea un túnel TLS externo que autentica al servidor y, a continuación, ejecuta un método interno, habitualmente EAP-MSCHAPv2 o EAP-GTC. Dado que el método interno puede utilizar un nombre de usuario y una contraseña, los puntos finales generalmente no necesitan certificados de cliente. El índice de especificaciones EAP de la IETF también describe el marco de estándares que emplean estos métodos.
Los usuarios no ven el túnel externo de PEAP. La identidad interna, que suele ser un nombre de usuario y contraseña o un token, se envía solo después de que se establece TLS. Esto hace que PEAP resulte familiar para los suplicantes basados en directorio, aunque deja la contraseña expuesta si el cliente no verifica el túnel correctamente.
PEAP con EAP-TLS interno es un caso especial más complejo que combina un método basado en certificados con un túnel TLS externo. Un despliegue etiquetado como "PEAP" suele referirse a PEAP-MSCHAPv2.
Donde el suplicante decide el resultado
Un informe sobre métodos EAP de seguridad inalámbrica empresarial explica la distinción: EAP-TLS utiliza autenticación mutua X.509. RADIUS valida el certificado del cliente y el cliente valida el certificado del servidor. No hay ninguna contraseña disponible para realizar ataques de phishing, retransmisión o fuerza bruta. El informe también señala que el NIST exige que tanto la estación inalámbrica como el servidor de autenticación dispongan de certificados válidos.
Con PEAP, el cliente debe validar la cadena de certificados RADIUS y el nombre de servidor esperado. Si falta cualquiera de estas comprobaciones, un punto de acceso no autorizado puede solicitar una contraseña del directorio. Un perfil de suplicante configurado en "no validar" no protege la contraseña.
Regla práctica: Fije el nombre del servidor RADIUS y la CA emisora en el perfil de WiFi. Sin esas comprobaciones, PEAP puede ofrecer una contraseña a un servidor no autorizado.
Las respuestas MS-CHAPv2 capturadas se pueden descifrar fuera de línea después de que un atacante las obtenga a través de un túnel malicioso. Validar el túnel es la medida de control; el método interno no soluciona un perfil que acepta un servidor no confiable. Este mismo riesgo con las contraseñas va más allá del WiFi. Los informes sobre credenciales comprometidas en pequeñas empresas australianas subrayan por qué una contraseña de directorio reutilizada sigue siendo valiosa para un atacante.
Asigne EAP-TLS a dispositivos gestionados y usuarios cuyo ciclo de vida de certificados pueda administrar. Utilice PEAP cuando los usuarios o dispositivos no puedan recibir y renovar certificados de forma fiable, pero aplique la validación del nombre del servidor y de la CA a través del perfil del suplicante. El compromiso operativo es directo: los certificados requieren trabajo de inscripción y recuperación, mientras que las contraseñas le obligan a gestionar la reutilización y los cambios de cuenta. El mejor método depende de a quién pueda gestionar, no de declarar un ganador único para cada SSID.
Requisitos de certificados antes del despliegue
Confirme estos seis elementos en un laboratorio antes de la primera conexión en producción. La falta de una cadena o un nombre incorrecto parecerá que "el WiFi no funciona", no un error de certificado.
- Certificado de servidor RADIUS. Emítalo desde su CA privada. Incluya el nombre que fija el perfil del suplicante en el asunto o SAN. Configure el uso de autenticación de servidor y proporcione la cadena intermedia completa con el certificado. Una CA pública que firme cualquier nombre coincidente es el modelo de confianza equivocado para un nombre RADIUS interno.
- Certificado de cliente. Uno por dispositivo o usuario, con uso de autenticación de cliente. Incluya una identidad única en el SAN, como un nombre principal de usuario o un número de serie de dispositivo. Almacene la clave privada en el TPM o en el enclave seguro cuando la plataforma lo admita.
- Ancla de confianza. Instale la CA raíz interna o emisora a través del perfil MDM. No apunte los dispositivos a una raíz pública esperando que la comprobación de nombre sea suficiente.
- Validez y renovación. Establezca un periodo de validez para el certificado de servidor y para los certificados de cliente. Cree una ventana de solapamiento para que el reemplazo esté instalado antes de que expire el antiguo.
- Revocación. Proporcione al servidor RADIUS un extremo CRL u OCSP al que pueda acceder. Decida, por escrito, si la autenticación falla o continúa cuando ese extremo está fuera de línea. Pruebe el caso fuera de línea. No lo descubra durante un fallo puntual de la WAN.
- Canal de inscripción. Entregue certificados con SCEP o un PKCS#12 a través del MDM. Pruébelo en un dispositivo, incluida la renovación, antes de aplicarlo a un grupo.
Supongamos que una clínica utiliza Okta para la identidad del personal e Intune para los portátiles. El nombre de RADIUS en el perfil debe coincidir con el certificado, y el grupo de Okta que debe asignarse a la VLAN clínica debe ser el mismo grupo que utiliza el MDM para la inscripción. Nuestras notas sobre la autenticación WiFi con Okta explican esta transferencia de identidad sin convertir el laboratorio en un SSID basado en contraseña.
Conecte un portátil de prueba, revoque su certificado y confirme que la siguiente asociación falla antes de aplicarlo en un entorno real.
Ciclo de vida de los certificados y esfuerzo de despliegue
La seguridad de EAP-TLS se convierte en una interrupción del servicio cuando un certificado caduca o cuando un cliente no puede acceder a la información de revocación, aunque la cuenta de usuario siga siendo perfectamente válida. Esa es la cuestión que conviene analizar. Decir que "los certificados son más difíciles" no equivale a un diseño.
La Publicación Especial 800-120 del NIST expone esta misma responsabilidad. EAP-TLS requiere procesos fiables de emisión, distribución, renovación, gestión de la cadena de confianza y comprobación de revocaciones. Un dispositivo con un certificado caducado o un servicio de revocación inaccesible puede perder el acceso a la red incluso si la identidad del usuario sigue siendo válida. Por lo general, PEAP autentica el servidor en la fase TLS externa y el nombre de usuario y la contraseña mediante un método interno como MS-CHAPv2, por lo que omite ese ciclo de vida del cliente. Facilitar el primer día traslada la carga de trabajo al restablecimiento de contraseñas y a los perfiles mal configurados.
Evite que los certificados se conviertan en la causa de una caída
La respuesta de diseño es la automatización, no un manual de procedimientos más extenso.
- Inscribir a través del MDM. Despliegue el perfil, el ancla de confianza y el certificado juntos. La configuración manual de WiFi es la razón por la que se desmarcan las comprobaciones del nombre de servidor.
- Solapar la renovación. Instale el nuevo certificado antes de que caduque el antiguo. Un fin de semana en el que todos los portátiles dejan de funcionar a la vez se debe a un solapamiento demasiado corto.
- Probar la revocación fuera de línea. Tenga claro si RADIUS falla en modo cerrado o abierto cuando no se pueden recuperar las listas CRL o las respuestas OCSP.
- Mantener una vía de recuperación. Un punto final con fallos necesita un método de retorno que no sea "pedir prestada la contraseña PEAP de alguien". Un puerto de soporte por cable o un SSID de recuperación con alcance restringido es mejor que una clave compartida escrita en una pizarra.
Purple Access obtiene certificados EAP-TLS de Microsoft Intune, Jamf Pro, JumpCloud, Kandji, Hexnode, Iru y Addigy, entregados a través de SCEP, con una configuración que solo requiere de cinco a diez minutos una única vez para la organización en lugar de hacerse por dispositivo. La red segura no requiere contraseña y se basa en certificados; si un dispositivo no cumple con la postura de seguridad, se rechaza en la autenticación mediante el Conditional Access. Se trata de un acceso condicionado al cumplimiento normativo, no de una segunda solicitud de contraseña.
PEAP sigue siendo la opción directa cuando la PKI no está suficientemente desarrollada, cuando los contratistas no pueden incluirse en el MDM o cuando los entornos BYOD mixtos no aceptan un certificado. La sanidad, la educación, el sector hotelero y otras flotas con múltiples sedes suelen enfrentarse a estos tres retos simultáneamente. Utilice EAP-TLS para dispositivos corporativos gestionados, del personal y de alto riesgo. Mantenga una alternativa estrictamente controlada para puntos finales no gestionados o temporales. La identidad a escala de las instalaciones es la decisión clave, no el eslogan de que TLS ha superado a las contraseñas.
Si el propio RADIUS es el elemento frágil, un backend alojado elimina el fallo del "servidor único en el armario de la sede central". Nuestro artículo sobre RADIUS-as-a-Service es el lugar adecuado para verificar la accesibilidad y la redundancia antes de atribuir el problema al método EAP.
El breve recorrido a continuación muestra la inscripción de certificados junto a un método interno por contraseña, que es el contraste que ven los equipos de soporte cuando la renovación se retrasa.
Velocidad de itinerancia con revocación y compatibilidad de clientes
El soporte y la velocidad son problemas de consulta. Los suplicantes actuales de Windows, macOS, iOS, Android y ChromeOS admiten ambos métodos. Lo que difiere es el modo de fallo.
EAP-TLS falla cuando el perfil, la CA emisora o las fechas de validez son incorrectos. PEAP falla cuando el método interno, el formato de identidad o la comprobación del nombre de servidor no coinciden con la directiva de RADIUS. Ninguno de estos fallos significa que el punto de acceso "no sea compatible con enterprise".
La revocación presenta la misma división. Deshabilitar el certificado de un dispositivo corta la conexión de ese portátil sin afectar a los demás inicios de sesión de la persona. Restablecer una contraseña de directorio afecta a todos los clientes no gestionados que la sigan utilizando. La interrupción inmediata y específica por dispositivo es la ventaja de EAP-TLS. Los fallos críticos por certificados caducados son el coste asociado.
Handshakes, no nombres de marca
Un documento de la ACM sobre la latencia de autenticación inalámbrica señala que el rendimiento depende del número de negociaciones (handshakes), la itinerancia (roaming), la validación de certificados y la latencia del backend, más que del nombre del método. EAP-TLS estándar completa la autenticación de certificados de cliente y servidor en su intercambio TLS. PEAP establece un túnel TLS y luego ejecuta la autenticación interna, añadiendo una fase distinta. El material técnico de Cisco citado en dicho documento señala que PEAP con EAP-TLS interno implica dos negociaciones TLS y puede resultar lento cuando se produce una reautenticación completa durante la itinerancia.
Mida estos valores por separado. No dé por ganador a ningún método basándose en un único tiempo medio de inicio de sesión.
- Tiempo de asociación a IP en el percentil 95
- Autenticación completa frente a latencia de reanudación de itinerancia
- Tiempo de ida y vuelta de RADIUS
- Tasa de fallos de autenticación
- Fallos en la renovación de certificados
La reanudación de sesión, el almacenamiento en caché de PMK o 802.11r, la accesibilidad local a RADIUS y una cadena de certificados corta influyen más en esas métricas que cambiar la suite de cifrado. PEAP puede parecer sencillo el primer día y, aun así, generar retrasos debido a intercambios de contraseñas repetidos y tareas de soporte al usuario. EAP-TLS puede parecer instantáneo tras la inscripción y, más tarde, fallar por completo debido a un certificado caducado.
| Síntoma | Método más probable | Causa habitual | Solución práctica |
|---|---|---|---|
| Solicitud de contraseña repetida cerca de un AP desconocido | PEAP | El suplicante no valida el nombre ni la cadena del servidor | Desplegar un perfil que fije el nombre RADIUS y la CA |
| El acceso se interrumpe en un portátil tras un cambio de rol | EAP-TLS | Certificado revocado o dispositivo eliminado del MDM | Confirmar la revocación y volver a inscribir solo ese dispositivo |
| Todo el equipo bloqueado un lunes | EAP-TLS | Los certificados caducaron a la vez o el solapamiento de renovación fue demasiado corto | Planificar la renovación antes de la caducidad y mantener una vía de recuperación |
| La itinerancia parece lenta solo en la reautenticación completa | PEAP con EAP-TLS interno | Dos Handshakes TLS | Priorizar la reanudación, la caché PMK o 802.11r; evitar EAP-TLS interno salvo que sea necesario |
| Rechazos aleatorios solo en una ubicación | Cualquiera | Tiempo de ida y vuelta de RADIUS o recuperación de cadena, no el nombre EAP | Medir el RTT y el percentil 95 de asociación a IP antes de cambiar de método |
Una iteración lenta de itinerancia (roaming) en una sede suele deberse a la distancia con el servidor RADIUS o a la búsqueda de la cadena de certificados, no a una prueba de haber elegido el tipo de EAP incorrecto.
Asigne cada grupo de usuarios y demuestre la separación
Un mismo edificio puede albergar portátiles de empleados, un invitado a una conferencia, un Mac de un contratista y una caja registradora. No deberían compartir el mismo tipo de credencial. Mapee cada grupo, realice una prueba piloto en una ubicación junto a la red que ya opera y evalúe las incidencias y el registro de autenticación antes de replicar el diseño.
| Población | Usar | No usar | Por qué |
|---|---|---|---|
| Personal gestionado por MDM y usuarios con privilegios | EAP-TLS en un SSID WPA-Enterprise | PSK compartida o PEAP | Identidad mediante certificado, VLAN por grupo, el acceso finaliza cuando la cuenta se deshabilita |
| Invitados y visitantes de corta estancia | Captive Portal o Passpoint en una VLAN de invitados | Inscripción de PEAP o EAP-TLS en recepción | Sin ciclo de vida de certificados y sin contraseña de directorio que pueda sufrir phishing |
| Portátiles no gestionados y contratistas | PEAP-MSCHAPv2 solo con validación forzada del servidor | EAP-TLS si no se pueden inscribir o renovar | Las contraseñas ya existen, pero el perfil debe verificar el certificado RADIUS |
| Impresoras, televisores, TPV, CCTV y sensores | PSK por dispositivo con su propia VLAN | EAP-TLS o una contraseña PEAP compartida | Estos dispositivos no suelen almacenar certificados y una clave compartida es difícil de rotar |
| Espacio de uso mixto en un solo edificio | División por identidad a través de VLAN independientes | Un solo SSID y un único método para todo el mundo | El personal, los invitados y los objetos fallan de formas distintas y no deben compartir el mismo tipo de credencial |
Quién sigue utilizando contraseñas y quién no debe hacerlo
El personal gestionado y los usuarios con privilegios obtienen EAP-TLS en un SSID WPA-Enterprise. El personal de limpieza, recepción y operaciones puede autenticarse con certificados desde un MDM mediante SCEP, asignarse a una VLAN por grupo de directorio y perder el acceso cuando se deshabilita la cuenta. Una PSK compartida o una contraseña PEAP vuelve a crear exactamente el problema que intentaba eliminar.
Los invitados y visitantes permanecen en un Captive Portal o Passpoint, en una VLAN de invitados. No inscriba certificados en la recepción ni los configure en PEAP. No hay un ciclo de vida que vaya a gestionar y hay una contraseña de directorio que no quiere que sea objeto de phishing. Un perfil de Passpoint puede volver a conectarse en la siguiente visita sin necesidad de una nueva solicitud.
Los portátiles no gestionados y los contratistas pueden permanecer en PEAP-MSCHAPv2, únicamente si el perfil fuerza la validación del servidor. Si no puede inscribirlos o renovarlos, EAP-TLS los dejará sin conexión. Si no puede forzar la comprobación del servidor, el riesgo de la contraseña supera la conveniencia y no deberían estar en el SSID del personal en absoluto.
Impresoras, televisores, cajas registradoras, EPOS, CCTV, sensores y controladores de puertas reciben una PSK por dispositivo y su propia VLAN. Por lo general, no pueden almacenar certificados. Una contraseña PEAP compartida vuelve a introducir el problema de la clave compartida. El requisito 2.3.2 de PCI DSS v4.0.1 exige que las claves inalámbricas cambien cuando cualquier persona que las conozca abandone la empresa, algo que una clave compartida hace inviable. iPSK es la solución adecuada para esos dispositivos. Los televisores de las habitaciones, los termostatos y las cajas registradoras deben estar en VLAN vinculadas a claves a las que los invitados nunca tengan acceso.
Demuéstrelo en una ubicación
Implemente el nuevo diseño en los puntos de acceso que la sede ya tiene, junto a la red actual. Evalúelo en función de las incidencias y las pruebas de auditoría, no por una sesión de demostración.
Exija un registro de autenticación que recopile cada aceptación y rechazo con identidad, dispositivo, estado de inscripción en MDM, método, punto de acceso, SSID, ubicación, VLAN, rol, motivo y hora. Ese mismo registro constituye el conjunto de evidencias para los controles de acceso y registro de ISO 27001 y para los requisitos 8 y 10 de PCI-DSS. Sin MDM, proteja primero los perfiles PEAP y programe los certificados únicamente para la población gestionada.
Podemos ejecutar esta división como tres redes por propiedad. Los invitados utilizan el portal, incluida la verificación de habitación del PMS cuando la propiedad disponga de uno. El personal utiliza EAP-TLS o Passpoint. Los dispositivos IoT utilizan claves por dispositivo. El servicio RADIUS en la nube envía cada dispositivo a la red y VLAN correctas según su identidad, y rechaza a los usuarios salientes cuya cuenta esté deshabilitada. La ruta de migración para dejar atrás una contraseña de personal compartida es la misma que se describe en nuestra guía para migrar el WiFi del personal multisentorno a 802.1X.
Comenzaría la prueba piloto con el SSID del personal gestionado y las claves por dispositivo para las cajas registradoras, dejando a los contratistas en un perfil PEAP validado hasta que el registro sea definitivo. Un único método para todos se ve más limpio en un diagrama, pero falla de tres formas distintas sobre el terreno.
Purple Access ejecuta WiFi de empleados basado en certificados y claves por dispositivo para objetos en los puntos de acceso que ya posee, de modo que eap tls vs peap pasa a ser una elección por población en lugar de un riesgo para toda la infraestructura. Puede probar accesos abiertos, seguros y xPSK en una sola ubicación para luego evaluar las incidencias y el registro de autenticación antes de un despliegue más amplio. Visite Purple Access para planificar las redes de sus empleados, invitados y dispositivos.
