Zerodha new device login account security two factor authentication password reset TOTP

Zerodha new device login notification

From WebNotes, a public knowledge base. Last updated . Reading time ~11 min.

The Zerodha new device login notification is an alert sent to your registered email and your current device the moment your correct Kite password is entered on a device Zerodha has not seen before, sent before two-factor authentication is completed. It tells you that your login credentials have been entered on a new device, so you can confirm the login was yours or act quickly if it was not. The notification keys on the device, which is what separates it from the login-from-a-different-city alert that keys on IP location.

The detail that matters most, and that most clients miss, is the timing. Zerodha fires this notification “as soon as the correct password is entered on a new device before the 2FA is entered.” It does not wait for a successful login. The reason is deliberate: even if your second factor, your TOTP or app code, stops an intruder from getting in, the fact that the password was accepted tells you the password itself is known to whoever used that device. The alert is therefore a warning about your credential, not just a record of a completed login.

This article explains exactly what triggers the notification, why it arrives at the password stage rather than after login, how to tell a genuine own-login from an intrusion, the steps to secure the account if the login was not you, the quirk that different browsers count as different devices, and how this alert relates to the other login and 2FA alerts on a Zerodha account.

Conflict-of-interest disclosure. This guide is published by the WebNotes Editorial Team for informational purposes and is written independently. WebNotes operates a Zerodha account-opening referral programme, disclosed on the pages that carry the referral link; this guide does not carry it and earns no referral commission from the procedure described here.

What triggers the notification

The trigger is a password, not a device alone. When your correct Zerodha password is entered on a device that is new to your account, the notification goes out immediately. Zerodha’s documentation is precise that it fires “as soon as the correct password is entered on a new device before the 2FA is entered,” and that it “informs the user that their login credentials have been entered on a new device.”

This has a clear implication. A wrong password on a new device does not fire it; the notification is specifically about the correct password working on an unfamiliar device. So the alert is doing two jobs at once. If the login was you, it is a benign record. If it was not, it is telling you something important and uncomfortable: your password is correct in someone else’s hands. That distinction is why you should never dismiss this notification on autopilot.

Why it arrives before 2FA

Most people expect a login alert to confirm a completed login. This one fires one step earlier, at the password, and the reason is the threat model it is built for. Two-factor authentication is the wall that stops an attacker who has your password but not your second factor. If the alert only fired after a successful login, an attacker who had your password but was blocked by 2FA would generate no warning at all, and you would never learn your password had leaked.

By firing at the password stage, the notification surfaces the credential exposure regardless of whether 2FA holds. A blocked login still tells you the password is compromised, which is the cue to change it before the attacker also obtains your second factor. This is the same defence-in-depth thinking behind the multiple-incorrect-2FA notification , which warns you when someone is failing at the second factor. Together the two alerts cover both halves of a login: the password being known, and the second factor being attacked.

How to verify it was you

Run through the situations where you yourself trigger the notification, because most of the time you are the cause:

  • A new phone or tablet. Installing Kite on a new device and logging in is a textbook trigger.
  • A reinstalled app. Deleting and reinstalling Kite, or a factory reset, makes the device look new even on the same hardware.
  • A different web browser. Zerodha treats “Kite web sessions on different web browsers as separate devices,” so logging in on Chrome after using Firefox, or in a fresh browser profile or incognito window, fires it on your own computer.
  • A cleared browser. Clearing cookies or browsing data can make a familiar browser present as new.

If the notification lines up with one of these, the login was yours and no action is needed. If it does not, if you were not logging in anywhere when it arrived, treat it as a credential-exposure event and move to the security steps. A “Did you know” note Zerodha attaches to this alert is relevant here: per an NSE circular, brokers must store and share the device details used to place, modify and cancel orders, so the device record behind this alert is also part of the regulatory order-trail, not just a convenience.

Securing the account if it was not you

