SSO para pequeñas empresas: ventajas, costes y cómo empezar

El inicio de sesión único (SSO) permite a los empleados iniciar sesión una sola vez en un proveedor de identidad (IdP) central y abrir todas las aplicaciones de trabajo aprobadas sin una contraseña distinta para cada una. Esta guía trata el SSO para equipos de pequeñas empresas: qué es, por qué ayuda, cuándo compensa el esfuerzo, cuánto cuesta y cómo desplegarlo en cinco pasos.

El SSO también concentra el riesgo. Si el acceso al IdP puede ser objeto de phishing, una sola credencial robada abre todas las aplicaciones conectadas, de modo que el método de inicio de sesión importa tanto como el producto que elija.

Hideez publica esta guía. Es un proveedor de autenticación de personal sin contraseña basada en FIDO2, así que sabe desde dónde hablamos. Los consejos que siguen son neutrales entre las principales vías e incluyen un plan de piloto de 30 días y las pruebas que conviene pedir a cada proveedor antes de comprar.

¿Qué es el inicio de sesión único en una pequeña empresa?

En la práctica, un único acceso en un proveedor de identidad (IdP) central sustituye a una contraseña distinta en cada aplicación de trabajo aprobada. El IdP verifica quién es la persona y cada aplicación confía en su respuesta. Microsoft Entra ID y Okta son dos ejemplos de proveedores de identidad, y el SSO es una pieza de la gestión de identidades y accesos, la disciplina que decide quién puede llegar a qué sistema.

¿Cómo funciona el inicio de sesión único?

Cuando alguien abre una aplicación, esta (el proveedor de servicios) redirige el navegador al IdP. Tras la autenticación SSO, el IdP devuelve un token firmado, llamado aserción en SAML, y la aplicación concede el acceso. Los empleados nunca entregan su contraseña del IdP a la propia aplicación, lo que reduce los lugares por donde puede filtrarse una credencial.

Dos protocolos sostienen este intercambio. SAML usa XML y es habitual en el SaaS empresarial. OpenID Connect (OIDC) se basa en OAuth 2.0 y es adecuado para aplicaciones web y móviles modernas. Una aplicación solo puede sumarse si admite uno de ellos, así que su lista de aplicaciones determina hasta dónde llega el SSO.

El «Iniciar sesión con Google» de consumo sigue el mismo patrón, pero la versión empresarial añade control. Usted elige qué aplicaciones se conectan, exige MFA en un único acceso y desactiva una cuenta para cortar el acceso federado. Eso es la autenticación centralizada: un solo lugar donde se comprueba la identidad y un solo lugar donde se puede revocar.

¿Por qué necesitan SSO las pequeñas empresas?

Para una pequeña empresa, el SSO rinde en cuatro frentes: acceso más rápido, mayor seguridad, altas y bajas de personal más ordenadas y menos tickets de contraseñas. También tiene límites, que se tratan más adelante en esta guía: el SSO tax, las aplicaciones que no pueden federarse y el IdP como punto único de fallo.

Acceso simplificado a las aplicaciones de negocio

Piense en un equipo de 15 personas con 10 accesos distintos. Sin SSO, son 150 contraseñas que crear, reutilizar, olvidar y restablecer. Con SSO, cada empleado inicia sesión una vez por la mañana en el IdP y desde ahí llega a Slack, HubSpot y QuickBooks, sin más avisos durante el resto de la sesión.

La ventaja no es solo la rapidez. Con menos accesos hay menos notas adhesivas y contraseñas guardadas en el navegador, y el propietario del negocio dispone de una única lista de aplicaciones en la nube y de quién las usa, en lugar de una hoja de cálculo que se queda anticuada.

El inicio de sesión único también ayuda a que las herramientas nuevas se asienten. Cuando un equipo prueba una aplicación compatible con SAML u OIDC, conectarla al IdP lleva minutos y nadie tiene que crear una contraseña más solo para evaluarla. El personal remoto y móvil usa el mismo punto de entrada, de modo que el acceso no depende de la red de la oficina.

Mayor seguridad y menos riesgos por contraseñas

