Select any of the 12 Languages.

Mera *Aadhaar#, Meri Pehchaan

Operation Model

This operating model outlines the actors involved in the Aadhaar Authentication ecosystem. The following figure identifies the key actors in the Aadhaar authentication model and depicts the data flow in which the key actors could engage with each other. The brief description of key actors and the scenarios in which they engage with each other are indicated in the figure below .


authentication process


UIDAI, in its “Aadhaar Authentication Framework” document has listed the various authentication types that it offers. For each service that needs to be enabled through Aadhaar authentication, the requesting entities agencies choose an authentication type depending on their business requirements.

Stakeholders in Aadhaar Authentication Ecosystem

Unique Identification Authority of India (UIDAI): UIDAI is an authority established by Central Government to be known as Unique Identification Authority of India that is responsible for the processes of enrolment and authentication and perform such other functions assigned to it under the Aadhaar Act. It is the overall regulator and overseer of the Aadhaar authentication system. It owns and manages the Central Identities Data Repository (CIDR) that contains the personal identity data (PID) of all Aadhaar-holders.

Authentication Service Agency (ASA): ASAs are agencies that have established secured leased line connectivity with the CIDR compliant with UIDAI’s standards and specifications. ASAs offer their UIDAI-compliant network connectivity as a service to Authentication User Agencies and transmit AUAs’ authentication requests to CIDR. Only agencies who have entered into a formal agreement with UIDAI become ASAs in order to send authentication requests to the CIDR; no other entity can directly communicate with CIDR. An ASA could serve several AUAs; and may also offer value added services such as multi-party authentication, authorization and MIS reports to AUAs.An ASA enters into a formal agreement with UIDAI in order to transmit authentication.

Authentication User Agency (AUA): AUAs are agencies that use Aadhaar authentication to enable its services and connect to the CIDR through an Authentication Service Agency (ASA). AUA may also engage more than one ASA. An AUA could also transmit authentication requests from other entities that are “Sub AUAs” under it (see details on Sub AUA below). AUAs can also act as an aggregator offering authentication services to Sub-AUAs below them and may also offer value added services such as multi-party authentication, MIS reports and authorization to their Sub AUAs. An AUA enters into a formal agreement with UIDAI in order to access Aadhaar authentication.

Sub AUA: An agency / entity (any legal entity registered in India) desiring to use Aadhaar authentication to enable its services could access Aadhaar authentication services through an existing AUA. The following are some possible examples:

    • Government of any State/Union Territory could become an AUA and several ministries/departments in the State could access Aadhaar authentication services through the State government as its Sub AUAs.
    • A small entity or business (e.g. a small scale bank) which does not want to directly engage in a formal agreement with UIDAI but still wants to use Aadhaar Authentication, may choose to access Aadhaar services as a Sub AUA of an existing AUA (e.g. a large bank or any aggregator AUA offering AUA services).
    • Several entities could combine under a single AUA for business reasons. Ex. several hotels could access Aadhaar authentication as Sub AUAs of an Hoteliers Association that becomes an AUA.

In all such cases, UIDAI has no direct contractual relationship with the Sub AUA. Only the AUA is contracted to UIDAI and shall be responsible for all authentication requests flowing through it, including those originating from its Sub AUAs. Upon appointment of sub-AUA, an AUA need to share the copy of the agreement between AUA and sub-AUA with UIDAI. AUA is liable to share the details of sub-AUA such as sub-AUA Organisation details, Business scope, code etc.

Requesting Entity: A requesting entity means an agency or person that submits the Aadhaar number and demographic information or biometric information, of an individual to be Central Identities Data Repository (CIDR) for authentication.

Authentication Devices: These are the devices that collect PID (Personal Identity Data) from Aadhaar holders, encrypt the PID block, transmit the authentication packets and receive the authentication results. Examples include PCs, kiosks, handheld devices etc. They are deployed, operated and managed by the AUA/Sub AUA.

Aadhaar number holders: These are individuals who have been issued Aadhaar numbers as per the Aadhaar Act. They seek to authenticate their identity towards gaining access to the services offered by the AUA.

The key actors could engage with each other in multiple ways. For example, an AUA could choose to become its own ASA, an AUA could access Aadhaar authentication services through multiple ASAs for reasons such as business continuity planning, an AUA transmits authentication requests for its own service delivery needs as well as on behalf of multiple Sub AUAs.

More details regarding key actors, their roles, responsibilities and obligations and how they engage with other actors in Aadhaar authentication ecosystem are available in Aadhaar Authentication Operating Model.

Federated Model of Aadhaar Authentication Service

UIDAI offers Aadhaar authentication that can be used alone or in conjunction with AUAs domain/application specific authentication scheme (called "federated authentication"). For example, in federated authentication, a Bank could choose to use an ATM card and fingerprint for authentication of which the ATM card is authenticated within Bank's application whereas the fingerprint is authenticated against data in the CIDR using Aadhaar authentication.

Most current authentication systems can be described as "local" (i.e., pertaining to and/or valid for a few services, situations or entities) and "revocable" (wherein an existing identity factor could be revoked and reissued as a result of expiry, compromise or other valid reasons). Aadhaar authentication system, on the other hand, could be described as "global" (because of its applicability across AUAs and services) and "non-revocable" (because Aadhaar identity factors such as fingerprints and iris scans cannot usually be revoked/replaced).

In the federated authentication model, the global-irrevocable Aadhaar authentication co-exists with and strengthens the local-revocable authentication of AUAs. Such a federated approach would result in authentication systems that are stronger and more reliable than those that are based either only on global-irrevocable model or only on local-revocable model.

While the federated model does not mandate the existence or use of an AUA’s own authentication (if an AUA/ Sub-AUA so wishes, they could use only Aadhaar authentication by itself), AUAs/ Sub-AUA are encouraged to use Aadhaar authentication in conjunction with their existing authentication to render the overall authentication system stronger and more reliable.

For more information on Network Exception Handling, please refer “Buffer Authentication” section on Aadhaar Authentication Operating Model For Biometric Exception Handling, please refer “Biometric Exception Handling” section on Aadhaar Authentication Framework.

Aadhaar Authentication Offerings

The below diagram depicts the various Aadhaar Authentication offerings of UIDAI

Type 1 Authentication: Through this offering, the service delivery agencies can use Aadhaar Authentication system for establishing identity of an Aadhaar number holder by matching his/her Aadhaar number and his/her demographic attributes (name, gender, date of birth, etc).

Type 2 Authentication: This offering allows service delivery agencies to authenticate Aadhaar number holders through One-Time-Password (OTP) delivered to their mobile number and/or email address that is registered with UIDAI and available in CIDR.

Type 3 Authentication: Through this offering, service delivery agencies can authenticate Aadhaar number holders using one of the biometric modalities, either iris or fingerprint.

Type 4 Authentication: This is a 2-factor authentication offering with OTP as one factor and biometrics (either iris or fingerprint) as the second factor for authenticating residents.

Type 5 Authentication: This offering allows service delivery agencies to use OTP, fingerprint & iris together for authenticating residents.


The Aadhaar number needs to be submitted in all forms of authentication so that this operation is reduced to a 1:1 match. Aadhaar number itself is not an authentication factor. Type 1 authentication may be combined with any other Aadhaar authentication offering.

Service delivery agencies should select the appropriate authentication type based on their business requirements. They would need to balance out the resident convenience and service delivery risk before finalizing the authentication offering.