Aadhaar Act masking requirement: why not just DPDP Act?

A clinic asks a new patient for a copy of their Aadhaar card 'for the file,' the same way it might ask for a PAN card or a previous prescription. It's a habit carried over from years of Aadhaar functioning as India's default proof-of-identity document, and it treats the Aadhaar number as just another field of personal data — the same category as a phone number or a date of birth.

It isn't. The Aadhaar (Targeted Delivery of Financial and Other Subsidies, Benefits and Services) Act, 2016 governs the Aadhaar number specifically, separately from the general personal-data rules the DPDP Act sets for everything else, and treating the two as interchangeable is exactly the mistake that leads a business to collect and keep something it likely never needed to.

Section 29 of the Aadhaar Act restricts how identity information obtained through the Aadhaar system can be used. Core biometric information — fingerprints and iris scans — cannot be shared for any reason. Identity information other than that can only be shared in accordance with the Act's own provisions and specified regulations, and critically, information collected from an individual for authentication or offline verification cannot be used or disclosed for any purpose beyond what was specifically communicated to that individual in writing at the time it was collected.

The Act also separately bars publicly posting, publishing or displaying an Aadhaar number, demographic information or photograph collected under it, except where specific regulations allow it. None of this is phrased as advice; it is a restriction with its own penalty provisions under Sections 29 and 37 of the Act, sitting apart from whatever the DPDP Act separately requires for personal data generally.

The reason a private business today generally cannot make Aadhaar mandatory as a condition of service traces to the Supreme Court's September 2018 judgment in Justice K.S. Puttaswamy (Retd.) v. Union of India, which struck down Section 57 of the original Aadhaar Act — the provision that had allowed 'any body corporate or person,' not just the state, to require Aadhaar authentication. The Court's reasoning was that requiring Aadhaar as a condition for a private contract did not meet the standard the Court itself had set for justifying an intrusion into the right to privacy, because a private contractual requirement is not the kind of law that standard demands.

The practical effect was to end the era in which telecom operators and banks could compel Aadhaar linking as a condition of service, while leaving Aadhaar's role in government welfare and subsidy delivery — the purpose the Act was originally built for — intact. A business today asking whether it may require a customer to produce Aadhaar as a precondition of service is asking a question this judgment already answered for most private, non-welfare contexts: generally, no, not as a mandatory condition — though how this plays out for a specific regulated sector with its own separate legal basis for identity verification is a narrower question worth checking with a professional rather than assuming this general rule settles every case.

Masking is a specific, defined format, not a vague idea of partially hiding a number. According to UIDAI's own published explanation, a masked Aadhaar replaces the first eight digits of the twelve-digit number with 'xxxx-xxxx,' leaving only the last four digits visible.

This format exists so a document or a database can retain enough of the number to be useful for limited verification purposes — confirming, for instance, that the last four digits on file match what a person is presenting — without holding or displaying the complete number that would let it be used, on its own, for unauthorised authentication elsewhere. Masking is not encryption and needs no special technical infrastructure to use; it is a display and storage convention, and its entire value depends on a business actually choosing to store the masked version rather than the full number in the first place.

This is the point worth sitting with: for the overwhelming majority of everyday business purposes — confirming someone's identity matches their name, satisfying a KYC-style checklist item, keeping a copy 'on file' out of habit — the last four digits are sufficient, and the first eight digits add no value to the business while adding real exposure if that record is ever breached, misfiled, or accessed by someone without a legitimate reason to see it.

A business holding full, unmasked Aadhaar numbers across hundreds of customer records is not doing something the law generically forbids in every circumstance, but it is holding data whose risk is disproportionate to any benefit the full number actually provides for most of those use cases — Section 29's restriction on using identity information beyond its stated purpose makes that a genuine legal exposure, not just a hygiene concern. Choosing to collect and store only the masked version, or a scanned copy kept access-restricted rather than pasted into a general customer database, is a deliberate design decision available to almost any business — not a technical requirement that most businesses happen to fall short of by default.

A small business handling identity documents — a clinic, a coworking space checking visitor identity, a lending or gig-work platform doing informal verification — is generally better served asking three questions before it asks for an Aadhaar copy at all: does this specific step actually require Aadhaar rather than any other proof of identity; if it does, does it need the full number or would the last four digits, via a masked copy, satisfy the actual purpose; and if the full number genuinely is needed for a specific, legally grounded reason, is it stored somewhere access-restricted rather than in a general file any staff member can open.

None of this substitutes for sector-specific legal advice — a bank, an NBFC, or a business operating under a regulator with its own specific Aadhaar-related KYC rules is working under a different, more detailed set of requirements than the general default described here, and should check those directly rather than relying on this article's general framing.