When a local authority signs a document online or verifies the identity of an agent on an internal portal, it relies on software bricks that are often invisible. CAPICOM has long been one of these bricks, integrated into Windows applications without end users suspecting its existence. Its role: to manage digital certificates, encrypt data, and apply electronic signatures through a few lines of code.
The problem is that Microsoft has officially deprecated CAPICOM and ceased all updates, placing local administrations in a technical blind spot.
Electronic Signature and Certificates: What CAPICOM Did in Practice
Before discussing replacements, a look at how it worked helps to understand the scope of the issue. CAPICOM is a COM (Component Object Model) library that allowed developers to integrate cryptographic functions into Windows applications without directly manipulating the low-level layers of the system.
In practice, this provided three main capabilities:
- Validate and manage digital certificates stored in the Windows store, for example, to authenticate an agent accessing an online service.
- Electronically sign documents or data streams, ensuring their integrity and the identity of the signer.
- Encrypt and decrypt sensitive information exchanged between services, such as civil status documents transmitted between a town hall and a prefecture.
For a local authority, these functions impacted concrete processes: dematerialization of public contracts, transmission of documents to state services, authentication on business portals. CAPICOM often ran via ActiveX controls in Internet Explorer, which explains why its use remained invisible in modern browsers for a long time.
Many resources detail capicom and its uses on Collectivité Numérique, which helps to gauge how deeply this library became embedded in various application chains.
Obsolescence of CAPICOM: Real Risks for Local Authorities
Microsoft no longer distributes CAPICOM in recent versions of Windows and explicitly recommends migrating to CryptoAPI, CNG (Cryptography API: Next Generation), or .NET classes. This is not just a version change: it is a definitive end to support.
Why does this pose a real problem for local authorities? Because a library without security patches becomes a gateway for attacks. Every vulnerability discovered after the end of support remains open, without a patch.
Weakened Regulatory Compliance
Local authorities handle personal data of residents (civil status, social assistance, local taxation). Using an obsolete cryptographic component weakens GDPR compliance, as the regulation requires technical measures appropriate to the state of the art. A tool abandoned by its publisher no longer meets this requirement.
The ANSSI’s guidelines and the state’s cloud doctrine push in the same direction: public service digital solutions must rely on maintained, audited, and, if possible, sovereign components. CAPICOM no longer meets any of these criteria.
Dependency on Internet Explorer
Many implementations of CAPICOM relied on ActiveX controls, a technology tied to Internet Explorer. However, Microsoft has ended support for Internet Explorer. Local authorities that have not yet migrated their internal web applications face a double obsolescence: browser and cryptographic library.
Migration to CryptoAPI and .NET: Where to Start
The migration is not a simple replacement of a DLL file. It requires identifying all applications that call CAPICOM, then rewriting the relevant portions of code. Here are the concrete steps this entails.
Start with a complete application inventory. Each department (urban planning, finance, human resources) may use business software that incorporates CAPICOM without the IT department being aware. Searching for calls to the DLL capicom.dll in the application portfolio is the starting point.
Next, the choice of replacement technology depends on the context:
- CryptoAPI is suitable for C/C++ applications that remain in a native Windows environment. It offers direct access to the system’s certificate store.
- CNG (Cryptography API: Next Generation) provides more recent algorithms and a modular architecture. This is the recommended path for new developments.
- The System.Security.Cryptography classes of .NET are suitable for applications developed in C# or VB.NET, which is often the case for local authorities’ internal business tools.
Each replacement must be tested in an isolated environment before deployment, as changing the cryptographic library can alter the format of generated signatures and render previously signed documents unreadable.
Sovereign Alternatives and Public Digital Suites
The issue is not limited to the technical replacement of CAPICOM. In recent years, French public policies have encouraged the adoption of free or controlled digital solutions for local authorities. DINUM offers LaSuite, an ecosystem of collaborative applications based on free software, hosted in France.
LaSuite does not directly replace CAPICOM (it is not a cryptographic library), but it illustrates the direction taken: favoring tools whose source code is auditable and hosting is sovereign. For the electronic signature layer, providers qualified by ANSSI offer services compliant with the eIDAS regulation, without relying on abandoned proprietary components.
Local authorities that take advantage of the migration to rethink their signature architecture gain on two fronts: they eliminate a technical debt and align with current security standards.
The disappearance of CAPICOM is not a minor incident. For the local authorities still using it, each month without migration increases exposure to unpatched vulnerabilities. The application inventory remains the first useful action, even before choosing between CryptoAPI, CNG, or .NET. And since the French regulatory framework pushes towards open and sovereign solutions, this is also an opportunity to avoid reproducing the same dependency on a single publisher.