Los empleados reutilizan menos contraseñas y usted aplica la autenticación multifactor (MFA) una sola vez en el acceso al IdP, en lugar de hacerlo aplicación por aplicación.

La contrapartida es la concentración. Cada aplicación federada queda ahora tras un único inicio de sesión, de modo que una contraseña robada o un código retransmitido en el IdP las abre todas. Proteja primero ese punto de entrada: el SMS y las aprobaciones push pueden ser objeto de phishing, mientras que los métodos resistentes al phishing, como las passkeys FIDO2 y las llaves de seguridad, están diseñados para resistirlo. La comparación aparece en la sección sobre funciones de seguridad.

La MFA también resulta más fácil de aplicar de forma uniforme. Sin SSO, cada aplicación tiene su propio ajuste de MFA y es fácil dejar alguna sin activar. Con un único IdP, una sola política decide quién debe usar qué método y un solo registro muestra los inicios de sesión fallidos. Es un control de acceso práctico para un equipo sin personal de seguridad dedicado.

Onboarding y offboarding de empleados más sencillos

El onboarding de empleados pasa a ser un único paso: se crea la identidad, se añade a los grupos adecuados y las aplicaciones aprobadas aparecen. El offboarding de empleados es donde más se gana. Desactivar una sola identidad corta el acceso federado a todas las aplicaciones conectadas, por ejemplo los accesos a Microsoft 365, al CRM y al sistema de tickets de un empleado que se marcha, en una sola acción.

Desactivar a un usuario en el proveedor de identidad bloquea únicamente los inicios de sesión federados. Las cuentas locales, los tokens de API y los buzones compartidos de las aplicaciones no federadas siguen ahí, así que mantenga una lista breve de esas aplicaciones y límpielas a mano el último día.

Ejecute la desactivación antes de que termine la conversación de salida, para que ningún antiguo empleado conserve una sesión activa, y traspase la propiedad de los documentos compartidos a un responsable antes de cerrar la identidad.

Menos administración de TI y menos soporte por contraseñas

Menos contraseñas que olvidar significa menos solicitudes de restablecimiento, y quien se ocupa de TI a tiempo parcial recupera esas horas. Anote su volumen actual de restablecimientos antes del piloto para poder comparar después, y no tome prestadas cifras de ahorro de los proveedores: cuente sus propios tickets antes y durante el piloto.

El trabajo de administración no desaparece; se desplaza. El tiempo que antes se iba en restablecimientos pasa a revisiones de accesos, renovaciones de certificados e incorporación de aplicaciones.

El soporte por contraseñas incluye también tareas más discretas: cuentas bloqueadas el lunes por la mañana y el nuevo registro de un teléfono nuevo. Un breve manual de procedimientos por escrito para estos casos, a cargo del administrador suplente, evita que las solicitudes rutinarias interrumpan al administrador principal.

¿Compensa el SSO en una pequeña empresa?

Que el SSO compense depende menos del número de empleados que de tres factores: cuántas aplicaciones usa la gente, lo complicada que se ha vuelto la gestión de accesos y lo que exigen su seguridad y sus clientes. Una empresa de 10 personas con 25 herramientas en la nube y datos de clientes puede ganar más que un equipo de 60 que vive en dos aplicaciones.

¿Cuándo necesita SSO una pequeña empresa?

Normalmente conviene plantearse el SSO cuando se dan varias de estas condiciones:

• Un gran número de servicios de negocio. Cuando la gente maneja una docena o más de aplicaciones en la nube, los restablecimientos de contraseña y los accesos olvidados se convierten en un coste rutinario.

• Concesión y revocación frecuentes de accesos. El personal de temporada, los colaboradores externos, los becarios y la contratación rápida implican onboarding y offboarding constantes, donde un único interruptor de desactivación es mejor que diez cierres manuales.

• Datos confidenciales. Los registros de clientes, las finanzas, los expedientes de RR. HH. o la información sanitaria justifican un control de acceso más estricto y registros de quién ha iniciado sesión en qué.

• Necesidad de autenticación centralizada. Si debe exigir MFA en todas partes, demostrar quién tenía acceso en una fecha concreta o responder a un cuestionario de seguridad de un cliente, un acceso central es mucho más fácil de defender que muchos separados.

