Puntos clave
- Apple aplica vigencias de certificados de 200 días desde finales de marzo de 2026, y Amazon ya emite certificados de 198 días. Para 2029, la vigencia bajará a 47 días.
- El 81% de las interrupciones relacionadas con certificados sigue debiéndose a certificados caducados o mal configurados. Vigencias más cortas multiplican ese riesgo.
- El 60% de las empresas gestiona sus propias autoridades de certificación (CA) internas, y la gran empresa media tiene en uso más de 140.000 certificados internos. La mayoría apenas tiene supervisión centralizada.
- La amenaza «Harvest Now, Decrypt Later» de la computación cuántica significa que las organizaciones deberían desplegar ya TLS híbrido (que combina ECDHE clásico con ML-KEM).
- Las organizaciones necesitan un inventario de certificados en tiempo real y de múltiples fuentes, que abarque la infraestructura pública y privada, para seguir el ritmo de estos cambios.
La vigencia de los certificados se acorta a toda velocidad
Los cambios ya están aquí. Apple aplica una vigencia máxima de los certificados de 200 días desde finales de marzo de 2026. Amazon también ha empezado a emitir certificados de 198 días. Si tiene certificados de estos proveedores en su entorno, el número de certificados se va a duplicar como mínimo este año.
Y esto es solo el principio. En 2027, la vigencia baja a 100 días. En 2029, llega a 47.
Este es el cálculo que importa: una vigencia de 47 días supone aproximadamente ocho veces más renovaciones de certificados al año que ahora. Si su organización tiene hoy 1.000 certificados públicos, en 2029 gestionará 8.000 renovaciones al año.
Con ese volumen, la renovación manual es imposible. Pero, como señaló Billy McDiarmid durante el webinar, la automatización por sí sola tampoco basta.
«Hablamos de esto con clientes todos los días», dijo McDiarmid. «Vienen y nos dicen que creían tenerlo todo automatizado. Después la automatización falló en una parte de su entorno, o caducó un certificado de un tercero del que dependía uno de sus servicios.»
La ventana de sustitución también se reduce. La práctica recomendada era empezar a rotar los certificados 30 días antes de su caducidad. Con vigencias más cortas, podría quedar una ventana de siete días. Eso recorta drásticamente el tiempo para detectar y corregir una automatización que ha fallado.
Y lo que está en juego es real: el 81% de las interrupciones relacionadas con certificados sigue debiéndose a certificados caducados o mal configurados. Ya es una de las mayores causas de inactividad. Vigencias más cortas, sin las herramientas adecuadas, lo empeorarán.
La PKI privada es el punto ciego que probablemente está ignorando
La PKI pública (los certificados que protegen su sitio web, sus API públicas y sus dominios externos) se lleva la mayor parte de la atención. Existe un ecosistema consolidado de CA, aplicación de normas por parte de los navegadores, registros de transparencia de certificados (CT) y requisitos de cumplimiento que mantienen la PKI pública relativamente bien gestionada.
La PKI privada es otra historia.
Los certificados internos que protegen sus servidores, VPN, pipelines de DevOps, dispositivos IoT y API internas suelen emitirlos CA privadas internas, como Microsoft Active Directory Certificate Services (ADCS), con una supervisión centralizada mínima. Las vigencias suelen fijarse en años, a veces incluso en décadas. Normalmente no hay monitorización externa. Y cuando algo sale mal (una caducidad inesperada, una raíz comprometida, una intermedia mal configurada), el impacto puede ser grave y difícil de diagnosticar.
Los números lo dicen todo. El 60% de las empresas gestiona sus propias CA internas. Una gran empresa tiene de media más de 140.000 certificados internos en uso. Y el 57% de las organizaciones está incorporando ya zero trust a su estrategia de cifrado, lo que hace que la PKI privada sea aún más central para su operativa.
Zero trust sigue un principio sencillo: nunca confiar, verificar siempre. Cada servicio recibe un certificado único. Cada conexión usa TLS mutuo (mTLS), es decir, ambas partes deben presentar un certificado válido firmado por una CA de confianza. El acceso se rige por políticas, no por la ubicación.
La PKI privada es lo que hace posible todo esto a escala. Da a cada servicio, dispositivo y usuario una identidad criptográfica sólida. Pero como zero trust favorece certificados de vida corta y rotación automática, el volumen y la velocidad de las operaciones con certificados no harán más que aumentar.
Y las consecuencias de un fallo de la PKI privada van más allá de que su sitio web deje de funcionar. Cuando caducan o fallan certificados privados, pueden paralizar líneas de fabricación, sistemas de tecnología operativa (OT) y servicios internos de los que depende su negocio. Como dijo McDiarmid: «Ya no hablamos solo de que su sitio web esté caído o de que su API no responda. Hablamos de que se deje de fabricar producto.»
Criptografía poscuántica: empiece la migración ya
Estar preparado para la criptografía poscuántica (PQC) parece un problema del futuro. Los plazos regulatorios para la migración completa se sitúan entre 2030 y 2033. Pero la preparación exige mucho trabajo, y hay una amenaza que obliga a actuar ya.
Cuando se construya un ordenador cuántico criptográficamente relevante (CRQC), romperá la criptografía de clave pública que hoy se usa de forma generalizada, incluidos RSA y la criptografía de curva elíptica (ECC), prácticamente de la noche a la mañana.
La preocupación inmediata se llama «Harvest Now, Decrypt Later». Los atacantes ya pueden capturar hoy datos cifrados (su tráfico TLS, sus túneles VPN) y almacenarlos. Cuando exista un CRQC, podrán descifrar todo lo que hayan recopilado. Para las organizaciones que manejan datos sensibles de larga vida, es un riesgo de hoy, no del futuro.
Bhushan Lokhande, de Red Sift, describió tres pasos para prepararse para la PQC.
- Paso uno: conozca su situación. No puede proteger lo que no ve. Construya un inventario completo y siempre actualizado de sus activos criptográficos, tanto en la infraestructura pública como en la privada interna. Cada dominio, subdominio, certificado y punto de conexión de red.
- Paso dos: identifique sus puntos débiles. ¿Qué sistemas usan algoritmos que los ordenadores cuánticos romperán? Eso implica localizar todos los despliegues de RSA y ECC. También debe buscar sistemas sin criptoagilidad (los que no pueden pasar a nuevos algoritmos sin una reingeniería importante).
- Paso tres: planifique la migración. No todo tiene que migrar a la vez. Priorice los datos de larga vida y los sistemas de alto riesgo, porque son los que tienen mayor exposición a «Harvest Now, Decrypt Later».
La migración tiene dos partes diferenciadas. En el intercambio de claves, la acción más urgente es desplegar TLS híbrido, combinando ECDHE clásico con ML-KEM (antes conocido como Kyber). Esto aborda directamente el riesgo «Harvest Now, Decrypt Later» y mantiene la retrocompatibilidad. Cloudflare, Google y los principales fabricantes de navegadores ya están desplegando el intercambio de claves híbrido a gran escala. En las firmas digitales, las organizaciones deberían introducir de forma gradual algoritmos poscuánticos estandarizados por el NIST, como ML-DSA y SLH-DSA, a medida que madure el ecosistema.
Estar preparado para la PQC no es un evento único. Es un proceso de migración, y debería empezar de inmediato.
Qué implica todo esto: necesita un inventario de certificados en tiempo real
Los tres cambios apuntan a la misma necesidad de fondo. Necesita un inventario completo y actualizado de forma continua de todos los certificados de su entorno, públicos y privados, en el momento en que se emiten.
Las hojas de cálculo ya no bastan. Los análisis diarios tampoco. Necesita ingesta en tiempo real de certificados desde varias fuentes de descubrimiento: descubrimiento basado en nombres de host, escaneo de red, registros de transparencia de certificados, integraciones con proveedores cloud y agentes en la infraestructura privada.
La mayoría de las organizaciones también subestima la dispersión de sus autoridades de certificación. McDiarmid compartió en el webinar una observación reveladora: la mayoría de los prospectos que Red Sift incorpora descubren certificados de 10 u 11 autoridades de certificación distintas, además de certificados autofirmados, y eso es solo la huella pública, antes de mirar dentro de la red.
También necesita visibilidad sobre su postura criptográfica: qué puntos de conexión admiten intercambio de claves seguro frente a la computación cuántica, qué certificados usan algoritmos vulnerables a ella y en qué punto está su entorno ante los cambios de vigencia que se avecinan.
Una herramienta de CLM (Certificate Lifecycle Management) gestiona la emisión y la renovación. Pero en 2026 necesita además un seguro que funcione junto a su CLM: algo que se despliega en minutos, detecta de forma continua y en tiempo real, correlaciona los datos de certificados con los registros CT y el DNS, y cubre ambos lados de la red.
Véalo en acción
Red Sift Certificates ofrece monitorización de la infraestructura pública y privada en una única vista, con paneles específicos para la preparación PQC y el cumplimiento del ciclo de vida de los certificados. El agente de PKI privada de la plataforma descubre certificados en la infraestructura interna y los incorpora al mismo inventario que sus certificados públicos.
Entre las nuevas capacidades que llegan en 2026 hay una integración con ADCS (prevista para el segundo trimestre), una integración con HashiCorp Vault más adelante en el año y acceso MCP (Model Context Protocol), para que los equipos puedan consultar su parque de certificados con IA.
¿Quiere ver cómo está su entorno? Compruebe la postura de seguridad de su dominio con Red Sift Radar Lite para una evaluación gratuita, o solicite una demo de Red Sift Certificates para obtener visibilidad completa de su infraestructura de certificados pública y privada.
