Incorporación BYOD: Cómo configurar el acceso de personal e invitados

Un nuevo empleado llega con su teléfono personal, un contratista aparece con un portátil antiguo y un invitado necesita WiFi antes de que empiece una reunión. Si los tres reciben la misma contraseña compartida, resulta fácil conceder el acceso pero difícil controlarlo después. La incorporación de dispositivos BYOD funciona mejor si se elige una vía para cada tipo de dispositivo y, a continuación, se planifica qué ocurre cuando alguien no puede o no quiere inscribirlo.

La clave consiste en tratar la incorporación como un ciclo de vida. Una página de inicio de sesión puede registrar quién se ha conectado, pero no establece que un dispositivo sea seguro, no decide a qué puede acceder ni garantiza que se pueda revocar su acceso.

Índice de contenidos

• Elección de un método de incorporación BYOD
  • Elija la opción predeterminada antes de la excepción
• Configure el portal cautivo y el inicio de sesión con SSO
  • Cree y pruebe el flujo de inicio de sesión
• Emita certificados EAP-TLS a través de su MDM
  • Haga que la confianza del dispositivo forme parte de la incorporación
• Incorporación sin MDM y claves por dispositivo para dispositivos compartidos
  • Utilice un pase o una clave con un propietario definido
• Rutas alternativas para dispositivos no compatibles y gestionados parcialmente
  • Mantenga la excepción acotada y documentada
• Reglas de consentimiento, privacidad y desvinculación
• Confirme el orden de las rutas y realice primero una prueba piloto
  • Establezca métricas para la prueba piloto antes del lanzamiento

Elección de un método de incorporación BYOD

Método	Gestión de dispositivos necesaria	Credencial emitida	Ideal para	Limitación principal
Portal cautivo con SSO, Google, Apple, Facebook o SMS	Ninguna	Sesión de navegador con consentimiento registrado	Invitados y visitantes ocasionales	El inicio de sesión en el portal no demuestra la postura de seguridad del dispositivo
Certificado EAP-TLS emitido por MDM a través de SCEP	MDM registrado como Intune o Jamf Pro	Certificado por dispositivo	Teléfonos y portátiles de empresa administrados	Los dispositivos personales no registrados no pueden conectarse
Pase WiFi instalado mediante aplicación sin MDM	Aplicación de instalación, sin MDM	Pase por usuario o por dispositivo	Personal de limpieza, personal de ETT, teléfonos personales	Menor visibilidad sobre la postura de seguridad del dispositivo
Clave xPSK por dispositivo	Ninguna en el dispositivo	Clave compartida previamente única por dispositivo	Cajas registradoras compartidas, IoT, residentes	Requiere gestión de claves y un proceso de revocación
Perfil Passpoint o OpenRoaming	Perfil instalado en el dispositivo	Identidad basada en certificados	Invitados habituales en múltiples sedes	Solo dispositivos compatibles con Passpoint

Estas vías se adaptan a diferentes niveles de confianza y a distintas expectativas de los usuarios. Un portal web mantiene el acceso de invitados de forma sencilla, pero no puede verificar el estado de seguridad de un teléfono. Un certificado proporciona a un dispositivo gestionado una identidad más sólida en el momento de la conexión, pero requiere inscripción. Para los dispositivos que no pueden admitir un perfil MDM, un pase o una clave única ofrece una alternativa a la contraseña compartida en todo el centro.

El uso de dispositivos personales (BYOD) se convirtió en un requisito de control de acceso a medida que estos pasaron al trabajo diario. En una encuesta del IBSG de Cisco realizada en 2012 a 600 líderes empresariales y de TI de EE. UU., el 95 % afirmó que sus organizaciones permitían de algún modo los dispositivos propiedad de los empleados, y el 84 % tanto permitía los dispositivos personales como proporcionaba al menos cierto soporte (estudio de BYOD de 2012 de Cisco). Esa distinción es importante: permitir un dispositivo en WiFi no es lo mismo que ofrecerle soporte, asignarle el acceso adecuado o prepararse para retirar sus credenciales.

Elija la opción predeterminada antes que la excepción

Comience asignando una ruta predeterminada a cada clase de dispositivo. Los dispositivos gestionados del personal deben utilizar certificados; los invitados deben usar un portal; los dispositivos sin MDM deben obtener un pase instalado mediante aplicación o una clave única, nunca una contraseña compartida. Para los invitados que vuelven, Passpoint o OpenRoaming pueden ser adecuados si sus dispositivos admiten el perfil.