Si coinciden dos o más, merece la pena dedicar tiempo a un piloto.

¿Cuándo puede ser innecesario el SSO?

El SSO puede ser más de lo que necesita cuando el equipo usa solo un puñado de aplicaciones, los accesos cambian rara vez y nada en su entorno de TI es complejo. En ese caso, un despliegue completo puede costar más en configuración y tiempo de administración de lo que devuelve, al menos por ahora.

Eso no significa que el equipo quede desprotegido. Se puede tener una base de seguridad sin SSO completo:

• Autenticación multifactor en el correo, el almacén de archivos y la herramienta de finanzas, preferiblemente con passkeys o llaves de seguridad.

• Un gestor de contraseñas para que cada cuenta tenga una contraseña única y generada.

• Una revisión periódica de accesos, por ejemplo cada trimestre, para eliminar cuentas y permisos que nadie usa.

Trate esta base como un punto de partida, no como un veredicto. Repita la prueba de selección cuando añada aplicaciones, contrate con rapidez o firme con un cliente que exija requisitos de seguridad. Muchos equipos empiezan por la base y añaden después el SSO para las primeras cinco o seis aplicaciones, cuando la lista crece.

¿Cuánto cuesta el SSO para pequeñas empresas?

La licencia es solo una de las seis partidas. El coste total combina las licencias del proveedor de identidad, las mejoras de plan de las aplicaciones, los complementos de autenticación, el hardware, el tiempo de administración y un piloto, así que calcule las seis antes de preseleccionar nada. Prepare una hoja de cálculo con una fila por partida:

• Licencia del IdP: precio por usuario y mes, multiplicado por el número de empleados. Compruebe primero si una suite por la que ya paga incluye uno. Microsoft 365 Business Premium incluye Microsoft Entra ID P1, como explica la documentación de licencias de Microsoft Entra.

• Mejoras de nivel por SAML: muchos proveedores de SaaS reservan SAML u OIDC para un plan superior, lo que se conoce como SSO tax. Abra la página de precios de cada aplicación clave, anote la diferencia de precio por usuario y compárela con el listado de sso.tax.

• Complementos de MFA y de acceso sin contraseña: la MFA avanzada y la gestión del ciclo de vida suelen ser partidas aparte.

• Llaves de seguridad físicas: una por usuario más una de repuesto, si las utiliza. Los precios varían según el modelo, así que use la lista de precios vigente de la llave que preseleccione.

• Tiempo de administración: pida a cada proveedor el esfuerzo mensual realista y multiplíquelo por su coste interno por hora.

• Piloto: incluso una prueba gratuita consume horas del personal.

Sume las filas y compare el total con lo que le cuestan hoy los restablecimientos de contraseña y el offboarding manual. Los precios por usuario cambian con frecuencia, por eso esta guía no incluye una lista de precios: consulte la página de precios vigente de cada proveedor el día en que compare.

Cómo elegir la mejor solución de SSO para una pequeña empresa

La mejor solución de SSO para pequeñas empresas es la que sus aplicaciones, su presupuesto y su tiempo de administración pueden sostener, no la que tiene la lista de funciones más larga. Las soluciones de SSO para pequeñas empresas se agrupan en tres vías: el servicio de identidad incluido en una suite por la que ya paga, un proveedor de identidad independiente o una plataforma sin contraseña. Cada una cubre una parte distinta de sus aplicaciones y oculta costes distintos. Para una visión más detallada, proveedor por proveedor, consulte nuestra comparativa de las principales soluciones de SSO.

La regla general: si trabaja con Microsoft 365, empiece por Entra ID. Si trabaja con Google Workspace, pruebe la consola de administración como centro de identidad. Pase a un IdP independiente solo cuando muchas aplicaciones queden fuera de su suite, y elija una plataforma sin contraseña cuando la decisión dependa de la resistencia al phishing o de las estaciones de trabajo compartidas. Los cuatro criterios siguientes convierten esa regla en una lista de comprobación.

