Certificados de terceros: El riesgo de la cadena de suministro que se oculta dentro de su perímetro

El riesgo asociado a los certificados de terceros es la vulnerabilidad de seguridad que persiste cuando los certificados digitales emitidos a un proveedor siguen siendo válidos y confiables una vez finalizada la relación comercial. Los certificados rara vez se gestionan mediante procesos de baja de proveedores como las cuentas de usuario, el acceso VPN y las claves API, lo que convierte a este riesgo en uno de los más ignorados en la cadena de suministro en entornos empresariales.

Cuando se da de baja a un proveedor, el departamento de compras cierra el contrato, se desactivan las cuentas de usuario y se revoca el acceso VPN. El certificado TLS mutuo emitido para su integración API nunca se registra en los sistemas afectados por la baja, por lo que nunca se revoca. Continúa autenticándose correctamente mucho después de que finalice el contrato.

Este es el comportamiento predeterminado en la mayoría de los entornos empresariales, ya que la gestión del ciclo de vida de los certificados (CLM) y la gestión de riesgos de proveedores operan como funciones completamente independientes. Los certificados emitidos para integraciones con terceros, incluido el acceso de certificados de cliente y las credenciales basadas en PKI , se encuentran en una brecha de gobernanza que ninguno de los equipos controla.

El informe DBIR 2025 de Verizon reveló que la participación de terceros en las filtraciones de datos se duplicó en un año, pasando del 15 % al 30 % de todos los incidentes confirmados. En la mayoría de los casos, el vector de acceso fue una credencial que debería haber sido revocada, pero no lo fue. Este blog analiza cómo las organizaciones pueden solucionar este problema antes de que el certificado de un antiguo proveedor se convierta en un vector de filtración.

Cómo los certificados otorgan acceso a terceros y por qué ese acceso es diferente

Para comprender por qué los certificados de terceros representan un riesgo distinto y a menudo subestimado, resulta útil especificar cómo se utilizan y qué beneficios otorgan realmente.

Autenticación TLS mutua (mTLS)

TLS mutuo es un mecanismo de autenticación basado en certificados en el que tanto el cliente como el servidor presentan certificados digitales para verificar la identidad del otro antes de establecer una conexión. A diferencia del TLS estándar, donde solo se verifica la identidad del servidor, mTLS requiere que la parte que se conecta demuestre su propia identidad criptográficamente.

Esto lo convierte en el mecanismo de autenticación preferido para las integraciones de API entre empresas, la comunicación de servicio a servicio en arquitecturas de confianza cero y cualquier integración en la que la parte que se conecta deba verificarse en la capa de transporte en lugar de mediante credenciales de la capa de aplicación.

Para integraciones con terceros, mTLS se implementa comúnmente mediante la emisión de un certificado al proveedor o socio, el cual sus sistemas presentan al conectarse a sus API. Este certificado es la credencial que otorga acceso. Es válido durante su período de vigencia completo, que puede ser de un año o más, y otorga acceso cada vez que se presenta a cualquier sistema configurado para confiar en él, independientemente de cualquier cambio en la relación comercial posterior a su emisión.

Certificados de autenticación de clientes

Los certificados de autenticación de cliente, certificados X.509 con la clave de autenticación extendida (EKU), se utilizan para verificar la identidad de un cliente que se conecta a un servidor o servicio. Su funcionamiento es similar al de mTLS, pero pueden aplicarse fuera de los protocolos de enlace TLS mutuos completos, por ejemplo, en la autenticación VPN, el control de acceso a aplicaciones web o las políticas de malla de servicios. Para las integraciones con proveedores, los certificados de autenticación de cliente suelen emitirse junto con las credenciales de nombre de usuario y contraseña, o en su lugar, como un mecanismo de acceso más seguro.

La ventaja de seguridad del acceso basado en certificados sobre el acceso basado en contraseñas es innegable: los certificados son credenciales más robustas y resistentes a los ataques de phishing y de relleno de credenciales, aunque el robo o la vulneración de la clave privada en el punto final sigue siendo un riesgo distinto. La desventaja en la gobernanza es igualmente real: las contraseñas caducan o se pueden rotar según un calendario que se ajusta a los eventos del ciclo de vida del proveedor, mientras que los certificados a menudo no tienen ninguna relación con la gestión del ciclo de vida del proveedor.

Certificados de firma de código y canalización de integración

Algunas integraciones con terceros implican que los proveedores firmen los artefactos de software, los paquetes de configuración o las cargas de datos que procesan sus sistemas. Su infraestructura confía en el certificado utilizado para la firma para validar dichos artefactos. Si el certificado de firma del proveedor no se revoca al finalizar la relación, su infraestructura seguirá confiando en los artefactos que lleven la firma de ese certificado y procesándolos, incluyendo, potencialmente, los artefactos emitidos por quien controle ahora los sistemas o la clave privada del proveedor.

