The shared password spreadsheet problem is an access lifecycle problem

A password spreadsheet can start as a practical favour. Someone needs the supplier portal. A colleague is on leave. The person who set up the account has left. Soon there is a workbook in a shared folder with account names, usernames, passwords and perhaps recovery details.

People use it because it works quickly. That deserves a more useful response than scolding them for using Excel. The workbook may even have sensible controls around it. Microsoft Excel supports file encryption, and Microsoft 365 sharing can restrict access to the current file. Those measures reduce exposure. They still leave a hard business question: who has learned each credential, who owns it, and what happens when that person changes role or leaves?

Credentials need a lifecycle. A document has a different job.

That distinction becomes urgent during offboarding, a supplier dispute, a suspected exposure or an audit. Removing a departed employee from a SharePoint folder may stop their access to the live workbook. It cannot make them forget a password they saw last week or remove a synced file, download, printout or screenshot. The organisation then has to decide which accounts need a password change, who can perform it, and whether it has enough records to make the decision safely.

The way out is careful work with the business owner and security team. It is rarely safe to begin by deleting a workbook or changing shared credentials without coordination. A rushed change can lock a team out of a payroll system, a vendor portal or a recovery account at the worst possible moment.

Excel protection has several meanings

“Password protected” tells you very little until you know which control is in use.

Microsoft’s Excel guidance on file protection separates Encrypt with Password from workbook and worksheet protection. File encryption protects the contents of the file until the correct file password is entered. It is a meaningful control for a legacy workbook at rest. Microsoft also warns that a password-protected sensitive file can still be unsafe to distribute. Someone who has the file and the password can open it, and a recipient may make a copy.

Worksheet protection has a narrower purpose. It can stop people changing locked cells, hiding formulas from casual editing, or altering selected sheet actions. That is useful when a finance model or template needs to retain its shape. It does not make a visible password confidential. Nor should a lock on the workbook structure be treated as evidence that only approved people can read the contents.

Then there are cloud permissions. OneDrive and SharePoint allow owners to manage people’s access and sharing links. For the live object, this is far better than passing an attachment around by email. An owner can remove a person, change a link or limit sharing under the organisation’s tenant policy.

Each layer answers a different question:

File encryption asks whether a person can open this particular file.
Sheet or workbook protection asks who can change parts of it.
Cloud permissions ask who can reach the current shared object.
Credential management asks who is allowed to use an account, how that access ends, and what happens after exposure.

A shared spreadsheet may use all of the first three. It can still have an unresolved answer to the fourth.

Audit records need the same care. Microsoft documents auditing in Purview, but event coverage, retention, licensing and configuration differ between tenants. A file-access event is useful context. It does not prove that a person read a particular cell, copied a password, or signed in to the downstream account. The account’s own logs are often the place to investigate use of the account.

Copies change the offboarding job

Consider a team that shared a workbook with an external contractor for six months. The contractor leaves the project. The file owner removes their SharePoint access that afternoon. Good. The team then needs to work through the accounts the contractor could have seen.

Some may be low consequence and already protected by an individual identity, single sign-on or separate MFA. Some may be shared vendor accounts with billing authority. One could be the recovery mailbox for several systems. Treating all of them identically makes little sense. Leaving every credential unchanged because the link was revoked makes little sense too.

The file may have travelled in ways cloud permissions cannot recall. It could exist in a Downloads folder, a sync client, an attachment, an old backup, a printed handover pack, a browser password store or a screenshot on a phone. It may also exist in version history. The purpose of this exercise is not to assume the worst about a former colleague. It is to recognise that access to a secret, once granted, has a longer life than access to a file.

This is why offboarding requires an account-by-account decision. A documented process can set triggers for changing credentials after a leaver, role move, lost device, over-broad share or suspected copy. It should name an owner for the account, an owner for recovery methods and a fallback person who can act if the first owner is unavailable. The process also needs a safe route for systems where a password change affects integrations or breaks a service account.

The same thinking applies to staff transfers. Someone moving from accounts payable to a different role may no longer need a payment portal, even though they remain an employee in good standing. Access reviews work best when they start with named people and real account purposes, rather than an assumption that everyone in a team needs every shared login.

A password manager changes the working model

Government guidance supports the basics. The Australian Cyber Security Centre’s password manager guidance describes how managers can generate, store and fill login details, and recommends choosing reputable products with encryption, MFA, updates and breach alerts. CISA’s guidance on strong passwords makes the practical point: a manager makes long, random and unique passwords easier to use. NIST’s digital identity guidance says services should allow password managers and paste functionality, avoiding rules that push people towards memorable, reused passwords.

For a business, the benefit is less about the shape of the vault and more about the operating model around it. A team vault can grant a named user or group access to one collection of accounts. A new starter is added through an approved process. A leaver is removed. The account owner has a clearer place to record the reason for the account, its recovery method and its rotation trigger. A strong, unique password can be generated without asking staff to remember it.

That is a real improvement on a cell that anyone with file access can copy. It also creates a better basis for a conversation about whether the team should have a shared login at all. Many services support individual accounts, role-based permissions, SSO or MFA. Those options are usually easier to review and investigate than one password used by a whole department.

A manager does not erase what happened before it was introduced. If five people knew the old password, removing four of them from the new vault does not remove their knowledge of the old one. Migration plans need a rotation decision for each account, based on the account’s importance and the people who previously had access.

It also has limits of its own. The ACSC calls password managers attractive targets. A vault has to be treated as a high-value system, with MFA, sensible recovery arrangements, controlled administrator roles, updated devices and a clear response plan. A compromised endpoint can still capture a session. A convincing phishing page can still trick someone. An administrator’s ability to view or recover items, the events a product logs, how exports work, whether data is available offline and how emergency access works all depend on the product and its configuration.

