FIPS 140-3:
Validación de módulos criptográficos para proveedores de TI y de « Software »
| Región | Estados Unidos y Canadá (norma federal de validación de módulos criptográficos; determina la idoneidad para la contratación pública federal y de defensa de EE. UU. en todo el mundo, ya que la lista de módulos validados es una puerta de acceso global para cualquier proveedor que venda en esos mercados) |
| Ámbito de aplicación | Proveedores de módulos criptográficos: bibliotecas de « software » , proveedores de criptografía de sistemas operativos, módulos de seguridad « hardware » y servicios criptográficos en la nube integrados en productos vendidos en mercados vinculados al Gobierno de EE. UU. o Canadá. Agencias federales y contratistas: están obligados a adquirir únicamente módulos validados según la norma FIPS 140 para proteger los datos federales y la información no clasificada controlada (CUI), lo cual se aplica a través de FedRAMP, CMMC y las normas de adquisición del Departamento de Defensa (DoD). Laboratorios de ensayo acreditados por el CMVP: laboratorios independientes de ensayo criptográfico y de seguridad (CSTL) que realizan ensayos de conformidad con la norma. |
| Apartados pertinentes | FIPS 140-3: Requisitos de seguridad para módulos criptográficos, en consonancia con las normas ISO/IEC 19790:2012 e ISO/IEC 24759:2017 . Listas activas e históricas del CMVP: el estado de validación que determina si un módulo es apto para nuevas contrataciones públicas federales. NIST SP 800-53 SC-13, SC-28, IA-7: controles que exigen que la criptografía proceda de un módulo validado. |
Visión general
La norma FIPS 140-3 fue aprobada por el Secretario de Comercio en marzo de 2019 y entró en vigor en septiembre de 2019, sustituyendo a la norma FIPS 140-2 y armonizando la validación de los módulos criptográficos de EE. UU. con las normas internacionales ISO/IEC 19790 e ISO/IEC 24759. Introduce pruebas de mitigación de ataques no invasivos en niveles de seguridad más elevados y requisitos formales de documentación de las fuentes de entropía que la norma FIPS 140-2 no exigía.
La transición tiene una fecha límite estricta. El CMVP dejó de aceptar nuevas solicitudes de certificación FIPS 140-2 en 2021 y, el 21 de septiembre de 2026, todos los certificados FIPS 140-2 activos restantes pasarán a formar parte de la «Lista histórica del CMVP», un estado que el programa define como aquel que las agencias federales «no deben incluir» en nuevas contrataciones. Los módulos FIPS 140-2 validados en los últimos cinco años pueden seguir utilizándose en los sistemas existentes, pero los nuevos contratos federales requieren un certificado FIPS 140-3 activo.
Por qué es importante
El proceso tradicional de validación según la norma FIPS 140-3 dura entre 18 y 30 meses, desde su inicio hasta la expedición del certificado. Los proveedores cuyos productos estén integrados en sistemas informáticos federales, dispositivos VPN, módulos de seguridad de hardware (HSM) o plataformas de comunicación segura, así como en sistemas operativos, quedarán prácticamente excluidos de las nuevas adquisiciones federales a partir del 21 de septiembre de 2026 si aún no han obtenido un certificado válido; los proveedores que no hayan iniciado el proceso a principios de 2025 corren un alto riesgo de perder por completo la oportunidad.
La presión es cada vez mayor y no se trata de un problema aislado: la misma cola del CMVP que necesitan los proveedores para obtener un certificado FIPS 140-3 estándar es también la cola para validar los algoritmos poscuánticos (ML-KEM, ML-DSA) que exigen simultáneamente la norma CNSA 2.0 y el documento NIST IR 8547, por lo que una única solicitud de validación tiene que superar cada vez más ambos requisitos a la vez.
Cómo se aplica esto a la criptografía
La norma FIPS 140-3 aborda la criptografía a través de varias áreas de control interrelacionadas. Las áreas clave con implicaciones criptográficas directas son:
| Sección | Función | Lo que dice | Productos complementarios |
| FIPS 140-3; Listas activas e históricas del CMVP | Seguimiento del estado de validación de módulos criptográficos | Confirme que cada módulo criptográfico incluido en el ámbito de un producto cuente con un certificado CMVP activo que se corresponda exactamente con la versión de software o de firmware implementada, y no solo con la familia de productos. | AgileSec |
| FIPS 140-3, niveles de seguridad 1 a 4 | Infraestructura de clave pública (PKI) basada en módulos validados | Emitir certificados y gestionar claves a través de autoridades de certificación y módulos de seguridad de hardware (HSM) respaldados por módulos criptográficos validados según la norma FIPS 140-3. | EJBCA |
| Transición de la lista histórica del CMVP, 21 de septiembre de 2026 | Planificación de la migración de módulos | Realizar un seguimiento de qué módulos implementados cumplen con la norma FIPS 140-2 y cuáles con la 140-3, y coordinar la generación de nuevas claves o la reemisión de certificados una vez que un módulo dependiente pase al estado «Histórico». | Keyfactor Command |
| NIST SP 800-53 SC-13, SC-28, IA-7 | Pruebas para los evaluadores federales | Informes centralizados que asocian cada certificado y cada clave a su módulo validado subyacente y a su número de certificado, lo que respalda el Plan de Seguridad del Sistema y las pruebas de auditoría. | Command / AgileSec |
| Documentación sobre la fuente de entropía según la norma FIPS 140-3 | Aleatoriedad y garantía en la generación de claves | Generar claves utilizando fuentes de entropía validadas y debidamente documentadas dentro de los límites de un módulo validado según la norma FIPS. | EJBCA |
| Mitigación de ataques no invasivos según la norma FIPS 140-3 (niveles de seguridad más elevados) | Hardware-Protección de claves con respaldo | Almacene las claves en módulos HSM validados según el nivel de seguridad FIPS 140-3 adecuado a la sensibilidad de los datos que protegen. | EJBCA |
Preparación para la auditoría
Las evaluaciones y los exámenes, ya sean realizados por la propia organización, llevados a cabo por un organismo regulador o revisados por un evaluador independiente, se centran en las pruebas demostradas y no únicamente en las declaraciones de política. Áreas clave que suelen analizar los examinadores y evaluadores:
- Verificación activa de certificados: ¿Cuenta cada módulo criptográfico dentro del ámbito del producto con un certificado CMVP activo, confirmado mediante la búsqueda de módulos validados por el CMVP, en lugar de basarse en las afirmaciones de marketing del proveedor?
- Coincidencia entre la versión y el certificado: ¿Coincide la versión específica de « software » o del firmware implementada en producción con la versión cubierta por el certificado?
- Exposición según la lista histórica: ¿Ha identificado la organización todos los módulos que aún están validados únicamente según la norma FIPS 140-2? ¿Dispone de un plan documentado para la transición del 21 de septiembre de 2026?
- Pruebas de la aplicación del modo FIPS: ¿Puede la organización demostrar que el modo FIPS está realmente activado en tiempo de ejecución, y no solo presente en la imagen implementada?
- Documentación sobre la fuente de entropía: ¿Está documentado que la fuente de entropía que alimenta la generación de claves cumple con los requisitos que ahora exige la norma FIPS 140-3?
- Hoja de ruta para la migración de módulos: ¿Existe alguna hoja de ruta al estilo POA&M para algún módulo que se acerque al estado «Histórico», en la que se especifiquen los responsables y se establezca un plazo de validación realista?
LLEVA ESTO A LA DIRECCIÓN
El 21 de septiembre de 2026 es una fecha límite vinculante para la adquisición, no una recomendación no vinculante. Todos los certificados FIPS 140-2 en los que nos basamos pasarán a formar parte de la Lista Histórica del CMVP ese día, y se ha ordenado a las agencias federales que no utilicen módulos con estado «histórico» para nuevas operaciones. La validación lleva entre 18 y 30 meses, por lo que, si aún no hemos comenzado el proceso o no hemos confirmado que nuestros proveedores lo hayan hecho, ya vamos con retraso.
Este no es solo un problema que debamos resolver internamente. Cada biblioteca integrada, cada proveedor de cifrado del sistema operativo y cada HSM de nuestro producto necesita su propio certificado actualizado, y debemos poder demostrarlo con un número de certificado y la versión correspondiente, no con una simple declaración de cumplimiento por parte del proveedor. Esa misma cola de validación es ahora también el cuello de botella para la validación de algoritmos poscuánticos, por lo que ponernos a la cola ahora nos da ventaja en ambos frentes.


