DPDP Act 2023: What It Means for Your IAM Stack

The Letter That Changed the Meeting Agenda

Rohan Mehta, Head of Engineering at a Bengaluru-based HR SaaS company, had the DPDP Act on his radar for two years. He had read the summaries, attended the webinar, and added "DPDP compliance review" to the annual roadmap. It felt like a future problem.

Then in February 2026, an enterprise customer — a 4,000-person manufacturing conglomerate in Coimbatore — sent a vendor security questionnaire with a new section at the bottom: Digital Personal Data Protection Act Compliance. Seventeen questions. The procurement team needed answers in ten days or the contract renewal would be paused.

Question 9: "Does your identity provider store authentication data and consent records within India? Provide your DPA and data residency documentation."

Rohan opened his Auth0 dashboard. US East. He called his AWS account manager. His RDS instances were in Mumbai, but the identity layer — every login event, every consent grant, every session token — was flowing through Auth0's US infrastructure.

The contract renewal was delayed by six weeks while Rohan rebuilt the authentication layer. He is not an outlier. He is the rule.

What the DPDP Act Actually Says About IAM

The Digital Personal Data Protection Act, 2023 (DPDP Act) received Presidential assent on August 11, 2023. Its enforcement provisions have been rolling out through the DPDP Rules, which the Ministry of Electronics and Information Technology (MeitY) notified in 2025. By 2026, compliance is no longer theoretical — enterprise customers are demanding evidence, and the Data Protection Board of India is operational.

The Act doesn't mention "identity providers" or "login systems" explicitly. But authentication data is personal data — and your IAM stack is the system that processes it, stores it, and controls access to it. Every section of the Act that governs personal data processing applies directly to your authentication layer.

Here are the provisions that matter most.

Section 4: Grounds for Processing of Personal Data

Under Section 4(1), a person may process the personal data of a Data Principal only for a lawful purpose — (a) for which the Data Principal has given her consent under Section 6, or (b) for certain legitimate uses specified in Section 7. "Lawful purpose" means any objective that is not expressly prohibited by law.

IAM implication: Your registration and login flows must capture consent for each purpose of data processing — not a single blanket "I agree to Terms." If you process authentication data for security analytics, fraud detection, and marketing attribution, that's three separate consent grants, not one.

Section 6(1): Consent Requirements

Under Section 6(1), consent given by a Data Principal must be:

• Free — given without subjection to deceptive or manipulative practices, including making consent a precondition for accessing goods or services
• Specific — limited to the specified purpose; fresh consent is required if the purpose changes
• Informed — given after the Data Principal has received the Notice required under Section 5, describing the personal data collected and the purpose for which it will be processed
• Unconditional — not subject to terms that constitute deceptive or manipulative practices
• Unambiguous — expressed through a clear affirmative action; mere inaction or disengagement does not constitute consent

Section 6(3) additionally requires that any request for consent must be presented in clear and plain language and, where possible, in a language the Data Principal can understand. Section 6(10) places the burden of proof on the Data Fiduciary to demonstrate that proper notice was provided and that consent was validly obtained.

IAM implication: Your login and registration pages are where consent is collected. The identity provider controls these screens. If your IdP doesn't support purpose-specific consent flows with versioning and timestamps, you cannot meet Section 6 requirements.

Sections 6(4) and 6(6): Right to Withdraw Consent

Under Section 6(4), a Data Principal has the right to withdraw her consent at any time, with the ease of doing so being comparable to the ease with which such consent was given. Section 6(6) requires that upon withdrawal, the Data Fiduciary shall, within a reasonable time, cease and cause its Data Processors to cease processing the personal data — except where such processing is otherwise required or authorised by applicable law. Section 6(5) clarifies that withdrawal does not affect the lawfulness of processing carried out on the basis of valid consent before the withdrawal.

IAM implication: Consent withdrawal must flow through your identity layer. When a user withdraws consent in your app, that signal must reach the IdP and block further token issuance. This requires a consent revocation webhook or API that most off-the-shelf IAM tools do not implement.

