UIDAI Aadhaar Compliance: The Complete VAPT and Cybersecurity Guide for AUAs, KUAs, and Sub-AUAs

One audit finding can put your Aadhaar authentication operations at risk. Not because someone broke in, but because you couldn’t prove that your systems met the required controls. That’s one of the less obvious challenges of UIDAI Aadhaar compliance. It’s not enough to have security controls in place. You also need evidence that they work.

Many teams start paying attention only when the audit window is almost shut. This guide is for those who’d rather understand the requirements now.

What Is UIDAI Aadhaar Compliance?

In simple words, it means meeting the security controls UIDAI has set for organisations allowed to use Aadhaar authentication or e-KYC services.

It’s not a certificate you buy once and frame on a wall. It’s a continuing duty. Three main requirements come together here.

• Rules under the Aadhaar Act
• Technical specifications for handling Aadhaar data
• Information security audits at the intervals and under the conditions UIDAI requires

Who Has to Comply

The main entity types covered in this guide are:

• Authentication User Agency (AUA) – an organisation approved to use UIDAI’s Aadhaar authentication services and send authentication requests through an Authentication Service Agency (ASA).
• KYC User Agency (KUA) – an AUA that can also receive demographic details and a photograph through e-KYC.
• Sub-AUA and Sub-KUA – organisations appointed by an AUA or KUA to use Aadhaar authentication or e-KYC services.

The parent AUA or KUA must follow UIDAI’s current approval and onboarding requirements before appointing a Sub-AUA or Sub-KUA. The parent also needs to oversee the security controls that apply to its downstream partners. Sub-AUAs and Sub-KUAs remain responsible for meeting the Aadhaar requirements that apply to them.

Why Cybersecurity Audits Matter and Where VAPT Fits

An Aadhaar number is not just another ID. Aadhaar authentication checks information such as demographic details or biometrics against UIDAI’s records. If an organisation exposes Aadhaar numbers or related data, it can put people at risk of identity misuse.

That’s why UIDAI requires information security audits covering the controls that apply to the requesting entity. Audit reports must be submitted to UIDAI as required. VAPT can help test whether technical controls work as intended, but its scope should match the systems and requirements being assessed.

AUA, KUA, Sub-AUA, and Sub-KUA: Who Needs What?

Each entity has a different role, so its security responsibilities differ too.

Authentication User Agency

An AUA is the entry point. It connects to an Authentication Service Agency, which then connects to UIDAI’s Central Identities Data Repository. Its job is to send authentication requests in the format UIDAI specifies and handle the response responsibly.

What does an AUA need for compliance?

• A designated security function
• A documented application architecture
• A clear map of how Aadhaar data moves through its systems
• Information security risk assessments and the security checks required by UIDAI
• An information security audit at the frequency and under the conditions UIDAI requires

e-KYC User Agency

A KUA can receive a resident’s demographic details and photograph through e-KYC in an encrypted, digitally signed response.

The extra access comes with extra security responsibilities. The KUA must make sure that

• The Aadhaar number and e-KYC data containing it are stored only in the Aadhaar Data Vault (ADV). Demographic details may be stored separately only under UIDAI’s conditions and with the required safeguards.
• Data is protected during transmission and storage
• Only authorised systems and people can access it
• Its e-KYC workflows and related interfaces are tested for security weaknesses

Sub-AUA and Sub-KUA

These entities work under the arrangement with a parent AUA or KUA. UIDAI requires the parent to oversee their compliance rather than simply hand over access and leave them to manage it alone.

Sub-AUAs and Sub-KUAs must meet the UIDAI requirements that apply to their role and arrangement. The parent AUA or KUA must oversee the arrangement, while each Sub-AUA or Sub-KUA remains responsible for meeting its applicable security and compliance obligations. Check the current Sub-AUA/Sub-KUA checklist and onboarding terms for the specific requirements.

Compliance Responsibilities at a Glance

UIDAI Cybersecurity and VAPT Requirements

This is where the compliance work becomes practical. The requirements are specific, and auditors look for evidence that the required controls are in place.

Annual Information Security Audit

UIDAI sets information security audit requirements for AUAs and KUAs, including the required frequency and any additional audits. The auditor must meet UIDAI’s applicable eligibility requirements. The audit should cover the controls that apply to the entity, and the report must be submitted to UIDAI as required.

Who Can Conduct the Audit?

Not every security firm is eligible to conduct the audit. The auditor must meet UIDAI’s stated requirements. Check the latest UIDAI checklist for the accepted auditor categories before appointing one.

