Respuesta rápida: La mayoría de las organizaciones descubren que FIPS 140-3 La transición es mucho más compleja que un simple intercambio de certificados. Ocho desafíos obstaculizan sistemáticamente los programas: un lenguaje de cumplimiento engañoso, una cola de validación CMVP que dura entre doce y dieciocho meses, algoritmos heredados integrados en el código del proveedor, plazos de entrega de HSM de tres a seis meses, configuraciones predeterminadas de KMS en la nube que no cumplen con el modo FIPS, un ecosistema de proveedores incontrolable, alcances de evaluación que no incluyen SaaS ni dispositivos, y un cronograma menos flexible de lo que parece. Cada desafío tiene una solución conocida, y cada solución requiere tiempo.

Puntos clave

Confirmaciones del proveedor de “Cumplimiento de FIPSLas declaraciones sin un número de certificado CMVP son autodeclaraciones no verificables. El enfoque de marcar casillas genera una falsa confianza, no una cobertura real.
La deficiencia más común en los entornos de producción es la de tener capacidad FIPS pero no estar habilitada: un certificado válido en un módulo que se ejecuta con una configuración predeterminada que no cumple con FIPS, invisible para las auditorías estándar.
La cola de CMVP tiene una duración de entre doce y dieciocho meses. Un módulo presentado a mediados de 2025 podría no tener un certificado activo para el 21 de septiembre de 2026, y el estado "en proceso" no constituye un estado de cumplimiento válido.
Los módulos de seguridad de hardware (HSM) son el componente con el plazo de entrega más largo: cuando no existe una ruta de actualización de firmware, el reemplazo tarda de tres a seis meses, lo que significa que la conversación con el proveedor debe tener lugar al inicio del programa.
Ningún proveedor importante de servicios en la nube configura la gestión de claves en modo FIPS de forma predeterminada. Puntos finales FIPS de AWS, niveles respaldados por HSM de Azure y GCP Cloud HSM Los llaveros son opciones de configuración explícitas.

Esta es la tercera parte de una serie de tres partes. Parte 1 cubre lo que requiere FIPS 140-3, lo que cambió de FIPS 140-2y por qué la fecha límite del 21 de septiembre de 2026 tiene una importancia inmediata en materia de cumplimiento normativo. Parte 3 es el manual paso a paso.

Así es como la mayoría FIPS 140-3 Las conversaciones transcurren con normalidad. Alguien solicita a sus proveedores que confirmen la certificación FIPS 140-3. Los proveedores responden afirmativamente, confirmando su cumplimiento. La organización documenta la respuesta, da por concluido el trámite y continúa, sintiéndose razonablemente protegida.

Ese enfoque genera una falsa sensación de seguridad que, en cierto modo, es más peligrosa que no realizar ninguna evaluación. Las deficiencias de cumplimiento que salen a la luz durante las auditorías e investigaciones de infracciones casi nunca son las que todos conocen. Son las de índole estructural: el producto que posee un certificado FIPS válido pero se ejecuta con una configuración predeterminada que no cumple con FIPS, el servicio de administración de claves en la nube que apunta a un punto final estándar cuando el cumplimiento exige el punto final FIPS, el firmware del HSM que nadie verificó para comprobar si tenía una ruta de actualización a FIPS 140-3 hasta que fue demasiado tarde para reemplazar el hardware.

Desafío 1: El idioma está haciendo mucho trabajo.

Tres frases aparecen indistintamente en las respuestas de los proveedores, los documentos de adquisición y las revisiones internas de cumplimiento. Se las trata como si fueran equivalentes. No lo son, y es precisamente en esta diferencia donde la mayoría de las organizaciones se sorprenden.