La brecha de gobernanza: lo que se pierde en la desvinculación de proveedores

Lo que dificulta la gestión de los tres tipos de certificados no es la tecnología en sí, sino la distancia organizativa entre los equipos que los emiten y los que gestionan las relaciones con los proveedores. Los procesos modernos de baja de proveedores han mejorado significativamente en la última década. La mayoría de las organizaciones ahora mantienen procesos estructurados para la desactivación de cuentas de usuario de proveedores, la revocación de VPN y el acceso remoto, la desactivación de claves API en sistemas de gestión de secretos y la revisión de permisos de acceso a datos. Estos pasos están integrados en los flujos de trabajo de RR. HH., los sistemas IAM y las plataformas de gestión de riesgos de proveedores. Se llevan a cabo, de forma imperfecta, pero sistemática.

Los certificados no pasan por ninguno de esos procesos. He aquí el motivo, clasificado según el tipo de credencial:

Tipo de credencial	¿Se realiza un seguimiento para la baja de proveedores?	Revocación al finalizar el contrato
Cuentas de usuario	Sí, el sistema IAM se desactiva al finalizar la relación laboral.	Generalmente automatizado
Acceso VPN	Sí, la política de VPN elimina el acceso al finalizar el contrato.	Generalmente automatizado
Claves API	Parcial, rastreado en bóvedas secretas si está gobernado	A menudo manual, varía mucho
Certificados mTLS	Rara vez, no se registra en la mayoría de los sistemas CLM.	Casi siempre manual o se pasa por alto.
Certificados de integración	Rara vez, emitido y olvidado	Casi siempre se pasa por alto por completo
Certificados de autenticación de cliente (PKI)	Casi nunca, gobernanza de ciclo de vida cero	No se revoca en la mayoría de las organizaciones.

El patrón es consistente: cuanto más se asemeja una credencial a una cuenta de usuario (con un propietario humano, registrada en un sistema de identidad y sujeta a la gobernanza de IAM), mayor es la probabilidad de que se incluya en el proceso de baja. Cuanto más se asemeja una credencial a la infraestructura (un certificado integrado en la configuración del sistema, sin registro en un sistema centralizado y emitido por un proceso PKI sin integración con la gestión de proveedores), menor es la probabilidad de que se modifique al finalizar la relación con el proveedor.

Esto se ve agravado por el hecho de que los certificados mTLS y de autenticación de clientes a menudo no son administrados por el mismo equipo que gestiona la relación con el proveedor. La gestión de compras y la gestión de riesgos de proveedores administran la relación comercial. Estas dos funciones rara vez se comunican específicamente sobre los eventos del ciclo de vida del certificado vinculados a los eventos del ciclo de vida del proveedor. Un cambio reciente en la política de las autoridades de certificación públicas ha añadido una nueva capa técnica a esta brecha de gobernanza existente.

El cambio hacia mTLS en 2026: una nueva urgencia para la gobernanza de certificados de terceros

Un cambio de política significativo que se produjo en todo el ecosistema de CA públicas en 2025 y 2026 ha añadido una nueva dimensión de urgencia a la gobernanza de certificados de terceros y ha creado un requisito de migración concreto para cualquier organización que utilizara certificados de CA públicas para mTLS.

Durante años, las organizaciones utilizaron certificados TLS de confianza pública, los mismos que protegen las conexiones HTTPS, para la autenticación mTLS y de clientes en las integraciones con proveedores. Esto resultaba práctico: las autoridades de certificación públicas emitían certificados que incluían los usos de clave extendida tanto para la autenticación del servidor como para la del cliente, lo que permitía que un único certificado sirviera para ambos propósitos.

Ese modelo ha llegado a su fin para los certificados públicos. El Programa Raíz de Chrome exige que los certificados TLS públicos se limiten exclusivamente a la autenticación del servidor. Las principales autoridades de certificación públicas comenzaron a eliminar la EKU de autenticación de cliente por defecto de los certificados TLS recién emitidos a partir de septiembre de 2025, y la mayoría completó su eliminación total en mayo de 2026. Chrome comenzó a rechazar los certificados TLS públicos recién emitidos que incluyen la EKU de autenticación de cliente a partir del 15 de junio de 2026. La fecha límite final de DigiCert para todas las emisiones, incluidas las renovaciones y reemisiones, es el 1 de marzo de 2027, y el mandato de Chrome para todos los certificados hoja públicos se extiende hasta el 15 de marzo de 2027. A medida que esta transición se implemente por completo, las organizaciones que crearon integraciones mTLS de proveedores en certificados de CA públicos encontrarán que esos certificados se vuelven funcionalmente defectuosos para la autenticación de cliente, a menudo silenciosamente, durante un ciclo de renovación automatizado, sin ninguna advertencia a nivel de aplicación hasta que falla la conexión.