Section 8(7): Erasure Obligation

Under Section 8(7), a Data Fiduciary must erase personal data — and cause its Data Processors to erase personal data — once the purpose of processing is no longer being served, or upon withdrawal of consent by the Data Principal, unless retention is required to comply with applicable law. Section 8(8) further clarifies that a purpose shall be deemed to no longer be served if the Data Principal has neither approached the Data Fiduciary nor exercised any right under the Act for the period prescribed under the DPDP Rules.

The Data Principal's corresponding right to request erasure is separately provided under Section 12(4), which gives Data Principals the right to request erasure of their personal data from the Data Fiduciary.

IAM implication: Your IAM stack stores authentication data — usernames, phone numbers, email addresses, login history, session metadata, device fingerprints, and sometimes linked attributes like employer or date of birth. All of this is subject to erasure. Your IdP must support right-to-erasure workflows with an audit trail confirming that the data has been erased.

Section 9: Processing of Personal Data of Children

The Act defines "child" in Section 2(d) as an individual who has not completed the age of eighteen years. Section 9(1) provides that before processing a child's personal data, a Data Fiduciary must obtain verifiable consent of the parent of the child or, where applicable, the lawful guardian, in the prescribed manner.

Section 9(2) additionally prohibits a Data Fiduciary from undertaking any processing of a child's personal data that is likely to cause any detrimental effect on the well-being of the child. Section 9(3) requires Data Fiduciaries to prohibit tracking or behavioural monitoring of children and targeted advertising directed at children. Certain classes of Data Fiduciaries may be exempted from subsections (1) and (3) by notification from the Central Government (Section 9(4) and 9(5)).

IAM implication: If your platform has any possibility of under-18 users — edtech, consumer apps, e-commerce — your registration flow needs age verification and parental consent capture. This is an authentication-layer responsibility. Age gating and the identity of the consenting parent or guardian must be recorded with a timestamp.

Sections 11–14: Rights of Data Principals

The DPDP Act establishes four distinct rights for Data Principals, each in its own section:

Section 11 — Right to access information about personal data: A Data Principal has the right to obtain from a Data Fiduciary: (a) a summary of personal data being processed by that Data Fiduciary and the processing activities undertaken; and (b) the identities of all other Data Fiduciaries and Data Processors with whom the personal data has been shared, along with a description of the personal data so shared. The Data Fiduciary need not disclose information shared with law enforcement for prevention, detection, or investigation of offences.

Section 12 — Right to correction, completion, updating and erasure: Under Section 12(1), a Data Principal has the right to correction, completion, updating and erasure of her personal data. Section 12(2) requires the Data Fiduciary to correct inaccurate or misleading data, complete incomplete data, and update records upon request. Under Section 12(4), a Data Principal has the right to request erasure of her personal data. Where correction occurs, Section 12(3) requires the Data Fiduciary to notify all downstream Data Fiduciaries and Processors who received the data and take reasonable steps to ensure they correct their records.

Section 13 — Right of grievance redressal: A Data Principal may raise a grievance with the Data Fiduciary. The Data Fiduciary must provide a readily available means of grievance redressal and respond within the period prescribed under the DPDP Rules. A Data Principal must exhaust this remedy before approaching the Data Protection Board.

Section 14 — Right to nominate: A Data Principal may nominate another individual to exercise rights under the Act on their behalf in the event of the Data Principal's death or incapacity (defined as inability to exercise rights due to mental unsoundness or physical infirmity).

IAM implication: The data access summary a user requests under Section 11 must include their authentication records, consent history, and linked attribute data. Your IdP must expose this via a user-accessible API or self-service dashboard. Erasure requests under Section 12(4) must be actioned at the identity layer — not just in your application database — to ensure complete removal of authentication records and consent logs.

---

The IAM Compliance Checklist for DPDP

Based on the above, here is what a DPDP-compliant IAM stack must do:

Requirement	DPDP Section	IAM Capability Required
Purpose-specific consent at registration	§6(1)	Consent collection with purpose tagging
Consent versioning and timestamps	§6(1), §6(10)	Immutable consent audit log
Consent withdrawal mechanism	§6(4)	Consent revocation API/UI
Block token issuance post-withdrawal	§6(4), §6(6)	Consent state check in auth flow
Erasure — fiduciary obligation	§8(7), §8(8)	Automated data deletion with audit record
Erasure — Data Principal's right	§12(4)	User-initiated deletion workflow
Data correction and update	§12(2)	User self-service profile correction
Data access summary for users	§11	User self-service data export
Session and login event audit log	§8(5), §8(6)	Immutable authentication event log
Age verification for minors	§9(1)	Age gate + parental consent capture
Lawful purpose documentation	§4(1)	Processing purpose registry
Cross-border transfer controls	§16(1)	Data residency enforcement

---

How Your Current IAM Stack Probably Fails DPDP

Most Indian companies running Auth0, Firebase Authentication, AWS Cognito, or Azure AD B2C built their authentication layers before the DPDP Rules were notified. These products were designed for GDPR and CCPA compliance — not DPDP. The gaps are structural, not cosmetic.

Requirement	Auth0	Firebase Auth	AWS Cognito	Azure AD B2C	KeycloakPro
Purpose-specific consent flows	No — single consent only	No	No	Partial	Yes
Consent versioning and audit log	No	No	No	No	Yes
Consent revocation that blocks tokens	No	No	No	No	Yes
Right-to-erasure with audit trail	Partial — manual	No	No	Partial	Yes
User self-service data export	Partial	No	No	Partial	Yes
India data residency default	No (US East)	No	ap-south-1 available	India region available	Yes — your AWS Mumbai account
Cross-border transfer controls	No	No	No	Configurable	Yes
Processing purpose registry	No	No	No	No	Yes (via custom attributes)

The fundamental problem with foreign-hosted IAM products is not that they are bad software — it is that consent state lives inside their infrastructure, not yours. When a user withdraws consent in your application, you can update a flag in your database. But the IdP doesn't know about it. The next time that user logs in, the IdP issues a valid token regardless of their consent withdrawal. Your application has to enforce the business logic that the IdP should be enforcing at the authentication layer.

This creates a class of compliance risk that no amount of application-layer patching can fully close.

---

DPDP and Data Localization: What's Actually Required

The DPDP Act does not mandate data localization in absolute terms. Under Section 16(1), the Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to any country or territory outside India. This is a restriction mechanism: cross-border transfers are permissible by default unless the Central Government issues a specific notification restricting transfer to a particular country or territory. Section 16(2) preserves any existing Indian law that imposes stricter restrictions on cross-border transfer. No restriction notification under Section 16(1) has been issued as of 2026.

However, three practical pressures are pushing Indian companies toward India-hosted identity:

1. Enterprise customer requirements: Large Indian enterprises — banks, insurers, healthcare groups — are including data residency requirements in vendor contracts. Even if the law doesn't mandate it, your enterprise contracts may.

2. Sectoral regulations: RBI's 2018 data localization circular requires financial data of Indian residents to be stored in India. Payment system data must be in India. If your users are transacting through your platform, their authentication records may be covered.

3. CERT-In compliance: CERT-In's April 2022 directive requires organizations to maintain logs of all ICT systems for 180 days and make them available to CERT-In within 6 hours of demand. If your authentication logs are in a US-hosted IdP, fulfilling a CERT-In demand in 6 hours is operationally complex.

The safe position — and the one enterprise customers are requiring — is authentication data in India from the start.

---

Building a DPDP-Compliant IAM Stack with Keycloak

Keycloak provides the building blocks. KeycloakPro assembles them into a DPDP-ready configuration.

Consent Management

Keycloak's Consent feature allows you to require explicit user approval for each OAuth 2.0 scope before tokens are issued. KeycloakPro extends this with:

• Purpose-labeled scopes: Each scope maps to a documented processing purpose (e.g., read:profile → "Personalizing your dashboard")
• Consent version tracking: When your privacy policy changes, users are prompted to re-consent at next login
• Consent audit log: Every grant, update, and withdrawal is recorded in the Keycloak event store with timestamp and IP address
• Consent withdrawal API: Applications call a webhook; Keycloak revokes the user's active sessions and blocks new token issuance

Right to Erasure

Keycloak stores user data in a PostgreSQL database you control. KeycloakPro's erasure workflow:

1. User submits erasure request via your application
2. Request triggers a Keycloak Admin API call
3. Keycloak anonymizes the user record — hashing email, clearing attributes, revoking active sessions
4. The anonymization event is recorded in the audit log (the event exists; the PII is gone)
5. Your application receives a webhook confirming erasure

When a DPDP auditor asks for evidence of an erasure, you produce the audit log event. The user's data is gone.

Authentication Event Logging

Every login, logout, token refresh, failed authentication attempt, and consent change is logged in Keycloak's event store. KeycloakPro ships this to your SIEM (Splunk, Elastic, CloudWatch) for:

• 180-day retention (CERT-In requirement)
• Real-time alerting on anomalous patterns
• User-level audit trail for data access summaries

Data Residency

KeycloakPro deploys Keycloak on your AWS account in ap-south-1 (Mumbai) or your Azure India tenant. The deployment topology:

[User] → [CloudFront / Azure CDN (India PoP)]
         → [Application Load Balancer (Mumbai)]
         → [Keycloak Cluster (ap-south-1)]
         → [PostgreSQL RDS (ap-south-1, Multi-AZ)]
         → [Redis Session Store (ap-south-1)]

Every authentication event, every token, every user record stays in India. The KeycloakPro operations team accesses the cluster via bastion in the same region. No data leaves India for routine operations.

---

Getting DPDP-Ready: A 6-Week Roadmap

For companies currently running Auth0, Firebase, or Cognito, this is a realistic migration timeline:

Week	Activity
1	IAM audit: map all current consent mechanisms, data flows, and user attributes
2	Keycloak deployment on AWS Mumbai (or Azure India) with HA configuration
3	Migrate user accounts from existing IdP; configure OIDC/SAML clients for existing apps
4	Implement consent flows, purpose mapping, and consent audit log
5	Configure right-to-erasure webhook and test erasure workflow end-to-end
6	Parallel run, cutover, and documentation package for auditors

The documentation package — data residency certificates, consent flow screenshots, erasure procedure, audit log samples — is what enterprise customers and auditors ask for. KeycloakPro produces this as a standard deliverable.

---

What Auditors Are Actually Asking For

Based on DPDP audit questionnaires from enterprise banking, insurance, and healthcare clients in 2025–2026, the recurring questions are:

1. Where is authentication data stored? Provide datacenter location and your cloud provider's data residency documentation.
2. How do you capture and record user consent? Provide a sample consent record with timestamp.
3. How do you process a right-to-erasure request? Provide your procedure and a sample audit trail.
4. How do you handle consent withdrawal? Does it immediately prevent further processing?
5. What is your authentication event retention policy? Can you produce 12 months of login events for a specific user?
6. How do you notify users of a data breach affecting their authentication records?

Every one of these questions has a clear answer when you're running KeycloakPro on your own AWS Mumbai infrastructure. Most of them are difficult or impossible to answer when your IAM is hosted by a US-based SaaS provider.

---

Act Before the Audit Finds You

The DPDP Act is not a future concern. The Data Protection Board of India is operational. Enterprise customers are including DPDP compliance clauses in procurement contracts. CERT-In is issuing notices.

The companies that will have smooth audits are the ones that built compliance into the architecture — not the ones trying to retrofit it when a questionnaire arrives.

A free DPDP IAM Assessment from KeycloakPro covers:

• A review of your current IAM stack against the DPDP compliance checklist
• Identification of gaps in consent management, data residency, and erasure workflows
• A realistic migration estimate for your specific stack
• A sample documentation package showing what DPDP-ready audit evidence looks like

Book your free DPDP IAM Assessment →