Transición a FIPS 140-3: cronograma y cambios

Publicado: enero de 2021. Actualizado: agosto de 2026. Revisado por el equipo de Servicios HSM de Encryption Consulting.

FIPS 140 (Estándar Federal de Procesamiento de Información) es el estándar de seguridad del gobierno estadounidense para módulos criptográficos, que incluyen el hardware, el firmware y el software que generan claves, firman transacciones y cifran datos dentro de un HSM. FIPS 140-3 es la versión actual. Reemplaza a FIPS 140-2, y su implementación ya no es un evento futuro: tiene una fecha límite de cumplimiento de tres semanas a partir de hoy. Esta guía abarca los cambios introducidos por FIPS 140-3, el cronograma exacto de transición y el trabajo técnico necesario para migrar una flota de HSM, incluyendo la topología de implementación, las ceremonias de claves, la alta disponibilidad y las pruebas de integración, antes de que los certificados FIPS 140-2 queden obsoletos.

Encryption Consulting también publica una guía complementaria, FIPS 140-3: Lo que las organizaciones deben saber para septiembre de 2026 , que aborda en profundidad el cumplimiento normativo de esta transición, incluyendo la distinción entre FIPS Validated, FIPS Compliant y FIPS Capable, así como las once áreas de seguridad que debe cubrir una evaluación. Este artículo se centra en la adquisición de HSM y la migración técnica: qué cambios se producen en el hardware, no solo en la hoja de cálculo de cumplimiento.

¿Qué es FIPS 140-3 y en qué se diferencia de FIPS 140-2?

FIPS 140-3 es el estándar actual del NIST que define los requisitos de seguridad que debe cumplir un módulo criptográfico para ser validado para su uso en sistemas federales de EE. UU. y en los numerosos marcos del sector privado que lo referencian. Sustituye a FIPS 140-2 y, por primera vez, armoniza los requisitos de los módulos criptográficos federales de EE. UU. con el estándar internacional ISO/IEC 19790:2012 , con una metodología de prueba alineada con ISO/IEC 24759:2017.

Las diferencias no son superficiales. Cuatro cambios son los más importantes para los compradores y operadores de HSM:

Área	FIPS 140-2	FIPS 140-3
Seguridad no invasiva	No se abordó. La resistencia a los canales laterales se probó solo de manera informal, si es que se probó.	Nueva área de seguridad exclusiva. Se requieren pruebas formales de mitigación para el análisis de potencia, el análisis electromagnético y el análisis de temporización en el Nivel 3 y superiores.
Integridad del software y del firmware	Se aceptaron comprobaciones de detección de errores menos rigurosas.	A partir del Nivel 2, el módulo debe verificar su propio código con una firma digital aprobada o una prueba basada en HMAC.
Soporte de algoritmos	Se permiten los algoritmos Triple-DES, SHA-1 para firmas, RSA-1024 y MD5 en muchos contextos.	No permite firmas digitales Triple-DES, SHA-1, RSA-1024 ni MD5. TLS 1.0 y 1.1 son incompatibles con la configuración aprobada del módulo.
Tipos de módulos	El documento se basa en módulos de hardware, a los que posteriormente se añadieron módulos híbridos y de software mediante instrucciones interpretativas.	Define formalmente los módulos de hardware, firmware, software, software híbrido y firmware híbrido, sin ninguna restricción en el nivel de seguridad que puede alcanzar un módulo híbrido.

Dos de estos cambios tienen consecuencias operativas directas para una flota de HSM. Las pruebas de seguridad no invasivas implican que el proveedor de HSM ahora debe demostrar una sólida resistencia a los ataques físicos de canal lateral, no solo a los lógicos, lo que representa un importante requisito de ingeniería de hardware y firmware. El requisito de integridad del software subsana una deficiencia real en la cadena de suministro: una actualización de firmware comprometida puede modificar silenciosamente el comportamiento de un módulo sin alterar su interfaz externa, y la norma FIPS 140-3 exige que el módulo se verifique precisamente frente a ese escenario antes de su funcionamiento.

¿Cuál es el cronograma de transición a FIPS 140-3?

Esta transición se define por tres fechas, y las tres se confirman cotejándolas con los registros del Programa de Validación de Módulos Criptográficos (CMVP) del NIST.

