What breaks when governments rely on passwords and OTPs instead of PKI for citizen identity verification?

Why This Matters for Security Teams

When governments use passwords and OTPs as the primary trust layer for citizen verification, the system is treating a weak authenticator as if it were a proof of identity. That creates avoidable fraud, account takeover, and transaction tampering risk, especially in high-value services such as tax, benefits, licensing, and social services. PKI changes the assurance model by binding identity to cryptographic proof, which is much harder to replay or intercept than a shared secret or one-time code.

This matters because citizen portals are not just login surfaces; they are decision systems that can trigger payments, change records, or expose sensitive personal data. Guidance from NIST Cybersecurity Framework 2.0 and the identity assurance direction in eIDAS 2.0 — EU Digital Identity Framework both point toward stronger, verifiable identity proofing and authentication for sensitive services. NHIMG research on the Ultimate Guide to NHIs shows why weak credentials fail at scale: 79% of organisations have experienced secrets leaks, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams learn this only after a credential-based fraud event has already been used to alter a live government record.

How It Works in Practice

Passwords and OTPs can support basic access, but they do not reliably prove that the user is the legitimate account holder, nor do they provide strong assurance that the browser, device, and transaction are untampered. OTPs are especially fragile because they can be phished in real time, relayed through adversary-in-the-middle tooling, or intercepted through SIM swap and mailbox compromise. PKI improves this by using private keys that remain under the user or device’s control and by allowing the service to validate a certificate chain, revocation status, and transaction signatures at runtime.

For citizen identity verification, the practical design goal is usually layered assurance rather than a single control. A stronger pattern is to use PKI for the highest-risk actions and keep passwords or OTPs only as one factor in a broader assurance stack. That may include device binding, certificate-backed login, transaction signing, risk-based step-up checks, and verified recovery processes. For public-sector rollouts, the control logic should be explicit about what a credential proves: authentication to the portal, proof of device possession, or approval of a specific transaction. Those are different statements, and password-plus-OTP often collapses them into one weak claim.

Current guidance suggests that services handling sensitive citizen records should evaluate authentication at the transaction level, not just at session start. NHIMG’s Lifecycle Processes for Managing NHIs highlights the operational lesson: identity systems fail when credentials are long-lived, poorly governed, or difficult to revoke. The same logic applies to citizen identity infrastructure, where revocation, certificate lifecycle, and recovery must be engineered before a breach, not after. These controls tend to break down in legacy government portals that cannot support device-bound certificates, real-time revocation checks, or modern federation without major application refactoring.

Common Variations and Edge Cases

Tighter authentication usually increases enrollment and support overhead, so governments have to balance stronger assurance against accessibility, inclusivity, and deployment cost. That tradeoff is real, especially where citizens use shared devices, low-end phones, or inconsistent broadband access.

Not every service needs the same assurance level. Low-risk informational portals may tolerate password-based access with OTP step-up for limited actions, while benefits disbursement, legal record changes, or cross-agency data access often justify PKI or equivalent phishing-resistant methods. The best practice is evolving, and there is no universal standard for this yet, but the trend is clear: if the transaction can create financial, legal, or privacy harm, the authenticator needs to do more than prove knowledge of a code.

Edge cases also matter. Recovery paths can become the weakest point if certificate issuance is strong but account restoration is still handled through email-only resets or call-center override. That is why the operational control plane must include identity proofing, revocation, audit logging, and fallback authentication that is stronger than the primary attack path. NHIMG’s 52 NHI Breaches Analysis is useful here because it shows a familiar pattern: weak credential handling usually fails through lifecycle gaps, not just login weakness. In high-assurance citizen services, those gaps often become visible only after a fraudulent submission or unauthorized record update.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on passwords and OTPs for high-risk access?
• What breaks when organisations rely on fraud tools instead of identity observability?
• What breaks when contact-centre identity checks rely on knowledge-based verification?
• What breaks when teams rely on identity inventories instead of visibility?