TLS 1.3 ya no es la próxima generación, es lo predeterminado
Que un protocolo se convierta en la línea base operativa lleva años. El IETF publicó TLS 1.3 con el RFC 8446 en 2018. Desde entonces el protocolo se ha extendido por los navegadores, se ha asentado en las bibliotecas y ha entrado en los marcos de auditoría. Para 2026 se ha cruzado un umbral: soportar los protocolos más antiguos es ahora más caro que abandonarlos.
Los clientes que necesitaban TLS 1.2 o se han actualizado, o se han vuelto irrelevantes, o se han reducido a una población que no justifica el coste del servicio continuo. Los clientes que requieren TLS 1.3 — por motivos de cumplimiento, rendimiento o modernización — leen cada vez más la frase "todavía soporta TLS 1.2 por defecto" como una señal de alarma en la compra.
Esta tendencia no es nueva. Los navegadores retiraron TLS 1.0 y 1.1 en 2020. PCI-DSS 4.0 (entró en vigor en 2024-2025) exige una "criptografía fuerte" que el consejo interpreta como TLS 1.2 o superior; la expectativa de cara al futuro es claramente TLS 1.3. FIPS 140-3 asume cada vez más TLS 1.3 como línea base. Lo que cambia en 2026 es que la larga cola de clientes TLS 1.2 se ha adelgazado lo suficiente: la decisión de "simplemente apagar 1.2" es ahora operativamente viable para la mayoría de los despliegues empresariales; ya no es solo teórica.
Este artículo cubre tres cosas: cuánto le cuesta realmente soportar TLS 1.2 en 2026, los argumentos de cumplimiento y rendimiento a favor de solo TLS 1.3, y cómo la aceleración SSL por hardware cambia la aritmética de la migración. No está escrito para criptógrafos, sino para los equipos que toman la decisión operativa; los detalles del protocolo se resumen, no se cubren de forma exhaustiva.
El coste real de soportar TLS 1.2 en 2026
Los costes de soportar TLS 1.2 junto con TLS 1.3 no son catastróficos uno por uno; pero se acumulan a escala y ninguno viene solo con lo antiguo. Ninguno parece grande por sí mismo — pero cuando todos están presentes a la vez, soportar el protocolo antiguo se vuelve más caro que abandonarlo.
Handshakes más lentos
TLS 1.2 requiere dos idas y vueltas para un handshake nuevo; TLS 1.3, una. Para clientes de alta latencia — móvil, internacional — la diferencia es perceptible: 100-300 ms de ahorro por conexión nueva. Multiplicado por millones de conexiones, el impacto en la experiencia de usuario y la conversión se vuelve medible.
Superficie de cipher suites más amplia
Soportar TLS 1.2 significa aceptar una lista de cifrados más amplia — incluidas construcciones antiguas con debilidades conocidas o propiedades de forward secrecy deficientes. Incluso configurada con cuidado, la superficie de ataque es mayor; el riesgo de deriva de configuración es más alto.
Código antiguo en la ruta crítica
Cada biblioteca TLS de la ruta de conexión incluye la implementación de TLS 1.2. Ese código rara vez es el foco de la nueva investigación de seguridad; pero históricamente ha sido fuente de vulnerabilidades (BEAST, Lucky13, ROBOT). Eliminar 1.2 elimina también esa superficie de la ruta crítica.
Inconsistencia de forward secrecy
TLS 1.3 hace obligatorio forward secrecy — cada sesión tiene claves efímeras. TLS 1.2 lo deja opcional y dependiente de la elección del cipher. Los despliegues mixtos significan que algunas sesiones tienen forward secrecy y otras no — lo que complica la evaluación de riesgos para la confidencialidad a largo plazo.
Presión de auditoría
En 2025-2026, las auditorías de PCI-DSS 4.0 referencian cada vez más TLS 1.3 como best practice, incluso cuando 1.2 es técnicamente conforme. FIPS 140-3 asume 1.3. Los informes SOC 2 anotan la mezcla de versiones como una preocupación de control. La presión de cumplimiento es unidireccional y va en aumento.
Complejidad operativa
Dos familias de protocolos significan dos políticas de cipher suites, dos rutas de código de depuración, dos vistas de monitoreo y dos modos de fallo. Cada dimensión adicional multiplica el coste operativo. Abandonar 1.2 simplifica esa dimensión.
TLS 1.3 en números (con aceleración por hardware)
TLS 1.3 — frente a 2 RTT para TLS 1.2. Ganancia en cada conexión nueva.
IETF RFC 8446Para las reconexiones se pueden enviar datos de aplicación en el primer paquete; no hay latencia de handshake.
IETF RFC 8446Tasa de reducción de la aceleración por hardware de TR7 frente a la línea base solo por software; el coste de CPU por handshake se desploma.
Aceleración SSL de TR7Cada sesión TLS 1.3 tiene claves efímeras; el descifrado retroactivo de los secretos de larga duración se vuelve imposible.
IETF RFC 8446El panorama de cumplimiento: la presión es unidireccional
Seis marcos distintos apuntan en la misma dirección hacia TLS 1.3, aunque con un lenguaje diferente. Ninguno dice "vuelvan a 1.2"; todos señalan 1.3 de forma directa o indirecta. El mensaje común: TLS 1.3 está dejando de ser best practice para convertirse en lo predeterminado.
PCI-DSS 4.0
Entró en vigor en marzo de 2024 y la transición completa se finalizó en marzo de 2025. Exige "criptografía fuerte" para los datos de titulares de tarjetas; TLS 1.0/1.1 están expresamente prohibidos, TLS 1.2 es aceptable y de cara al futuro se espera TLS 1.3. A lo largo de 2025-2026, la retroalimentación de auditoría muestra cada vez más 1.3 como best practice.
FIPS 140-3
Estándar de validación de módulos criptográficos. Los laboratorios de validación de 2025-2026 asumen TLS 1.3 como contexto de despliegue. Los módulos validados solo para TLS 1.2 cada vez son más difíciles de posicionar para nuevas compras en sectores regulados.
SOC 2 e ISO 27001
Ambos esperan "criptografía estándar del sector". El comentario de los auditores en 2026 trata el despliegue de TLS 1.3 como evidencia de práctica actual; el despliegue solo de TLS 1.2 atrae cada vez más notas de auditoría aunque sea técnicamente conforme.
DORA (Resiliencia Financiera de la UE)
Introduce requisitos de resiliencia operativa para las entidades financieras de la UE. La agilidad criptográfica — la capacidad de actualizar protocolos con rapidez — forma parte del panorama de riesgo operativo. El despliegue de TLS 1.3 es una señal positiva; el bloqueo en TLS 1.2 es negativo.
CNSA 2.0 / ruta PQC
El paquete criptográfico de seguridad nacional de EE. UU. avanza hacia la PQC para 2030. Asume TLS 1.3 como protocolo subyacente de la migración PQC — el intercambio de claves híbrido ML-KEM se ha definido para TLS 1.3, no para 1.2. Saltarse TLS 1.3 deja después una migración PQC más difícil.
Imposiciones de los navegadores
Chrome, Firefox, Safari, Edge — todos soportan TLS 1.3 por defecto y tienen calendarios de fin de vida para TLS 1.2. Los indicadores de degradación de la conexión en las DevTools del navegador empiezan a marcar cada vez más TLS 1.2 en las pruebas de cara al usuario.
¿Cómo migrar sin romper nada importante?
Inventaríe el tráfico TLS 1.2
Habilite en su ADC el logging por conexión de la versión de TLS. Agregue por user-agent, rango de IP de origen y endpoint. El resultado: la población de clientes que perdería acceso si apaga TLS 1.2. La mayoría de las organizaciones encuentra esa población más pequeña de lo que temía.
Clasifique la población TLS 1.2
Agrupe el inventario por categoría: navegadores de cara al cliente (deberían estar cerca de cero en 2026), integraciones de API de partners, servicios internos, dispositivos embebidos. Cada categoría tiene una ruta de remediación distinta.
Establezca la política por endpoint
Solo TLS 1.3 no es todo o nada. Configure por endpoint: los endpoints de cara al cliente públicos reciben solo TLS 1.3; los servicios internos con necesidad documentada de 1.2 lo mantienen temporalmente; las integraciones de partners reciben una ruta de fin de vida con una fecha límite documentada.
Comuníquese con los partners
Para las integraciones B2B que requieren TLS 1.2, envíe al partner un plan de fin de vida documentado con una fecha límite real. La mayoría de los partners se actualizará más rápido que ante una "caída de TLS 1.2" si se les solicita; muchos pueden estar esperando una función forzante.
Imponga TLS 1.3 por defecto
Para los nuevos endpoints, cambie el valor predeterminado a solo TLS 1.3. Los endpoints existentes con necesidades de 1.2 documentadas reciben una excepción; todo lo demás se predefine a la línea base moderna. Esto detiene la acumulación de nueva deuda técnica.
Ya que está aquí, planifique también la PQC
Si ya está tocando la configuración TLS, habilite el intercambio de claves híbrido ML-KEM en TLS 1.3. El cambio es conservador (el modo híbrido recae en la seguridad clásica) y empieza a proteger el tráfico contra el "recoge ahora, descifra después". Las migraciones de PQC y TLS 1.3 son el mismo proyecto; se ejecutan en la misma transición de configuración.
¿Dónde encaja la aceleración SSL por hardware?
Las ventajas de rendimiento de TLS 1.3 se ven sobre todo cuando las operaciones criptográficas no son el cuello de botella. A alto volumen, el TLS solo por software ejerce una presión notable de CPU sobre los núcleos de propósito general; en picos, solo los handshakes TLS pueden consumir el 20-30 por ciento de la CPU disponible en balanceadores de carga muy cargados. La aceleración SSL por hardware descarga estas operaciones a unidades cripto dedicadas y reduce drásticamente el coste de CPU por conexión.
La aceleración SSL por hardware de TR7 reduce la carga de procesamiento SSL en torno al 95 por ciento frente a solo software. El efecto práctico: el mismo hardware procesa muchas más sesiones TLS simultáneas, la latencia es más consistente (el hardware dedicado no compite por CPU) y el coste por handshake cae por debajo del umbral en el que la elección del protocolo TLS tiene un impacto medible en la aplicación.
Para la ruta PQC, la aceleración por hardware de ML-KEM y de los cifrados AEAD es el camino para un despliegue PQC de alto volumen. El tamaño del handshake crece (ML-KEM, en torno a 1,1 KB frente a unos 100 bytes de X25519); pero el coste de CPU por operación puede competir con RSA-2048. El hardware que incluye primitivas PQC mantiene constante el coste por handshake a medida que avanza la migración. La hoja de ruta de TR7 alinea la aceleración por hardware con el calendario de migración PQC; no hay que cambiar de hardware para migrar.
La idea principal vuelve una vez más en este punto: la migración a TLS 1.3 y la migración PQC para 2030 son la misma ruta de configuración. La aceleración por hardware es el componente que hace que el coste de ambas sea operativamente invisible.
Referencias y fuentes
Especificación del protocolo que incluye el diseño del handshake de 1 RTT, los datos 0-RTT, el forward secrecy obligatorio y las cipher suites antiguas eliminadas. https://datatracker.ietf.org/doc/html/rfc8446
Versión actual del Payment Card Industry Data Security Standard. La transición completa se finalizó en marzo de 2025. https://www.pcisecuritystandards.org/document_library/
Estándar Federal de Procesamiento de Información para la validación de módulos criptográficos. https://csrc.nist.gov/projects/cryptographic-module-validation-program
Regulation (EU) 2022/2554 que introduce requisitos de resiliencia operativa, incluida la agilidad criptográfica, para las entidades financieras. https://eur-lex.europa.eu/eli/reg/2022/2554/oj
Commercial National Security Algorithm Suite 2.0 — TLS 1.3 como protocolo predeterminado bajo el calendario de migración PQC. https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3148990/
TLS moderno, hardware moderno
El procesamiento SSL acelerado por hardware de TR7 transporta TLS 1.3 con 0-RTT, intercambio de claves híbrido ML-KEM y una descarga de CPU en torno al 95 por ciento frente a solo software. La migración a TLS 1.3 y la historia PQC para 2030 son la misma ruta de configuración.
Descubra la aceleración SSL de TR7