Application Security Assessment: Code Review and Runtime Testing

The authentication application handles requests and responses involving Aadhaar data. Its security needs to be checked at the code level and while the application is running.

• Source code review checks the application for insecure coding patterns and hardcoded secrets. Third-party components should also be checked for known vulnerabilities.
• Dynamic testing checks the running application for weaknesses such as injection flaws, broken authentication, and incorrect security settings.

Check the latest UIDAI checklist for the application security checks required for your entity type. Keep evidence of the tests performed and the findings.

VAPT Scope: Applications, APIs, Network, and Infrastructure

VAPT for UIDAI Aadhaar compliance isn’t limited to a web portal. The scope may include:

• The network that carries authentication traffic
• The infrastructure hosting the application
• The application itself
• The APIs used to exchange authentication requests and responses with the Authentication Service Agency

UIDAI’s checklist sets out the testing requirements that apply to each entity type. Check UIDAI’s current Comprehensive Compliance Checklist for Requesting Entities, the applicable entity-specific requirements, and any relevant circulars to confirm the security tests, audit scope, and frequency required for your organisation.

Audit Evidence, Remediation, and Retesting

Finding a vulnerability is only the first step. The organisation must track the issue and take corrective action under the applicable requirements.

The process includes

• Record each vulnerability and assess its risk.
• Track corrective action and apply fixes.
• Retest to check whether the fix has resolved the vulnerability.
• Record the findings and corrective action for the audit.

Evidence should record what was found, what corrective action was taken, and whether follow-up testing confirmed the fix. If an issue remains open, its status and planned action should be documented.

Aadhaar Data Vault Compliance

The Aadhaar Data Vault needs special care because UIDAI sets specific rules for storing Aadhaar numbers and connected data.

What Is an Aadhaar Data Vault?

An Aadhaar Data Vault (ADV) is a separate, secure system for storing Aadhaar numbers and connected Aadhaar data. UIDAI requires requesting entities to keep this data in the ADV rather than in other application databases. Sub-AUAs and Sub-KUAs may use their own ADV or their parent AUA’s/KUA’s ADV as a service, provided UIDAI’s access-control and logical-segregation requirements are met.

Two rules are especially important.

• Full Aadhaar numbers and connected Aadhaar data, including e-KYC XML containing the Aadhaar number, must be stored only in the ADV.
• Each Aadhaar number must be referred to by a separate identifier called a reference key

The mapping between the reference key and the Aadhaar number stays inside the vault. The rest of the application uses the reference key instead of storing the full Aadhaar number in multiple places.

What Data Must Be Stored in the ADV?

The vault holds the full Aadhaar number and connected Aadhaar data. This includes e-KYC XML files containing the Aadhaar number and demographic details received in an e-KYC response.

The full Aadhaar number and e-KYC data containing it must be stored only in the ADV. UIDAI permits demographic details and UID Tokens to be stored separately under specific conditions, provided the Aadhaar number is not stored with them and the required safeguards are in place. Separately stored demographic details must be protected through measures such as encryption, masking or obfuscation.

UIDAI prohibits requesting entities from storing the Aadhaar number or related data supplied by a resident as input to an authentication or e-KYC request.

Reference Keys and Replacing Aadhaar Numbers

A reference key is a stand-in identifier the application uses in place of the Aadhaar number.

The vault holds the mapping between the reference key and the Aadhaar number. Access to that mapping is tightly controlled, so other systems can use the reference key instead of storing the full Aadhaar number.

During an ADV audit, the organisation needs to show that the full Aadhaar number is kept in the vault and that access to the vault is properly controlled.

Encryption and HSM Requirements

Aadhaar numbers and connected data stored in the ADV must be protected by encryption. UIDAI requires a Hardware Security Module (HSM) for specified cryptographic operations, including signing authentication requests and encrypting or decrypting ADV data. Private keys used to digitally sign authentication XML and decrypt e-KYC data must remain inside the HSM.

The HSM must be FIPS 140-2 Level 3 certified or higher and logically isolated for each requesting entity, with dedicated cryptographic keys, multi-factor and multi-role access controls, and audit logging. Encryption for Aadhaar numbers and connected data must follow UIDAI’s current specifications for Authentication and e-KYC APIs.

Access Control, Logging, and Network Isolation

The vault must sit in a highly restricted network zone, isolated from untrusted zones and other internal network zones. Only trusted communication channels should be used, with secure APIs or microservices controlling access to the vault.

Other security measures include

• Strong access controls
• Multi-factor authentication for privileged access
• Audit logging for access and cryptographic operations
• Monitoring for unusual or unauthorised activity

