Monday, August 31, 2026

Aadhaar Data Vault Compliance: UIDAI Circular 14

UIDAI Circular No. 14 of 2025 resets how banks, NBFCs and fintechs must store Aadhaar numbers and eKYC data.

Aadhaar Data Vault Compliance in 2026: What UIDAI Circular 14 of 2025 Changes for Banks and NBFCs

Most Aadhaar Data Vaults running inside Indian banks and NBFCs today were built against a circular that no longer exists. UIDAI withdrew the 2017 ADV circular in November 2025 and replaced it with a substantially stricter framework — one that names permitted hosting environments, mandates a specific HSM certification level, bans a reference-key technique many teams quietly relied on, and adds high-availability and audit obligations that were previously left to the entity's discretion.

For a KUA, AUA or Sub-AUA, this is not a documentation refresh. If your Aadhaar Data Vault sits on a general-purpose private cloud, if your reference keys are derived from a hash, or if your HSM was procured without checking its FIPS level, you have a live compliance gap that will surface at your next UIDAI audit. This article breaks down exactly what changed, what must sit inside the vault versus outside it, and how to run a practical gap assessment.

Short answer: what changed?

UIDAI Circular No. 14 of 2025 (dated 4 November 2025) supersedes the 2017 Aadhaar Data Vault circular (11020/205/2017) and Circular 8 of 2025. Under the new rules, a requesting entity must:

Host its ADV only on-premises, on a MeitY-empanelled Government Community Cloud, or via ADV as-a-service from an eligible provider
Encrypt Aadhaar data using AES-256 or higher, with keys held in a FIPS 140-2 Level 3 or higher HSM
Stop using hashes of Aadhaar numbers as reference keys
Maintain a single logical ADV instance per entity, in an isolated network zone, with HA/DR and full access logging
Obtain an annual SOC 2 Type II audit by a CERT-In empanelled auditor where the ADV runs on GCC or as-a-service

What is an Aadhaar Data Vault?

An Aadhaar Data Vault (ADV) is a separate, encrypted database that is the only place inside a requesting entity's infrastructure where full Aadhaar numbers and connected Aadhaar data may be stored. Every other system in the organisation — core banking, LOS, CRM, collections, data warehouse — must reference a customer using a reference key instead of the Aadhaar number itself.

The mapping between reference key and Aadhaar number lives only in the vault. That single design decision is what shrinks the "Aadhaar footprint" across an enterprise: even if a business database is compromised, the attacker gets tokens, not identities.

Per the UIDAI ADV/HSM FAQs updated on 3 November 2025, "Aadhaar related data" means the Aadhaar number together with demographic details — name, date of birth, gender, address, photo, email ID and mobile number.

Circular 14 of 2025 vs the 2017 circular: what actually changed

The 2017 circular established the principle. Circular 14 of 2025 supplies the engineering specification. The differences matter because they turn previously acceptable architectures into non-compliant ones.

Requirement	2017 circular	Circular 14 of 2025
Hosting location	Any isolated system inside the entity's infrastructure	Only on-premises, MeitY-empanelled GCC cloud, or ADV as-a-service
Encryption standard	Not specified; entity's choice	AES-256 or higher, or as per the latest Authentication API specification
HSM certification	HSM mandated; no level prescribed	FIPS 140-2 Level 3 certified or higher
Reference key method	Any non-reversible scheme	Non-reversible, and hashing of Aadhaar numbers is expressly not allowed
Availability	Not addressed	HA/DR at the same security level, with dual redundant connectivity to ASAs
Third-party assurance	Not addressed	Annual SOC 2 Type II audit by a CERT-In empanelled auditor for GCC / as-a-service deployments
Data deletion	Not addressed	Vault must support secure deletion and update in line with the entity's retention policy

The full text is available in the UIDAI Circular No. 14 of 2025 (PDF), published under the authority's authentication documents library.

What must go inside the vault — and what may stay outside

This is the question most integration teams get wrong, and the November 2025 FAQs finally answer it cleanly. The rule is not "encrypt everything Aadhaar-adjacent". It is narrower and more precise.