If you did not enter your password on a new device, your password is compromised, even if 2FA stopped the login. Zerodha’s instruction for an unrecognised login is unambiguous: “the password must be changed immediately to prevent the account from being compromised.” Do that first; see how to recover or reset your Kite password , which works on both the Kite app and Kite web.

Then close the gap that let the password matter. Enable TOTP if you have not, so that a password alone can never complete a login again: the attacker would also need a time-based code from your authenticator app. Review your active sessions from My profile and clear them so no logged-in session of the attacker’s survives the password change. If you see trades or fund movements you did not make, or you cannot regain control, raise a ticket with Zerodha and treat it as a security incident; cross-check the exchange trade SMS and the CDSL demat-debit SMS to see whether anything moved while the account was exposed.

How it relates to the other login alerts

Three alerts cluster around logging in, and each watches a different thing.

AlertKeys onFires whenTells you
New device login notificationThe devicePassword accepted on a new device, before 2FAYour password worked on an unfamiliar machine
Login from a different cityThe IP locationA completed login from a new IPYour account logged in from a new network or city
Multiple incorrect 2FAThe second factorRepeated wrong 2FA entriesSomeone is failing at your second factor; the account may be blocked

Read together, they let you reconstruct what happened. A new-device notification with no different-city alert means the unfamiliar device was on your usual network. A new-device notification followed by a multiple-2FA notification means someone has your password and is now attacking the second factor, the strongest signal to change credentials at once. The shared-IP alert is a separate, surveillance-driven message and does not belong to this login-security cluster.

See also

External references

References

  1. Zerodha support, Why was a notification sent for logging into Kite on a new device? (as of 21 June 2026).
  2. Zerodha support, Why was a notification sent for entering multiple incorrect Two Factor Authentication (2FA)? (as of 21 June 2026).
  3. NSE requirement that brokers store and share device details used to place, modify and cancel orders (referenced in Zerodha support documentation).

Frequently asked questions

Why did I get a notification that my Kite credentials were entered on a new device?
Zerodha sends it the moment your correct password is entered on a device it has not seen, before 2FA is completed. It tells you your login credentials were used on a new device, so you can confirm it was you or act if it was not.
Does the new-device notification mean someone got into my account?
Not necessarily. It means your correct password was entered on an unfamiliar device. If 2FA was not completed, the login did not finish. But it does mean your password worked on that device, so verify it was you and change the password if not.
Why does it fire before 2FA instead of after a successful login?
By design. Firing at the password stage warns you that your password is known to whoever used that device, even when 2FA blocks the login from completing. You learn the credential is exposed regardless of whether the second factor held.
It was me on my new phone. Do I need to do anything?
No. If you recognise the login, for example a new phone, a reinstalled Kite app, or a different web browser, no action is needed. Kite web sessions on different browsers count as separate devices, so a browser switch can trigger it.
What do I do if the login was not me?
Change your Kite password immediately to stop the account from being compromised, then enable TOTP so a password alone cannot complete a future login. If you cannot regain control or see unfamiliar trades, raise a ticket with Zerodha at once.
Does opening Kite in a different browser count as a new device?
Yes. Zerodha treats Kite web sessions on different web browsers as separate devices, so logging in on Chrome after using Firefox, or on a fresh browser profile, can fire the new-device notification even on your own computer.
How is this different from the login-from-a-different-city alert?
The new-device notification keys on the device and fires at the password stage. The different-city alert keys on the IP location of a completed login. One says the machine is new; the other says the network or city is new.

Reviewed and published by

The WebNotes Editorial Team covers Indian capital markets, payments infrastructure and retail investor procedures. Every article is fact-checked against primary sources, principally SEBI circulars and master directions, NPCI specifications and the official support documentation published by the intermediary in question. Drafts go through a second-pair-of-eyes review and a separate compliance read before publication, and revisions are tracked against the SEBI and NPCI rule changes referenced in the methodology section.

Last reviewed
Conflicts of interest
WebNotes is independent. No relationship with any broker, registrar or bank named in this article.