Compatibilidad con las aplicaciones de negocio existentes

La compatibilidad depende de la compatibilidad con protocolos, no del tamaño del proveedor, así que una aplicación empresarial conocida no está lista automáticamente. Compruebe cuáles de sus aplicaciones en la nube admiten SAML u OpenID Connect, y en qué nivel de precios, antes de comparar ningún proveedor. El método de la hoja de cálculo se describe en el paso 1 del despliegue.

Después mire el lado del proveedor. Un buen candidato ofrece integración SSO ya preparada para las aplicaciones que usted ya utiliza, además de una forma documentada de conectar el resto mediante una URL de metadatos o una plantilla genérica de SAML u OIDC. Pida la lista de aplicaciones compatibles y abra un tenant de prueba para confirmar que sus tres aplicaciones más críticas se conectan sin desarrollos a medida.

Compruebe también el directorio: su proveedor de identidad debe leer las cuentas y los grupos del que ya utiliza, para no tener que reconstruir los usuarios dos veces.

Funciones de seguridad y compatibilidad con MFA

El SSO deja todas las aplicaciones federadas tras un único inicio de sesión, por lo que el acceso al IdP debe resistir el phishing. Los métodos se diferencian sobre todo en si un atacante puede reutilizar lo que introduce el usuario:

Las passkeys ofrecen un punto de partida FIDO2 sin hardware específico allí donde sus dispositivos y aplicaciones las admiten. Compruebe la compatibilidad de cada aplicación y defina una vía de recuperación para los dispositivos perdidos.

Hay dos situaciones que exigen pensarlo con más detalle. Los ordenadores compartidos y la prohibición de teléfonos personales descartan la MFA basada en aplicaciones, de modo que las llaves de seguridad con NFC o USB-C permiten a cada empleado identificarse y salir con rapidez. La certificación FIDO corresponde a un modelo de llave concreto, así que compruebe el estado de certificación del modelo exacto que piensa comprar y pruébelo en una estación de trabajo compartida antes de hacer un pedido grande. Para las aplicaciones que el SSO no puede federar, un gestor de contraseñas o una pasarela para aplicaciones web heredadas cubren parte de la carencia, aunque ninguno cambia el inicio de sesión propio de la aplicación.

Facilidad de despliegue y de gestión

Un equipo pequeño no tiene personal de seguridad de sobra, así que el esfuerzo de despliegue importa tanto como las funciones. Haga una pregunta a cada proveedor: ¿cuál es el esfuerzo mensual realista de administración una vez que el sistema está en marcha? Después pregunte cuánto tardan en conectarse las tres primeras aplicaciones y quién le da soporte cuando caduca un certificado.

No es necesario sustituir Entra ID, Active Directory ni Keycloak para eliminar las contraseñas. El directorio sigue siendo la fuente de cuentas y grupos, y las passkeys o las llaves FIDO2 solo cambian la forma en que los usuarios demuestran su identidad. Antes de añadir una capa sin contraseña, compruebe:

• qué protocolo aceptan sus aplicaciones (SAML, OIDC o WS-Federation);

• qué usuarios necesitan llaves de seguridad físicas y cuáles pueden usar un teléfono;

• cómo se revoca y se sustituye una llave perdida.

Precios transparentes y escalabilidad

Elija un proveedor cuya página de precios muestre lo que incluye cada nivel, porque el precio por usuario que se anuncia rara vez refleja la factura completa. Compruebe si la gestión del ciclo de vida, la MFA avanzada, la conservación de los registros de auditoría y el soporte se facturan como partidas aparte, y pregunte qué ocurre con el precio cuando se duplica la plantilla o se añade una segunda sede.

La escalabilidad significa también que el producto siga funcionando a medida que crece la lista de aplicaciones. Confirme que añadir aplicaciones no conlleva una tarifa por aplicación, que los grupos y los roles se pueden gestionar sin scripts y que su configuración se puede exportar si algún día decide marcharse.

Por último, pida pruebas en lugar de adjetivos. Al preseleccionar proveedores, verifique las certificaciones (por ejemplo, ISO/IEC 27001), los registros de auditoría, la ubicación de los datos y el soporte de integración, y guarde las respuestas junto a su hoja de costes.

