National Digital ID Schemes Map: Aadhaar to Login.gov

Government digital identity schemes now sit in front of tax, benefits, health and banking, yet each one defines assurance differently, imposes different duties on the services that rely on it, and fails in different ways. A service operating in several countries has to map those differences before it can decide which scheme to accept for which transaction. This map compares four official schemes and frameworks for which primary documentation could be read: India's Aadhaar, Singapore's Singpass, GOV.UK One Login and the US Login.gov, with the EU Digital Identity Wallet framework as the cross-border reference. It covers scope, the assurance levels each exposes, duties on relying parties, current status, penalties and what changes when software agents act for people. It is for identity architects, product owners and compliance teams integrating national identity. Status line: facts checked against the official sources listed on 27 October 2026; schemes change often, so confirm current documentation before relying on any detail.

Key takeaways

Assurance levels are not interchangeable. Login.gov signals NIST SP 800-63-4 levels through acr_values, GOV.UK One Login uses GPG 44 credential levels and identity confidence levels P0 to P2, and Aadhaar returns a yes or no match by demographic, OTP, biometric or multi-factor mode.
Facial matching changes the level. Login.gov states that urn:acr.login.gov:verified meets IAL1 but not IAL2, while verified-facial-match-required meets IAL2, so a relying party asking for "verified" may not get what its policy assumes.
Aadhaar is a statute with criminal penalties. The Aadhaar Act 2016 requires consent before authentication (s.8), bars sharing core biometric information for any reason (s.29) and sets offences for requesting entities (ss.40 and 41); amendments in 2019 changed the regime, so check the consolidated text.
Phishing resistance is arriving unevenly. Singpass launched passkeys in beta for iOS on 30 June 2026, Login.gov offers a phishing-resistant AAL value, while GOV.UK One Login's documented second factors are SMS one-time passwords and authenticator apps.
Agents need delegation, not shared logins. None of these schemes is designed for software agents to hold a person's identity credential; services must use the scheme's federation tokens and their own scoped machine credentials.

Regulations and frameworks at a glance

Scheme	Operator and basis	What a relying party receives	Assurance signalling	Status note
Aadhaar (India)	UIDAI under the Aadhaar (Targeted Delivery of Financial and Other Subsidies, Benefits and Services) Act, 2016 (18 of 2016), amended by the Aadhaar and Other Laws (Amendment) Act, 2019 (14 of 2019)	A yes or no authentication response; e-KYC only via OTP and/or biometric authentication	Mode of authentication: demographic, OTP, biometric (fingerprint, iris or other), multi-factor	UIDAI lists a version of the Act updated up to 10 October 2023
Singpass (Singapore)	GovTech Singapore, a statutory board under the Ministry of Digital Development and Information	Login and, for businesses, government-sourced customer information	Login method (QR, Face Verification, SMS OTP, passkeys)	Over 2,000 services by over 700 agencies and businesses; over 41 million transactions monthly; passkeys beta from 1 July 2026
GOV.UK One Login (UK)	UK government service; levels from GPG 44 (authentication) and GPG 45 (identity checking)	Authentication, plus identity attributes when identity confidence is requested	Vectors `Cl` and `Cl.Cm`; identity confidence `P0`, `P1`, `P2`	Identity attributes require `Cl.Cm`
Login.gov (US)	General Services Administration	Authentication, plus identity-proofed attributes at verified levels	`acr_values` mapped to NIST SP 800-63-4 IAL and AAL	IAL2 requires the facial match service levels
EU Digital Identity Wallet	Regulation (EU) 2024/1183 amending eIDAS; Member State wallets	User-approved attributes from the wallet	Wallet presentation; relying parties registered under Art. 5b	Member States must provide a wallet within 24 months of the implementing acts (Art. 5a(1))

For the EU wallet in depth see the eIDAS 2.0 and the European Digital Identity Framework Guide; for UK digital verification services beyond One Login see the UK Digital Verification Services Trust Framework Guide.

Scope: who and what is covered

Aadhaar: the Act governs enrolment, the Central Identities Data Repository (CIDR), authentication and the "requesting entities" that ask for it. UIDAI says requesting entities include government and private entities. Section 44 extends the offences to conduct abroad by any person where it involves CIDR data.
Singpass: covers residents logging in to government and participating private services, and businesses retrieving government-sourced information and checking customer details in person without photocopying documents.
GOV.UK One Login: covers UK government services that integrate it. Its documentation says to use the low credential level Cl only if the service holds no personal information.
Login.gov: covers US government partner agencies. Login.gov says submitted information is used to create or update the account and to give access to partner agencies, and that operators cannot view or change user information.
EU wallet: covers wallet providers (Member States), relying parties that must register in their Member State of establishment (Art. 5b(1)), and users, whose use is voluntary (Art. 5a(15)).