Data element	Where it may be stored
Full Aadhaar number	ADV only
eKYC XML containing the Aadhaar number	ADV only
Aadhaar PDF received in the eKYC response	ADV only, encrypted
Demographic details from eKYC (name, DoB, gender, address, photo)	May be stored locally if the Aadhaar number and UID Token are not stored or mapped with them, with encryption, obfuscation or masking
UID Token alone	May be stored locally after mapping with the reference key, with reasonable security safeguards
Aadhaar number keyed in by the customer in your auth/eKYC front-end	Prohibited from storage in any form

That last row deserves emphasis. Data placed in the ADV must have come back from UIDAI as part of an eKYC response. A requesting entity cannot capture the Aadhaar number a customer types into an onboarding screen and persist it — not in the vault, not anywhere. Many mobile onboarding journeys log this input for debugging or retry purposes without realising it is a direct violation.

The three permitted hosting models

Circular 14 of 2025 closes the door on ad-hoc hosting. An ADV may run in exactly three places:

On-premises — within the secure premises of the requesting entity or its technical service provider.
MeitY-empanelled Government Community Cloud (GCC) — entities must refer to the current empanelment list maintained by the Ministry of Electronics and Information Technology, since the list is updated periodically.
ADV as-a-service — provided by an eligible entity.

On who qualifies to offer ADV as-a-service, the FAQs identify three categories: existing global AUAs/KUAs that have implemented a fully compliant vault, cloud service providers offering ADV as a service on a GCC-empanelled cloud, and technical service providers delivering on-premises ADV services.

Where the GCC or as-a-service route is chosen, the requesting entity — not the provider — is accountable for ensuring the annual SOC 2 Type II audit of the cloud infrastructure is carried out by a CERT-In empanelled auditor authorised for cloud security audits. Vendor assurance does not transfer liability.

Reference keys: the change that breaks existing implementations

The most consequential technical change is a single sentence: hashing of Aadhaar numbers is not permitted as a reference key generation method.

This is a meaningful restriction because a hash of a 12-digit number is trivially reversible by brute force. The Aadhaar number space is small enough that any commodity machine can pre-compute the full rainbow table for an unsalted hash in minutes. Teams that chose SHA-256 in 2018 because it looked cryptographically respectable now hold a vault whose tokens can be reversed offline.

UIDAI's stated test remains outcome-based rather than algorithm-based: recovery of the original Aadhaar number must not be computationally feasible from knowledge of one reference key or a set of reference keys. Approaches that satisfy this include:

Randomly generated UUIDs — no mathematical relationship to the source value, so reversal is infeasible by construction
Existing internal unique identifiers such as a customer ID, provided they map uniquely and do not leak the Aadhaar number (the FAQs permit this, while cautioning entities to consider the wider implications of reusing business identifiers)

The FAQs also confirm two practical points that often come up in bank architecture reviews: multiple reference keys may be generated for a single Aadhaar number where a genuine business case requires it, and Aadhaar numbers already stored encrypted across multiple legacy databases must still be replaced with reference keys. Encryption at rest in a business database is not a substitute for tokenisation.

HSM requirements for REs and ASAs

Hardware Security Modules are mandatory for requesting entities and Authentication Service Agencies, covering signing of the authentication request, encryption and decryption of ADV data, and decryption of eKYC response data. Under the new circular the HSM must be:

FIPS 140-2 Level 3 certified or higher
Logically isolated for each requesting entity or ASA independently
Capable of key generation, secure key storage, and multifactor, multirole access control with audit logging

Private keys used for signing authentication XML and decrypting eKYC data must reside only within the HSM and never leave it.

Sub-AUA and Sub-KUA obligations

Sub-AUAs and Sub-KUAs may either implement their own vault or consume their parent AUA's or KUA's ADV as-a-service, subject to Identity and Access Management controls and logical segregation. Two constraints are worth flagging to any bank acting as a sponsor:

An AUA or KUA cannot access data in the ADV of its Sub-AUAs or Sub-KUAs.
Where a shared HSM is used, the parent must provide a separate logical partition per Sub-AUA/Sub-KUA with dedicated cryptographic keys and IP whitelisting.

Regardless of the model chosen, the Sub-AUA or Sub-KUA remains fully responsible for its own compliance with the Aadhaar Act, 2016 and associated regulations. Outsourcing the infrastructure does not outsource the obligation.

Where the DPDP framework intersects

The Digital Personal Data Protection Rules, 2025 were notified in November 2025, with core operational obligations taking effect eighteen months from notification — mid-2027 for most requirements. The Rules do not replace the ADV mandate; they layer additional duties on top of it.

The overlap is direct. Rule 6 prescribes reasonable security safeguards including encryption or masking of personal data, role-based access control, and logging and monitoring of data access with logs retained for at least one year. A correctly implemented Aadhaar Data Vault already delivers most of this for Aadhaar data specifically. The gap for most BFSI organisations lies in extending equivalent controls to the demographic and UID Token data they are permitted to store outside the vault — which the FAQs explicitly condition on "reasonable security safeguards", the same language the DPDP framework uses.

The reference material published by MeitY on the DPDP Rules, 2025 is the authoritative starting point for that mapping exercise.

Common gaps in existing BFSI deployments

Across vaults built to the 2017 specification, the same findings tend to recur:

Reference keys derived from a hash of the Aadhaar number
The vault running on a private or public cloud that is not MeitY GCC-empanelled
HSM in place, but procured without confirming FIPS 140-2 Level 3 certification
No documented HA/DR posture for the vault, or a DR site with weaker controls than production
Aadhaar numbers still present, encrypted, in legacy tables that were never migrated to reference keys
Customer-entered Aadhaar numbers captured in application logs, session stores or error-tracking tools
No secure deletion capability, making retention-policy enforcement impossible
Vault access permitted from a general application network zone rather than a highly restricted, isolated one

A practical migration path

Inventory Aadhaar data. Identify every table, file store, log sink and backup that contains an Aadhaar number, encrypted or otherwise.
Test your reference keys. If they are derived from the Aadhaar number by any deterministic transformation, plan a key regeneration and re-mapping exercise.
Confirm the hosting model. Verify GCC empanelment status against MeitY's current list, or confirm on-premises placement in an isolated network zone.
Validate the HSM. Obtain the certificate confirming FIPS 140-2 Level 3 or higher, and confirm logical isolation and multirole access control.
Close the ingestion gap. Ensure customer-supplied Aadhaar input is never persisted anywhere in the authentication journey.
Build HA/DR. Extend production-grade controls to the DR site and establish dual redundant connectivity to your ASA.
Instrument access. Route all vault access through authenticated applications with authorisation checks and complete logging.
Schedule assurance. Where hosting is on GCC or as-a-service, commission the annual SOC 2 Type II audit through a CERT-In empanelled auditor.

Challenges worth planning for

Re-tokenisation is the hard part. Replacing reference keys across a production estate means coordinated updates to every downstream system holding the old key, usually with a dual-key transition period. For a bank with a decade of Aadhaar-linked records, this is a data migration programme, not a configuration change.

The second challenge is organisational. Vault compliance sits across infrastructure, security, application engineering and compliance functions, and the failure mode is that each assumes another owns it. Assigning single-point accountability early prevents the audit-eve scramble.

Where FinaVault fits

FinaVault, Finahub's Aadhaar Data Vault solution, is a turnkey package built for KUAs, AUAs and Sub-AUAs that need an encrypted vault for Aadhaar numbers and eKYC data. It exposes REST APIs for integration with existing services, supports database encryption, and integrates with leading HSM models for key protection. It can be deployed on cloud or on-premises, and forms part of Finahub's broader Aadhaar eKYC solution already in use at banks and NBFCs registered as KUA or AUA.

Two design decisions in FinaVault map cleanly onto the 2025 requirements. Reference keys are generated using a UUID scheme rather than derived from the Aadhaar number, which sits on the correct side of the hashing prohibition. And the product ships with an administration console offering role-based user access plus searchable access logs covering all API activity — the access control, logging and monitoring expectations the circular now sets out explicitly.

