The single most common misconception in Indian product onboarding is that Aadhaar verification is a service you sign up for. It is not. Online Aadhaar authentication is restricted to entities licensed as Authentication User Agencies, Know Your Customer User Agencies or sub-KUAs under the UIDAI framework, and that licensing is generally available to regulated entities rather than to private companies at large. A software product that is not itself a bank, NBFC or similarly notified entity cannot independently authenticate against the Aadhaar database, however many vendors offer to arrange it.
What is available more broadly is offline verification, and it is genuinely useful. UIDAI supports several offline modes: the secure QR code printed on Aadhaar, the paperless eKYC XML that a resident downloads and shares, the e-Aadhaar PDF, and W3C verifiable credentials. Each is cryptographically signed by UIDAI, which means you can verify authenticity without querying UIDAI at all. Organisations performing offline verification register as offline verification seeking entities, and the UIDAI offline verification handbook sets out the mechanics.
The design difference between online and offline is not cosmetic. Online authentication is a real-time check against the authority. Offline verification is a check on a document the user supplies, protected by a share code the user sets. That means the user journey involves them fetching and providing something, rather than entering a number and receiving an OTP. Products designed around the smoother online flow and then discovered to be ineligible for it end up redesigning the most sensitive screen in the funnel late, under pressure.
There is a further route through DigiLocker, which lets a user share government-issued documents from their own locker with your application under their control. For many use cases where the requirement is identity assurance rather than regulated KYC, this is the appropriate mechanism and it avoids the Aadhaar licensing question entirely. It also carries a better consent story, which matters increasingly as the DPDP framework takes hold.
Whatever route you use, data minimisation should drive the design rather than follow it. Store the assurance, not the artefact: a verified flag, the verification method, a timestamp, and a reference — rather than a full Aadhaar number, a raw XML payload or an unmasked image sitting in object storage for the next five years. Masking obligations exist, encryption is expected, and the practical risk of holding a large store of Aadhaar-linked records considerably exceeds the operational convenience of doing so.
The sequence that avoids expensive surprises is straightforward. Establish first whether your client is an entity that can perform online authentication. If yes, design around it. If no — and for most product companies the answer is no — design around offline verification or DigiLocker from the beginning, and tell the client plainly that the smoother flow they have seen in a banking app is not one they are permitted to build.