FIPS validado Esto significa que un laboratorio independiente acreditado por el NIST probó el módulo específico en una versión determinada, y el NIST emitió un certificado activo, verificable en csrc.nist.gov. Esto es lo que realmente exige el cumplimiento normativo.
Cumple con FIPS Es una autodeclaración. Sin laboratorio, sin certificado, sin verificación externa.
Compatible con FIPS Esto significa que el producto contiene un módulo validado por FIPS que puede ejecutarse en modo FIPS, pero que actualmente se ejecuta en modo predeterminado no FIPS. Las autocomprobaciones están desactivadas y las restricciones de algoritmo no se aplican. El certificado es auténtico; el cumplimiento no lo es.

Los productos suelen distribuirse con configuraciones predeterminadas que no cumplen con FIPS, ya que estas configuraciones exponen más funcionalidades. Habilitar el modo FIPS es un paso de configuración deliberado y, sin un programa específico para verificarlo, a menudo no se lleva a cabo. Esta brecha no genera alertas, no aparece en los análisis de vulnerabilidades y es invisible para las auditorías de seguridad estándar. La única forma de detectarla es mediante una evaluación criptográfica específica que examine la configuración real en tiempo de ejecución en comparación con la Política de Seguridad de cada módulo.

Desafío 2: La cola de CMVP es más larga que su cronograma de transición.

Históricamente, la cola del Programa de Validación de Módulos Criptográficos ha tardado entre doce y dieciocho meses desde la presentación de la solicitud hasta la obtención del certificado activo. Esto no es un retraso temporal, sino una característica estructural del proceso de validación.

La implicación práctica es que un módulo de proveedor presentado para la validación FIPS 140-3 a mediados de 2025 podría no contar con un certificado activo para el 21 de septiembre de 2026. Las organizaciones que consideran que una presentación CMVP en proceso equivale a una certificación activa están asumiendo un riesgo de incumplimiento que no han caracterizado correctamente. Una evaluación FedRAMP, una auditoría de la OCR y una revisión de un examinador financiero no aceptan el estado de "en proceso" como un estado de cumplimiento válido.

La respuesta: supervise la lista de módulos en proceso del CMVP en csrc.nist.gov para cada módulo de proveedor incluido en el alcance, comuníquese directamente con los proveedores para establecer plazos de finalización realistas y elabore planes de contingencia para los módulos cuyos plazos generen una incertidumbre real. Estas conversaciones deben tener lugar ahora, en paralelo con el resto de la evaluación, ya que los plazos de los proveedores están completamente fuera de su control y no pueden ajustarse únicamente por la urgencia.

Desafío 3: Eliminar algoritmos heredados no es un cambio de configuración.

La norma FIPS 140-3 prohíbe los algoritmos presentes en entornos heredados en todos los sectores regulados. Encontrarlos es la parte sencilla; eliminarlos es un problema completamente distinto.

Triple-DES Persiste en interfaces de pago, middleware heredado y cifrado de bases de datos que no se ha modificado en años. En muchos entornos, está integrado en código controlado por el proveedor que la organización no puede modificar. Su eliminación requiere un ciclo de coordinación con el proveedor, no un cambio de configuración.
SHA-1 Los certificados se almacenan en cadenas de certificados de implementaciones de infraestructura de clave pública (PKI) que se establecieron hace años y nunca se renovaron. Reemplazarlos implica reemplazar todos los certificados de la cadena (raíz, intermedios y finales), lo que afecta a todos los sistemas que dependen de dichos certificados.
RSA-1024 Este problema se presenta en configuraciones PKI antiguas, sistemas de tarjetas inteligentes y firmware de dispositivos donde solo el fabricante puede actualizar la pila criptográfica. Sus opciones son contactar al fabricante y esperar, o reemplazar el dispositivo.
TLS 1.0 y 1.1 Estos problemas persisten en portales heredados y puntos finales internos donde la coordinación con el proveedor de la plataforma se ha relegado repetidamente a un segundo plano. Detectarlos requiere un escaneo activo; solucionarlos requiere ciclos de proveedores proporcionales al número de sistemas afectados.

La solución para cada problema varía desde un cambio de configuración que lleva horas hasta un programa de reemplazo de proveedor que puede durar meses. Las organizaciones que inician el análisis tarde simplemente no tienen tiempo para implementar las soluciones más largas antes del 21 de septiembre. Esto no es una advertencia, sino una limitación de tiempo con una fecha límite fija.