Key obligations

Obligations on relying parties

Scheme	Consent and notice	Data limits	Assurance choice
Aadhaar	s.8(2)(a): obtain consent before collecting identity information for authentication; s.8(3): disclose the nature of information shared, its uses and alternatives to submitting identity information	s.8(2)(b): use identity information only for submission to CIDR for authentication; s.29(1): core biometric information must not be shared with anyone for any reason	Choose mode (OTP, biometric, multi-factor) by risk; e-KYC only via OTP and/or biometric
Singpass	Not covered by the sources read	Not covered by the sources read	Accept the login methods the integration offers; passkeys are domain-bound to the legitimate Singpass login domain
GOV.UK One Login	Not covered by the sources read	Identity attributes only with `Cl.Cm`	Request `Cl.Cm` (default) unless no personal data; request P1 or P2 identity confidence by need
Login.gov	Not covered by the sources read	Attributes differ for auth-only and identity-proofed accounts	Request IAL via `acr_values`; request `aal/2?phishing_resistant=true` or `?hspd12=true` for stronger authentication
EU wallet	Wallet shows the relying party and data requested; draft rules require the wallet to inform the user when a request exceeds registration	Art. 5b(3): no data beyond the registered intended use	Register intended use and data (Art. 5b(2)(c))

Login.gov service levels in detail

Value	Meaning stated by Login.gov
`urn:acr.login.gov:auth-only`	Email, password and at least one MFA method, no identity verification; AAL1 or AAL2 depending on agency configuration
`urn:acr.login.gov:verified`	Identity verification without facial match; IAL1, not IAL2
`urn:acr.login.gov:verified-facial-match-required`	Facial match for all users, including previously verified ones; IAL2
`urn:acr.login.gov:verified-facial-match-preferred`	New users complete facial match; previously verified users keep existing data; only facial match users meet IAL2
`.../aal/2?phishing_resistant=true`	Security key, face or touch unlock, or PIV/CAC; second factor always required

The default AAL value requires re-authentication with a separate second factor at least every 30 days. For how the NIST levels are defined see the NIST SP 800-63 Digital Identity Guidelines Guide.

Timeline and current status

Date	Event	Source
25 March 2016	Aadhaar Act, 2016 (18 of 2016) effective as listed by UIDAI	UIDAI legal framework
25 July 2019	Aadhaar and Other Laws (Amendment) Act, 2019 (14 of 2019) effective	UIDAI legal framework
10 October 2023	Date to which UIDAI's updated Act text runs	UIDAI legal framework
20 May 2024	Regulation (EU) 2024/1183 adopted	European Commission
30 June 2026	GovTech announces Singpass passkeys beta for iOS; creation opens 1 July 2026; Android later	GovTech
End of 2026	EU wallets described by the Commission as set to launch	European Commission

GOV.UK One Login and Login.gov documentation used here is living developer documentation without a version date; it was read on 27 October 2026.

Enforcement and penalties

Aadhaar: the original 2016 text of Chapter VII sets, among others, these maximum penalties. The 2019 amendment changed parts of this chapter, so confirm current figures against the consolidated Act before relying on them.

Section (2016 text)	Offence	Penalty in the 2016 text
s.34	Impersonation at enrolment with false demographic or biometric information	Up to three years' imprisonment, or fine up to ten thousand rupees, or both
s.37	Intentionally disclosing identity information to unauthorised persons	Up to three years, or fine up to ten thousand rupees (one lakh rupees for a company), or both
s.38	Unauthorised access to or damage to the CIDR	Up to three years and a fine not less than ten lakh rupees
s.40	Requesting entity using identity information in breach of s.8(3)	Up to three years, or fine up to ten thousand rupees (one lakh rupees for a company), or both
s.41	Enrolling agency or requesting entity failing s.3(2) or s.8(3)	Up to one year, or fine up to ten thousand rupees (one lakh rupees for a company), or both
s.42	Other contraventions without a specific penalty	Up to one year, or fine up to twenty-five thousand rupees (one lakh rupees for a company), or both

