Authentication systems collect more than an email address. They accumulate sessions, device records, failed sign-ins, IP addresses, consent history, OTP challenges, password-reset requests, waitlist entries, provider links, audit events, and backups.

Keeping all of it forever feels safe until it becomes a privacy liability. Deleting everything quickly feels privacy-friendly until you cannot investigate an account takeover or meet another legal obligation. The useful answer is a documented retention schedule tied to purpose, law, and technical state.

This guide shows how an India-facing startup can build that schedule. It is general engineering information, not legal advice; regulated sectors and specific business records need counsel review.

Start with the DPDP rule, not an arbitrary number

Section 8(7) of India's Digital Personal Data Protection Act, 2023 says a Data Fiduciary should erase personal data when consent is withdrawn or when it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier, unless another law requires retention. It must also cause its processor to erase data made available for that processing.

Section 12 separately gives a Data Principal a right to request erasure, subject to retention needed for the specified purpose or compliance with law.

That creates three questions for every authentication record:

What purpose requires this record?
When does that purpose end?
Does another law or defensible security need require a limited hold?

“Storage is cheap” is not a purpose. “We may want it later” is not a retention policy.

Read the notified Rules with the commencement schedule

The Digital Personal Data Protection Rules, 2025 add more specific mechanics.

Rule 8 provides an inactivity-based erasure process for the classes and purposes listed in the Third Schedule. For those specified entities, the period is generally three years from the Data Principal's last approach or exercise of rights, subject to the schedule and exceptions such as data needed to let the person access an account or virtual token. The rule requires notice at least 48 hours before scheduled erasure.

Rule 8(3) also requires covered processing data, associated traffic data, and processing logs to be retained for at least one year for the purposes in the Seventh Schedule, followed by erasure unless another law or government notification requires longer retention.

Do not turn either number into “all Indian startups must keep all authentication data for three years.” The three-year rule applies through the classes and purposes in the Third Schedule, and the one-year rule concerns the processing records and purposes specified by the Rules. Scope the requirement with counsel against your actual service.

The commencement notification is phased. MeitY's November 2025 notification brings the principal processing obligations into force eighteen months after 13 November 2025. Use that runway to implement lifecycle controls; do not wait for the effective date to discover that deletion cannot be executed across production, processors, and backups.

Inventory data before assigning retention

Start with a data map. For each record, capture:

system and table or storage location;
fields that identify or can be linked to a person;
purpose and lawful basis;
system of record and downstream processors;
creation event and last-use event;
deletion trigger;
minimum or maximum period, with its authority;
backup and legal-hold behavior;
owner accountable for the policy.

Authentication data often hides in analytics, support tickets, email delivery logs, webhook payloads, and observability tools. Deleting the user row while preserving a full email address in five log systems is not a complete erasure workflow.

NamoID's DPDP checklist for SaaS provides the broader inventory and accountability context.

A practical authentication retention matrix

The periods below are policy examples, not statutory defaults. Replace them with periods justified by your purpose, risk, contracts, and applicable law.

Data category	Active purpose	Example deletion trigger	Engineering treatment
User profile and verified identifiers	Provide the account and sign-in	Account erasure or purpose ending	Delete or irreversibly de-identify fields not under a valid hold
Password verifier	Authenticate the active account	Password replacement or account erasure	Replace immediately on change; never retain old hashes for convenience
OTP challenge	Complete one short-lived verification	Expiry, successful use, or attempt exhaustion	Store a hash, not the code; purge expired challenge rows promptly
Password-reset token	Complete account recovery	Expiry or successful reset	Hash, single-use, short-lived; revoke all competing reset tokens when appropriate
Active session and refresh token	Maintain signed-in access	Expiry, logout, revocation, or account erasure	Revoke immediately; purge expired records on a scheduled job
Passkey credential	Authenticate the active account	Credential removal or account erasure	Retain public credential material and metadata only while bound
Failed sign-in and risk signal	Detect abuse and investigate incidents	Security window ending	Minimise identifiers; aggregate or pseudonymise when detailed evidence is no longer needed
Consent record	Prove notice, purpose, and user action	End of evidence need, subject to legal hold	Keep version, timestamp, purpose, and action; avoid copying unrelated profile data
Waitlist application	Review and communicate access	Decision becoming stale or waitlist ending	Separate from active users; erase rejected and abandoned applications on schedule
Provider connection	Deliver federated sign-in	Disconnect, token expiry, or account erasure	Revoke upstream where possible; delete encrypted tokens and unnecessary provider profile data
Audit event	Security, accountability, and dispute evidence	Defined audit period ending	Minimise payloads, restrict access, and support tombstoning or de-identification where required
Email/SMS delivery record	Deliver and troubleshoot authentication messages	Support and billing window ending	Retain status and provider reference; avoid plaintext OTPs and full message bodies
Backup copy	Disaster recovery	Backup rotation expiry	Enforce finite rotation; prevent deleted data from re-entering live systems on restore