Some Circular 14 requirements are deployment-dependent rather than product-dependent, and any honest evaluation should treat them as joint work between vendor and institution: your choice of HSM and its FIPS level, your hosting environment and its empanelment status, your HA/DR topology and ASA connectivity, and your SOC 2 Type II audit arrangements where a cloud or as-a-service model is used. Finahub's team works through these as part of implementation rather than leaving them as assumptions.

For related work on identity assurance in onboarding journeys, see FinaGuardAI multifactor authentication with deepfake detection, and the Finahub blog for ongoing coverage of Aadhaar ecosystem changes.

Frequently asked questions

What is an Aadhaar Data Vault?

An Aadhaar Data Vault is a separate, encrypted database that is the only permitted storage location for full Aadhaar numbers and connected Aadhaar data within a requesting entity's infrastructure. All other systems must use a reference key instead, with the key-to-Aadhaar mapping held solely in the vault.

Which UIDAI circular currently governs Aadhaar Data Vaults?

UIDAI Circular No. 14 of 2025, dated 4 November 2025. It supersedes the 2017 ADV circular (11020/205/2017) and Circular 8 of 2025, and is read in continuation of the 2017 HSM circular (11020/204/2017).

Who must implement an Aadhaar Data Vault?

All requesting entities storing a full Aadhaar number along with connected Aadhaar data under the Aadhaar Act, 2016 and associated regulations. This covers AUAs, KUAs, Sub-AUAs and Sub-KUAs. Entities that only perform offline verification without availing UIDAI authentication have been clarified as outside the ADV requirement.

Can a hash of the Aadhaar number be used as a reference key?

No. UIDAI expressly states that hashing of Aadhaar numbers is not permitted for reference key generation. The chosen method must make recovery of the original Aadhaar number computationally infeasible from one reference key or a set of them.

Where can an Aadhaar Data Vault be hosted?

In one of three environments only: on-premises within the secure premises of the requesting entity or its technical service provider; on a MeitY-empanelled Government Community Cloud; or as ADV as-a-service from an eligible provider. GCC and as-a-service deployments require an annual SOC 2 Type II audit by a CERT-In empanelled auditor.

What HSM specification does UIDAI require?

The HSM must be FIPS 140-2 Level 3 certified or higher, logically isolated for each requesting entity or ASA, and must support key generation, secure key storage, and multifactor, multirole access control with audit logging.

Can demographic data or UID Tokens be stored outside the vault?

Yes, with conditions. Demographic details from eKYC may be stored locally provided the Aadhaar number and UID Token are not stored or mapped alongside them, with encryption, obfuscation or masking applied. A UID Token on its own may be stored locally after mapping with the reference key, subject to reasonable security safeguards. The Aadhaar PDF from an eKYC response must remain encrypted inside the vault.

Does the DPDP framework replace the Aadhaar Data Vault requirement?

No. The DPDP Act, 2023 and the DPDP Rules, 2025 operate alongside UIDAI's requirements and add obligations around consent, breach notification, retention and data principal rights. A compliant vault addresses much of the security safeguard expectation for Aadhaar data, but not the wider DPDP programme.

Conclusion

Circular 14 of 2025 converts Aadhaar Data Vault compliance from a design principle into a testable specification. Hosting environment, encryption strength, HSM certification level, reference key method, availability posture and audit cadence are now each independently verifiable — which means each is independently failable at audit.

For banks and NBFCs, the practical priority is to establish where the current implementation diverges from the new text before an auditor does it for you. Reference key methodology and hosting empanelment are the two findings most likely to require a multi-quarter remediation programme, so they belong at the front of the queue.

Assess your Aadhaar Data Vault against Circular 14 of 2025

Finahub has implemented Aadhaar infrastructure for banks, NBFCs and financial institutions registered as AUA and KUA. If you need a review of your existing vault, or are planning a compliant implementation from scratch, our team can walk through the specific gaps in your architecture.

Talk to the FinaVault team