Why centralised identity databases fail

The conventional way to verify people online is to collect their identity documents into a database. Every service does it: scans of passports and licences, selfies, dates of birth, addresses, accumulated as a by-product of onboarding and kept indefinitely, because deleting data takes a decision and keeping it takes none. The result is thousands of independent archives of exactly the material needed to impersonate the people in them.

This is not a problem of careless operators, though carelessness makes it worse. It is a structural property of the architecture. A central identity database fails not because someone administers it badly, but because of what it is: a single location whose contents are worth more to attackers than the cost of any defence its operator can economically mount.

Security economics turns on the ratio between the value of a target and the cost of defending it. An identity archive concentrates value superlinearly: each additional record makes the whole more attractive, because attackers monetise at scale. Defence costs, meanwhile, grow with complexity — every employee, integration, backup and legacy system is attack surface. Past some size, the archive is worth a level of attacker effort — including patient, well-resourced effort — that no ordinary operator's defences are priced to resist.

Breach of identity evidence is also uniquely irreversible. A leaked password is rotated in a minute. A leaked face, birth date and document number are leaked for the life of the person. The blast radius of an identity archive breach is measured in decades, and the people harmed are not the ones who chose the architecture — the incentives are misaligned exactly where the stakes are highest.

Breach is not the only failure mode. A central identity database is also an instrument: whoever controls it can observe, profile, exclude or coerce at population scale, and every actor who can compel the operator inherits that power. History's lesson on registries is that capability outlives intent — databases built for one purpose are repurposed under pressure. This is why the human-rights analysis of identity systems, explored in a companion article, treats protection from surveillance and private capture as design requirements, not policy add-ons.

Even short of misuse, centralisation concentrates operational fragility: one outage locks everyone out; one corrupted migration damages everyone's records; one vendor's pricing decision taxes every dependent service. Identity is infrastructure, and infrastructure with a single point of failure fails.

The failure is architectural, so the fix must be too. The design used by the Identity Wallet makes three structural moves. First, evidence is encrypted on the user's device before it goes anywhere — what the network stores are encrypted payloads it cannot browse, so there is no plaintext archive to steal. Second, verification produces results, not copies: services receive a tier and a yes/no answer, never documents, so no service accumulates evidence as a side effect of checking it. Third, the record of results lives on a decentralised network with no single administrator to breach, compel or capture.

Notice what this does to the honeypot maths. The high-value asset — a browsable pile of identity evidence — simply never exists. What exists is ciphertext under user-held keys, distributed results, and consent records. An attacker who compromises a service gets that service's answers ("over 18: yes"), not the documents of everyone who ever verified.

Deleting is also honest in this design: when you delete your identity, encryption keys are destroyed, making remaining ciphertext permanently unreadable — a stronger guarantee than any promise to purge rows from an archive you cannot inspect.

• "Blockchains are public — isn't that worse?" It would be if personal data were written to the chain, which is why it never is. The chain stores encrypted references and verification results; its role is tamper-evidence for the record, not storage for the evidence.
• "Doesn't decentralisation just move trust to the code?" Yes — deliberately. Code can be audited by anyone before trusting it; a private operator's database practices cannot. The wallet's code is open source for exactly this reason.
• "Central databases enable recovery when things go wrong." Recovery is a real requirement, met differently: re-verification against your documents on a new device, not an administrator's master key.