Nepal’s ID security scare is a warning for every DPI rollout
Nepal offers a fresh reminder that opening up an identity system is not the same as securing it. According to Biometric Update, the country took a newly launched national ID card download service offline less than 24 hours after it went live, following an investigation that reportedly found the service exposed sensitive documents. The reported flaw was simple and serious: anyone who knew a person’s full name, date of birth and citizenship issuance date could retrieve and download that person’s national ID, with no additional verification layer.
The same report situates this inside a broader story. Nepal recently cancelled the international tender for the operation and maintenance of its national ID system, choosing to bring management in house in the name of data sovereignty, while card printing capacity has collapsed and a large enrolment backlog has built up. The download service was meant to be a step forward, letting citizens get their card on a smartphone instead of queueing at an office. Instead it became the weak point.
This is a pattern, not a Nepal problem
We see versions of this across programs. The move from siloed registries to digital public infrastructure, with interoperable services layered on top, creates real public value: faster service delivery, reuse across sectors, less duplication. It also widens the attack surface. Every open online service is a new door, and a lookup endpoint that trades weakly secret attributes (a name, a birth date, an issuance date) for a full identity document is a door left open.
The lesson is old and keeps being relearned. Security cannot be bolted on after launch. A full security design, a threat model and a hardened implementation have to ship with the opened service, not arrive in a later sprint once the breach is in the press.
Decentralized identity as a structural mitigation
There is a design choice that changes the risk profile, not just the controls. Decentralized identity, built on Verifiable Credentials and digital wallets, does not require exposing citizen data through an open online lookup. Rather than querying a central store every time a document is needed, the system issues a digital credential to the citizen, after strong authentication, onto a trusted device. From then on the citizen presents cryptographic proof. The verifier checks the proof, it does not interrogate a database of everyone.
This does not remove the need for sound registry security, governance and key management. It does remove an entire class of mass exposure risk, because there is no open endpoint that returns someone else’s identity on the strength of three guessable facts. As more governments open services on top of their foundational ID, that distinction is worth designing for from day one.
At ID30 we work with governments on exactly this question, vendor neutral, from architecture and standards to supervision. If you are opening services on top of your ID or CRVS systems and want security designed in from the start, let us talk.
Want to comment, ask a question, or join the discussion? Continue the conversation on LinkedIn.