ADV on Cloud Requirements

UIDAI’s hosting requirements depend on how the ADV is deployed.

• The ADV may be hosted on-premises, on a Government Community Cloud platform empanelled by the Ministry of Electronics and Information Technology (MeitY), or through an eligible ADV-as-a-service arrangement
• For Government Community Cloud hosting or ADV-as-a-service, the requesting entity must ensure an annual SOC 2 Type II audit of the cloud infrastructure by a CERT-In-empanelled audit agency authorised to conduct cloud security audits
• The organisation must review any non-compliant or qualified controls reported in the SOC 2 Type II report and take the required action

e-KYC API Penetration Testing

The e-KYC API carries e-KYC requests and responses between the KUA and UIDAI’s systems. If the API has security weaknesses, an attacker may be able to misuse requests or access data they should not see.

What to Test in an e-KYC API

API testing should verify the controls required by UIDAI and check for weaknesses that could expose data or allow unauthorised access. Depending on the application, tests may include:

• Compliance with UIDAI’s authentication and e-KYC API specifications
• Whether request and response structures can be tampered with
• Whether any sensitive data travels in the clear

Authentication, Authorisation, and Session Security

The API must enforce authentication and authorisation correctly. Testers look for:

• Broken access control
• Weak session handling
• Ways to bypass the intended flow

Test whether session tokens and API keys can be stolen or reused. Check the security of API keys and other credentials wherever they are used.

Data Exposure and Encryption Testing

Testing should confirm that:

• Responses are encrypted in transit using current TLS configurations
• Sensitive fields don’t leak through error messages or logs
• The KUA’s systems don’t store e-KYC data outside permitted boundaries

UIDAI requires the PID block to be encrypted at capture. A source code review can help check whether the authentication application follows this requirement.

Logging, Monitoring, and Audit Trails

Requesting entities and ASAs must maintain authentication logs in accordance with the requirements that apply to their roles. These rules restrict the information that may be recorded, so the permitted contents of each entity’s logs must be checked separately. For requesting entities, Regulation 18 prohibits retaining PID information and sets out the authentication-request and response details that may be logged.

Under the Aadhaar (Authentication and Offline Verification) Regulations, 2021, entities must generally retain authentication logs for two years and then archive them for five years, or longer where applicable laws or regulations require it. The organisation should not treat the retention period and permitted log contents as a blanket rule for every application, security, or infrastructure log.

Retesting After Remediation

API testing doesn’t end when the first report lands. Once vulnerabilities are fixed, testers should repeat the relevant tests to confirm the fixes work and haven’t introduced new weaknesses. Retest results form part of the evidence that the organisation has followed up on the findings.

VAPT Checklist for AUAs, KUAs, Sub-AUAs, and Sub-KUAs

This is the practical side. The following is a checklist a team can actually follow.

Define the Aadhaar-Related Scope

Before testing begins, draw a clear line around what’s in scope. That means naming every application, API, server, network segment, and cloud environment that touches Aadhaar authentication or e-KYC data.

A scope that’s too narrow may leave systems untested. A scope that includes unrelated systems can waste testing time.

Inventory Applications, APIs, Cloud, and Infrastructure

A current inventory is the backbone of a credible audit. It should list:

• Every Aadhaar-facing application
• Every API endpoint used for authentication or e-KYC
• Cloud services in use
• Infrastructure components that support them

Documenting Aadhaar data flows also helps the team ensure that they have included all systems in scope in testing.

Review Source Code and Third-Party Components

Source code review checks for hardcoded secrets, insecure handling of Aadhaar data, and vulnerable third-party components. Follow UIDAI’s latest checklist for the specific code-review requirements that apply to your entity.

Third-party components deserve the same scrutiny.

Perform Static and Dynamic Testing, Plus API Testing

The testing programme should combine three layers:

• Code-level review catches issues visible in the source
• Runtime testing catches issues that appear when the application is running
• API testing catches issues in the contract between systems, such as broken object-level authorisation, excessive data exposure, and weak rate limiting

Test ADV, HSM, Encryption, and Access Controls

The assessment should verify that:

• Aadhaar numbers are stored only in the vault
• Reference-key mapping is protected and works as designed
• Encryption is active
• Keys are held in the HSM
• Access controls and logging behave as expected

The team should examine network isolation and trusted communication paths in the same exercise.

Document Findings, Remediate, and Retest

Each finding should be documented with enough detail that a remediation team can act on it. At minimum:

• The affected component
• The risk it creates
• A clear remediation direction

