Case studies

MOSIP: an open-source platform for national digital identity

Case studies · Published 2026-09-22

A hand placed flat on an illuminated fingerprint scanner at a service desk
A four-finger fingerprint scanner in use (illustration only; not a MOSIP deployment). Photo: U.S. Customs and Border Protection, public domain, via Wikimedia Commons.

For a long time, a government that wanted a national digital identity system had essentially one route: buy it from a specialised vendor, often with the biometric matching, enrolment devices and software bundled together. MOSIP, the Modular Open Source Identity Platform, was created to offer another route: an open-source core that a country owns and runs, with components it can source from different suppliers.

Origins

MOSIP was established in 2018 at the International Institute of Information Technology Bangalore (IIIT-B), a public university in India, with philanthropic funding. The idea drew on lessons from large identity programmes, including India's Aadhaar, but MOSIP is not Aadhaar: it is a separate, generic platform designed to be adapted by any country, with its own configuration, data and legal framework.

Its code is published under the Mozilla Public License 2.0, and it is listed as a digital public good by the Digital Public Goods Alliance. Documentation and source code are public on docs.mosip.io and GitHub.

What the platform does

MOSIP covers the core lifecycle of a foundational identity system, split into modules that can be deployed and replaced separately:

Around this core, the MOSIP community has developed related open-source tools, such as an OpenID Connect-based authentication service (eSignet) and a stack for issuing and verifying digital credentials (Inji), so that the identity can be used for online login and portable credentials.

Vendor neutrality by design

The most consequential design choice is the use of standard interfaces between MOSIP and the components where proprietary technology is still common:

The aim is to prevent the lock-in that has made some national identity programmes dependent on a single supplier for decades, with costly renewals and limited bargaining power.

Adoption

MOSIP-based systems are in use or under deployment in a growing number of countries. Among the most prominent:

In March 2025, MOSIP reported that representatives of more than 25 MOSIP-adopting countries attended its annual country forum in Manila. Counts vary with definitions (pilot, partial adoption or national rollout), so it is worth checking the MOSIP website for current figures.

How a country typically deploys it

Adopting MOSIP is not a matter of downloading software. Countries usually go through a sequence of steps: defining the legal and policy framework (who is enrolled, which data is collected, who may authenticate); selecting the modules they need; choosing a system integrator or building an in-house team; procuring and certifying biometric devices and a matching system through the standard interfaces; configuring the platform, languages and workflows; and running a pilot before national enrolment. MOSIP's own team provides technical support and documentation, but does not run national systems: operation, hosting and security remain the responsibility of the national identity authority. This division matters because it places accountability, and the need for skilled staff, squarely with the state.

What open source does not decide

An open-source identity platform solves a procurement and sovereignty problem. It does not by itself answer the hardest questions, which remain national choices:

These issues are covered in our guide to digital ID privacy safeguards.

Strengths and risks at a glance

StrengthsRisks and open questions
Country owns the code and data; no licence fees for the core.Integration, hosting and operations still cost money and require skills.
Standard interfaces reduce biometric vendor lock-in.Certification of devices and vendors must be rigorous and well resourced.
Modular: countries can adopt parts and add their own.Customisation can drift from the core, making upgrades harder.
Shared community: fixes and features benefit all adopters.Long-term funding of the core team depends on philanthropy and adopting states.
Supports privacy-protective options (tokenised IDs, minimal responses).Whether they are used depends on national configuration and law.

Lessons

  1. Separate the platform from the policy: open-source code does not make a system rights-respecting.
  2. Put standard interfaces wherever proprietary components remain.
  3. Budget for operations and in-house capacity, not just deployment.
  4. Stay close to the upstream core to benefit from community upgrades.

Sources