Acceso con tarjetas físicas y Passkeys: Guía técnica

La seguridad moderna se define por la disolución de las antiguas fronteras. Durante décadas, las organizaciones operaron con una clara demarcación entre la seguridad física (guardias, cerraduras y tarjetas de acceso) y la seguridad lógica o ciberseguridad (firewalls, contraseñas y protocolos de red). Estos dos dominios se gestionaban en silos separados, con equipos, políticas y objetivos distintos.

Hoy, esa separación ya no es viable. La proliferación de sistemas físicos conectados a la red, desde cámaras de seguridad hasta cerraduras de puertas inteligentes y controles de climatización, ha creado un entorno ciberfísico profundamente interconectado. Esta convergencia significa que una vulnerabilidad en un ámbito puede desencadenar un fallo catastrófico en el otro. Un ciberataque puede abrir puertas físicas, y una tarjeta de acceso robada puede llevar a una brecha en la sala de servidores. En consecuencia, una estrategia de seguridad holística y convergente ya no es una tendencia de futuro, sino un requisito fundamental para cualquier postura de seguridad sólida, lo que impulsa una inversión significativa en plataformas unificadas.

Esta nueva realidad presenta un desafío para la autenticación de la fuerza laboral. Los empleados, ya sea en la oficina, en remoto o en roles híbridos, necesitan acceso a una cartera en rápida expansión de aplicaciones en la nube y SaaS. Este modelo de acceso distribuido crea una superficie de ataque vasta y compleja. El tradicional nombre de usuario y contraseña, incluso cuando se complementa con la autenticación multifactor (MFA) tradicional como los códigos SMS, sigue siendo el eslabón más débil, un vector principal para ataques de phishing, credential stuffing y toma de control de cuentas. En respuesta, la industria está experimentando un cambio hacia la autenticación sin contraseña y resistente al phishing. Las previsiones del mercado proyectan que el mercado de la autenticación sin contraseña crecerá de más de 18 000 millones de dólares en 2024 a más de 60 000 millones para 2032, con un 87 % de las empresas que ya están implementando o en proceso de implementar passkeys para su personal.

En medio de esta evolución tecnológica se encuentra un activo potente y a menudo subestimado: la tarjeta de empleado física. Omnipresente en casi todas las organizaciones medianas y grandes, esta simple tarjeta es la clave para desbloquear un futuro digital más seguro y sin fricciones.

El propósito central de este artículo es proporcionar un análisis neutral y profundamente técnico de los patrones de arquitectura disponibles para integrar estas tarjetas físicas con la autenticación basada en passkeys. Específicamente, este análisis se centra en aplicaciones SaaS personalizadas en un contexto laboral, donde no se da por sentada la dependencia de un proveedor de identidad (IdP) corporativo tradicional y on-premise. Las siguientes secciones analizarán tres caminos distintos para esta integración, evaluando sus componentes técnicos, modelos de seguridad y las concesiones críticas entre ellos.

Antes de diseñar un sistema convergente, es esencial establecer una comprensión detallada de sus componentes fundamentales. Las capacidades del token físico y la mecánica de la credencial digital dictan las rutas de integración disponibles. No apreciar las sutiles diferencias entre un simple identificador y un auténtico autenticador criptográfico puede llevar a decisiones de arquitectura erróneas.

Las tarjetas de empleado no son algo monolítico; su tecnología subyacente abarca un amplio espectro de complejidad y seguridad. Entender en qué punto de este espectro se encuentra una tarjeta específica es el primer paso para determinar su papel potencial en un sistema de autenticación moderno. Las siguientes tablas proporcionan un desglose detallado de esta evolución.

Las organizaciones que actualizan sus sistemas de acceso basados en UID a tokens de autenticación seguros suelen seguir esta ruta:

1. Tarjeta UID básica → usada solo para acceso físico.
2. Tarjeta NFC segura → añade cifrado para el control de acceso, pero sigue sin ser adecuada para la autenticación digital.
3. Smartcard PKI (PIV) → añade acceso basado en certificados digitales (VPN, correos firmados), requiere middleware.
4. Smartcard FIDO2 → permite el inicio de sesión sin contraseña a través de WebAuthn, también puede combinarse con funciones de acceso físico.
5. Passkeys de plataforma → visión futura donde los tokens físicos se vuelven opcionales, pero la convergencia se logra mejor cuando un solo dispositivo maneja tanto el acceso físico como el lógico.

