MOSIP: an open-source platform for national digital identity

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:
- Pre-registration and registration: booking appointments and capturing demographic and biometric data at enrolment centres, including offline-capable registration clients for remote areas.
- Registration processing: validating packets, checking for duplicates through an automated biometric identification system (ABIS) and issuing a unique identity number.
- Identity repository and authentication: storing identity records and answering yes/no or limited-data authentication requests from authorised services ("relying parties").
- Partner management: onboarding device makers, biometric vendors and relying parties under defined policies.
- Resident services: letting individuals update data, download credentials, lock certain authentication types or view their authentication history, depending on the country's configuration.
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:
- Biometric devices (fingerprint, iris and face capture) connect through published device interface specifications, so devices from different makers can be certified and used side by side.
- Biometric matching (ABIS) sits behind a defined interface, so a country can change its matching supplier without rebuilding the whole system.
- Biometric SDKs for quality checks and matching are also pluggable.
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:
- The Philippines, where the Philippine Identification System (PhilSys), created by the PhilSys Act of 2018 (Republic Act No. 11055), uses MOSIP as part of its technology stack.
- Ethiopia, whose national digital ID programme (Fayda) has adopted MOSIP.
- Morocco, which was among the first adopters.
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:
- Is the identity mandatory? And for which services? Making a single ID a precondition for food rations, pensions or SIM cards raises the stakes of every exclusion error.
- Which data is collected? Collecting iris and fingerprints from every resident, including children, is a policy choice, not a technical necessity of the platform.
- Who can authenticate, and what do they receive? Yes/no answers, tokenised identifiers and minimal attributes protect privacy; full data returns do not.
- What is the legal basis and oversight? A data protection law, an independent authority and a grievance route are preconditions, not optional extras.
- Who runs it? Countries still need skilled teams, or trusted system integrators, to deploy, operate and secure the platform. Open source shifts dependency from licences to skills.
These issues are covered in our guide to digital ID privacy safeguards.
Strengths and risks at a glance
| Strengths | Risks 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
- Separate the platform from the policy: open-source code does not make a system rights-respecting.
- Put standard interfaces wherever proprietary components remain.
- Budget for operations and in-house capacity, not just deployment.
- Stay close to the upstream core to benefit from community upgrades.
Sources
- MOSIP, mosip.io and technical documentation.
- MOSIP, MOSIP Connect / Country Conversations 2025.
- Philippine Statistics Authority, Philippine Identification System.
- Digital Public Goods Alliance, DPG Registry.
GuidesDigital ID privacy safeguards
Minimisation, sector-specific identifiers, selective disclosure, access logs and the court cases that shaped the field.
AnalysisOpen source or proprietary?
Lock-in, cost, security and skills: what national policies say, and a decision framework for public infrastructure.
Case studiesSingapore: Singpass, Myinfo, PayNow
A two-decade-old login that became a national identity platform, consent-based data sharing, and instant payments that cross borders.