Procurement should test those details rather than rely on feature labels. Ask what the organisation’s administrators can see. Ask how external guests are handled, how access is removed, whether export can be restricted, and what an activity record actually records. Ask how a vault is recovered if the person who set it up leaves. For an account with production, database, API or break-glass access, ask whether a password manager is enough. A privileged access or secrets-management tool may be the safer fit.

MFA remains important at both ends. Protect the vault with MFA. Turn on MFA or passkeys for the account being accessed wherever the service supports them. A password manager reduces the pressure to reuse passwords. It does not replace the account owner’s decisions about identity, recovery, permissions or the target system’s own security.

Account ownership matters as much as the secret

A row labelled “Marketing Facebook” or “Supplier portal” is rarely enough for a team to run the account safely. Who owns the relationship? Which email address receives recovery messages? Is the account a personal login being used for business? Are there named users available? Who can approve a change? What happens if the vendor support desk calls while the usual contact is away?

These details explain why a password can be shared for years. They also point to a safer design.

Every shared account should have a business owner. The owner need not be the person who administers the vault every day. They are the person who can explain why the account exists, who should use it and when it can be retired. The technical owner handles the system settings, vault access and change process. In a small business, those may be the same person. The names and responsibilities still need to be clear.

Recovery channels deserve special attention. A password reset link sent to a former employee’s personal email address can defeat a carefully planned vault migration. So can a phone number held by a person who has left. Move recovery methods to approved, maintained business-controlled channels through the authorised process. Take care with any account that controls other accounts, such as a domain registrar, identity provider, billing administrator or recovery mailbox.

Shared passwords are often a sign that the service’s account model is poor or that the team has not been given enough licences, time or support to set up individual access. Blaming staff will not fix that. Record the exception, restrict its audience, use MFA where possible, give it an owner and review it. Put a vendor change or replacement on the roadmap if the risk remains unacceptable.

Keep credential handling out of document workflows

A document management system can hold sensitive documents with permissions, version history and retention settings. Those controls can be useful for documents. They do not make a DMS the right place to receive, inspect or clean a password list.

Do not upload a real password workbook to a DMS for review. Do not paste entries into a ticket, chat thread or migration spreadsheet. Do not send screenshots, exports, account URLs, usernames, recovery codes or a “redacted” production workbook. Hidden worksheets, notes, comments, named ranges, document properties, version history and embedded objects can expose more than the visible cells suggest.

Planning can happen without copying secrets. A security-approved inventory might record an invented asset label, account category, owner role, access group, criticality, rotation trigger and migration state. A synthetic mock-up such as “Demo supplier portal” is enough to test the process and train people. It should contain no real identifiers or patterns from the business.

If someone finds an old credential list in a shared drive, the safe first move is containment. Stop circulating it and follow the organisation’s security escalation process. The authorised IT or security team can decide how to inspect it, who needs access to handle it, whether it triggers password changes and how temporary migration material will be protected and disposed of. A document platform cannot certify that a credential workbook is safe, identify every secret inside it or determine whether a past incident was caused by the file.

A cautious migration plan

Migration is often where organisations create more copies of the same problem. Exporting a workbook to CSV, emailing it to a consultant, then importing it into a new tool gives the secret more places to live. A controlled approach takes longer, but it reduces avoidable exposure.

Start by appointing the security owner and business owners for the work. They should agree on scope, incident thresholds, temporary handling rules, the approved destination for human passwords and the path for service or privileged secrets. Give the team a way to ask for help when an account cannot be moved without vendor support or business interruption.

Build an inventory that avoids credential values. Group accounts by purpose and impact: ordinary SaaS access, finance, social media, supplier portals, production administration, service accounts, recovery accounts and emergency access. Identify personal accounts used for business, duplicate accounts and systems that already support individual access or SSO. This tells the team what to migrate, what to replace and what needs a different tool.

Move accounts in small, authorised batches. Add named users or approved groups to the new location with the smallest access set that lets them do their job. Confirm that vault MFA, recovery and emergency arrangements work before broad rollout. Avoid testing changes against live, high-impact accounts without the people who own them and a rollback plan.

Rotate passwords when the risk decision calls for it, especially after an uncontrolled share, a leaver or an unknown history of copies. Coordinate every change with the account owner. Check linked applications, scheduled jobs, recovery contacts and MFA devices first. For some systems, changing a credential before the service owner is ready causes an outage. For others, delay leaves a known exposure in place. The right action is a documented decision, not a blanket rule.

Only after access and recovery have been verified should the team retire the legacy sharing path under its approved retention and disposal process. Remove live folder permissions and links. Deal with authorised migration copies. Record that privately held copies may not be recoverable, then act on the credentials that may have been exposed. Deleting the central workbook first can destroy the team’s only map of what needs attention, while leaving copies elsewhere.

Run a leaver test before calling the job finished. Take a non-production, authorised scenario and ask whether the organisation can remove a contractor from a group, identify accounts they could access, change the right passwords, preserve the right records and recover an urgent account without sharing a live secret. Gaps found in this exercise are useful. They give the team a concrete list of changes to make.

The practical next step

If a shared password spreadsheet exists, involve the organisation’s trusted IT or security contact before moving, deleting or changing anything. Use the ACSC’s account security guidance as a starting point, alongside the organisation’s own incident and access-management procedures. For teams outside Australia, CISA’s password guidance offers a clear public reference.

The aim is a workable system: named access where available, MFA, a known account owner, a safe recovery path and an offboarding process that reaches the accounts people could actually use. That work is less visible than a spreadsheet, but it gives the team a far better answer when access changes.