Fecha	Milestone
22 de septiembre de 2019	La norma FIPS 140-3 se convierte en la norma vigente, tras su aprobación por el Secretario de Comercio.
22 de septiembre de 2020	CMVP comienza a aceptar solicitudes de validación FIPS 140-3.
1 de Abril, 2022	CMVP ha dejado de aceptar nuevas solicitudes de certificados de validación FIPS 140-2. Esta prórroga, concedida a laboratorios y proveedores que ya tenían contrato con la empresa, se extendió respecto a la fecha límite original del 21 de septiembre de 2021.
21 de septiembre de 2026	Todos los certificados FIPS 140-2 restantes pasarán a la Lista Histórica de CMVP. Esto ocurrirá dentro de tres semanas.

En resumen: Durante más de cuatro años, FIPS 140-3 ha sido el único estándar que CMVP utiliza para validar nuevos módulos. Lo que cambia el 21 de septiembre de 2026 no es el proceso de validación, ya que esa transición ya se produjo, sino el estado de todos los certificados que aún se basan en FIPS 140-2. Si su flota de HSM, la hoja de ruta de su proveedor o sus especificaciones de adquisición todavía hacen referencia a FIPS 140-2 como un objetivo aceptable, dicha referencia caduca en una fecha fija, no de forma continua.

¿Qué sucede cuando un certificado FIPS 140-2 pasa a ser histórico?

El estado histórico es un cambio en la base de datos CMVP, no un interruptor de apagado en el hardware. Un HSM que ejecuta un módulo validado según FIPS 140-2 continúa cifrando, firmando y generando claves exactamente igual que el día anterior. Nada en el dispositivo deja de funcionar el 21 de septiembre de 2026.

Lo que deja de funcionar es la validez del certificado como prueba de criptografía validada. Un certificado histórico ya no cumple con los requisitos de adquisición federales para sistemas nuevos, ya no admite la autorización FedRAMP para operar por sí solo, ya no cumple con las expectativas de seguridad técnica de HIPAA basadas en los estándares NIST actuales y ya no se sostiene de la misma manera en una revisión de PCI HSM o de un examinador financiero. CMVP aún incluye módulos históricos y continúa respaldando la compra y el uso de sistemas existentes basados ​​en ellos, pero recomienda explícitamente que los compradores elijan módulos actualmente validados para nuevas implementaciones en el futuro.

En la práctica, tres categorías de organizaciones tienen una opinión diferente al respecto:

• Organizaciones sin obligación de cumplimiento vinculada al estatus CMVP. Un certificado histórico no es un asunto de alta prioridad. Planifique un ciclo normal de actualización de hardware para cumplir con la norma FIPS 140-3.
• Organizaciones con una obligación de cumplimiento que hace referencia a la criptografía “validada”. (FedRAMP, HIPAA, PCI HSM, contratos de defensa, adquisiciones estatales y federales). Un certificado histórico es un hallazgo activo que podría presentarse en la próxima auditoría, examen o renovación de contrato.
• Actualmente, existen organizaciones que están adquiriendo nuevos módulos de seguridad de hardware (HSM). Cualquier orden de compra que especifique FIPS 140-2 como objetivo de validación aceptable, en lugar de requerir un certificado FIPS 140-3 activo, está creando hoy la brecha de cumplimiento del próximo año.

¿Qué topología de despliegue debería planificar para la migración de una flota de HSM?

Migrar a módulos validados según FIPS 140-3 es un buen incentivo para reevaluar la topología del HSM, en lugar de simplemente reemplazar el hardware. Cuatro decisiones dan forma a la migración:

• Clústeres centralizados versus clústeres distribuidos. Un clúster de alta disponibilidad centralizado en uno o dos centros de datos es más sencillo de validar y supervisar, pero concentra el riesgo. Un clúster distribuido geográficamente dispersa el riesgo y cumple con los requisitos regionales de residencia de datos, a costa de una sincronización de claves y una segmentación de red más complejas.
• Local, en la nube o híbrido. Los servicios HSM en la nube, como AWS CloudHSM y Google Cloud HSM, ahora incluyen hardware con certificación FIPS 140-3 Nivel 3, lo que puede acortar considerablemente la migración en comparación con una renovación completa del hardware local. Un modelo híbrido, que combina HSM locales para la gestión de claves raíz y de CA emisoras con HSM en la nube para cargas de trabajo de aplicaciones de alto rendimiento, es común cuando los requisitos de custodia de claves varían según el caso de uso.
• Particionamiento y multitenencia. Decida si los nuevos módulos utilizarán particiones lógicas por aplicación o por unidad de negocio, y confirme que el límite y el nivel de seguridad de FIPS 140-3 se aplican de forma coherente en todas las particiones, no solo en el dispositivo físico en su conjunto.
• Segmentación de red para interfaces de gestión. La gestión de HSM y el tráfico de clientes PKCS#11/KMIP deben ubicarse en segmentos de red separados y estrictamente controlados. Utilice la migración como punto de control para confirmar que esta segmentación aún coincide con la arquitectura actual, especialmente si la flota ha crecido desde la última revisión de topología.

