UIDAI / Aadhaar (AUA-KUA)

1. Introduction to the UIDAI AUA/KUA Compliance Framework

The Unique Identification Authority of India (UIDAI) governs the Aadhaar ecosystem — the world's largest biometric identity programme, covering more than 1.3 billion residents. Any organisation that wishes to authenticate an individual's identity against the Central Identities Data Repository (CIDR), or to consume Aadhaar-based electronic Know-Your-Customer (e-KYC) data, must first be onboarded and certified by UIDAI. The two principal roles through which entities connect to the ecosystem are the Authentication User Agency (AUA) and the KYC User Agency (KUA). An AUA is an entity that uses Aadhaar authentication (Yes/No or e-KYC responses) to enable its services; a KUA is an AUA that is additionally authorised to receive resident demographic and photograph data through the e-KYC service.

Compliance for an AUA/KUA is not a single standard but a layered obligation set. It draws from the Aadhaar (Targeted Delivery of Financial and Other Subsidies, Benefits and Services) Act, 2016 (as amended by the 2019 Amendment Act); the Aadhaar (Authentication) Regulations, 2016 and the Aadhaar (Authentication and Offline Verification) Regulations, 2021; the Aadhaar (Data Security) Regulations, 2016; the UIDAI Information Security Policy — AUA/KUA/Sub-AUA/ASA; the mandatory AUA/KUA and ASA/KSA agreements; and the technical API specifications (Authentication API 2.5/2.6 and e-KYC API 2.5). Since the Aadhaar and Other Laws (Amendment) Act, 2019, private entities may authenticate only where permitted by law or notified by the Central Government, further tightening the eligibility and governance envelope.

This guide provides an auditor-grade deep-dive into the AUA/KUA compliance regime. It enumerates every obligation family — legal, contractual, technical, operational and security — and maps each to what an assessor must verify and the evidence that typically satisfies the requirement. It is intended for compliance leads, information security officers, internal auditors and the empanelled auditors who perform the mandatory UIDAI compliance audit prior to and during go-live.

It is important to appreciate why the AUA/KUA regime is unusually strict compared with ordinary information-security standards. The Aadhaar number is linked to a resident's biometrics and demographics held in a single national repository; a compromise does not merely expose one organisation's customers but can undermine trust in a foundational public-good identity system. UIDAI has therefore designed the ecosystem around three non-negotiable principles: residents must retain control through informed consent; sensitive identity data must be minimised and protected in transit and at rest; and biometric data must never leave the resident's control to reside in a requesting entity's systems. Every control described in this guide traces back to one of these principles. Auditors are expected to test not only that documentation exists, but that the live system behaves in accordance with them — for instance, by inspecting the actual data model to confirm no biometric field is ever written to disk, and by sampling real transactions to confirm consent and masking are enforced in production, not merely in policy.

The consequences of non-compliance are material. UIDAI can suspend or terminate authentication rights, disable licence and API keys, and refer serious violations for action under Chapter VII of the Aadhaar Act, which creates offences and penalties for unauthorised access, disclosure and use of identity information. Financial and reputational exposure compounds with sectoral regulatory action from the RBI, IRDAI, SEBI or DoT, and, increasingly, with obligations under the Digital Personal Data Protection Act, 2023. A disciplined, evidence-led compliance programme is therefore both a licensing prerequisite and a risk-management imperative.

2. What is UIDAI AUA/KUA?

UIDAI AUA/KUA compliance refers to the complete set of security, privacy, technical and governance controls that a requesting entity must implement and continuously maintain to be permitted to consume Aadhaar authentication and e-KYC services. The framework exists because AUAs and KUAs handle two categories of extremely sensitive data: the Aadhaar number itself (a Sensitive Personal Data element) and, for KUAs, the resident's demographic and photograph data returned by the e-KYC service. UIDAI never permits an AUA/KUA to store the resident's biometrics (Personal Identity Data), and imposes strict rules on the handling of the Aadhaar number and e-KYC data.

The ecosystem is intermediated. An AUA/KUA does not connect directly to the CIDR; it connects through an Authentication Service Agency (ASA) or KYC Service Agency (KSA) that holds a secure leased-line or MPLS connection to the UIDAI data centres. The AUA/KUA forms the PersonID (PID) block, encrypts it using UIDAI's public key, and transmits the encrypted request through its ASA/KSA to the CIDR, which responds with a Yes/No (authentication) or an encrypted e-KYC response. This intermediated model means the AUA/KUA's compliance obligations are defined jointly by the UIDAI agreements and the back-to-back agreement with its chosen ASA/KSA.

