Rolling out a password manager across an Indian SMB means moving every team's credentials out of spreadsheets, WhatsApp chats, and browser autofill into a zero-knowledge vault, then systematically finding and rotating reused or weak passwords, turning on MFA for the vault itself, and building an offboarding process that revokes access the day an employee leaves — not weeks later. Done properly, it is a two-to-four-week project, not a one-click software purchase.
Most Indian SMBs already "have" password management — it just lives in a shared Google Sheet named passwords_final_v2.xlsx or a WhatsApp group where the Wi-Fi password, the AWS root key, and the Tally login sit in the same thread as lunch orders. That is the actual starting point for this guide, and the actual attack surface.
Why spreadsheets and WhatsApp are the real risk, not "hackers"
Verizon's Data Breach Investigations Report has, year over year, identified stolen or reused credentials as one of the leading initial-access vectors in confirmed breaches — not zero-days, not exotic malware, but a password that worked somewhere it shouldn't have. A credentials spreadsheet or chat thread is what makes stolen-credential attacks so effective at SMB scale, for four compounding reasons:
- No access boundary. Anyone with the file has every password in it — the intern who needed the Canva login also has the payment gateway login.
- No audit trail. Nobody knows who opened the sheet, when, or from which device. If a laptop is stolen, you cannot tell what was exposed.
- No rotation discipline. Passwords in a spreadsheet get created once and reused forever, because changing one means manually finding and updating it everywhere it was copied.
- No offboarding hook. When someone leaves, the spreadsheet does not "know" to revoke their access — someone has to remember to change every password the departing employee ever saw, and in practice almost nobody does.
How zero-knowledge vault architecture actually works
A proper password manager is not "a website that remembers your passwords." The architectural property that matters is zero-knowledge encryption: your vault data is encrypted and decrypted entirely on your device, using a key derived from your master password. The vendor's servers only ever store and sync ciphertext — they cannot read your vault contents even if compelled to, and neither can an attacker who breaches the vendor's infrastructure, because there is nothing intelligible to steal without the client-side key.
The practical implications for a rollout:
- The master password never leaves the device. It is used locally to derive an encryption key (via a key-derivation function such as Argon2 or PBKDF2 with a high iteration count); the derived key, not the password, does the encrypting.
- A forgotten master password is often unrecoverable by design unless the organisation has configured an admin-recovery feature ahead of time. This is a feature, not a bug — but it must be planned for.
- Unencrypted vault exports (CSV) are the biggest self-inflicted leak in any rollout. Import/export should happen on one controlled machine, over a short window, with the export file deleted immediately after.
What to evaluate before picking a vendor
This guide is vendor-neutral — evaluate any candidate against these criteria, not a price sheet.
| Evaluation area | What to look for | Why it matters |
|---|---|---|
| Cryptography | Published, independently audited encryption design (not "military-grade" marketing copy); regular third-party penetration test summaries | Unaudited crypto is unverifiable crypto |
| Open standards | Support for open, portable formats for import/export; no proprietary lock-in on vault data | You must be able to leave without re-typing every credential |
| SSO integration | SAML or OIDC support so vault access rides on your existing identity provider | One less password to phish, one place to revoke access |
| SCIM provisioning | Automated user provisioning and deprovisioning tied to your HR/identity system | This is what makes offboarding actually happen on day zero, not "eventually" |
| Recovery model | Clear, documented account-recovery and admin-recovery options, with the trade-offs stated | You need a way back in that doesn't defeat zero-knowledge |
| Offline access | Vault usable without live internet (cached, still encrypted locally) | Field staff, factory floors, and patchy connectivity are normal in Indian SMB operations |
| Self-hosting option | Availability of a self-hosted or on-premises deployment mode | Relevant for regulated data or organisations wary of any third-party custody, even encrypted |
| Passkey / FIDO2 support | Native support for storing and using passkeys, not just passwords | Passwords and passkeys are converging into one credential manager |
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanThe password manager rollout plan
Step 1 — Inventory where credentials live today
Find out where passwords actually are: browser-saved passwords per device, shared spreadsheets, chat threads, sticky notes, individual memory. You cannot secure what you haven't located. A short survey plus a look at browser password exports from a sample of devices is usually enough to size the problem.
Step 2 — Pick and pilot with one team
Run a pilot with a single team (usually finance or IT, since they hold the highest-value credentials) for one to two weeks before a company-wide rollout. This surfaces workflow friction — browser extension conflicts, mobile enrolment, shared-vault permissions — while the blast radius of a mistake is still small.
Step 3 — Define vault structure and shared vaults
Design shared vaults around teams and access boundaries, not individuals: a Finance vault, a Marketing/Social vault, an IT/Infrastructure vault, an executive vault. Each should map to who genuinely needs those credentials day to day — this is where a spreadsheet's "everyone sees everything" problem gets fixed structurally.
Step 4 — Bulk import
Import existing credentials from browsers and any spreadsheet inventory in one controlled session, on one machine, then permanently delete the source file and clear the browser's local password store. Do not leave the CSV export sitting in a downloads folder.
Step 5 — Detect reused and weak passwords
Every mainstream password manager includes a built-in audit that flags reused, weak, and old passwords across the imported vault. Run this immediately after import — this is usually the moment an SMB discovers its admin panel, email, and accounting software share the exact same password.
Step 6 — Forced rotation of the worst offenders
Prioritise rotation by blast radius, not by count: financial systems, domain/DNS registrar, cloud provider root/admin accounts, and email admin accounts go first. NIST SP 800-63B guidance favours long, unique passphrases over complex-but-reused strings, and discourages mandatory periodic rotation for its own sake — rotate because a password is weak, reused, or exposed, not on a calendar.
Step 7 — Enable MFA on the vault itself
The master password is now a single point of failure protecting every other credential — it must be protected with multi-factor authentication, ideally an authenticator app or hardware security key rather than SMS OTP. This is non-negotiable and should happen before, not after, bulk import.
Step 8 — Document the break-glass procedure
Define, in writing, what happens if the vault administrator is unreachable, leaves without notice, or loses their device: who has emergency-access rights, how they are granted, and how that access is itself audited and time-boxed. A break-glass procedure that only exists in one person's head is not a procedure.
Step 9 — Offboarding revocation, the step most companies forget
The moment an employee's last working day is confirmed, their vault access must be revoked and any credentials only they used must be rotated. This is the step spreadsheets and chat-based "password management" can never deliver, and the one most SMBs still handle manually and late — often days after the person has left, if at all. SCIM-based deprovisioning tied to your HR or identity system turns this into something automatic, not remembered.
How this fits with MFA and passkeys
A password manager is not a replacement for multi-factor authentication — it is the foundation that makes MFA and passkeys practical, because it gives every account a genuinely unique, non-memorised password to pair MFA with. Passkeys, built on the FIDO2/WebAuthn standards from the FIDO Alliance and the W3C, remove the shared-secret problem entirely by using device-bound cryptographic key pairs instead of a password — a modern password manager increasingly acts as the sync and storage layer for passkeys as well as passwords, which is why passkey support belongs on your vendor evaluation checklist rather than a separate future project.
The chart below is an illustrative breakdown, not a cited statistic — it reflects a typical pattern observed during the Step 1 inventory exercise, not a published survey figure.
Bachao.AI, by Dhisattva AI Pvt Ltd, treats credential hygiene as part of the broader attack-surface picture we assess in every VAPT engagement — a free VAPT scan will flag exposed credentials and weak authentication alongside your infrastructure findings. For regulated organisations that need a formal compliance angle on identity and access controls, see our DPDP compliance guidance, and browse our blog for related guides on MFA rollout and access-control hardening.