Cómo implantar el SSO en una pequeña empresa

Un plan con plazos definidos permite que un único administrador de TI despliegue el SSO junto con sus demás tareas. Los cinco pasos siguientes llevan unos 30 días para un equipo pequeño, con el piloto en el medio y una decisión go/no-go (seguir adelante o no) antes del despliegue general.

Paso 1: Revise sus aplicaciones y sus necesidades de acceso

Basta una hoja de cálculo de una página para ver qué cubrirá el SSO. Enumere todas las aplicaciones SaaS y anote estas columnas:

• Nombre de la aplicación, responsable y número de usuarios

• Método de inicio de sesión actual (contraseña, cuenta de Google o Microsoft, cuenta local)

• Compatibilidad con SAML u OIDC (sí, no, sin confirmar)

• Nivel de precios que la habilita

• Sensibilidad de los datos (finanzas, registros de clientes, RR. HH.)

Tome el nivel de la página de precios o de la documentación de administración de cada proveedor y confírmelo después en un tenant de prueba. En la consola de administración, busque los ajustes de «SSO», «SAML» o «proveedor de identidad». Después clasifique las aplicaciones en tres grupos:

• Federar ahora: el protocolo está disponible en su plan actual. Empiece por las aplicaciones con los datos más sensibles.

• Federar más adelante: el protocolo requiere un nivel superior. Compare el precio de la mejora con el riesgo antes de pagar.

• No se puede federar: no admite SAML ni OIDC en absoluto.

Para el tercer grupo, las opciones son las credenciales custodiadas en un gestor de contraseñas, el SSO basado en contraseñas o una pasarela para aplicaciones web heredadas como Hideez AuthShield. Ninguna cambia el inicio de sesión propio de la aplicación, así que mantenga un paso manual de offboarding para estas aplicaciones.

Paso 2: Elija un proveedor de identidad

Use la auditoría para elegir la vía de la comparativa anterior: suite integrada, IdP independiente o plataforma sin contraseña. Preseleccione dos proveedores como máximo, porque cada prueba adicional cuesta horas del personal.

Para cada uno, confirme cuatro puntos: que conecta sus aplicaciones de «federar ahora», que admite MFA resistente al phishing, que lee su directorio actual y que su precio es claro para su número de empleados. Verifique las certificaciones y los registros de auditoría con documentos, no con una respuesta comercial.

Decida quién es el responsable del sistema. Nombre un administrador principal y uno suplente, para que unas vacaciones o una baja voluntaria no dejen el IdP sin gestión. Anote en una sola página la decisión, el coste mensual y las aplicaciones incluidas para la revisión go/no-go del paso 4. Documente también la vía de salida: cómo se trasladarían los usuarios y la configuración a otro proveedor si cambian los precios o las necesidades.

Paso 3: Configure el SSO y la MFA

Conecte primero de tres a cinco aplicaciones, empezando por las más sensibles. Para cada una, configure SAML u OIDC, asigne los atributos de usuario que espera la aplicación (normalmente correo electrónico y nombre) y pruebe un inicio de sesión completo de principio a fin. Después exija MFA en el acceso al IdP, con passkeys o llaves de seguridad cuando los dispositivos lo permitan, y deje el SMS solo como último recurso.

El SSO concentra el riesgo en un único acceso, así que planifique su fallo antes de que alguien dependa de él. Cree dos cuentas de administrador de emergencia (break-glass) que no dependan del SSO ni de políticas de inicio de sesión que pudieran bloquearlas, y guarde sus credenciales en lugares seguros y distintos. Microsoft recomienda al menos dos cuentas de acceso de emergencia.

Configure también un método de autenticación de respaldo para cada usuario, anote los pasos de recuperación ante la pérdida de un dispositivo y empiece un calendario con las fechas de caducidad de los certificados. Un certificado SAML caducado es una causa frecuente de fallos repentinos de inicio de sesión en toda la empresa.

Paso 4: Pruebe con un grupo pequeño de empleados