Desafío 4: Sus HSM son el elemento con el plazo de entrega más largo del programa.

Los módulos de seguridad de hardware son la base criptográfica de la infraestructura de clave pública (PKI), la gestión de claves y el procesamiento de pagos. También son el componente con el mayor tiempo de respuesta para su corrección y el que tiene más probabilidades de generar una sorpresa desagradable cuando se plantea por primera vez la cuestión del firmware.

Muchos HSM implementados cuentan con certificados FIPS 140-2 que caducarán en septiembre. La cuestión no es solo si existe un certificado FIPS 140-3 para el modelo, sino si la versión específica del firmware en producción cuenta con dicho certificado y si el proveedor ofrece una ruta de actualización compatible. Muchas organizaciones están descubriendo que la respuesta a la segunda pregunta es no.

Cuando no existe una ruta de actualización de firmware, la única solución es reemplazar el hardware: adquisición, instalación física, migración de claves, pruebas y gestión del cambio, lo que suele tardar entre tres y seis meses. Una organización que descubra esto en junio o julio de 2026 casi con seguridad no completará el reemplazo antes del 21 de septiembre. Esta conversación con los proveedores de HSM debe tener lugar al inicio de la evaluación, no después de que todo lo demás esté completado.

Desafío 5: Es casi seguro que su KMS en la nube no está en modo FIPS.

Organizaciones que utilizan importantes cloud Los proveedores de gestión de claves suelen asumir que, al hacerlo, cumplen con la normativa FIPS. Si bien es posible, no lo es automáticamente y requiere configuraciones específicas que no vienen por defecto en ninguna plataforma importante en la nube.

Proveedor	Lo que realmente requiere el modo FIPS
AWS KMS	Puntos finales FIPS (kms-fips.[region].amazonaws.com). Las aplicaciones que llaman a los puntos finales regionales estándar no utilizan la ruta validada por FIPS, independientemente de para qué esté certificada la infraestructura subyacente (HSM FIPS 140-3 Nivel 3).
Azure Key Vault	La validación basada en hardware se aplica a los niveles Premium y Managed HSM, ambos validados ahora según la norma FIPS 140-3 Nivel 3. Key Vault, en su nivel Estándar, almacena las claves en software, fuera de ese límite de hardware.
Sistema de gestión de claves de Google Cloud	Los llaveros de Cloud HSM (HSM con validación FIPS 140-2 Nivel 3) deben configurarse explícitamente. Las claves de software en Cloud KMS estándar solo cuentan con validación de Nivel 1; las cargas de trabajo que requieren garantía basada en hardware necesitan Cloud HSM.

Las revisiones estándar de seguridad en la nube no examinan la configuración del punto final de KMS ni la selección del nivel de clave a nivel criptográfico. Esta deficiencia solo sale a la luz cuando alguien la busca específicamente, y en la mayoría de los entornos de nube nadie lo ha hecho. Es uno de los hallazgos más comunes en las evaluaciones que realizamos.

Desafío 6: Tus proveedores son una dependencia que no puedes controlar directamente.

La seguridad de una organización conforme a la norma FIPS 140-3 depende de la solidez del módulo criptográfico más débil de su ecosistema de proveedores. Plataformas de registros médicos electrónicos, herramientas SaaS, sistemas de laboratorio, procesadores de pagos, interfaces de red de pagadores: todos incorporan módulos criptográficos, y cada módulo necesita un certificado FIPS 140-3 activo para que la seguridad general sea sólida.

Muchos proveedores aún no han completado FIP Validación 140-3. Algunos procesos están en cola; otros aún no han comenzado. La metodología para gestionar esto es sencilla: exigir un número de certificado CMVP a cada proveedor con módulos incluidos en el ámbito de aplicación y verificar cada uno en csrc.nist.gov. Esto transforma un ejercicio de confianza en un ejercicio de verificación, que es precisamente lo que exigen los reguladores y auditores.