Este desglose detallado aclara la distinción entre un simple identificador y un autenticador criptográfico, que es el concepto más importante en este análisis. Una tarjeta RFID básica solo puede proporcionar un UID, que en el mejor de los casos puede servir como una pista de nombre de usuario para iniciar un flujo de autenticación. No puede participar en el desafío-respuesta criptográfico que es el corazón de WebAuthn. Una smart card FIDO2, por el contrario, está diseñada precisamente para este propósito. Esta diferencia fundamental es la que da lugar a los tres patrones arquitectónicos distintos que siguen. Las opciones 1 y 2 son esencialmente soluciones provisionales diseñadas para acomodar las limitaciones de las tarjetas que solo son identificadores, mientras que la opción 3 representa la integración nativa de un verdadero autenticador.

Con una comprensión clara de las tecnologías subyacentes, ahora podemos explorar los tres modelos arquitectónicos principales para integrar tarjetas físicas con la autenticación de passkeys para una aplicación SaaS de la fuerza laboral. Cada ruta presenta un conjunto único de concesiones en seguridad, costo, experiencia de usuario y complejidad.

Este modelo es conceptualmente el más abstracto. La tarjeta física no almacena una passkey en sí misma. En su lugar, funciona como un token de baja garantía utilizado para autorizar a un servicio centralizado a realizar una autenticación de alta garantía en nombre del usuario. La clave privada de la passkey no está en manos del usuario, sino que se almacena y gestiona dentro de un Módulo de Seguridad de Hardware (HSM) operado por un proveedor de "Bóveda de Credenciales".

1. Acción del usuario e identificación: Un empleado acerca su tarjeta RFID/NFC estándar a un lector conectado a su estación de trabajo. El lector captura el UID estático de la tarjeta.
2. Solicitud a la bóveda: Un componente del lado del cliente envía el UID a un endpoint de API propietario alojado por el proveedor de la Bóveda de Credenciales.
3. Inicio de WebAuthn del lado del servidor: El servicio de la bóveda recibe el UID, busca la cuenta de usuario asociada y luego inicia una ceremonia de autenticación WebAuthn con la aplicación SaaS de destino (la Relying Party) en nombre del usuario. La aplicación SaaS devuelve un desafío de autenticación estándar.
4. Firma basada en HSM: El servicio de la bóveda pasa este desafío a su HSM interno. El HSM almacena de forma segura el componente de clave privada de la passkey del usuario para esa aplicación SaaS específica. El HSM realiza la operación de firma criptográfica en el desafío y devuelve la firma resultante al servicio de la bóveda. La clave privada nunca sale del perímetro seguro del HSM.
5. Finalización de la autenticación y emisión de token: El servicio de la bóveda completa el flujo WebAuthn enviando el desafío firmado de vuelta a la aplicación SaaS. La aplicación SaaS verifica la firma utilizando la clave pública del usuario (que tiene registrada) y, si tiene éxito, emite un token de sesión de autenticación (p. ej., un JSON Web Token).
6. Entrega de la sesión: El servicio de la bóveda reenvía este token de sesión al navegador del usuario, que puede usarlo para establecer una sesión autenticada con la aplicación SaaS, completando el inicio de sesión.

• Ventajas:
  • Aprovecha la infraestructura existente: El principal atractivo de este modelo es su capacidad para funcionar con las tarjetas RFID/NFC más comunes y económicas que ya están desplegadas en una organización, evitando una costosa y disruptiva renovación de hardware.
  • Experiencia de usuario muy fluida: Puede proporcionar un verdadero inicio de sesión "tocar y listo". Desde la perspectiva del usuario, un solo toque en el lector de tarjetas le permite iniciar sesión directamente en la aplicación, lo que representa una fricción extremadamente baja.
  • Gestión centralizada: Todas las credenciales de passkey se crean, almacenan y gestionan dentro del ecosistema del proveedor. Esto puede simplificar tareas administrativas como la revocación y la aplicación de políticas.