Elija de 5 a 10 usuarios piloto de funciones distintas, idealmente con una persona a la que no le gusten los cambios. Proporcióneles de tres a cinco aplicaciones conectadas, una guía de una página y un canal directo para los problemas. Mantenga el piloto durante varias semanas y fije los criterios go/no-go antes de que empiece.

Un plan de cuatro semanas basta para un equipo pequeño:

• Semana 1: inventaríe todas las aplicaciones y elija de 3 a 5 aplicaciones y de 5 a 10 usuarios piloto.
• Semana 2: configure SAML u OIDC y exija MFA o passkeys.
• Semana 3: recoja los puntos de fricción y los tickets de la mesa de ayuda.
• Semana 4: decida go o no-go según sus criterios.

Compare los tickets con el volumen de restablecimientos que anotó antes. Pruebe a propósito los casos incómodos: una llave perdida, un teléfono nuevo, un usuario que se marcha y una estación de trabajo compartida.

Paso 5: Despliegue el SSO y supervise los accesos

Si el piloto cumple sus criterios, despliegue por oleadas, equipo a equipo, en lugar de hacerlo en un solo fin de semana. Anuncie la fecha, publique la guía y mantenga disponibles las vías de acceso antiguas durante un periodo breve y fijo, para que un inicio de sesión fallido nunca bloquee una llamada con un cliente.

Cuando todos estén en SSO, pase a la supervisión rutinaria. Revise los registros de inicio de sesión en busca de intentos fallidos y ubicaciones inusuales, haga una revisión trimestral de accesos y compruebe el calendario de certificados cada mes. Cada vez que alguien se marche, desactive primero la identidad y después limpie las aplicaciones no federadas de su hoja del paso 1.

Revise el inventario de aplicaciones cada seis meses. Las herramientas nuevas llegan sin hacer ruido, y cada una que evita el IdP vuelve a abrir el problema de las contraseñas que el SSO debía cerrar.

Retos habituales del SSO en las pequeñas empresas (y cómo superarlos)

CISA estudió las barreras para la adopción del SSO en las pequeñas y medianas empresas y publicó su informe en junio de 2024. La tabla recoge los retos habituales de los equipos pequeños y una forma práctica de superar cada uno.

La mayoría de estos retos se convierten en puntos de una lista de comprobación cuando se planifican antes de comprar.

Cómo ayuda Hideez a las pequeñas empresas a implantar el SSO sin contraseña

Hideez Workforce Identity ofrece SSO sin contraseña, que permite a los empleados iniciar sesión una sola vez para acceder a las aplicaciones de negocio conectadas sin contraseñas distintas. Es compatible con SAML y OpenID Connect, con autenticación mediante passkeys, la app móvil Hideez Authenticator o llaves de seguridad FIDO2.

Para los equipos de TI pequeños, esto significa menos contraseñas que restablecer y un único lugar desde el que gestionar el acceso a los servicios conectados. Hideez se integra con Active Directory y Microsoft Entra ID, de modo que las empresas pueden conservar su directorio de empleados actual. Para las aplicaciones web heredadas compatibles que no tienen SSO nativo, Hideez AuthShield ofrece una opción de integración adicional.

La oferta de SSO para pequeñas empresas incluye una versión en la nube gratuita hasta cinco usuarios, que permite a los equipos probar sus aplicaciones antes de ampliar. También hay despliegues en nube privada y on-premises. Nuestra calculadora de ROI estima los costes de software y hardware de Hideez junto con el posible ahorro de tiempo de la mesa de ayuda y de los empleados.

Otras funciones extienden la protección de acceso a los ordenadores con Windows. Los empleados pueden iniciar sesión sin contraseñas con un smartphone o con Hideez Key 5, con acceso sin contacto y bloqueo automático de la sesión según la distancia cuando se alejan. Con un sistema de control de acceso compatible, Hideez Key 5 también puede servir como tarjeta de acceso al edificio.

Empiece con el SSO sin contraseña en su pequeña empresa

Traiga a la llamada su lista de aplicaciones y su número de empleados. Solicite una demo: la llamada incluye un piloto gratuito. ¿Tiene preguntas antes? Use la página de contacto.