Los dispositivos médicos representan la versión más compleja de este problema. Dado que no es posible modificar la pila criptográfica, solo el fabricante puede solucionarlo, y sus plazos están completamente fuera de nuestro control. Contactarlos con anticipación no es prematuro; es la única manera de disponer de tiempo suficiente para responder si su respuesta no es satisfactoria.

Desafío 7: El alcance de su evaluación probablemente sea demasiado limitado.

Las organizaciones que realizan evaluaciones internas de FIPS tienden a definir su alcance en torno a la infraestructura que ya conocen: HSM, TLS puntos finales y puertas de enlace VPN. Ese alcance omite una parte significativa de la huella criptográfica real, y el material omitido no es trivial.

Plataformas SaaS Son la categoría que más se suele pasar por alto. Las herramientas de gestión del ciclo de ingresos, las plataformas de interacción con el paciente y las aplicaciones de análisis incorporan controles criptográficos a los que los escaneos de infraestructura no pueden acceder. La única vía son los cuestionarios estructurados para proveedores con verificación directa de CMVP.
Aplicaciones personalizadas Las llamadas directas a bibliotecas criptográficas requieren una evaluación a nivel de código. El escaneo de red indica que existe una conexión TLS; no indica qué algoritmo utiliza una llamada de generación de claves ni si la biblioteca en uso tiene activado el modo validado por FIPS.
Dispositivos conectados y equipos de terapia ocupacional Casi siempre se encuentran fuera de las evaluaciones de infraestructura. La documentación del NIST señala ciclos de actualización de OT que se miden en décadas, lo que significa que los algoritmos obsoletos pueden permanecer arraigados en entornos operativos durante años sin que ningún proceso de gobernanza los haya modificado.

Desafío 8: El plazo es menos indulgente de lo que parece.

Las organizaciones que inicien programas FIPS 140-3 en junio de 2026 tendrán aproximadamente catorce semanas antes del 21 de septiembre. Eso parece un plazo razonable. Sin embargo, si hacemos los cálculos, el tiempo es muy justo.

Descubrimiento criptográfico exhaustivo y CBOM El desarrollo lleva de dos a cuatro semanas. El análisis de brechas y la clasificación de riesgos llevan otras dos o tres. Eso deja de siete a diez semanas para todas las actividades de remediación, que deben acomodar los ciclos de actualización del firmware de HSM de cuatro a seis semanas como mínimo, el reemplazo de certificados en grandes PKI entornos, reconfiguración de KMS en la nube con pruebas de compatibilidad posteriores y plazos de escalamiento del proveedor que están fuera de su control.

Las organizaciones que comienzan ahora ejecutan un programa estructurado y llegan al 21 de septiembre con una postura defendible. Las organizaciones que comienzan en julio están tomando decisiones de triaje, remediando los elementos de mayor prioridad y aceptando el riesgo en el resto. Las organizaciones que comienzan en agosto no están gestionando una transición; están gestionando una el cumplimiento brecha.

Cómo puede ayudar Encryption Consulting

Cada uno de estos ocho desafíos tiene una solución conocida. Lo que determina si las organizaciones llegan al 21 de septiembre con una postura de cumplimiento sólida es si cuentan con la estructura de asesoramiento adecuada y el tiempo restante para su implementación.

Evaluación de cumplimiento de FIPS 140-3: Descubrimiento criptográfico integral en HSM, puntos finales TLS, KMS en la nube, PKI, plataformas SaaS, aplicaciones personalizadas y dispositivos conectados, generando una lista completa de materiales criptográficos con cada brecha clasificada por nivel de riesgo.
Verificación del modo FIPS: Evaluación de la configuración en tiempo de ejecución con respecto a la política de seguridad de cada módulo. Esta comprobación es la que revela la brecha entre la capacidad FIPS y el incumplimiento, algo que las auditorías estándar no pueden detectar, y que se presenta en casi todos los entornos que examinamos.
Programa de colaboración con proveedores: Verificación directa del certificado CMVP para cada módulo de proveedor incluido en el alcance, recopilación del cronograma de certificación, caracterización del riesgo de la cartera de proyectos CMVP y apoyo a la toma de decisiones de reemplazo, desde el primer día del proyecto.
Estrategia de transición a FIPS 140-3: Una hoja de ruta de remediación secuenciada y priorizada según el riesgo, que refleje las limitaciones reales de su entorno, los plazos de entrega de HSM, las posiciones en la cola de CMVP, las dependencias de reconfiguración en la nube y la disponibilidad del proveedor, ajustada a la fecha límite del 21 de septiembre de 2026.