• Desventajas:
  • Sistema propietario y de ciclo cerrado: Esta arquitectura convierte efectivamente a la tarjeta y al proveedor de la bóveda en un nuevo proveedor de identidad (IdP) propietario. La organización se vuelve profundamente dependiente de este único proveedor para una función crítica. Tales sistemas de "ciclo cerrado" son inherentemente inflexibles y crean una dependencia significativa del proveedor, haciendo que las futuras migraciones sean difíciles y costosas.
  • Requisito de confianza extrema: La seguridad de todo el sistema depende de la confiabilidad y competencia del proveedor de la bóveda. Dado que los HSM del proveedor guardan las claves privadas de todos los usuarios en todas las aplicaciones, una brecha de seguridad en el proveedor sería catastrófica.
  • Alto costo y complejidad: Esta no es una solución simple. Requiere construir o suscribirse a un servicio altamente complejo y de misión crítica que incluye una costosa infraestructura de HSM, software sofisticado y operaciones de alta disponibilidad.
  • Desviación de los principios de WebAuthn: Este modelo rompe fundamentalmente con el principio central de WebAuthn, que es la autenticación del lado del cliente y en posesión del usuario. El autenticador está del lado del servidor, lo cual es un antipatrón para la autenticación web general. Como se señaló en la consulta inicial, este enfoque generalmente no se recomienda para autenticarse en una aplicación SaaS web estándar.

Este modelo representa un compromiso pragmático. Utiliza la tarjeta simple existente no para autenticar, sino para agilizar y acelerar un flujo estándar de WebAuthn. Un software instalado en el ordenador del usuario actúa como un "puente" entre el lector de tarjetas físico y el navegador web.

1. Acción del usuario y detección local: Un empleado acerca su tarjeta RFID/NFC básica a un lector USB estándar conectado a su estación de trabajo.
2. Agente de escucha local: Un servicio o daemon ligero que se ejecuta en segundo plano en el sistema operativo (p. ej., utilizando la API PC/SC) está a la escucha de eventos del lector de smart card. Detecta el toque de la tarjeta y lee el UID de la misma.
3. Comunicación entre agente y extensión: Este agente local comunica el UID capturado a una extensión de navegador compañera. Esto se logra típicamente utilizando la API de mensajería nativa del navegador, que permite que una extensión en un entorno aislado (sandbox) intercambie mensajes con una aplicación nativa pre-registrada.
4. Autocompletado de usuario e inicio del flujo: La extensión del navegador contiene la lógica para mapear el UID recibido a un nombre de usuario específico. Al recibir el UID, inyecta el nombre de usuario correspondiente en el formulario de inicio de sesión de la aplicación SaaS. Los formularios de inicio de sesión modernos también pueden usar el atributo autocomplete="webauthn" en los campos de entrada para indicar al navegador que se puede iniciar un flujo de passkey para el usuario autocompletado. La extensión puede entonces activar programáticamente el inicio del proceso de autenticación de passkey.
5. Ceremonia estándar de WebAuthn: A partir de este punto, tiene lugar una ceremonia de autenticación WebAuthn completamente estándar. El navegador solicita al usuario que use su autenticador de passkey registrado. Este podría ser el autenticador de plataforma del ordenador (p. ej., Windows Hello, Touch ID de macOS) o un autenticador móvil separado (como una YubiKey o incluso el teléfono del usuario). El usuario completa el gesto de autenticación (p. ej., escaneo de huella dactilar) y el inicio de sesión se completa según el flujo estándar. El papel de la tarjeta ha terminado.

• Ventajas:
  • Autenticación conforme a los estándares: El beneficio más significativo es que la autenticación criptográfica real es un flujo WebAuthn puro y sin adulterar. El modelo de seguridad se basa en los principios probados de FIDO2, no en una solución propietaria. El toque de la tarjeta es puramente una mejora de la experiencia del usuario.
  • Aprovecha el hardware existente: Al igual que la Opción 1, este enfoque funciona con la flota existente de tarjetas RFID/NFC básicas y lectores USB económicos.
  • Mejora la experiencia del usuario: Aunque no es un inicio de sesión de un solo toque, reduce significativamente la fricción. El usuario se ahorra tener que recordar y escribir su nombre de usuario, lo que acorta el proceso de inicio de sesión y reduce la posibilidad de error.