Documente la topología de destino antes de solicitar el hardware. Una migración que comienza con "comprar el mismo equipo, solo que más nuevo" tiende a reproducir las deficiencias topológicas que ya presenta la flota actual.

¿Qué es el límite criptográfico FIPS 140-3 y por qué es importante en este caso?

El límite criptográfico es el perímetro físico o lógico explícito que encierra todos los componentes de hardware, firmware y software que realizan operaciones criptográficas dentro del módulo. Todo lo que se encuentra dentro de este límite se probó y validó conjuntamente como una unidad; no se puede asumir que nada fuera de él cuente con la garantía del certificado, incluso si se encuentra en el mismo chasis físico.

Esto es de vital importancia durante la migración por tres razones. Primero, una actualización de firmware que modifica algo dentro del límite, incluyendo un parche que afecta las rutas de código criptográfico, produce técnicamente un módulo diferente al que fue validado, razón por la cual los proveedores deben volver a enviar el firmware actualizado para su propio certificado en lugar de tratarlo como un incremento de versión menor. Segundo, FIPS 140-3 admite formalmente módulos híbridos (hardware más firmware, o hardware más software) sin restricciones en el nivel de seguridad que pueden alcanzar, por lo que una migración que cambia el tipo de módulo, por ejemplo, pasar de un dispositivo de hardware puro a un servicio HSM en la nube con un plano de control administrado por software, necesita su propia revisión de límites, no asumir que "HSM a HSM" es un intercambio equivalente. Tercero, al evaluar una oferta de HSM en la nube o HSM como servicio, confirme exactamente qué se encuentra dentro del límite validado del proveedor y qué se encuentra fuera de él en la infraestructura compartida del proveedor; un certificado que cubre el hardware subyacente no cubre automáticamente cada capa de un servicio multiusuario construido sobre él.

¿Cuáles son las principales implicaciones para la ceremonia al migrar a un nuevo HSM?

Trasladar material criptográfico a un módulo recién validado rara vez es una simple operación de copia, y tratarla como tal es el error técnico más común en una migración de HSM.

• Las claves raíz y de CA casi siempre requieren una nueva ceremonia. Dado que el límite criptográfico cambia con el módulo, las CA raíz y otras claves de firma de larga duración generalmente deben generarse desde cero, dentro del límite validado del nuevo módulo, mediante una ceremonia documentada y presenciada, en lugar de exportarlas y volver a importarlas. Planifique las funciones de custodia, los requisitos de quórum M-of-N y la captura de evidencia (video, registros firmados, declaraciones de testigos) del mismo modo que lo haría para una primera ceremonia de raíz.
• Las claves de cifrado de la aplicación y de los datos pueden respaldar una ruta de migración documentada. Algunos proveedores ofrecen clonación segura de claves o exportación/importación cifrada entre módulos de la misma familia de productos, siempre que ambos módulos cuenten con la certificación FIPS y la transferencia permanezca cifrada de extremo a extremo o utilice procedimientos de conocimiento dividido. Confirme esta capacidad y su cumplimiento normativo directamente con el proveedor antes de utilizarla; no dé por sentado que existe.
• Actualiza tu documentación de CP/CPS y de la ceremonia principal. Si una Política de Certificación o una Declaración de Prácticas de Certificación hace referencia a hardware específico, números de certificado o nombres de módulos, la migración activa una actualización de la documentación, no solo una técnica, y es posible que dicha actualización requiera la aprobación de la gobernanza antes de que el nuevo módulo entre en producción.
• Recertificar las funciones de los custodios. Confirme que los custodios clave, los testigos de la ceremonia y los aprobadores nombrados en su documentación de gobernanza siguen vigentes y vuelva a certificar formalmente sus funciones como parte del registro de la ceremonia para el nuevo módulo.