La solución correcta a largo plazo, como ha dejado claro el ecosistema de las CA, es utilizar una infraestructura de clave pública (PKI) privada para la autenticación de clientes. Los certificados de cliente para integraciones con proveedores deben ser emitidos por su propia CA interna, bajo su propia política de gobernanza y con una gestión del ciclo de vida bajo su control. Esto es técnicamente correcto y operativamente necesario: un certificado emitido por su CA privada puede revocarse inmediatamente al finalizar un contrato con un proveedor, sin depender de la infraestructura de revocación de una CA pública.

Sin embargo, los certificados de cliente emitidos por CA privadas son precisamente aquellos sobre los que la mayoría de las organizaciones no tienen visibilidad, ni gestión del ciclo de vida, ni conexión con los procesos de baja de proveedores. La transición que impulsa el ecosistema de CA es, a su vez, un factor determinante para las mejoras en la gobernanza que la gestión de certificados de terceros siempre ha necesitado. Cuando no se implementan dichas mejoras, el patrón de riesgo se manifiesta de la forma que la industria ya ha documentado.

Consecuencias en el mundo real: Cuando el acceso del proveedor se extiende más allá del contrato.

Cuando no se implementan las mejoras de gobernanza que el ecosistema de las CA está impulsando, las consecuencias siguen un patrón bien documentado. El riesgo de certificados de proveedores no revocados no es hipotético. El patrón general, en el que las credenciales de acceso de terceros perduran más allá de la relación comercial que las justificó, es un factor recurrente en incidentes de seguridad reales, y los datos del sector demuestran con qué frecuencia los atacantes acceden a los sistemas mediante credenciales.

El informe de Verizon de 2025 sobre investigaciones de filtraciones de datos identificó las credenciales robadas o mal utilizadas como el principal vector de acceso inicial, presente en el 22 % de todas las filtraciones. El índice de inteligencia de amenazas IBM X-Force 2025 reveló que el abuso de credenciales de cuentas válidas se situó entre los dos principales vectores de acceso inicial en las intervenciones de respuesta a incidentes, junto con la explotación de aplicaciones de cara al público, y que los adversarios recurren cada vez más a credenciales legítimas en lugar de a malware novedoso.

Un certificado de proveedor que nunca ha sido revocado es precisamente eso: una credencial válida, en posesión de un atacante o simplemente en un estado sin supervisión, que otorga un acceso que ya no debería existir.

Cerrando la brecha: Un enfoque de 5 pasos para la gobernanza de certificados de terceros

Para cerrar la brecha en la gobernanza de certificados de terceros, es necesario conectar dos funciones que históricamente han operado de forma independiente: la gestión del ciclo de vida de los certificados y la gestión de riesgos de los proveedores. El siguiente enfoque de cinco pasos refleja cómo las organizaciones con programas consolidados han establecido dicha conexión.

1. Descubra todos los certificados de terceros en su entorno.
   Ejecutar certificado automatizado descubrimiento en todos los entornos: tiendas de Windows, IIS, servidores Linux, balanceadores de carga, puertas de enlace API y contenedoresFiltre los resultados para identificar los certificados emitidos a organizaciones externas examinando el CN ​​del sujeto, los SAN y la CA emisora. Este es el inventario básico que probablemente nunca haya tenido.

2. Asignar cada certificado a una relación con un proveedor.
   Para cada certificado de terceros encontrado, determine la relación comercial a la que corresponde: para qué proveedor o contratista se emitió, quién es el titular de la relación, cuándo vence o se renueva el contrato y a qué sistemas otorga acceso el certificado.

   Los certificados de firma de código en poder de los proveedores requieren una atención especial en esta etapa: a diferencia de los certificados TLS, que se invalidan por completo al ser revocados, el certificado de firma de un proveedor continúa validando los documentos firmados previamente incluso después de que finalice la relación comercial, a menos que dichos documentos se eliminen o se deje de confiar en el certificado. Los certificados sin una relación comercial identificable deben considerarse huérfanos de alto riesgo e investigarse de inmediato.