• Desventajas:
  • Despliegue y mantenimiento de software: El principal inconveniente es la sobrecarga operativa. Esta arquitectura requiere desplegar, configurar y mantener dos piezas de software separadas —un agente nativo a nivel de SO y una extensión de navegador— en cada una de las estaciones de trabajo de los empleados. Esto puede ser una carga significativa para los departamentos de TI, que deben gestionar actualizaciones, solucionar problemas de compatibilidad con diferentes versiones de SO y navegadores, y encargarse de los parches de seguridad.
  • Fragilidad de la arquitectura: El canal de comunicación entre el controlador de hardware, el agente nativo y la extensión del navegador es un puente construido a medida. Este "pegamento" puede ser frágil y es susceptible de romperse cuando el sistema operativo o el navegador lanzan actualizaciones, lo que lleva a una experiencia de usuario pobre y poco fiable.
  • Solución incompleta: Esta no es una solución de "tocar y listo". El usuario aún debe realizar una segunda acción distinta para completar la autenticación con su passkey real. El toque de la tarjeta solo automatiza el primer paso del proceso de inicio de sesión.

Esta es la arquitectura más directa, segura y alineada con los estándares. En este modelo, la tarjeta de empleado es en sí misma una smart card compatible con FIDO2. Es un verdadero autenticador criptográfico que puede participar directamente en la ceremonia de WebAuthn sin ningún software intermediario.

1. Navegación del usuario: Un empleado navega a la página de inicio de sesión de la aplicación SaaS. La aplicación está configurada para admitir la autenticación con passkey.
2. Inicio de WebAuthn: El usuario hace clic en un botón "Iniciar sesión con una passkey", o la IU Condicional del navegador (autocompletar) detecta automáticamente las passkeys disponibles y las presenta en un aviso no modal. El JavaScript del navegador llama a navigator.credentials.get() para iniciar la ceremonia de autenticación.
3. Interacción con el autenticador: El navegador, a través del sistema operativo, solicita al usuario que presente su llave de seguridad. El empleado acerca su tarjeta FIDO2 a un lector NFC integrado o la inserta en un lector de smart card conectado.
4. Firma criptográfica en la tarjeta: El navegador envía el desafío desde la aplicación SaaS a la tarjeta. El elemento seguro dentro de la tarjeta utiliza su clave privada almacenada internamente y no exportable para firmar el desafío. Dependiendo de la política de la Relying Party y las capacidades de la tarjeta, este paso también puede requerir la verificación del usuario, como introducir un PIN en la estación de trabajo o colocar un dedo en un sensor biométrico integrado en la propia tarjeta.
5. Finalización de la autenticación: La tarjeta devuelve la respuesta firmada al navegador, que la reenvía al servidor SaaS. El servidor verifica la firma y el usuario inicia sesión de forma segura. Todo el proceso es orquestado por el navegador y el sistema operativo utilizando protocolos FIDO estandarizados.

• Ventajas:
  • Máxima seguridad y alineación con estándares: Este es el enfoque "estándar de oro" para el acceso convergente. Utiliza los estándares FIDO2 y WebAuthn exactamente como fueron diseñados, proporcionando la protección más fuerte posible contra ataques de phishing y man-in-the-middle. El usuario está en posesión física del token de hardware que contiene su clave privada.
  • Simplicidad y robustez de la arquitectura: Este modelo es elegante en su simplicidad. No hay agentes personalizados, extensiones de navegador o puentes propietarios que desarrollar y mantener. El flujo de autenticación se basa en las API y los controladores altamente robustos y bien mantenidos integrados en los sistemas operativos y navegadores modernos.
  • Verdadera convergencia de seguridad: Esta arquitectura cumple la promesa de una credencial verdaderamente convergente. Un único token físico gestionable se utiliza para conceder acceso tanto a espacios físicos (puertas) como a recursos lógicos (aplicaciones), simplificando la experiencia del usuario y el modelo de seguridad.
• Desventajas:
  • Costo de hardware significativo: La barrera más sustancial para este enfoque es la inversión inicial. Requiere reemplazar toda la flota de tarjetas RFID/NFC básicas de una organización por tarjetas inteligentes compatibles con FIDO2 más caras. Dependiendo de la infraestructura existente, también puede ser necesario actualizar los lectores de puertas físicas para que sean compatibles con las nuevas tarjetas.
  • Gestión compleja del ciclo de vida de las credenciales: Gestionar el ciclo de vida completo de las credenciales criptográficas para una gran fuerza laboral es más complicado que gestionar una simple lista de UIDs. Los procesos para la emisión segura, la rotación de claves, la renovación de certificados (si también se usa PKI) y, especialmente, la revocación y la recuperación se vuelven más críticos y complejos.
  • Matices de la experiencia de usuario: Aunque muy segura, la experiencia del usuario puede introducir diferentes puntos de fricción. Si la tarjeta requiere un PIN para la verificación del usuario, reintroduce un factor de "algo que sabes" que debe ser recordado. La acción física de insertar una tarjeta en un lector puede percibirse como menos fluida que un simple toque sin contacto, dependiendo del hardware específico desplegado.

