A Pakistani public-sector agency (name withheld under NDA)
NatID Verification Portal — an internal delivery codename, not a commercial product name.
The problem
Verification was a manual, in-person process with the throughput characteristics that implies. Digitising it meant integrating with NADRA APIs whose availability the agency did not control.
The portal had to be usable by citizens on any device, including older phones and assistive technology, and WCAG conformance was a procurement requirement rather than a preference.
Constraints we had to design within
- Upstream NADRA API availability outside the agency's control.
- Accessibility conformance as a hard procurement gate.
- Public-sector data handling requirements, including residency.
- Very wide device and connectivity range across the citizen user base.
Approach
Design for upstream unavailability
Because upstream availability could not be guaranteed, verification requests are queued and processed asynchronously with clear status communication to the citizen, rather than failing synchronously and asking them to try again later.
Accessibility built in, not audited in
Semantic structure, keyboard operability, focus management and contrast were properties of the component library from the start. Retrofitting conformance costs several times more than designing to it, and the semantic quality also improves how search engines and assistive technology parse the pages.
PKI signing with a defined key lifecycle
Digital signatures use PKI with a documented key management and rotation lifecycle. The cryptography is the easy part; the operational lifecycle is where these systems fail years later.
Engineering notes
Verification as graded evidence rather than a boolean
A national identity portal serves the whole population, including the part of it whose records are imperfect. Treating verification as pass or fail leaves no defined behaviour for the substantial minority who are legitimate but do not match cleanly.
Assurance tiers make the ambiguous cases ordinary rather than exceptional, each with a documented path to a higher tier, so a mismatch becomes a next step rather than a dead end.
Biometric fallback as an accessibility requirement
Fingerprint capture fails at rates that correlate with occupation and age — manual work wears ridges down, and older citizens have measurably higher failure rates. A system that requires biometric success excludes specific groups of people by construction.
A documented alternative route is therefore not a convenience feature. For a public-sector platform it is the difference between a service and a barrier, and it has to be designed rather than improvised at a counter.
Storing outcomes, not raw biometrics
The system retains the fact of verification, its timestamp, the assurance level reached and a reference — not raw templates or images, absent a specific documented lawful reason.
Biometric data is the highest-consequence category anyone can hold: permanently identifying and impossible to reissue after a compromise, unlike a password or a card number. Most platforms have no need for it once the check has completed.
Outcome
Verification moved from in-person to online with asynchronous handling that tolerates upstream outages rather than propagating them to citizens.
The portal met the agency's accessibility requirement as a build property rather than through a remediation project.
Figures above are drawn from delivery records held under NDA and are pending independent confirmation. Where a figure cannot be evidenced it will be removed rather than qualified.