3. Integrar el ciclo de vida de los certificados en la incorporación y desvinculación de proveedores.
   Cree un punto de control formal en su proceso de incorporación de proveedores donde todos los certificados emitidos al proveedor se registren en una plataforma de gestión del ciclo de vida de los certificados (CLM) con la fecha de finalización del contrato, el equipo responsable y el alcance del acceso.

   Si su organización aún no utiliza una plataforma CLM, el paso 3 es el momento en que esa inversión se amortiza con mayor claridad: el inventario automatizado creado en el paso 1 solo es viable a gran escala si se almacena en un sistema que pueda activar alertas y automatizaciones de flujo de trabajo cuando cambien las fechas de los contratos o los atributos de los certificados.

   Cree un punto de control de baja correspondiente que active la revocación del certificado como parte del proceso de salida del proveedor, junto con los pasos de eliminación de la cuenta de usuario y la VPN que ya existen.

4. Imponer períodos de validez cortos para todos los certificados de proveedores.
   Evite emitir certificados de larga duración para integraciones con proveedores basándose en la conveniencia operativa. Períodos de validez cortos Con una vigencia de 90 días o menos, se establece un ciclo de revalidación natural que confirma que la relación con el proveedor se mantiene activa y que el certificado sigue siendo necesario. Cuando un certificado caduca sin renovación, el acceso finaliza automáticamente en lugar de permanecer activo indefinidamente.

5. Realizar auditorías periódicas para detectar certificados que hayan caducado.
   Incluso con una mejor gobernanza en el futuro, los entornos existentes conservarán certificados heredados de relaciones anteriores con proveedores. Programe análisis trimestrales específicos para identificar certificados cuyos contratos hayan expirado. Estas son las vulnerabilidades existentes que se crearon antes de que se implementara la gobernanza.

Consideraciones de Seguridad

Mejorar la gobernanza de los certificados de terceros reduce una superficie de ataque real y a menudo subestimada. Esta transición también implica decisiones de seguridad que merecen una atención especial.

Al migrar las integraciones de proveedores de certificados de autenticación de clientes emitidos por CA públicas a certificados emitidos por CA privadas, coordine cuidadosamente la transición con cada proveedor. Un certificado que deja de funcionar inesperadamente debido a un cambio en la política de la CA, en lugar de una transición planificada, genera una interrupción operativa y una carga adicional en materia de seguridad.

Los periodos de validez cortos de los certificados de proveedores son una medida de seguridad, no un inconveniente administrativo. Rechace las solicitudes de los proveedores para extender la vigencia de los certificados por motivos de conveniencia operativa. El costo de la renovación es preferible a la alternativa: un certificado que permanece válido durante dos años sin ninguna revisión.

Establezca un proceso formal para la revocación de emergencia de certificados de proveedores, que pueda ejecutarse en horas, no en días. Si una relación con un proveedor finaliza en circunstancias adversas, o si un proveedor le notifica un incidente de seguridad, la capacidad de revocar de inmediato todos los certificados asociados a dicho proveedor es fundamental para la respuesta ante incidentes.

Supervise el uso de certificados de proveedores fuera del horario laboral o desde direcciones IP de origen inesperadas. Un certificado válido que se conecta desde una dirección IP que no pertenece al proveedor no necesariamente implica una acción del proveedor; podría indicar que el certificado ha sido robado o que los sistemas del proveedor han sido comprometidos.

Para las integraciones con proveedores que impliquen acceso a sistemas sensibles o datos regulados, incorpore revisiones anuales de certificados en los procesos de renovación de contratos con proveedores. Considere la continuidad de los certificados como una decisión consciente, no como una opción predeterminada.

Cómo ayuda la consultoría de cifrado

Encryption Consulting trabaja con empresas para cerrar la brecha de gobernanza entre la gestión del ciclo de vida de los certificados y la gestión de riesgos de los proveedores, creando programas que garantizan que los certificados de terceros se descubran, gestionen y revoquen como parte del ciclo de vida estándar del proveedor, en lugar de como algo secundario.

Nuestros servicios de asesoramiento comienzan con una evaluación de detección de certificados de terceros: identificamos todos los certificados que se encuentran actualmente en su entorno y que fueron emitidos a o para terceros, los relacionamos con las relaciones con proveedores activos y vencidos, y elaboramos un inventario de riesgos priorizado de los certificados que deben revisarse, renovarse o revocarse.

Para las organizaciones que estén listas para implementar CertSecure Manager , nuestro equipo de implementación integra el ciclo de vida de los certificados en sus flujos de trabajo de baja de proveedores existentes, crea la infraestructura de CA privada necesaria para la autenticación de clientes y establece la supervisión y las alertas que hacen que la gobernanza continua sea sostenible.

Administrador de CertSecure