Key terminology used throughout this guide:

3. Who Must Comply

Any organisation that consumes Aadhaar authentication or e-KYC — whether directly onboarded by UIDAI or operating as a Sub-AUA under a parent AUA — is subject to AUA/KUA compliance. Post the 2019 amendment, only entities permitted by a law made by Parliament or notified by the Central Government (in the interest of the State) may perform Aadhaar authentication, so eligibility itself is a gating control.

• Entities must possess a valid legal basis (statute or Central Government notification) to authenticate — self-declaration is not sufficient.
• Direct AUAs/KUAs sign the AUA/KUA agreement with UIDAI and an ASA/KSA agreement with a service agency.
• Sub-AUAs inherit obligations contractually and are audited as part of the parent's ecosystem.
• All categories must clear the mandatory UIDAI compliance audit by a UIDAI-empanelled/CERT-In auditor before production access.
• Requesting entities handling e-KYC (KUAs) carry heightened data-minimisation, consent and storage obligations relative to authentication-only AUAs.

4. Structure of UIDAI AUA/KUA Compliance

There is no single numbered control catalogue as in ISO 27001 or PCI DSS. Instead, obligations are distributed across statutory, regulatory, contractual, technical and security-policy instruments. For assessment purposes it is helpful to organise them into control domains. The table below presents the domain structure used throughout this guide's master checklist.

5. Master Assessment Checklist

This is the core of the guide. Each domain from Section 4 is expanded below with the specific controls an auditor must examine. For every control the checklist states what to verify and the typical evidence that demonstrates conformity. Auditors should not skip any domain: a single unmet control — for example, storing the Aadhaar number in plain text, or retaining biometrics — can result in suspension of authentication rights.

When applying this checklist, assessors should adopt a test-of-design followed by test-of-operating-effectiveness approach. Test of design confirms that a control, as documented and architected, is capable of meeting the objective; test of operating effectiveness confirms that it has actually operated over a period, using samples of transactions, logs, tickets and reviews. For high-risk controls — the prohibition on storing biometrics, encryption of the PID block, consent capture and Aadhaar-number masking — a single point-in-time observation is insufficient; the auditor should seek independent, corroborating evidence such as database schema inspection, packet or payload review in staging, and log sampling across dates. Findings should be rated by severity, with any prohibited-data or unencrypted-transmission finding treated as critical and blocking for production access.

D1 — Legal Eligibility and Licensing

D2 — Agreements and Contractual Controls

D3 — Consent and Resident Notice

D4 — Purpose Limitation and Permitted Use

D5 — Data Storage, Retention and Disposal

D6 — Encryption and Key Management

D7 — Network and Connectivity Security

D8 — Application and API Security

D9 — Access Control and Identity Management

D10 — Logging, Audit Trail and Monitoring

D11 — Information Security Management (Governance)

D12 — Human Resources and Awareness

D13 — Physical and Environmental Security

D14 — Incident Management and Breach Reporting

D15 — Business Continuity and Availability

D16 — Fraud Management and Exception Handling

D17 — Sub-AUA / Third-Party Governance

D18 — Compliance Audit and Reporting

6. Scoping

Correct scoping determines audit effort and, more importantly, ensures that no system that touches Aadhaar data escapes control coverage. The scope is defined by the flow of the Aadhaar number, the PID block and (for KUAs) the e-KYC response — from the point of resident interaction, through the AUA/KUA application, to the ASA/KSA gateway and back.

• In scope: all applications, APIs and micro-services that construct the PID block, encrypt/sign requests, or receive and decrypt e-KYC responses.
• In scope: databases and stores that hold the Aadhaar number, reference keys/UID tokens, or e-KYC demographic/photo data.
• In scope: the ASA/KSA integration layer, connectivity, keys, HSMs and certificates.
• In scope: logging, SIEM, backup and monitoring systems that process Aadhaar-related transaction metadata.
• In scope: Sub-AUA integration points and any partner that relays authentication through the entity.
• Explicitly out of design (prohibited): storage of biometrics/PID; these must be architected out rather than 'scoped out'.
• Consider network segmentation to reduce scope — isolating the Aadhaar environment limits which systems are subject to full control assessment.
• Cloud/hosted components are in scope; verify data localisation within India and provider assurances.