The matrix should distinguish logical expiry from physical deletion. A session can become invalid at its expiry timestamp even if a maintenance job removes the row later. Security enforcement must use the former; retention compliance must eventually complete the latter.

Authentication secrets should disappear fastest

Short-lived secrets have narrow purposes. An OTP exists to complete one verification transaction. A reset token exists to complete one recovery transaction. Once used, expired, superseded, or exhausted, it should not remain a valid credential.

Good implementation patterns include:

store only cryptographic hashes of OTPs and reset tokens;
invalidate the previous OTP when a resend issues a replacement;
mark tokens single-use atomically;
keep plaintext secrets out of logs, analytics, traces, and audit payloads;
purge expired records on a predictable schedule;
record the security event without copying the secret.

The audit trail might retain “password reset completed at this time from this risk context.” It should never retain the reset token.

Logs and audit events need separate policies

Application logs and audit events are not interchangeable.

Operational logs help diagnose software and infrastructure. They should be structured, access-controlled, redacted, and relatively short-lived. Audit events establish who performed a sensitive action, on what resource, and when. They may need a longer, deliberately justified evidence window.

An “append-only” audit design means application code cannot silently edit history. It does not mean personal data in audit payloads must be retained forever. Prefer stable internal identifiers over email addresses, phone numbers, raw request bodies, and provider responses. Where erasure applies, consider a tombstone or controlled de-identification process that preserves event integrity without retaining unnecessary direct identifiers.

For the event design itself, see DPDP audit-trail requirements.

Deletion must propagate to processors

The DPDP Act explicitly reaches personal data made available to processors. Your workflow therefore needs more than a database delete:

Revoke sessions, refresh tokens, passkeys, API grants, and provider links.
Delete or de-identify the primary profile and environment-scoped identity.
Queue deletion with relevant email, analytics, support, and infrastructure processors.
Record completion and exceptions without rebuilding the deleted profile in the evidence record.
Let finite backups age out under the documented rotation policy.

Define what happens if a backup is restored. A deletion ledger containing minimal internal identifiers can prevent previously erased profiles from silently returning to active service after recovery.

Contracts with processors should state deletion assistance, timelines, backup treatment, and evidence. A dashboard button cannot compensate for a processor that offers no deletion path.

Handle legal holds as exceptions, not defaults

Another Indian law, a court order, a fraud investigation, or a contractual dispute may require specific records to be retained. Model this as a scoped legal hold:

identify the authority and purpose;
select only the necessary records;
record approver, start, review, and expiry;
restrict access;
suspend only the affected deletion action;
resume deletion when the hold ends.

“Potential future litigation” should not become a permanent global hold. Sector-specific teams in banking, payments, insurance, health, telecom, and regulated marketplaces should map their separate recordkeeping duties before adopting a general startup schedule.

Build deletion as a testable product capability

A credible retention policy needs code and operations behind it:

scheduled expiry and purge jobs;
account export and erasure workflows;
processor-deletion queues with retries and evidence;
backup rotation and restore tests;
dashboards for overdue deletion tasks;
policy-version history;
legal-hold controls;
automated tests that expired credentials cannot authenticate;
periodic sampling that deleted identifiers are absent downstream.

Test both normal deletion and failure. What happens when the email processor is unavailable? When a purge job stops for a week? When a customer requests deletion for an end user while a security incident is open? Those are product states, not policy footnotes.

A defensible policy has an owner

For every category, publish internally:

data → purpose → trigger → period → deletion action → exception → owner

Review the matrix when you add an authentication method, analytics destination, provider, new market, or regulated use case. Show users a clear summary in the privacy notice, and keep the operational detail in the internal retention schedule and customer DPA.

The goal is not the shortest possible period or the largest possible archive. It is a lifecycle where every retained record has a current purpose, every exception has authority, and every deletion promise can be executed and demonstrated.

NamoID provides environment-scoped identities, expiring authentication artifacts, user export and erasure surfaces, and auditable security events. Your organisation remains responsible for selecting and reviewing the periods that apply to its product and sector. Create a NamoID account to begin in Test.

Authentication Data Retention for Indian Startups