A continuación, compruebe si la opción predeterminada elegida requiere algo que el usuario no vaya a proporcionar, como permiso para gestionar un teléfono personal. Envíe únicamente esas excepciones a las rutas de reserva, en lugar de debilitar la opción predeterminada para todos. Una WiFi descripción general del control de acceso puede ayudar a los equipos a asignar la autenticación a la directiva de acceso, pero las clases de dispositivos y los permisos de red deben determinar la elección final.

Configure el portal cautivo y el inicio de sesión de SSO

Un portal cautivo es una opción predeterminada y práctica para los invitados, ya que pueden iniciar sesión sin necesidad de instalar un perfil de gestión. También es útil cuando se debe registrar el consentimiento o permitir que los visitantes se autentiquen con una cuenta que ya posean. La decisión de diseño fundamental es a dónde redirige el portal a cada usuario tras iniciar sesión: la autenticación debe llevar a la red adecuada y no conceder un acceso amplio por defecto.

Cree y pruebe el flujo de inicio de sesión

1. Planifique la red y elija un sitio piloto. En una sesión de diseño, mapee los puntos de acceso, los SSID, los grupos de directorio y las clases de dispositivos en redes abiertas, seguras y de xPSK. Un ingeniero de redes debe proporcionar al equipo un plan y un sitio piloto, de modo que la configuración refleje la infraestructura física en lugar de un diagrama idealizado.

2. Registre una aplicación de identidad. Configure una aplicación en Entra ID, Google Workspace o Okta y otorgue el acceso al directorio necesario para el inicio de sesión. Utilice primero un registro piloto para poder comprobar los permisos y la experiencia de inicio de sesión antes de ampliar el despliegue.

3. Añada los detalles del portal y de RADIUS al controlador. Configure el servidor RADIUS y la URL de la página de bienvenida. Una vez creado el registro de la aplicación, la configuración del lado del cliente se completa en menos de 15 minutos, incluidos estos cambios en el controlador.

4. Elija los métodos de inicio de sesión para cada audiencia. Utilice SSO para el personal que necesite una identidad corporativa, Google o Apple para cuentas personales, y Facebook donde los visitantes lo esperen. Los códigos de acceso de un solo uso por SMS ofrecen otra alternativa a los visitantes que no dispongan de una cuenta adecuada.

5. Aplique la identidad de marca al portal y aclare el consentimiento. Redacte el texto de consentimiento en un lenguaje sencillo y registre una entrada para cada inicio de sesión. Ubique el aviso donde el usuario pueda leerlo antes de aceptar, no debajo del botón que debe pulsar.

6. Pruebe dispositivos reales en la red de invitados. Conecte un iPhone personal, un teléfono Android y un portátil Windows. Confirme que cada usuario acceda a la red VLAN de invitados y que el aislamiento de clientes impida que los dispositivos de invitados se comuniquen entre sí.

Los errores habituales en las pruebas piloto son una URL de bienvenida que apunta a la controladora equivocada, el texto de consentimiento oculto debajo del botón de inicio de sesión y realizar pruebas únicamente con dispositivos corporativos. Cada uno de estos fallos puede hacer que un portal parezca un éxito en una prueba reducida, pero falle para las personas que realmente lo necesitan. Los equipos que utilizan Okta también pueden revisar esta guía sobre la autenticación de Okta WiFi al planificar la conexión de identidades.

Emita certificados de EAP-TLS a través de su MDM

