Every Indian MSME I've sat with in the last two years has a version of the same problem: somewhere between 60 and 300 credentials scattered across a Google Doc called "Shared Passwords (NEW)", a pinned Slack message, a Notion page titled "IT — do not share", and three people's memories. The AWS root. The Godaddy login for the domain. The SBI Corporate portal. The Tally admin password. The WiFi PSK that everyone has taped to their monitor anyway.
Moving off that into a proper zero-knowledge vault is the single highest-leverage security change a small company can make — higher than MDM, higher than SSO, higher than turning on MFA on five SaaS tools. It closes the attack surface that produces most of the real breaches I see in India: not sophisticated zero-days, but a shared credential that leaked through a former employee's laptop.
This article is the migration plan. It assumes you've already decided to switch (if you haven't, the zero-knowledge explainer is the place to start) and you need to execute without breaking anything.
Step 1: Inventory every credential
The goal of this step is to produce one spreadsheet. Not a pretty one. A Google Sheet with four columns: what it is, where it currently lives, who currently uses it, what tier of sensitivity it is. Expect to spend 2–4 hours.
Sources to mine:
- The Google Docs / Notion / OneNote pages people know about
- The "saved passwords" in everyone's Chrome / Edge / Safari
- The email inboxes — search for "password", "credentials", "login", "welcome to"
- The WhatsApp groups — search the same terms
- Slack DMs and channels — same search
- Post-its on monitors (you will find some)
- The autofill on shared kiosk machines (printers, meeting-room laptops)
You will end up with between 60 and 400 items depending on team size and how long you've been accumulating. For a 30-person Indian MSME I recently migrated, the count was 178 distinct credentials across 62 services.
Step 2: Categorise everything
Every credential in the spreadsheet belongs to exactly one of these five buckets. Tag the column.
- Personal-only — an individual's login to a SaaS tool. Gmail, LinkedIn, their Figma. Goes into that person's individual vault.
- Team-shared — credentials multiple people legitimately need. The AWS root, the domain registrar, the office WiFi, the Tally admin. Goes into a shared vault scoped to the right group.
- Service / system accounts — credentials used by code or automation. The deploy bot's GitHub token, the backup script's SSH key. Goes into a separate service-account vault with stricter rotation rules.
- SSO-eligible — logins to services that could be behind SSO (most of your SaaS tools). Flag these — once you move to SSO via something like Warden, the password itself becomes irrelevant.
- Delete — credentials for services you no longer use. Retire them now rather than migrating them.
Most MSMEs discover in this step that ~30% of credentials are category 5 (delete), ~20% are category 4 (SSO-eligible), and the real migration work is on the 50% that remain. That re-sizes the problem.
Step 3: Pick a zero-knowledge vault
The criteria are covered at length in the zero-knowledge explainer, but the short form for this article:
- True zero-knowledge architecture (your master password derives the encryption key client-side)
- Team-shared vaults with role-based access
- Browser extension on Chrome/Firefox/Edge that auto-fills reliably
- Temporal access (credentials that auto-expire on a date) — this is the feature that makes exit-handling tractable
- Audit log of who accessed what
- A deletion workflow that actually removes the ciphertext, not just hides it
Concrete evaluation against Unit vs 1Password Business and the competitive landscape is in the compare pages — pick based on budget, India-support needs, and whether you want USD-billed or INR-billed.
Step 4: Migrate — but not in one weekend
Big-bang migrations break things. The pattern that works:
Week 1: Onboard everyone. Every employee gets an account, sets a strong master password (the vault's own check catches weak ones), installs the browser extension, and does a 10-minute orientation. Start with the IT admins so they can coach the rest.
Week 2: Migrate personal credentials. Everyone moves their own logins into their individual vault. Tell people to import from their browser's saved-passwords. This is the easy part and it gets everyone comfortable with the tool before the team-shared migration.
Week 3: Migrate team-shared credentials. The admin imports the team-shared bucket (category 2 from step 2) into scoped shared vaults. Important: do not bulk-import everything into one "Company" vault — segment by actual need (Engineering, Finance, Ops, Sales). The principle of least privilege matters even inside a 30-person company.
Week 4: Service account migration and rotation. Move category-3 credentials in, rotate every one during the move. Service accounts are the ones most likely to have leaked historically; the rotation is load-bearing.
The whole process is typically 3–4 weeks elapsed, maybe 20 admin-hours of work plus 10 minutes per employee.
Step 5: Rotate the high-value credentials
Not everything needs rotating on day one — but these do:
- Domain registrar login (Godaddy, Big Rock, whoever)
- DNS provider (Route 53, Cloudflare)
- Email admin (Workspace, M365, Nectr)
- Cloud provider root (AWS, Azure, GCP)
- Production database admin
- Payment processor (Razorpay, Stripe, Cashfree)
- SMS / email transactional provider (Twilio, SES, Msg91)
- GitHub org owner
These are the credentials that if compromised, nothing else matters. Rotate them during migration. Every subsequent rotation is easier because the vault generates and stores random passwords, so there's no "but I have to remember it" excuse.
Step 6: Decommission the old sources
The Google Docs, Slack pins, Notion pages — delete them. Not archive. Delete. Do this after you've verified every credential made it to the vault, obviously, but the old sources need to go. The value of a zero-knowledge vault is undermined if the plaintext copy still lives in a Google Doc.
A variant of this bites teams: "we'll keep the Google Doc for reference." Six months later, someone updated a credential in the vault but not in the Doc, and a junior engineer pulled the stale value. Delete the Doc.
Step 7: First 30 days — audit and enforce
In the first month post-migration, do these:
- Access audit: who has access to which shared vault? Revoke anything that looks historical. For most MSMEs this is where you discover that the marketing intern from 2024 still has access to the AWS shared vault.
- Password strength audit: most vaults show a security score. Aim for 90%+ strong. Weak passwords are typically pre-migration imports that nobody rotated.
- Unused credentials: anything not accessed in 30 days, flag for the credential's owner to confirm "still needed". Kill the stale ones.
- Exit rehearsal: pick an employee and simulate their exit. Are the temporal access expiries set? Does revocation actually take effect? If your vault doesn't make this trivial, you picked the wrong vault.
The compliance angle
A zero-knowledge vault is load-bearing for:
- DPDP Act 2023 reasonable-security obligations (encryption of access credentials for personal-data-processing systems)
- ISO 27001 Annex A controls on secret management (A.5.17, A.8.2, etc.)
- SOC 2 Type II — every audit now asks about credential storage
If you're going after enterprise customers, a functioning vault + audit log is a line item on most vendor-onboarding questionnaires. The DPDP face-attendance compliance article has more on the regulation's texture.
Where this ends
A year after a clean migration, the team I mentioned at the start — the one whose customer contract went sideways because of a Google Doc — had fewer than 15 active admin-level credentials across the entire company, rotated quarterly. No shared plaintext anywhere. Full audit trail. A new hire could be onboarded into the right credentials in 15 minutes via shared-vault access, and fully revoked in 5 on exit.
That's not a transformation. That's just a vault, wired correctly.
If you're picking a vault — Unit is Hives.cloud's rupee-priced take, designed for Indian MSMEs with GST invoicing and temporal access built in. For a broader view of where credential management sits alongside identity, email, attendance, and asset management in a single stack, our 6-product thesis lays out the full picture.