After fixes go in, a retest confirms the closure. Keep these records as audit evidence for review under the applicable UIDAI requirements.

Prepare Audit-Ready Evidence

Audit-ready evidence includes:

• The scope document
• The inventory
• The test reports
• The remediation records
• The retest results
• The compliance checklist completed in UIDAI’s format

The evidence should make clear what testers evaluated, what they found, what they fixed, and whether they confirmed the fix through retesting.

Want a Sample Penetration Testing Report?

See how our experts document vulnerabilities, risk severity, and clear remediation steps.

Download Sample Report→

Common UIDAI Compliance Gaps

These are gaps organisations should check for:

• Missing required information-security audit evidence or VAPT records. Testing may have happened, but they don’t retain reports, retest records, and audit evidence in a form that can be submitted for review.
• Incomplete inventory of Aadhaar-facing applications, APIs, and infrastructure. A new microservice or a forgotten API endpoint sits outside the tested scope.
• Weak ADV access controls or improper Aadhaar data storage. Aadhaar numbers end up in logs, backup tables, or analytics datasets outside the vault.
• Unsecured e-KYC API integrations. The API works functionally but lacks proper authentication, rate limiting, or response filtering. Downstream systems receiving e-KYC data aren’t tested.
• Poor oversight of Sub-AUAs and Sub-KUAs. The parent assumes the downstream partner is handling security, while they miss applicable audit requirements or follow-up actions.
• No structured remediation and retesting process. Findings are noted, but fixes aren’t tracked to closure. The same issues reappear in the next audit cycle.

How Qualysec Supports UIDAI Aadhaar Compliance

For AUAs, KUAs, Sub-AUAs, and Sub-KUAs, finding vulnerabilities is only part of the job. Teams also need to fix them and keep evidence for compliance audits. Qualysec helps test systems, explain findings, and verify fixes.

VAPT for Aadhaar Authentication and e-KYC Systems

Weaknesses in authentication applications, e-KYC APIs, or supporting infrastructure can expose sensitive data. Qualysec tests these systems and provides practical remediation guidance, with testing scoped to the UIDAI requirements that apply to the organisation.

ADV and HSM Security Assessment

A poorly secured Aadhaar Data Vault can expose Aadhaar numbers. Where included in the agreed scope, Qualysec can assess controls such as encryption, access restrictions, logging, and network separation.

Application and Infrastructure Security Testing

Automated scans can miss flaws in access controls and business logic. Qualysec combines automated tools with manual testing across web applications, mobile apps, APIs, cloud environments, and networks.

Remediation and Audit Reporting

A report alone won’t fix a vulnerability. Qualysec provides risk-rated findings, remediation guidance, and retesting to check whether fixes worked. These records can support the organisation’s audit evidence.

Conclusion

UIDAI Aadhaar compliance is a continuing discipline, not a one-time submission. It rests on the required security audits, a properly configured Aadhaar Data Vault with the prescribed encryption and HSM controls, VAPT covering applications, APIs, networks, and infrastructure as required, and a remediation and retesting process that produces audit evidence. Organisations that stay compliant treat these requirements as part of their normal security operations, not as a last-minute scramble before the audit window closes.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

FAQs

1. What is the difference between an AUA, KUA, and Sub-AUA under UIDAI guidelines?

An AUA uses Aadhaar authentication to provide its services. A KUA can also access e-KYC data, subject to UIDAI requirements. A Sub-AUA operates under a parent AUA or KUA and must meet the requirements that apply to its role.

2. Is VAPT mandatory for AUAs and KUAs?

UIDAI requires security testing, including VAPT and source code review, for systems covered by its applicable requirements. The current checklist sets out the scope and frequency that apply to each entity type.

3. Who is authorised to conduct a mandatory UIDAI security audit?

The audit must be conducted by a CERT-In-empanelled auditor where UIDAI requirements specify this. Audit reports and certificates must be submitted to UIDAI as required.

4. Is an Aadhaar Data Vault (ADV) audit mandatory for private enterprises?

Organisations that store Aadhaar numbers and connected Aadhaar data must implement an ADV in line with UIDAI’s requirements. The vault must meet the applicable storage, encryption, HSM, and access-control requirements. The audit and assessment obligations depend on the current UIDAI checklist and the entity’s role. Organisations should confirm which requirements apply to them rather than assume that a separate ADV audit is always mandatory or never required.

5. What happens if vulnerabilities are found during VAPT?

The organisation should fix the identified vulnerabilities and retest to check whether the fixes work. Remediation and retest records can support audit evidence.