La decisión entre estas tres rutas arquitectónicas no es meramente técnica; es una decisión estratégica que equilibra prioridades contrapuestas. La Opción 1 prioriza una experiencia de usuario fluida y el uso del hardware existente, pero lo hace creando una dependencia propietaria de alto costo y alto riesgo que se desvía de los estándares abiertos. La Opción 2 también aprovecha el hardware existente y mejora la experiencia del usuario mientras se adhiere a los estándares de autenticación, pero traslada el costo y la complejidad al difícil y a menudo subestimado problema de gestionar software en cada endpoint. La Opción 3 prioriza la seguridad, la robustez y la adhesión a los estándares abiertos por encima de todo, aceptando un mayor costo inicial de hardware a cambio de una arquitectura más simple y preparada para el futuro con una menor sobrecarga de mantenimiento a largo plazo. No hay una elección universalmente "correcta"; el camino óptimo depende de la tolerancia al riesgo específica de una organización, su presupuesto, la infraestructura existente y sus capacidades de soporte de TI.

Elegir la arquitectura correcta requiere una comparación clara y directa de estas concesiones. Esta sección proporciona un marco para destilar el análisis complejo en un formato práctico para los líderes técnicos y para abordar los desafíos prácticos y del mundo real de la implementación.

El camino óptimo para una organización depende de sus principales impulsores de negocio.

• Si su principal impulsor es minimizar el gasto de capital inicial y aprovechar su flota de tarjetas existente, entonces la Opción 2 (Puente de Escritorio) es la elección más pragmática. Proporciona una mejora tangible en la experiencia del usuario y adopta un núcleo de autenticación conforme a los estándares sin requerir una gran inversión en hardware. Sin embargo, este camino solo debe elegirse si la organización tiene una capacidad de gestión de endpoints madura y sólida, ya que el éxito de este modelo depende de la capacidad para desplegar y mantener de manera fiable el software necesario del lado del cliente.
• Si su principal impulsor es alcanzar el más alto nivel de seguridad, alinearse con las mejores prácticas de la industria y construir una arquitectura de bajo mantenimiento y preparada para el futuro, entonces la Opción 3 (Credencial Convergente) es la clara ganadora estratégica. Este enfoque adopta plenamente los estándares abiertos, elimina el software personalizado frágil y proporciona la protección más fuerte resistente al phishing. El costo inicial del hardware es una inversión en seguridad a largo plazo y simplicidad operativa.
• Si su principal impulsor es ofrecer una experiencia de inicio de sesión "mágica" y sin fricciones por encima de todas las demás consideraciones, entonces la Opción 1 (Bóveda Centralizada) es la única que realmente lo proporciona. Sin embargo, este camino debe abordarse con extrema precaución. Introduce un riesgo estratégico significativo a través de la dependencia de un proveedor y exige un nivel excepcionalmente alto de confianza en la arquitectura de seguridad y las operaciones del proveedor. Para la mayoría de las aplicaciones web abiertas y SaaS, la naturaleza propietaria y de ciclo cerrado de este modelo lo convierte en una opción menos deseable en comparación con las alternativas basadas en estándares.

Una estrategia de passkeys exitosa va mucho más allá del flujo de inicio de sesión; debe abarcar todo el ciclo de vida de la identidad. La elección de la arquitectura tiene profundas implicaciones en cómo se incorporan los usuarios, cómo se revoca el acceso y cómo se recuperan las cuentas.

