An Aadhaar Data Vault is centralised, restricted-access storage for every Aadhaar number an entity has collected, held inside its own secure infrastructure. The requirement originated in UIDAI circular 11020-205/2017 of 25 July 2017, was revised by Circular No. 8 of 2025 on 18 July 2025, and the accompanying FAQs were updated on 3 November 2025. If you build for anyone handling Aadhaar, the 2025 revision is the version to work from.
The single most useful clarification is about scope, because a great many product teams assume the obligation applies to them when it does not. The vault requirement falls on Requesting Entities — Authentication User Agencies, e-KYC User Agencies, and their sub-AUAs and sub-KUAs. Entities that collect Aadhaar purely for offline verification, without using UIDAI's authentication facilities, are exempt. Since most private companies cannot perform online authentication anyway and use offline verification or DigiLocker, the vault is frequently not their problem — and establishing that early avoids building infrastructure nobody required.
Where it does apply, the central technical requirement is the reference key. Every Aadhaar number must be referenced by an additional key that does not computationally permit reverse engineering or guessing of the number itself, with the mapping held in the vault. In practice that means the Aadhaar number appears in exactly one place in your estate, and every other table, log, report and downstream system carries only the reference key. That is an architectural decision affecting every schema, not a storage setting.
Encryption keys must live in hardware security modules not shared with any other entity, and the 2025 revision specifies AES-256 or above. It also introduced a useful accommodation: sub-AUAs and sub-KUAs may share the AUA or KUA's HSM provided there is logical isolation and dedicated cryptographic keys per entity. For a smaller entity operating under a larger one's licence, that materially reduces the cost of compliance, and it is worth asking your sponsoring AUA about rather than procuring your own.
Two further points from the 2025 clarifications matter for design. Data in the vault must originate from UIDAI post-authentication only — you cannot populate a vault from Aadhaar numbers typed in by customers or imported from an old system. And the scope of connected data is now explicitly defined, which means demographic details returned alongside the number have their own handling rules rather than being treated as ordinary customer data.
The practical sequence, if you are scoping work for a client in this space: establish first whether they are a Requesting Entity at all, because that single answer removes or creates most of the project. If they are, design the reference key into the data model before writing anything, since retrofitting it means touching every table that ever held an Aadhaar number — including the analytics warehouse and the log files, which is where these projects overrun.
