Password manager for accounting firms: one identity, not a second login
Most password managers give a firm one more password to protect. The way we run it, there is no new password at all. Staff sign in with the Microsoft identity they already have, the firm's credentials live in shared vaults instead of a spreadsheet, and the day someone leaves, disabling their Microsoft account locks their vault.
The short answer
A password manager on its own solves one problem and creates another. It ends the shared spreadsheet, then hands every staff member a master password that is now the most valuable credential in the building. The fix is to make the password manager part of the firm's identity rather than a second login. We deploy Keeper through Microsoft Entra ID, so signing in to the vault is the same Microsoft sign-in staff use for email. There is no master password, because there is no second login. Everything else follows from that one decision: shared folders driven by the firm's Microsoft groups, credentials staff can use without seeing, the firm's app logins carrying their own second factor inside the vault, and an offboarding that is one action in Entra ID.
Why the second login is the problem
Accounting firms run on logins the vendor never designed for a team. Xero, XPM, the document platform, a dozen practice apps. The living example is the Xero login problem: staff end up sharing one set of credentials because the product gives them no clean alternative.
A consumer-grade password manager fixes the sharing and introduces a new single point of failure: the master password. It is typed on every device, reused under pressure, written down eventually, and phishable. Once it goes, the whole vault goes with it. The ACSC's public advice puts multi-factor authentication first and then says a password manager "can help" with the rest. The question is what the manager itself is protected by.
How the Microsoft sign-in becomes the vault sign-in
We connect Keeper to Microsoft Entra ID with SAML, so a staff member opens Keeper and is signed in with their Microsoft account. No master password is created, which means there is nothing extra to write down and no second credential to phish. The phishing target becomes the Microsoft sign-in, which is the one credential the firm already protects hardest. Each device holds its own encryption key pair, a new device needs an approval before it can open the vault, and Keeper itself cannot decrypt what is in it.
Because the sign-in is the Microsoft identity, it inherits everything the firm already enforces on that identity: multi-factor authentication, conditional access and device compliance. We add the policy that says the vault only opens on a device the firm manages. On a personal laptop or an unmanaged phone, the sign-in is refused, so the vault never opens there in the first place.
Every login the firm owns, in one place
Credentials the firm owns, as opposed to the ones an individual owns, go into shared folders. A folder is shared with a team, with per-record permissions (view only, edit, share), and we provision the teams straight from Entra ID groups. Remove someone from the group and the folders leave their vault. The firm's Microsoft group membership becomes the access list for its passwords.
It is not only the credentials you planned for. Every firm accumulates the other kind: the supplier portal someone set up in 2019, the domain registrar, the alarm company, the industry body login, the client's software account they asked you to hold, the Wi-Fi password on a sticky note. Those are the ones that live in someone's head, a notebook or a Teams chat, and they are the ones that go missing the day that person leaves. The vault is where they finally get a home, in a folder the right people can see, with an owner.
The vault also settles the hygiene argument nobody wins by memo. Every new password is generated, long and random, and different for every account, because the tool makes it rather than the person. We set the rules at the record level, so a login cannot be saved with a password that falls short of them, and the generator is the only way to fill the field. Staff stop choosing passwords, which is the whole point. What slipped through before the vault existed gets found afterwards: we run Keeper's security audit across the firm, which scores every user on password strength, how many of their passwords are unique and whether two-factor is on, without showing anyone the passwords themselves. A reused password shows up as a number on a report, and then it gets fixed.
Two things inside the vault matter more than they sound. The first is masking. Keeper can hide a password from the person using it: the login is filled into the form for them and the password itself is not shown. For a practice app login that a junior needs to use but has no reason to know, which is exactly the Xero case, that is the difference between a credential that can be used and one that can be repeated out loud, screenshotted or carried in someone's head to the next job. The second is secure notes, records whose contents stay masked until someone unmasks them on purpose. That is where the licence keys, recovery codes and one-line instructions that otherwise live in a Word document belong.
The app's second factor lives in the vault too
This is the part that changes how a firm feels day to day. A practice app that asks for a six-digit code usually ties that code to one person's phone. The firm then depends on that phone being charged, present and still employed here. We store the app's two-factor code in the same Keeper record as its masked password, and the browser extension fills it when the site asks. Records are shared, so nobody has to, in Keeper's own phrase, "track down the person who has the only device containing the code", and they are backed up, so losing a device does not mean resetting every code.
So the second factor for the firm's app stack is not gated on a staff member's personal phone. It travels with the vault, opens only on a compliant, managed work device, and is filled right there in the browser extension. Staff do not reach for a phone. The firm's primary identity, the Microsoft account, keeps its own multi-factor authentication and conditional access in front of all of it.
What changes on Monday
The spreadsheet is imported once, into shared folders named for the teams that use them. Staff see Keeper inside their Microsoft sign-in, with the logins they are entitled to already there. Browser-saved passwords are imported or retired, because a password the browser remembers is a password outside the model. Nobody is handed a master password, because there is none to hand out.
The day someone starts
A new starter's primary identity is their Microsoft account, with the firm's conditional access and multi-factor authentication already enforced on it. Their group memberships are set, the shared folders for those groups arrive in their vault, and the app logins they need are already provisioned, masked password and second factor included. The first day is one sign-in. We call that Worktopia managed, and it is the same arrangement that makes the leaving day simple.
The day someone leaves
Offboarding a staff member is the same action as disabling their Microsoft account. Keeper sees the identity provider disable the user and locks the vault. Nothing is re-entered, nothing is reset, and there is no second list of accounts to remember. Whether we flip the switch or the firm does, it is one action in Entra ID.
What was in their vault does not leave with them. An administrator moves the departed user's records and folders into another user's vault, in a single folder carrying the leaver's email address, and the original account is then permanently deleted. It is not a back door: the account has to be locked first, the leaver is notified at each step, and nobody can open a live vault from the admin console.
There is one condition, and it is why this is set up on day one rather than on the day someone resigns. The transfer policy has to be in place, and accepted by the user at a sign-in, before the departure. We switch it on during deployment and every new starter accepts it at first sign-in, so the consent exists long before anyone needs it. Nothing is lost, because the consent happened on their first day, not their last.
Where the data sits
We provision firms in Keeper's Australian region, so the encrypted vault data stays in Australia. Records are encrypted on the device with AES-256 keys generated there, and Keeper cannot decrypt them. Its cryptographic module is FIPS 140-3 validated (certificate #4976) and it holds SOC 2 Type 2 and ISO 27001 certifications.
What this is not
It is not a regulatory requirement. No Australian regulator names a password manager as mandatory for an accounting firm. The TPB's cyber guidance is best practice rather than mandate, as we set out in what the TPB actually requires on cyber security, and the ACSC's public advice is recommendation. A firm that runs its credentials this way is well above the stated floor. The whole Australian picture, law, regulators and insurers, is in our guide to cyber security for accounting firms.
It is also not a substitute for the identity it sits behind. The vault is as strong as the Microsoft sign-in in front of it. Multi-factor authentication on that identity, enforced for everyone, is the control the whole model depends on. The TPB's best-practice list puts it more gently, as "consider using a second form of authentication" where possible; we treat it as non-negotiable.