• Emisión e incorporación: Para un nuevo empleado, el proceso difiere significativamente. En las Opciones 1 y 2, la incorporación implica emitir una tarjeta estándar y luego crear una entrada en una base de datos que mapea el UID de la tarjeta a la cuenta del usuario. En la Opción 3, el proceso es una ceremonia formal de registro FIDO2, donde la nueva tarjeta compatible con FIDO2 se utiliza para generar una passkey que luego se registra en la aplicación SaaS. Este proceso es más seguro pero también más complejo de gestionar a escala.
• Revocación (cese del empleado): Cuando un empleado se va, su acceso físico siempre se revoca en el PACS central. Para el acceso lógico, los pasos son:
  • Opción 1: Se debe notificar inmediatamente al proveedor de la bóveda para deshabilitar o eliminar la credencial almacenada en su HSM.
  • Opción 2: La passkey real del usuario (p. ej., la almacenada en el TPM de su portátil a través de Windows Hello) debe ser revocada desde la configuración de la aplicación SaaS. El mapeo del UID de la tarjeta se vuelve irrelevante una vez que la passkey subyacente está deshabilitada.
  • Opción 3: La clave pública asociada con la tarjeta FIDO2 del empleado debe ser eliminada de su perfil de usuario dentro de la aplicación SaaS, haciendo que la tarjeta sea inútil para iniciar sesión.
• Recuperación (tarjeta perdida o robada): Este es un modo de fallo crítico que debe planificarse. Las implicaciones varían drásticamente:
  • En las Opciones 1 y 2, una tarjeta perdida es menos crítica para el acceso lógico, ya que solo es un identificador. El riesgo principal es el acceso físico no autorizado. El usuario todavía puede iniciar sesión usando su autenticador de passkey real.
  • En la Opción 3, una tarjeta perdida puede ser un problema grave. Si la tarjeta FIDO2 es la única passkey registrada para la cuenta del usuario, quedan completamente bloqueados. Esto subraya una práctica recomendada fundamental para cualquier despliegue de passkeys empresarial: se debe exigir o alentar encarecidamente a los usuarios a registrar múltiples autenticadores. Una política robusta exigiría que un empleado registre tanto su tarjeta FIDO2 (como autenticador principal para el día a día) como una copia de seguridad, como su autenticador de plataforma (Windows Hello/Face ID) o su teléfono, para ser utilizado en la recuperación de la cuenta.

En última instancia, un despliegue exitoso de passkeys no es solo un proyecto de autenticación; es un proyecto de gestión de identidades y accesos (IAM). La arquitectura técnica para el flujo de inicio de sesión no puede diseñarse en el vacío. Debe estar estrechamente integrada con una estrategia integral para aprovisionar, gestionar y desaprovisionar identidades y sus credenciales asociadas a lo largo de su ciclo de vida. Esta visión holística es esencial para mitigar riesgos como el bloqueo de cuentas y garantizar el éxito y la seguridad a largo plazo del sistema.

El camino para integrar las tarjetas de acceso físico con la autenticación digital moderna es una clara manifestación de dos tendencias potentes que se cruzan: la convergencia de la seguridad física y cibernética y la inexorable migración de toda la industria para abandonar las contraseñas. Como se ha detallado en esta guía, las organizaciones tienen tres caminos arquitectónicos distintos para elegir, cada uno presentando una concesión fundamental.

• La Bóveda Centralizada ofrece una experiencia de usuario fluida a costa de la dependencia de un sistema propietario y un riesgo estratégico significativo.
• El Puente de Escritorio ofrece un camino pragmático y de bajo costo hacia una mejor experiencia de usuario mientras se mantienen los estándares de seguridad, pero introduce una considerable sobrecarga de mantenimiento de software.
• La Credencial Convergente ofrece el más alto nivel de seguridad y robustez al adherirse estrictamente a los estándares abiertos, pero requiere una inversión inicial significativa en hardware.

Si bien cada camino representa un paso hacia un futuro más seguro y sin contraseñas, la trayectoria a largo plazo de la seguridad empresarial favorece las soluciones construidas sobre estándares abiertos e interoperables. Las arquitecturas que adoptan FIDO2 y WebAuthn de forma nativa —como lo ejemplifica el modelo de Credencial Convergente y, hasta cierto punto, el Puente de Escritorio— proporcionan la base más robusta y preparada para el futuro. Empoderan a las organizaciones para construir sistemas de seguridad de primer nivel que aprovechan un ecosistema competitivo de hardware y software, libres de las restricciones de la plataforma de ciclo cerrado de un único proveedor. Para cualquier organización que esté construyendo la próxima generación de aplicaciones para la fuerza laboral, adoptar estos estándares abiertos no es solo una elección técnica; es un compromiso estratégico con un mundo digital más seguro, flexible e interoperable.