Para obtener una descripción completa de la estructura de la ceremonia, los controles del custodio y el empaquetado de pruebas, consulte la guía de Encryption Consulting para el diseño de una ceremonia de clave de CA raíz.

¿Cómo se planifica una migración de HSM conforme a FIPS 140-3?

Una secuencia práctica de migración, en orden:

1. Inventarie todos los módulos criptográficos incluidos en el ámbito de aplicación, como los HSM, los servicios HSM en la nube y las bibliotecas de proveedores, y registre el número de certificado CMVP y el estado actual de cada uno.
2. Verifique cada certificado directamente en la página de búsqueda de módulos validados de CMVP, en lugar de confiar en la afirmación de marketing del proveedor sobre el cumplimiento de FIPS.
3. Confirme la hoja de ruta de firmware o hardware validado según FIPS 140-3 de su proveedor de HSM, incluyendo el número de certificado objetivo y la fecha de disponibilidad prevista.
4. Antes de solicitar el hardware de reemplazo, defina la topología de implementación objetivo, la ubicación del centro de datos o la región de la nube, el tamaño del clúster de alta disponibilidad y el modelo de particionamiento.
5. Planifique la ceremonia de entrega de llaves para el nuevo módulo: roles de los custodios, quórum M-de-N, método de generación o migración de claves y captura de evidencia.
6. Instale el nuevo módulo junto con el existente en una configuración paralela o activo-pasiva, y realice las integraciones de la aplicación en lotes controlados.
7. Antes de desactivar el módulo FIPS 140-2, valide todas las aplicaciones dependientes, las rutas de copia de seguridad y los nodos de recuperación ante desastres con respecto al nuevo HSM.

Los plazos de entrega del hardware y las colas de validación de laboratorio implican que esta secuencia suele durar entre tres y seis meses para una flota de producción con altos requisitos de disponibilidad. Iniciar la fase de inventario hoy, tres semanas antes de la fecha límite histórica, aún es viable para fines de planificación, pero no permitirá completar el reemplazo total del hardware antes del 21 de septiembre de 2026 para la mayoría de las organizaciones. El objetivo realista en este momento es un plan de migración documentado y financiado con una ruta de adquisición FIPS 140-3 activa, no un reemplazo completo de la flota.

¿Cómo se mantiene la alta disponibilidad y las copias de seguridad durante la migración?

Una migración de HSM nunca debería crear un único punto de fallo, ni siquiera temporalmente. Unas pocas reglas mantienen la disponibilidad intacta:

• Mantenga la capacidad N+1 durante todo el intercambio. En lugar de reemplazar un nodo por completo, agregue el nuevo módulo FIPS 140-3 al clúster junto con el existente, de modo que el clúster nunca caiga por debajo de su capacidad normal de conmutación por error durante la migración.
• Confirme que sus módulos HSM de respaldo también estén validados según la norma FIPS 140-3. Un HSM de respaldo o de sitio de recuperación ante desastres que aún ejecute el firmware FIPS 140-2 socava el beneficio de cumplimiento que supone migrar el clúster principal, y seguirá mostrando un certificado histórico después del 21 de septiembre de 2026.
• Exporta las copias de seguridad de las claves en un formato que acepte el nuevo módulo. La copia de seguridad y la restauración de claves deben permanecer cifradas tanto en tránsito como en reposo, utilizando procedimientos de exportación encapsulada o de conocimiento dividido compatibles con el proveedor y con los límites del nuevo módulo, y no una exportación sin procesar que presupone un firmware idéntico en ambos extremos.
• Practique la conmutación por error y la recuperación en los nuevos módulos antes de que finalice la transición. Antes de desactivar el último nodo FIPS 140-2, compruebe que la conmutación por error en tiempo real al nuevo HSM funciona bajo carga y que la restauración desde una copia de seguridad en un módulo nuevo recién configurado se realiza correctamente.

¿Cuáles son los requisitos previos de integración antes de migrar?

Antes de migrar cualquier aplicación al nuevo módulo, confirme lo siguiente:

• La biblioteca cliente PKCS#11, KMIP, CNG o JCE de cada aplicación es compatible con el firmware y la versión de API del nuevo módulo. Una biblioteca creada para una interfaz antigua puede fallar silenciosamente en lugar de hacerlo de forma evidente.
• El modo FIPS está habilitado en la configuración de producción de todas las aplicaciones dependientes, no solo es compatible con el módulo. Un módulo validado por FIPS que se ejecuta en una configuración predeterminada que no cumple con FIPS, es decir, que en la práctica se denomina "compatible con FIPS" en lugar de "compatible con FIPS", es una de las deficiencias más comunes que se pasan por alto en las evaluaciones de cumplimiento.
• El rendimiento y la latencia se prueban bajo cargas realistas. Las medidas de mitigación de ataques no invasivas y las autopruebas más estrictas en los módulos FIPS 140-3 pueden modificar notablemente el rendimiento de la firma y el cifrado en comparación con el hardware FIPS 140-2 anterior; planifique la capacidad en consecuencia en lugar de asumir un simple reemplazo.
• El monitoreo, las alertas y el registro de auditoría hacen referencia al número de certificado y a los identificadores seriales del nuevo módulo, de modo que los paneles operativos y las pruebas de cumplimiento se mantengan precisos después de la transición.
• Los manuales de procedimientos para la rotación de claves, la copia de seguridad y la respuesta a incidentes se actualizan para reflejar los procedimientos del nuevo módulo, ya que las reglas más estrictas de autenticación y gestión de claves de FIPS 140-3 pueden modificar pasos que antes eran rutinarios.

¿Qué sucede si no cumples con la fecha límite del 21 de septiembre de 2026?

El modo de fallo más común no es una interrupción drástica del servicio, sino una brecha de cumplimiento silenciosa causada por documentación de compras que nunca se actualizó. Un ejemplo típico: un equipo de compras emite una orden de renovación que hace referencia al mismo modelo de HSM y hoja de especificaciones que se usaron dos o tres años antes, y que aún incluye FIPS 140-2 como objetivo de validación aceptable. El hardware se envía, se implementa y funciona correctamente desde el punto de vista técnico, pero la organización acaba de agregar un módulo cuyo certificado está a punto de ser, o ya es, incluido en la lista histórica, a un entorno sujeto a cumplimiento normativo.

Las consecuencias se manifiestan más tarde y de forma desigual: un revisor de monitoreo continuo de FedRAMP señala el módulo, una investigación de violación de HIPAA determina que el cifrado implementado no cumple con los requisitos de puerto seguro, la renovación de un contrato de defensa se estanca porque no se puede presentar el certificado FIPS 140-3 activo requerido, o un examinador financiero abre una investigación que su equipo no puede resolver sin un nuevo ciclo de hardware. Ninguno de estos casos es hipotético; son el resultado directo y previsible de una especificación de adquisición que nunca se actualizó para cumplir con el plazo establecido.

Dos medidas permiten subsanar esta deficiencia antes de que se produzca. Primero, revisar cada orden de compra, solicitud de propuestas (RFP) y contrato con proveedores de hardware o firmware HSM, e incluir el requisito indispensable de contar con un certificado CMVP FIPS 140-3 activo en el momento de la entrega, en lugar de una preferencia. Segundo, auditar cualquier entrega de HSM programada para después del 21 de septiembre de 2026, comparándola con el número de certificado FIPS 140-3 confirmado por el proveedor; si este no puede proporcionarlo, dicha entrega constituye la deficiencia.

Tabla de decisiones sobre el estado del módulo

Estado del módulo	Qué hacer	Se prorroga
Certificado FIPS 140-2, actualmente activo.	Continúe operando el hardware implementado; comience ahora mismo la planificación y adquisición de equipos para la migración a FIPS 140-3.	El certificado pasará a la categoría de histórico el 21 de septiembre de 2026.
Certificado FIPS 140-2, ya histórico o revocado.	No confíe en él para nuevas adquisiciones sujetas a cumplimiento normativo; priorice la sustitución de las cargas de trabajo reguladas.	Ahora.
Certificado FIPS 140-3, Activo	Estatus preferencial para todas las nuevas adquisiciones de HSM y despliegues que requieran cumplimiento normativo.	En curso; confirme el estado en cada renovación.
Presentación de FIPS 140-3 incluida en la lista de módulos en proceso de CMVP.	Realice el seguimiento del listado; no cite una presentación en proceso como validación actual en una auditoría o certificación hasta que pase a estar activa.	Varía según el proveedor y la cola de CMVP.
No cuenta con certificado CMVP; el proveedor afirma únicamente que cumple con la normativa FIPS.	Tratar como no verificado. Solicite el número de certificado y confirme el estado Activo directamente en csrc.nist.gov antes de la implementación.	Antes de la adquisición, no después.