A common scoping error is to treat only the customer-facing application as in scope while overlooking downstream systems that inadvertently receive Aadhaar data — data warehouses, analytics platforms, customer-service tools, backup repositories and log aggregators. Auditors should perform data-flow tracing from the point of capture to every terminal store, and use data-discovery scanning to detect Aadhaar-number patterns (the twelve-digit Verhoeff-checksummed number) in unexpected locations. The UID token, or reference key, mechanism provided by UIDAI is the recommended way to avoid storing the raw Aadhaar number at all: the entity stores an opaque token that can be resolved back only through UIDAI, dramatically shrinking the sensitive-data footprint and the audit scope.

7. Implementation Approach

A phased implementation aligns technical build with contractual onboarding and the mandatory pre-production audit. The following four phases take an entity from intent to certified production operation.

Phase 1 — Eligibility, Onboarding and Design

• Activities: confirm legal basis/permitted use; select and contract an ASA/KSA; execute the AUA/KUA agreement; define use cases and data flows; design the target architecture (encryption, HSM, no-biometric-storage, reference keys).
• Deliverables: signed agreements; use-case register; data-flow diagrams; solution architecture and security design; UIDAI onboarding references and licence/API keys.

Phase 2 — Build and Secure Integration

• Activities: implement PID-block construction, AES/RSA encryption with UIDAI public key, HMAC and XML signing; integrate with ASA/KSA staging; deploy HSM and key-management; implement consent capture, logging and masking; harden network and application layers.
• Deliverables: working integration in UIDAI staging; encryption/key-management runbooks; consent and logging implementation; hardening baselines and configuration standards.

Phase 3 — Testing, Pre-Production Audit and Certification

• Activities: conduct functional and conformance testing against staging; run VAPT/SAST/DAST; remediate findings; engage a UIDAI-empanelled/CERT-In auditor for the mandatory compliance audit; close audit findings.
• Deliverables: conformance-test evidence; VAPT and remediation reports; the UIDAI compliance audit report and UIDAI production-access approval.

Phase 4 — Production Operation and Continuous Compliance

• Activities: go live; operate logging/monitoring; run periodic access reviews, patching and DR tests; onboard and monitor Sub-AUAs; perform annual audits and self-assessments; manage change and incidents.
• Deliverables: production runbooks; monitoring dashboards; periodic audit reports; incident and change records; annual compliance attestation to UIDAI.

8. Maturity / Capability Model

UIDAI does not publish a formal maturity scale, but a capability model is a useful lens for internal benchmarking and for demonstrating a trajectory of improvement to auditors and management. The five-level model below adapts common maturity thinking to the AUA/KUA control domains. In practice, an entity must reach at least Level 3 (Defined) to pass the mandatory compliance audit, because standardised, consistently operating controls are what the auditor tests. Levels 4 and 5 reflect the operational maturity expected of high-volume AUAs/KUAs — banks and large government departments — where continuous monitoring and automation are necessary to sustain compliance across millions of daily transactions and a wide Sub-AUA network.

9. Assessment and Audit Approach

The mandatory UIDAI compliance audit is performed by an auditor empanelled by UIDAI/CERT-In. The following ordered steps describe a rigorous assessment lifecycle for both the initial and periodic audits.

1. Define scope: identify all systems, data stores, integrations and Sub-AUAs that touch Aadhaar data, and confirm the applicable agreement version and API version.
2. Review documentation: examine agreements, security policy, risk assessment, data-flow diagrams, key-management and retention policies.
3. Assess design: evaluate the architecture for no-biometric-storage, correct encryption/signing, HSM use, masking and segmentation.
4. Test controls: verify consent capture, logging, access control, encryption in practice; sample transactions and logs (redacted).
5. Conduct technical testing: perform or review VAPT, configuration reviews and conformance tests against UIDAI staging.
6. Interview stakeholders: confirm roles, awareness, incident and change processes with ISO, developers and operations.
7. Evaluate Sub-AUA governance: review onboarding, agreements, key segregation and oversight of downstream entities.
8. Rate findings: classify gaps by severity and impact on Aadhaar data protection and regulatory obligations.
9. Report and remediate: issue the audit report, agree remediation plans and owners, and revalidate closure of critical findings.
10. Submit and attest: provide the report/attestation to UIDAI as required and schedule the next periodic audit.

10. Evidence Request List

The following categorised list is a practical pull-list an auditor issues at kick-off. Providing these promptly accelerates the assessment.

