A growing SaaS stack means a growing number of doors, and most teams lose track of who holds the keys.
No small team ever decides to run thirty SaaS tools. The stack accumulates. Someone signs up for a scheduling app during a busy week. A contractor introduces a design tool that sticks around after the project ends. Finance adopts an invoicing platform, marketing adds two analytics products, and eighteen months later nobody can produce a complete list of what the company pays for or who can log into it.
Most of the conversation about SaaS sprawl focuses on cost. Duplicate subscriptions, unused seats, renewals that slipped through unnoticed. Those are real problems, and they are relatively easy to see once someone audits the card statements. The harder problem sits underneath: every one of those tools is a door, and most small teams have lost track of who holds the keys.
How access quietly becomes unmanageable
Three patterns show up again and again in growing teams.
The first is the shared login. One seat costs less than five, so the team creates a single account and passes the credentials around in chat. It works fine until someone leaves, at which point the password either gets changed (breaking access for everyone) or does not (leaving a former team member with a working key). Shared logins also destroy any audit trail, so when something goes wrong there is no way to establish who did what.
The second is reuse. When a person has to invent and remember credentials for twenty-five services, they do the human thing and reuse one password with small variations. This turns a breach at any single vendor into a problem across the whole stack. Attackers know this, which is why credential stuffing (taking username and password pairs leaked from one service and trying them everywhere else) remains such a productive technique.
The third is the orphaned account. A tool gets trialled, abandoned, and never cancelled. The account still exists, still holds whatever data was uploaded during the trial, and nobody is watching it. The Federal Trade Commission’s small business cybersecurity guidance makes the point directly: accounts belonging to people who have left should be deactivated, and access should be limited to those with a documented business need.
What current guidance actually recommends
Password advice has changed substantially over the last decade, and a lot of teams are still following rules that have been formally retired.
The updated federal guidance in the United States, published as NIST Special Publication 800-63B-4, moved away from the practices most of us were trained on. Forced periodic password changes are no longer recommended, because they push people toward predictable patterns. Composition rules (one capital, one number, one symbol) are similarly discouraged for the same reason. What the guidance does emphasise is length, support for long passwords, screening credentials against lists of known compromised values, and allowing paste into password fields, which only makes practical sense if people are using a tool to store them.
CISA’s guidance for small and medium businesses sets out a similar shape: passwords should be long, random, and unique to each account, stored in a password manager, and paired with multi-factor authentication.
Notice what these two documents have in common. Both assume the credentials are being generated and stored by software rather than invented and memorised by people. That is the shift. The old model asked humans to be random, which humans are demonstrably poor at. The new model asks humans to remember one strong credential and delegates the rest.
Where a password manager fits into a SaaS stack
The practical value for a small team is less about cryptography and more about inventory.
A shared vault gives you something the spreadsheet never did: a live list of which services the team actually uses, who has access to each, and which credentials are weak or duplicated. That list is the foundation for everything else, including the cost audit. You cannot cancel a subscription you do not know exists.
It also changes offboarding from an archaeology project into a checklist. Revoke vault access, rotate anything that was genuinely shared, and the exposure closes in minutes rather than surfacing months later.
For teams watching their tooling budget, a free password manager is a reasonable place to start, and it removes the most common objection to rolling this out, which is adding another line item to a stack that is already too expensive.
Two caveats worth stating plainly. A password manager reduces credential risk, it does not eliminate it, and it does nothing about phishing that targets your multi-factor codes or about a vendor breach that exposes data rather than passwords. It should sit alongside multi-factor authentication on every account that supports it, prioritising email and anything with billing access, since email is usually the reset path for everything else.
A realistic first week
You do not need a project plan. You need a list.
Start by pulling the last three months of card statements and writing down every SaaS charge. Add the tools people mention that do not appear on the statement, since free tiers are invisible to finance and often hold real data. For each entry, note who has access and whether the login is shared.
That document will be uncomfortable reading. It will also tell you exactly where to spend the next hour: usually eliminating two or three shared logins on the tools with the most sensitive access, and turning on multi-factor authentication for the email account everything else resets through.
The stack will keep growing. That is fine, and mostly a sign the business is working. The thing worth building now is the habit of knowing what is in it.