Section 43 extends liability to persons in charge of a company, section 46 preserves penalties under other laws, and section 47 limits who may bring a complaint to the Authority or a person it authorises.

EU wallet: the Regulation's enforcement of relying parties runs through registration (Art. 5b) and data protection authorities, to which users can report relying parties from the wallet dashboard (Art. 5a(4)(d)). If a wallet scheme is breached, the Member State must suspend it without undue delay (Art. 5e(1)) and withdraw it if not remedied within three months (Art. 5e(2)).

Singpass, GOV.UK One Login and Login.gov: the sources read are service documentation, not penalty regimes. Relying party obligations arise from integration terms and general data protection and computer misuse law, which this map does not cover.

What it means for AI agents and non-human identities

No scheme credential for agents: these schemes identify people. An agent acting for a person should receive a delegated, scoped token from your service after the person authenticates through the scheme, never the person's scheme password, OTP, passkey or wallet PIN.
Phishing-resistant methods block replay: Singpass passkeys only work on the legitimate login domain and Login.gov's phishing-resistant AAL uses cryptographic authenticators, so an agent or script cannot replay captured credentials; design agent flows around this instead of working around it.
Relying party backends are NHIs: the client credentials, signing keys and EU access certificates your service uses to talk to a scheme are machine identities. Inventory them, store them in a secrets manager and rotate them. See the Secrets Management Guide.
Aadhaar consent cannot be automated away: s.8 consent and s.8(3) notice apply per authentication; an agent workflow that triggers Aadhaar authentication must still present consent and alternatives to the person.
Registered intent binds automation: under Art. 5b(3) an EU relying party cannot request data beyond its registration, including when an automated agent builds the request.
Logging: record which agent, acting for which person, under which delegated grant, triggered each scheme interaction. See the OAuth Token Exchange and Delegation Guide.

Compliance steps

Map transactions to required assurance: for each journey decide the identity and authentication level needed, then map it to each scheme's actual signal (for example, IAL2 requires a facial match level on Login.gov).
Verify what you receive: check the returned assurance claim on every login rather than trusting configuration.
Minimise data: request only attributes you need; for EU wallets align the request exactly with the registered intended use.
Implement consent and notice: for Aadhaar, present consent, the nature and use of the information and alternatives before each authentication.
Prefer phishing-resistant options: where a scheme offers them, request them for high-risk actions.
Keep alternatives: EU Art. 5a(15) and Aadhaar s.8(3) both contemplate alternatives; design a non-scheme route for people who cannot use it.
Govern machine credentials: inventory, store and rotate the client secrets, keys and certificates used for each integration.
Re-check status quarterly: documentation and levels change; assign an owner per scheme.

Common failure patterns

Assuming "verified" means IAL2: on Login.gov the plain verified level meets IAL1 only.
Requesting Cl for a service with personal data: GOV.UK One Login documentation says to use it only when no personal information is held.
Storing Aadhaar biometrics or numbers casually: s.29 bars sharing core biometric information for any reason, and storage beyond need multiplies exposure.
Over-asking in wallet requests: requesting attributes outside the registered intended use breaches Art. 5b(3) and triggers user warnings.
Letting automation hold a person's login: scripts or agents using shared scheme credentials defeat assurance and attribution.

Practitioner checklist

List every national scheme you accept and the assurance claim you rely on from each.
Validate returned acr, vector or confidence values on every session.
For Login.gov, use a facial match service level wherever your policy requires IAL2.
For GOV.UK One Login, request Cl.Cm whenever identity attributes or personal data are involved.
For Aadhaar, implement s.8 consent and notice, choose OTP or biometric modes by risk and never retain core biometrics.
For EU wallets, register intended use precisely and request no more.
Give agents delegated tokens, never scheme credentials, and log the delegation chain.
Inventory and rotate the machine credentials for each scheme integration.
Recheck each scheme's documentation and status every quarter.

Standards and references

This guide summarises national digital identity schemes and their rules for identity practitioners and is not legal advice; confirm obligations with your legal and compliance teams and the primary texts. Related NHI Mgmt Group resources: Digital Identity Wallets Guide · Citizen Digital Wallet Safety Guide · Identity Proofing and KYC Guide · NIST SP 800-63A-4 Identity Proofing (IAL) Guide

National Digital ID Schemes Map: Assurance Levels, Rules and Risks Compared