Digital Identity Is the Prerequisite, Not the Product

The dependency nobody budgets for

Almost every digital government initiative shares a hidden prerequisite: the system must know who it is dealing with. Benefits must reach the intended recipient. Health records must attach to the right patient. Credit must be extended to a person who can be found again.

Identity is therefore not one programme among many. It is the layer every other programme silently depends on. Yet it is routinely sequenced late, because it produces no visible service of its own and its benefits appear in other departments' results.

The cost of retrofitting

When identity is built late, each service builds its own partial solution. A health system creates patient numbers. A benefits agency creates claimant records. A tax authority creates taxpayer identifiers. None reconcile.

Reconciling them afterwards is among the most expensive projects a government can undertake, because it requires matching records that were never designed to match, resolving conflicts with no authoritative source, and doing so without interrupting services that are running on the broken data.

The rule of thumb is unpleasant and consistent: identity built first is cheap, identity built fifth costs more than the four systems that preceded it.

Trustworthy, not merely functional

A functioning identity system is not automatically a trustworthy one, and the distinction determines adoption.

Trustworthiness requires that the system minimises data collected to what a transaction needs, that it cannot be silently queried to track individuals across unrelated services, that exclusion has a remedy accessible to people without documents, and that the operator is subject to genuine external audit.

These are not constraints imposed on the system from outside. They are what makes population-scale adoption possible, because a system people avoid is not infrastructure — it is an expensive database with partial coverage.

Designing against the failure modes

Two failure modes recur often enough to design against explicitly.

The first is exclusion. Biometrics fail for manual labourers with worn fingerprints and for the elderly; any system with no fallback pathway excludes precisely the people most dependent on the services it gates. A documented, staffed, non-biometric exception route is not optional.

The second is function creep. A system built for benefits delivery becomes a law-enforcement tool, then a condition for private services. This erodes trust faster than any technical breach, and the protection against it is legal and architectural — purpose limitation written into statute and enforced by the system's design, not by the current operator's restraint.