En el caso de los dispositivos gestionados del personal, una incorporación basada en certificados vincula el acceso a la red con un dispositivo inscrito, en lugar de depender de una contraseña compartida WiFi. El dispositivo demuestra su identidad durante la conexión y la identidad del usuario puede determinar qué permisos de red son aplicables. El NIST describe un certificado aprovisionado como una forma de identificar y autenticar un dispositivo móvil en el punto de conexión, y señala que combinarlo con las credenciales del usuario puede proporcionar una autenticación de doble factor (guía de seguridad de dispositivos móviles del NIST's).

La escala rara vez resulta un problema aquí. La distribución de certificados a través de SCEP tarda de cinco a diez minutos una sola vez para toda la organización, por lo que la noche del cambio los ordenadores portátiles y teléfonos gestionados reciben su certificado desde el MDM y se conectan automáticamente. El trabajo más complejo consiste en decidir qué controles debe superar un dispositivo antes de que ese certificado pase a ser de confianza.

Incorpore la confianza en el dispositivo en el registro

1. Autentique al usuario. Comience con SSO u otro factor aprobado, para que la red pueda asociar un dispositivo con una persona o cuenta conocida.

2. Compruebe la inscripción y el estado de seguridad. Confirme que el dispositivo esté inscrito y cumpla con los requisitos mínimos de seguridad y SO de la organización. Trate los dispositivos personales como potencialmente no fiables hasta que superen estas comprobaciones.

3. Emita un certificado vinculado al dispositivo. Utilice el MDM para entregar el certificado mediante SCEP. Una credencial vinculada a un dispositivo es más fácil de gestionar que un secreto compartido, ya que se puede asociar a un único punto final inscrito y revocarse sin afectar a nada más.

4. Conéctese mediante EAP-TLS. Configure el cliente y la red para validar los certificados correspondientes. Las credenciales de usuario y el certificado del dispositivo ofrecen entonces comprobaciones de identidad independientes en el momento de la conexión.

5. Asigne el acceso por grupos. Asocie grupos de directorio con VLAN de privilegio mínimo, de modo que el rol del empleado determine a qué recursos puede acceder la sesión. Una autenticación correcta no debe implicar automáticamente el acceso a todos los servicios internos.

6. Revise la conformidad de forma continua. No limite la evaluación de directivas a la inscripción inicial. Vuelva a evaluar el estado de seguridad del dispositivo y retire el acceso cuando un dispositivo deje de cumplir los requisitos o cuando se deshabilite la cuenta asociada.

Entre las causas habituales de las incidencias del servicio de asistencia se incluyen versiones de SO no compatibles, certificados caducados, hora del sistema incorrecta, falta de certificados en la cadena de confianza, aleatorización de la dirección MAC privada y usuarios que rechazan los permisos de gestión. Siga de cerca los fallos por modelo de dispositivo y versión de SO, ya que una tasa general de registro satisfactoria puede ocultar un fallo recurrente en una plataforma concreta.

• SO no compatible: Ofrezca una ruta de actualización autorizada o redirija el dispositivo a un acceso restringido.
• Certificado caducado: Automatice la renovación con la suficiente antelación para evitar interrupciones al caducar una credencial.
• Hora incorrecta o falta de cadena de confianza: Compruebe el reloj del dispositivo y la instalación del certificado antes de modificar la directiva de red.
• Aleatorización de MAC privada: Confirme si la directiva de la red depende de una dirección de dispositivo estable y proporcione instrucciones de configuración específicas de la plataforma.
• Permisos de gestión rechazados: Explique qué puede ver la administración y ofrezca una ruta de reserva en lugar de conceder un acceso amplio.

La línea base de cumplimiento en sí sigue siendo sencilla. Los dispositivos deben recibir actualizaciones de seguridad de forma puntual y programada, utilizar el bloqueo de pantalla, instalar aplicaciones únicamente de fuentes autorizadas y tener prohibido el acceso si se han sometido a procesos de root o jailbreak. Un dispositivo que no supere estos controles de estado debe ubicarse en una red segregada y con privilegios reducidos, no en la red corporativa.

La secuencia es más fácil de entender cuando se puede ver el flujo de certificados en contexto. El siguiente vídeo ofrece un complemento visual a los pasos de incorporación.

Incorporación sin MDM y claves por dispositivo para dispositivos compartidos

Algunos dispositivos no pueden completar la inscripción en el MDM. Esto incluye un teléfono personal cuyo propietario no permite su gestión, una caja registradora o quiosco compartido y un sensor IoT sin una interfaz de inscripción adecuada. La solución no consiste en ponerlos todos en la red del personal. Utilice una ruta restringida que proporcione a cada dispositivo una credencial identificable y un propietario claramente asignado.

Utilice un pase o clave con un propietario definido

1. Confirme que el dispositivo no está administrado o no es compatible. Compruebe que no puede utilizar la ruta de certificado y que su propietario acepta la aplicación de instalación. Esto evita que una excepción se convierta en la norma solo porque el registro sea incómodo.

2. Proporcione a los teléfonos personales un pase WiFi instalado mediante aplicación. El usuario inicia sesión e instala el pase sin registrar todo el teléfono en el MDM. Para un despliegue administrado, los teléfonos personales pueden instalar un pase WiFi desde la aplicación Purple en dos toques la noche de la transición.

3. Asigne a cada terminal compartido su propia clave xPSK. Sitúe la caja registradora o quiosco en su propia VLAN, con un límite de ancho de banda adecuado a su función. Una clave única evita que una misma contraseña se extienda por todas las cajas registradoras.

4. Ajuste la duración de la clave al uso. Configure su validez para que coincida con la reserva, el contrato o el patrón de turnos. Credenciales temporales no deberían seguir siendo útiles cuando la persona o el dispositivo ya no necesiten acceso.

5. Registre quién posee cada clave. Mantenga el propietario del dispositivo o usuario asociado a la credencial, de modo que el personal de soporte pueda identificar qué acceso revocar cuando se pierda un dispositivo o se marche un empleado.

6. Revoque la clave y pruebe el resultado. Elimine el acceso al finalizar la relación y confirme que el dispositivo se desconecta de la red. La revocación forma parte del diseño del proceso de incorporación, no es una tarea que deba inventarse tras surgir un problema.

Estas rutas ofrecen menor visibilidad sobre el estado del dispositivo que un certificado, por lo que se deben mantener en redes restringidas en lugar de en la VLAN del personal. El equilibrio operativo es claro: una clave por dispositivo requiere más atención para su emisión y seguimiento, pero limita el alcance de una credencial comprometida.

Rutas alternativas para dispositivos no compatibles y gestionados parcialmente

El soporte no es lo suficientemente uniforme como para que la política de "registrarse o perder el acceso" sea viable para todos los empleados. Un informe de seguridad móvil de Verizon de 2025 reveló que el 15 % de las organizaciones encuestadas ofrecía soporte completo para todos los tipos de dispositivos móviles, mientras que el 32 % ofrecía soporte puntual, el 27 % solo admitía modelos designados y el 23 % no ofrecía soporte alguno. Esta brecha afecta a las personas que utilizan dispositivos más antiguos, a los contratistas, al personal de primera línea y a los empleados que no dan su consentimiento para una supervisión exhaustiva de su teléfono personal.

Caso de dispositivo	Ruta de incorporación	Acceso a la red	Comprobación antes de conceder
S.O. compatible y totalmente gestionado	Certificado MDM a través de EAP-TLS	Red segura por grupo de directorio	Estado de cumplimiento y caducidad del certificado
Teléfono personal, sin permiso de gestión	Portal cautivo o pase de aplicación WiFi	WiFi de invitados VLAN con aislamiento de clientes	Consentimiento registrado, sin VLAN corporativo
Versión de S.O. no compatible	Acceso solo por navegador a aplicaciones designadas	Red segregada de bajos privilegios	Fecha de actualización y lista de aplicaciones aprobadas
Caja registradora compartida o quiosco	Clave xPSK por dispositivo	WiFi propio VLAN con límite de ancho de banda	Propietario de la clave y ruta de revocación
Contratista o trabajador temporal	Inicio de sesión de invitado con límite de tiempo o dispositivo de préstamo	WiFi de invitados VLAN, que caduca al finalizar el contrato	Fecha de fin de contrato y responsable designado
Accesibilidad o solicitud para dispositivos antiguos	Revisión manual con un dispositivo de préstamo	Limitado a aplicaciones aprobadas	Fecha de revisión y propietario asignado

Mantenga la excepción acotada y documentada

Otorgue a cada dispositivo el acceso mínimo imprescindible para cumplir su función. Un teléfono personal que solo requiere acceso mediante navegador a un servicio concreto no necesita una ruta hacia las aplicaciones internas ni a la VLAN corporativa. Una caja registradora compartida necesita sus servicios asignados, y su credencial requiere un propietario designado y una ruta de revocación.

Publique una matriz de compatibilidad de dispositivos para que el personal pueda comprobar si su sistema operativo y su dispositivo se pueden inscribir antes de llegar a un centro. Mantenga un inventario de los sistemas operativos y aplicaciones no admitidos, y registre qué ruta alternativa se aplica a cada uno. Para contratistas y visitantes, una ruta de red con límite de tiempo ayuda a que la caducidad y la autorización sean explícitas.

Una regla rígida puede empeorar la seguridad si empuja a los empleados a utilizar zonas de cobertura inalámbrica personales, contraseñas compartidas u otras soluciones alternativas no gestionadas. Una ruta restringida y documentada suele ser más segura que denegar el acceso sin ofrecer una alternativa.

Consentimiento, privacidad y reglas de salida

«¿Puedo rechazar el uso de mi propio dispositivo (BYOD) y qué podrá ver o borrar mi empleador exactamente?». Incluya la respuesta en el aviso de incorporación, antes de pedir al trabajador que acepte un perfil o instale una aplicación. La autenticación técnica no demuestra que la persona haya comprendido las condiciones o haya elegido libremente.

En una encuesta del sector asistencial, el 50 % de los proveedores utilizaba BYOD, pero solo la mitad de ellos disponía de una directiva al respecto; solo el 40 % del personal que utilizaba dispositivos personales recordaba haber firmado alguna norma o directiva. Una encuesta independiente de 2025 reveló que el 70 % del personal prefería dispositivos proporcionados por la organización (informe BYOD de atención social a adultos de 2025). Estos hallazgos cuestionan la suposición de que el acceso mediante dispositivos personales sea automáticamente más económico o conveniente para los trabajadores.

El aviso debe indicar, en un lenguaje sencillo:

• Qué telemetría de seguridad se recopila y qué contenido personal no puede ver la organización.
• Qué se puede eliminar, incluida la confirmación de que la eliminación de un perfil de trabajo no borrará el contenido personal.
• Quién paga los datos móviles de trabajo y el desgaste del dispositivo, con las reglas de reembolso correspondientes al país relevante.
• Cuál es la alternativa si el trabajador rechaza la gestión del dispositivo personal.

Una casilla de verificación no constituye un consentimiento válido si la participación es obligatoria en la práctica. Ofrezca un dispositivo de préstamo u otra ruta de acceso, y vuelva a solicitar el consentimiento si la supervisión o el uso de datos cambian. Para los procesos de registro de visitantes, los equipos también pueden utilizar la guía para verificar las identificaciones de los invitados antes del registro como recordatorio para reflexionar sobre qué información de identidad es necesaria y cómo se debe tratar.

El proceso de baja debe eliminar el certificado, el perfil de gestión, los tokens guardados en caché y cualquier clave xPSK asociada al dispositivo. Una demostración de Purple Access puede mostrar a un ingeniero emitiendo y revocando una clave en una red activa, utilizando los dispositivos de un apartamento: una cerradura, un termostato, el portátil de un invitado y el teléfono del personal de un cliente.

1. Emita una clave en un dispositivo activo.
2. Revoquela.
3. Cronometre cuánto tarda en interrumpirse el acceso.
4. Registre el resultado como la nota de corte para la revocación en la prueba piloto.

Confirme el orden de la ruta y realice una prueba piloto primero

Despliegue las rutas en un orden que impida que las excepciones definan toda la red. Cada clase de dispositivo obtiene una opción predeterminada, mientras que la prueba piloto confirma que la ruta funciona con las identidades, los controladores y los dispositivos en una ubicación real.

1. Empiece por los dispositivos gestionados del personal en EAP-TLS. Utilice la vía del certificado para portátiles y teléfonos registrados, con acceso vinculado a grupos de directorio y una ruta de revocación verificada.

2. Añada el portal de invitados. Procure que la experiencia de inicio de sesión sea clara y registre el consentimiento en cada sesión de invitado.

3. Pase los teléfonos personales y no gestionados del personal a un pase WiFi. Esto ofrece a los usuarios una vía que no requiere el registro completo del dispositivo.

4. Asigne a las TPV compartidas, quioscos y dispositivos IoT claves xPSK únicas. Asigne cada dispositivo a su propia directiva de acceso y registre quién es el propietario de sus credenciales.

5. Aplique vías alternativas únicamente para las excepciones. Utilice el acceso solo para navegador, una red de invitados o contratistas, un dispositivo de préstamo o una revisión manual cuando la ruta predeterminada no sea posible.

Establezca métricas piloto antes del lanzamiento

Elija un centro piloto y defina las notas de aprobación antes de que nadie comience la inscripción. Mida la finalización de la inscripción, la primera autenticación con éxito, las interacciones con el servicio de soporte por cada 100 inscripciones y el tiempo de revocación del acceso. Si establece los umbrales después de la prueba piloto, resulta demasiado fácil dar por bueno un resultado deficiente solo porque el centro ya está operativo.

Reserve una sesión de diseño y prepare su lista de SSID, el proveedor de sus puntos de acceso, el directorio y el MDM. Un ingeniero de redes puede trasladar esos datos a las redes abiertas, seguras y de xPSK, además de validar el plan con el centro piloto antes del despliegue. La solicitud de demostración recopila la información de la organización y de contacto, junto con la configuración actual del WiFi del cliente, incluidos los SSID, el proveedor de puntos de acceso, el directorio y el MDM.

---

Purple Access admite el inicio de sesión y el consentimiento mediante portal cautivo, certificados EAP-TLS a través de MDM y claves por dispositivo para equipos no gestionados. Visite Purple Access para solicitar una demostración e incorporar los detalles de sus dispositivos y de su red a la sesión de diseño.