El próximo 21 de septiembre de 2026, todos los certificados FIPS 140-2 pasarán a la lista histórica del NIST y dejarán de incluirse en nuevas adquisiciones federales, lo que ha desatado una oleada de compras de módulos FIPS 140-3. Sin embargo, la validación FIPS responde a una pregunta muy concreta: certifica que un módulo criptográfico concreto, con una versión de firmware y configuración específicas, implementa correctamente algoritmos aprobados y cumple ciertos requisitos de diseño. No garantiza que el producto que lo rodea sea seguro, que el módulo se opere en su configuración validada ni que las claves se gestionen de forma adecuada.
La evidencia acumulada desmonta la idea de que la certificación equivale a seguridad. El fallo ROCA (2017) en Infineon pasó cinco años bajo certificados FIPS 140-2 y Common Criteria EAL5+. EUCLEAK (2024) afectó a los YubiKey 5 FIPS y al YubiHSM 2 FIPS durante catorce años y unas 80 evaluaciones Common Criteria. Dual_EC_DRBG fue un algoritmo aprobado durante una década pese a sospechas de puerta trasera. Paradójicamente, los YubiKey serie FIPS de 2019 fueron menos seguros que los modelos de consumo por un fallo introducido precisamente por los self-tests obligatorios de FIPS.
Además, el proceso CMVP tarda entre doce y dieciocho meses, lo que obliga a los proveedores a elegir entre parchear un fallo y perder la validación, o mantener código vulnerable certificado. El caso de Go ilustra esta parálisis: hasta la versión 1.24, que incluye un módulo nativo validado en Go puro, la comunidad dependía de bifurcaciones no oficiales sobre BoringSSL, OpenSSL o CNG de Windows. Comprar FIPS como sinónimo de seguridad es pagar por un certificado que no cubre la mayor parte de los incidentes reales.