Limitaciones

Esta guía abarca la ruta general de migración de HSM y no reemplaza una evaluación de brechas específica del proveedor. Los marcos específicos del sector, como FedRAMP, PCI HSM y las adquisiciones de defensa, pueden imponer requisitos intermedios más estrictos o sus propios plazos de transición, que se suman al plazo de CMVP. Los requisitos de nivel de seguridad (Nivel 2, Nivel 3 y Nivel 4) también modifican el aspecto de una migración "conforme" para un caso de uso determinado; un HSM de pago de Nivel 3 y un módulo de software de Nivel 1 no conllevan la misma carga de migración. Este artículo se centra en la validación de módulos FIPS 140-3 y no cubre la migración de algoritmos post-cuánticos, que es un proyecto relacionado pero independiente para la mayoría de las flotas de HSM. El estado de los certificados CMVP y los plazos de la cola pueden cambiar; siempre confirme el estado actual en la página de búsqueda de módulos validados de CMVP antes de tomar una decisión de adquisición o cumplimiento.

¿Qué recomendaría Encryption Consulting?

Comience con un inventario verificado, no con una orden de compra. Antes de reemplazar un solo HSM, confirme exactamente qué módulos de su entorno cuentan con certificados FIPS 140-2 activos, cuáles son históricos y cuáles ya cumplen con FIPS 140-3. Este paso de inventario por sí solo resuelve la mayor parte de la falsa confianza que las organizaciones tienen antes de esta fecha límite, ya que la indicación "cumple con FIPS" en la ficha técnica del proveedor y la "validación FIPS 140-3" en la base de datos CMVP no son lo mismo.

A partir de ahí, solemos recomendar dos enfoques que se ejecutan en paralelo. El equipo de Servicios HSM de Encryption Consulting se encarga del aspecto técnico: inventario de la flota, diseño de la topología de implementación, planificación y ejecución de la ceremonia de claves y migración por etapas a hardware validado según FIPS 140-3 o servicios HSM en la nube, manteniendo la alta disponibilidad en todo momento. Para las organizaciones que prefieren que el hardware sea gestionado en lugar de ser de su propiedad, HSM-as-a-Service ofrece capacidad HSM dedicada y validada según FIPS 140-3 sin el tiempo de espera ni el coste de capital de una renovación completa en las instalaciones, lo que puede acortar significativamente el plazo para los equipos que empiezan tarde.

Paralelamente, el equipo de Asesoramiento en Cumplimiento Normativo de Encryption Consulting adapta la migración al marco normativo al que se somete su organización (FedRAMP, HIPAA, PCI HSM o contratación pública para el sector de la defensa), de modo que el paquete de pruebas (números de certificado, registros de ceremonias, CP/CPS actualizados) esté listo para la próxima auditoría o examen, en lugar de recopilarse a posteriori.

Conclusión

El 21 de septiembre de 2026 no es una fecha límite fácil. Es una fecha fija que CMVP ha mantenido durante años, y se acerca en semanas, no en trimestres. Las organizaciones que la traten únicamente como una actualización de hardware pasarán por alto los aspectos que realmente generan riesgos: una topología de implementación que nunca se reevaluó, una ceremonia de entrega de claves realizada de manera informal en lugar de documentada, HSM de respaldo que aún ejecutan firmware antiguo y pruebas de integración omitidas porque "es el mismo HSM, solo que más nuevo". El trabajo técnico, el inventario, el estado verificado de los certificados, el diseño de la topología, la ceremonia de entrega de claves, la transición segura para alta disponibilidad y la validación de la integración son lo que distingue una migración conforme de una compra de hardware que parece conforme sobre el papel.

Póngase en contacto con Encryption Consulting en [email protected] para iniciar un inventario de su flota de HSM y un plan de migración a FIPS 140-3 antes de la fecha límite del 21 de septiembre de 2026.

Referencias

NIST CSRC: Esfuerzo de transición a FIPS 140-3

Registro Federal: Anuncio de la publicación de la norma FIPS 140-3

NIST CSRC: Programa de validación de módulos criptográficos (CMVP)

Consultoría en cifrado: FIPS 140-3: Lo que las organizaciones deben saber para septiembre de 2026.