• Legal and contractual: enabling statute/notification, permitted-use approvals, executed AUA/KUA and ASA/KSA agreements, Sub-AUA agreements, licence/API key register.
• Governance: information security policy, risk assessment and treatment plan, ISO/CISO appointment, management-review minutes, roles and RACI.
• Consent and privacy: consent capture screens/scripts, disclosure notices, purpose register, data-flow diagrams.
• Data protection: retention schedule, purge/deletion logs, encryption and key-management policy, HSM inventory, masking configuration.
• Technical: API integration/design documents, conformance-test results, SAST/DAST/VAPT reports, network and segmentation diagrams, TLS/cipher scans.
• Access control: role matrix, MFA configuration, access-review sign-offs, joiner-mover-leaver records, privileged-account inventory.
• Logging and monitoring: log schema and samples (redacted), retention/immutability config, SIEM dashboards and alert rules, NTP configuration.
• Operations: change tickets/CAB minutes, patch records, BCP/DR plans and test reports, backup/restore evidence.
• People: BGV records, signed NDAs, training completion reports and content.
• Incident and fraud: IR plan and playbooks, incident register, CERT-In/UIDAI notification procedure, fraud-analytics rules, grievance logs.
• Third party: Sub-AUA onboarding/due-diligence, oversight audits, cloud/hosting provider assurance reports and data-localisation proof.
• Audit: previous UIDAI compliance audit report, remediation trackers, UIDAI correspondence and approvals.

11. Roles and Responsibilities

12. KPIs to Track

• Authentication success rate and failure-reason distribution (to detect issues without denying service).
• Percentage of transactions with valid, recorded consent (target 100%).
• Number of prohibited-data findings (biometrics/PID/OTP persisted) — target zero.
• Encryption/signing conformance rate against the current API specification.
• Mean time to detect and mean time to respond for Aadhaar-related incidents.
• Percentage of privileged accesses under MFA and coverage of access recertification.
• VAPT critical/high findings open beyond SLA and average remediation time.
• Log completeness and retention compliance (mandated retention met, tamper-evidence intact).
• Percentage of Sub-AUAs with current agreements and passed compliance reviews.
• Audit findings closed on time; recurrence rate of previously closed findings.
• DR test success and RTO/RPO adherence for the authentication service.
• Training completion rate for personnel handling Aadhaar data.

13. Readiness Checklist

• Lawful basis / permitted use confirmed and documented.
• AUA/KUA and ASA/KSA agreements executed and current.
• Architecture verified to never store biometrics/PID/OTP.
• Aadhaar number encrypted or replaced by reference key/UID token where stored.
• PID block encryption, HMAC and XML signing implemented per current API spec.
• Private keys and certificates held in an HSM with lifecycle management.
• Informed consent captured, disclosed and logged for every transaction.
• Aadhaar number masking enforced on screens, prints and logs.
• Transaction logs retained for the mandated period on tamper-evident storage.
• Network segmentation and TLS with strong ciphers in place.
• RBAC, MFA for privileged access and periodic recertification operating.
• SIEM, log review and alerting active for the Aadhaar environment.
• Incident response plan with UIDAI/CERT-In notification path tested.
• BCP/DR for the authentication service tested within the last cycle.
• VAPT/SAST/DAST completed and critical findings remediated.
• Sub-AUA onboarding, agreements and oversight in place.
• Security awareness training completed for relevant staff.
• Mandatory UIDAI compliance audit passed and production access approved.
• Remediation tracker maintained with owners and closure evidence.

14. Common Gaps

• Storing biometric/PID data or persisting OTP values — an outright prohibition breach.
• Storing the Aadhaar number in plain text or without adequate access restriction, instead of using a reference key/UID token.
• Weak or missing masking of the Aadhaar number on screens, receipts, exports and logs.
• Consent not genuinely informed, not recorded, or not linked to the transaction.
• Using e-KYC data for purposes beyond the disclosed and permitted use (secondary use).
• Private keys/certificates held in software rather than an HSM, or with no rotation/revocation process.
• Running an outdated API version or non-conformant PID/XML construction.
• Logs missing required metadata, under-retained, or stored without tamper-evidence.
• Inadequate Sub-AUA governance — no flow-down clauses, key segregation or oversight audits.
• No defined UIDAI/CERT-In breach-notification path or untested incident response.
• Missing or expired legal basis/permitted-use approval, especially for private entities post-2019.
• Skipping periodic audits or leaving prior audit findings unremediated.

15. UIDAI AUA/KUA Mapped to Other Frameworks

Entities usually operate multiple compliance regimes concurrently. The mapping below helps reuse controls and evidence across frameworks. Mappings are indicative, not one-to-one; UIDAI obligations remain authoritative for Aadhaar handling.

16. How CyberSigma Helps

Frequently asked questions

Need help with UIDAI AUA/KUA?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.