Multi-Factor Authentication (MFA)
Logging in with more than one proof of identity, such as a password and a code from a phone.
Multi-factor authentication asks for two or more different proofs of identity at login, such as a password and a code sent to your phone. A stolen password alone then no longer opens the door.
Meaning of Multi-Factor Authentication (MFA)
MFA makes stolen passwords far less useful. It is not named in the Rules, but it is a common part of reasonable security safeguards for systems that hold personal data.
Multi-factor authentication, or MFA, combines factors from different categories: something you know, such as a password or PIN; something you have, such as a phone, a hardware key or a smart card; and something you are, such as a fingerprint or face scan. Two passwords do not count, because they are the same category. The idea is that an attacker who steals one factor still lacks the other.
The DPDP Rules 2025 do not mention MFA by name. Rule 6 asks for appropriate measures to control access to computer resources, and MFA is one of the most common ways to meet that expectation for systems holding personal data. Whether a particular system needs it depends on risk, but administrator panels, remote access, cloud consoles, e-mail and systems with bulk personal data are the usual candidates.
Not all factors are equally strong. SMS codes can be intercepted through SIM swapping, authenticator apps generate time-based codes on the device, push approvals are convenient but can be abused through repeated prompts, and hardware security keys resist phishing best. Regulators in finance, such as RBI for digital payments, already require additional factors for many transactions, and these requirements apply alongside the DPDP Rules.
MFA protects the login, not the data itself. It does not replace encryption, role-based permissions or logging, and it does not help once an attacker holds a valid session. It also processes personal data of its own, such as phone numbers and biometrics, which are subject to notice, security and retention rules under the Act.
Examples of Multi-Factor Authentication (MFA)
An employee enters a password and then approves a prompt on her phone before opening the HR system.
A firm holding client PAN and bank details requires an authenticator app for e-mail and the document portal. When a partner's password is phished, the attacker cannot proceed without the second factor.
A pharmacy asks customers for a one-time password before showing prescriptions or changing the delivery address. Its staff use hardware keys for the admin console and refuse approval prompts they did not start.
A school app lets teachers log in with a password alone. After a parent's account is accessed by a student guessing a weak password, the school adds a second factor for teachers and administrators first.
Why Multi-Factor Authentication (MFA) matters
Stolen or guessed credentials remain among the most frequent causes of breaches, whether through phishing, reused passwords or credential stuffing from earlier leaks. MFA blocks most such attempts, which is why it is one of the cheapest and most effective controls a small organisation can adopt.
If a breach happens through an admin account with only a password, the Board is likely to ask why a widely available control was not used, and the question links to the penalty of up to ₹250 crore for failing to take reasonable security safeguards. Using MFA also reduces the chance of a notifiable breach under Section 8(6) and Rule 7.
How it works in practice
- 1Rank your systems by risk and turn on MFA first for administrator accounts, remote access, e-mail, cloud consoles, payroll and HR systems and any system with bulk personal data.
- 2Choose factors suited to the users: authenticator apps or hardware keys for staff and administrators, and app-based or SMS codes for customers where the transaction risk is lower.
- 3Provide recovery procedures that do not undo the security, such as identity checks by a manager or backup codes stored safely.
- 4Apply step-up checks for risky events, such as a login from a new device, a change of mobile number or a large export.
- 5Monitor failed attempts and unusual approvals, train staff to refuse unexpected prompts, and disable accounts that cannot use MFA.
Where it appears in the DPDP Act and Rules
Common mistakes to avoid
Relying on SMS codes alone for high-risk accounts. Attackers can swap SIMs, so use stronger methods for privileged users.
Applying MFA to customers but not to staff admin tools. A single compromise there exposes everyone.
Approving every push prompt without checking. Attackers send repeated prompts hoping for a tired approval.
Making account recovery too easy. A phone call to the help desk then bypasses the second factor.
Compliance tips
Roll out in phases, starting with administrators, and publish simple instructions to reduce help-desk calls.
Keep backup methods for staff who lose phones, and store emergency codes securely.
Include MFA coverage as a figure in your regular security report, and aim for full coverage of privileged accounts.
Common questions about Multi-Factor Authentication (MFA)
Does the DPDP Act require multi-factor authentication?
Neither the Act nor Rule 6 names MFA. Rule 6 does require appropriate [access control](term/access-control), and MFA is a widely used way to meet that for important systems. The need depends on risk.
What counts as multi-factor authentication?
It needs two or more factors from different categories: something you know, something you have, or something you are. A password plus an app code or fingerprint qualifies. Two passwords do not.
Is OTP by SMS good enough?
It is better than a password alone, but weaker than app-based codes or hardware keys because of SIM-swap and interception risk. Use stronger methods for administrators and high-risk accounts.
Does MFA make my system compliant with Rule 6?
No. It is one control. Rule 6 also expects encryption or similar measures, logging, backups, log retention and processor contract terms, so MFA supports compliance without completing it.