# How to take inventory of shared accounts and what to record A shared account inventory lists who knows each password and who may use each account. Find the accounts, record what matters, sort them, and keep it current. Updated: October 16, 2026 A shared account inventory is a list of the accounts several people use at your company, showing who knows each password and who may use each account. A shared account's records don't show which person acted ([What is a shared account?](/guides/shared-accounts/what-is-shared-account)). So this list is the first step toward knowing who used each account. ## What the inventory is for The inventory gives you what you need for three decisions. Can the account be split into personal ones? If it stays shared, who uses it and how? Can you close it? You can't answer any of them without knowing who knows the password and who uses the account. Microsoft's Entra ID documentation lists the drawbacks of sharing by handing out a username and password. You can't tell who has access, and you can't tell who accessed the app. To remove someone, you have to change the password and send it out again. An inventory answers the first of these with a list. The CIS Controls, published by the Center for Internet Security, start account management the same way. Safeguard 5.1 asks you to "establish and maintain an inventory of all accounts managed in the enterprise." At minimum it holds each person's name, username, start and stop dates, and department. Active accounts are confirmed as authorized at least quarterly. That model assumes one person per account. A shared account has one username for several people, so its list needs extra columns for who knows the password and who uses it. ## Where to find shared accounts Look before you build the list. If you rely on an admin's memory, you can miss services a department signed up for on its own. Five places help, and each one misses something. 1. Invoices, expense reports and company card statements show paid services and who signed up. They miss free plans, and services someone pays for on a personal card. 2. Your identity provider (a service such as Okta or Microsoft Entra ID that signs employees in to many apps) shows the apps connected to it. It won't show services nobody connected, where people sign in with a username and password directly. 3. Email to company addresses, such as notices and password resets, shows services signed up with a department or shared address. It misses services signed up with someone's personal address. 4. Passwords saved in work browsers and shared folders in a password manager show logins in actual use. They miss what's saved in browsers on personal devices. 5. Asking each department tells you what an account is for, who uses it and how it was handed over. A login one person thinks of as theirs alone can still stay hidden. When you ask, skip "Do you have shared accounts?" Ask how people sign in when the usual person is out. That's a question about how work gets done, so people answer it without feeling accused. ## What to record Keep the columns to what you'll use for sorting and for departures. This is the full set. The seven minimum columns in [Managing shared accounts](/guides/shared-accounts) are part of it. 1. Service: the name and the sign-in page address. This keeps look-alike services apart. 2. Username: the email address or user name used to sign in. This separates multiple accounts on one service. 3. Purpose: the work it's for. This is your reason to keep, merge or close it. 4. Owner: the responsible team and the person who can change settings. This decides who acts on changes, closures and departures. 5. Who knows the password: the people who know it now. Mark people who knew it before as former, with the date they stopped using it. This tells you whether a departure means a password change. 6. Who uses it: the people whose work calls for this account. The gap between this column and the previous one shows how far the password has spread. 7. Two-step verification: the method, the phone or number that receives the code, and where backup codes are kept. This tells you what to change when someone is out or leaves. 8. Where the password is kept: paper, a file or a password manager. This tells you which copies to update after a change. 9. Last changed: the date the password and two-step verification last changed. This shows accounts nobody changed after someone left. 10. Last checked: the date someone last reviewed this row. This shows rows that have slipped out of review. 11. Use records: whether there's a way to tell who used the account. That might be the service's activity log, a check-out log, or the log of a tool that enters the password for people. Keeping an account shared depends on this. 12. Can it be split: whether it can move to personal accounts, and if not, why. This feeds the sorting step. Record where each password is kept, never the password itself. If the list holds passwords, everyone who can read the list knows them. ## Sorting the accounts Once the list is filled in, each account gets one of three outcomes. 1. Split into personal accounts. The service supports several users and you can take on the setup. Give each person an account, then delete the shared one or change its password so it can't be used. 2. Keep it shared. There's a reason it can't be split, and you can tie each use to a person. Keep the people who can use it to a minimum, and set how use is recorded and what happens when someone leaves. [When shared accounts can't be split](/guides/shared-accounts/when-accounts-cannot-be-split) covers these cases. 3. Close it. It has no purpose, or nobody knows when it was last used. Cancel or delete it, and note the closing date in the list. Tying use to a person is a separate job from the list. The list shows who may use an account, not who did something on a given day. How to run the accounts you keep is in [Managing shared accounts](/guides/shared-accounts). ## When to update the list The list starts going stale the day you finish it. NIST SP 800-53 Rev. 5 asks organizations to notify account managers when users are terminated or transferred (AC-2 h). It asks for account reviews at a set frequency (AC-2 j), and for account management that follows personnel departures and transfers (AC-2 l). For a shared account list, that means these triggers. - When someone joins the team or takes on this work, add them to "who uses it" and "who knows the password," and confirm where two-step codes go. - When someone leaves or changes roles, change the password and two-step verification, update the last-changed date, and mark the person as former in "who knows the password." - When a contract renews or ends, confirm the purpose and owner. If you cancel, record the closing date. - At the scheduled review, check every column, fill in the last-checked date, and flag accounts with no known last use for closing. How often to run the full review is your decision. AC-2 j leaves the frequency to the organization. CIS safeguard 5.1 sets quarterly as the minimum for confirming that active accounts are authorized. ## Frequently asked questions **Which accounts should the inventory cover?** Every account whose password more than one person knows. Include free plans, services paid on a personal card, tools a department set up itself, and anything signed up with a shared email address. **Should the list include the passwords?** No. Record where each password is kept. If the list holds passwords, everyone who can read it knows them, and the column for who knows the password stops meaning anything. **Does the list show who used an account?** No. It shows who may use each account, not who did something on a given day. You need a separate way to record each use by person. **How often should we review the list?** Update the affected rows whenever someone joins or leaves, or a contract renews or ends. Then review every row on a set schedule. CIS safeguard 5.1 asks you to confirm active accounts at least quarterly. ## Sources - [Microsoft Learn: Sharing accounts and credentials - Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/users/users-sharing-accounts) - [CIS Controls Assessment Specification: CIS Control 5, Account Management](https://cas.docs.cisecurity.org/en/latest/source/Controls5/) - [NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (AC-2)](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf) ## How Junify handles this **Doing this by hand** To keep shared accounts safe, you track who knows each password, and change it and send out the new one whenever someone leaves. You also keep a separate record of who did what under the same login. **With Junify** For shared accounts you add to Junify, only admins know the password, and the people who may use each account are the ones assigned to it in Junify. That fills in the "who knows the password," "who uses it" and "use records" columns, and each use is recorded by person. Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when. - [Try the demo](https://www.junify.com/bpo/try?lang=en&scenario=shared-accounts&from=guide&cluster=shared-accounts&slug=shared-account-inventory) - [Book a 30-minute demo](https://www.junify.com/bpo/demo) ## More on this topic - [How 1Password and Junify differ for shared accounts](/guides/shared-accounts/1password-and-junify): 1Password fits storing and sharing each employee's own passwords. Junify fits shared accounts people should use without seeing the password. You can run both. - [How Bitwarden and Junify differ for shared accounts at work](/guides/shared-accounts/bitwarden-and-junify): Bitwarden fits employees who keep their own passwords and share some with trusted coworkers. Junify fits shared accounts used without seeing the password. - [Should employees save work passwords in the browser?](/guides/shared-accounts/browser-saved-passwords-at-work): Fine for a person's own work login, in a company-managed profile, on a device only they use. Avoid it for shared accounts, personal devices and personal sync.