Zerodha is extremely cautious, and security as a practice is baked into processes when writing code and managing infra. To ensure the safety of client data, some of the common-sense practices are as follows:

• Regular internal and external penetration testing and audits.
• Regular human and automated reviews of infrastructure.
• The default policy is to limit internet exposure. All new pieces added to the infrastructure are disconnected from the internet and reviewed regularly.
• Cloudflare in front of all public endpoints that provide web app firewall, bot and DDoS protection.
• Different systems are located on different networks to isolate them from each other.
• Employee computers are on VPN and require 2FA to access, and access to systems is based on their department and roles.
• This role-based access is embedded as a practice into the compliance department that clears access and their processes as well.
• Non-tech employee computers run Linux to reduce the large attack surface of Windows systems.
• Zerodha self-hosts all internal systems on private networks without the involvement of IT vendors, eliminating third-party maintenance and access.
• No key or password-based access to AWS cloud resources.
• Developers use passwordless certificate (+2FA) based SSH logins to critical systems.
• Client accounts are supported with 2FA and app-based TOTP. See How to set up 2FA security to log in to Kite web? And How to set up Time-based OTP (TOTP) to log in to Kite?
• Instant alert when Kite is logged in from unfamiliar geographic locations. See, Why did I get an email alerting me about a login from a different city?
• All the apps (Kite, Coin and Console) use a single login (SSO) + 2FA.
• SEBI has official cybersecurity guidelines (WEB) that all brokers must adhere to and be audited.

Being cautious of security and applying whatever possible common-sense security principles is all one can do in complex, interconnected systems.

100% security does not exist. For example, in 2018, all Intel processors globally became vulnerable overnight (MELTDOWN, SPECTRE vulnerabilities). In 2014 the Heartbleed vulnerability rendered a significant majority of the internet and its security infra (SSL / TLS) vulnerable. In 2010 the Stuxnet malware attacked a specific nuclear powerplant which was not connected to the internet.