CAPICOM es una biblioteca de cifrado desarrollada por Microsoft, utilizada durante mucho tiempo para gestionar la firma electrónica y la autenticación en aplicaciones de Windows. Para las entidades locales, esta herramienta ha permitido durante años asegurar el intercambio de documentos y validar certificados digitales.
Su estatus ha cambiado radicalmente: Microsoft ha oficialmente desaprobado CAPICOM y ha cesado su soporte, lo que coloca a las administraciones locales ante una elección técnica con consecuencias directas sobre su conformidad y su seguridad informática.
CAPICOM y entidades locales: una dependencia técnica heredada
Antes de hablar de migración o reemplazo, es necesario entender por qué CAPICOM se ha encontrado en el centro de ciertos sistemas de información públicos. La biblioteca ofrecía una interfaz COM (Component Object Model) accesible desde lenguajes de script como VBScript o entornos de Visual Basic. Para los servicios informáticos de ayuntamientos o mancomunidades con recursos limitados, esta facilidad de integración representaba una ventaja concreta.
Los usos más frecuentes en el sector público giraban en torno a tres funciones: la firma electrónica de documentos administrativos, el cifrado de datos sensibles intercambiados entre servicios, y la verificación de certificados durante conexiones seguras. Aplicaciones desarrolladas internamente o por proveedores locales han integrado CAPICOM sin siempre documentar esta dependencia.
El problema es que esta integración a menudo data de hace más de una década. Los equipos que implementaron estas soluciones a veces han dejado la entidad, y la documentación técnica es escasa. Para saber más sobre Capicom en Collectivité Numérique, varios recursos detallan los casos de uso históricos en el sector público.
Desaprobación por parte de Microsoft: lo que significa en la práctica
Microsoft ha anunciado el cese de CAPICOM y recomienda migrar hacia las API CryptoAPI o las clases .NET Framework (System.Security.Cryptography). La última versión disponible, CAPICOM 2.1.0.2, estaba en el Windows SDK para Windows Server 2008, Windows Vista y Windows XP. Para sistemas de 64 bits y versiones más recientes de Windows, Microsoft orienta hacia .NET o .NET Framework.
Concretamente, la desaprobación significa varias cosas para una entidad local:
- No se publicará ningún parche de seguridad si se descubre una vulnerabilidad en CAPICOM, lo que expone a los sistemas que aún lo utilizan a riesgos no corregidos.
- Las actualizaciones de Windows pueden romper la compatibilidad en cualquier momento, sin previo aviso ni solución oficial.
- Las auditorías de ciberseguridad, cada vez más frecuentes en el sector público, señalan sistemáticamente el uso de componentes obsoletos como un punto de no conformidad.
Los marcos de ciberseguridad públicos recientes desaconsejan el uso de bibliotecas criptográficas obsoletas. Utilizar CAPICOM en producción equivale a mantener una puerta cuya llave ha sido desechada por el fabricante.
Migración a CryptoAPI y .NET: restricciones reales para el sector público
Sobre el papel, pasar de CAPICOM a .NET o CryptoAPI parece lógico. En la realidad de las entidades locales, la migración plantea dificultades que las guías técnicas de Microsoft no abordan.
La primera restricción es presupuestaria. Los pequeños municipios y las mancomunidades no siempre cuentan con un servicio informático dedicado. Hacer auditar todas las aplicaciones que dependen de CAPICOM, y luego reescribir el código correspondiente, representa un costo que muchas estructuras no han anticipado en su programación plurianual.
Identificar las aplicaciones afectadas
El trabajo comienza con un inventario. Se trata de identificar cada script, cada aplicación de negocio y cada proceso automatizado que llama a la biblioteca CAPICOM. En las entidades de tamaño medio, este inventario a veces revela usos insospechados: un formulario de firma en la intranet, un script de cifrado de archivos de recursos humanos, una interfaz con un software de gestión financiera.
Sin este inventario previo, cualquier migración sigue siendo parcial y deja componentes vulnerables en funcionamiento.
Elegir la tecnología de reemplazo
Microsoft propone dos vías principales. CryptoAPI sigue siendo una opción de bajo nivel, adecuada para desarrollos en C/C++. Para la mayoría de las entidades cuyas aplicaciones se basan en lenguajes de más alto nivel, las clases System.Security.Cryptography de .NET constituyen el reemplazo natural. Cubren la firma, el cifrado simétrico y asimétrico, y la gestión de certificados X.509.
Los comentarios de campo divergen sobre la facilidad de esta transición. Algunas entidades informan de una migración fluida cuando las aplicaciones estaban bien documentadas. Otras se enfrentan a código heredado difícilmente legible, donde cada modificación puede introducir regresiones.
Seguridad y conformidad: los riesgos concretos de la inacción
Mantener CAPICOM en producción no es solo una elección técnica discutible. Es un riesgo jurídico y operativo para las entidades locales.
Las obligaciones de protección de datos personales imponen el uso de medios criptográficos actualizados. Un componente sin soporte de seguridad debilita toda la cadena de confianza, incluso si el resto de la infraestructura es reciente. Un certificado firmado a través de una biblioteca vulnerable ya no garantiza la integridad del documento.
El riesgo operativo es igualmente concreto. Una actualización del sistema aplicada un viernes por la noche puede hacer que una aplicación de firma utilizada para validar compras públicas el lunes por la mañana quede inoperativa. Sin soporte del editor, la búsqueda de soluciones recae completamente en los recursos internos o en un proveedor, con plazos incompatibles con la continuidad del servicio público.
Las entidades que aún no han comenzado su migración se encuentran en una situación donde cada mes que pasa aumenta el riesgo de incidentes sin reducir el costo de la transición. El inventario de las dependencias de CAPICOM, incluso parcial, sigue siendo la primera acción útil, aquella que permite medir la magnitud del proyecto antes de presupuestarlo.