Preguntas frecuentes

¿Cuánto tiempo tarda la validación de CMVP?

Históricamente, el proceso para obtener un certificado activo suele durar entre doce y dieciocho meses desde la presentación de la solicitud. Los evaluadores de FedRAMP, los auditores de la OCR y los examinadores financieros no aceptan el estado de "en proceso" como un estado de cumplimiento válido.

¿Es suficiente la afirmación de un proveedor de que cumple con la normativa FIPS?

No. Sin un número de certificado CMVP verificado en csrc.nist.gov, se trata de una autodeclaración no verificable. Exija el número, confirme el estado activo y verifique que la versión del módulo coincida con la versión implementada.

¿Cómo puedo comprobar si el modo FIPS está realmente activado?

Examine la configuración de ejecución con respecto a la Política de seguridad de cada módulo: confirme que se ejecutan las autocomprobaciones, que se aplican las restricciones del algoritmo y que la configuración coincide con el modo de operación validado. La mera posesión de un certificado no demuestra nada sobre el estado de ejecución.

¿La gestión de claves de AWS, Azure o Google Cloud cumple con la norma FIPS de forma predeterminada?

No alcanzan el nivel de seguridad que la mayoría de los programas necesitan. AWS requiere puntos finales FIPS (kms-fips.[region].amazonaws.com), Azure requiere el nivel Premium o Managed HSM con respaldo de HSM, y Google Cloud requiere llaveros de Cloud HSM para claves con respaldo de hardware; las claves de software solo cuentan con validación de Nivel 1. Ninguna de estas configuraciones es la predeterminada.

¿Qué ocurre si mi proveedor no puede obtener la certificación antes de septiembre de 2026?

Tome la decisión sobre la contingencia con anticipación: aceptar el riesgo con controles compensatorios para sistemas de bajo riesgo, o adquirir sistemas de reemplazo para aquellos que manejan datos regulados. Las decisiones tardías sobre la contingencia se vuelven imposibles.

Conclusión

Ninguno de los ocho desafíos es irresoluble. La acumulación de tareas pendientes del CMVP es manejable si la colaboración con los proveedores comienza con suficiente antelación. La brecha en el modo FIPS se puede identificar mediante una evaluación de la configuración en tiempo de ejecución. Los plazos de entrega de HSM se ajustan al período disponible si la evaluación del hardware se realiza al inicio del programa. Las configuraciones incorrectas de Cloud KMS se solucionan una sola vez, una vez que alguien las busca.

El factor común a los ocho desafíos es el tiempo. Cada uno requiere más tiempo del que las organizaciones prevén inicialmente, y ninguno puede comprimirse con urgencia una vez que la fecha límite se acerca y la urgencia se convierte en la única herramienta disponible. Las organizaciones que completan las transiciones a FIPS 140-3 a tiempo las tratan como programas estructurados con fases definidas y plazos realistas, no como proyectos que pueden acelerarse en un sprint cuando septiembre se vislumbra en el horizonte.

La tercera parte de esta serie es la guía paso a paso: el marco completo de migración en cuatro fases, el enfoque de gestión de proveedores que determina si el programa se finaliza antes de la fecha límite y la lista de verificación de cumplimiento de ocho puntos que define cuándo se considera que el trabajo está realmente terminado. Contacto Consultoría de cifrado en [email protected] Para reservar su llamada de consulta personalizada.