CertSecure Manager es la plataforma de gestión del ciclo de vida de los certificados empresariales de Encryption Consulting, diseñada para brindar a los equipos de seguridad y operaciones visibilidad y control centralizados sobre todo su inventario de certificados, incluidos los certificados de terceros y de integración a los que las herramientas externas no pueden acceder.

En lo que respecta a la gobernanza de certificados de terceros, CertSecure Manager proporciona las capacidades de detección y aplicación de políticas que conectan CLM con la gestión del ciclo de vida de los proveedores. La detección identifica todos los certificados presentes en el entorno, incluidos los emitidos a organizaciones externas, y los normaliza en un inventario unificado con asignación de propiedad y seguimiento de vencimiento.

La aplicación de políticas puede configurarse para marcar los certificados vinculados a contratos de proveedores caducados, activar flujos de trabajo de revocación cuando se produzcan eventos de baja de proveedores y alertar cuando algún certificado se acerque a su fecha de caducidad sin que haya una decisión de renovación o revocación en curso.

• Descubrimiento automatizado: Detección de certificados de terceros en todos los entornos, con análisis del sujeto y de la CA emisora ​​para identificar los certificados emitidos a entidades externas.
• Mapeo de la propiedad de los proveedores: Asignación de propiedad que vincula cada certificado descubierto con una relación de proveedor, el propietario del contrato y la fecha de vencimiento, conectando los datos de CLM con el contexto de gestión de proveedores.
• Integración de la desvinculación: Integración del flujo de trabajo de revocación que puede activarse mediante eventos de baja del proveedor, lo que garantiza que la revocación del certificado se produzca como parte del proceso estándar de salida del contrato, en lugar de como un paso separado y olvidable.
• Aplicación de la validez: Aplicación de periodos de validez cortos para todos los certificados orientados a proveedores, con solicitudes de renovación automatizadas y alertas cuando los certificados se acerquen a su fecha de vencimiento sin una decisión clara de renovación o revocación.
• Integración de CA privada para autenticación de clientes: Ofrece soporte para la implementación o integración con infraestructura de CA privada para emitir certificados de autenticación de cliente para integraciones con proveedores, garantizando que las credenciales mTLS de los proveedores se rijan por el marco de políticas de su propia organización, en lugar de depender de políticas de CA públicas que están en constante evolución.

El riesgo en la cadena de suministro dentro de su perímetro no es una nueva categoría de amenaza. Se trata de una brecha de gobernanza en materia de credenciales que la mayoría de las organizaciones nunca ha gestionado sistemáticamente. Las organizaciones que logren cerrar esa brecha ahora serán las que no tendrán que explicar, a posteriori, por qué un proveedor cuyo contrato finalizó hace un año aún tenía acceso a un sistema de producción.

Conclusión

Cuando finaliza la relación con un proveedor, se ejecuta el proceso de desvinculación: se desactivan las cuentas de usuario, se revoca el acceso VPN y se inhabilitan las claves API. Además, el certificado (la credencial TLS mutua que los sistemas del proveedor utilizan para autenticarse en su puerta de enlace API, sus servicios internos y sus puntos finales de integración) permanece válido y activo, sin estar vinculado a ningún proceso de desvinculación ni registrado en ningún sistema que controle la seguridad o la gestión de riesgos del proveedor.

Esta configuración no es inusual. Es la norma en entornos empresariales donde la gestión del ciclo de vida de los certificados y la gestión de riesgos de proveedores nunca se han conectado. El 85 % de los CISO que no pueden detectar amenazas de terceros más allá de sus proveedores directos, el 70 % que experimentó un incidente grave con terceros el año pasado, el 61 % que sufrió una brecha de seguridad causada por terceros: la brecha de credenciales dentro del perímetro es un factor significativo y subestimado que contribuye a todas estas cifras.

El cambio en las políticas de las autoridades de certificación públicas (CA) para la autenticación de clientes entre 2025 y 2026, que eliminó la extensión de uso de certificados (EKU) de autenticación de clientes de los certificados TLS de confianza pública, ha actuado como un factor determinante. Las organizaciones que dependían de certificados de CA públicas para mTLS de proveedores deben migrar a una infraestructura de clave pública (PKI) privada. Y los certificados de PKI privada son precisamente el tipo de credencial que requiere una gobernanza del ciclo de vida que la mayoría de las organizaciones aún no han implementado.

Para obtener más información sobre cómo CertSecure Manager ayuda a las empresas a descubrir y gestionar certificados de terceros, o para hablar sobre una evaluación de certificados de terceros con nuestro equipo, póngase en contacto con Encryption Consulting.