Most small business owners can list every vendor they pay every month – the bookkeeper, the marketing agency, the web developer, the alarm company, the prior IT consultant. What most cannot do, off the top of their head, is list every vendor who still has a working login to a system they actually own.

That gap is where third-party access risk lives. A bookkeeper who finished the books eighteen months ago may still have a QuickBooks Online admin login. A web developer from the last site rebuild may still have your hosting control panel password. A point-of-sale installer may still have a remote support tool running on a workstation tucked behind the register. None of those people are villains. Their access is just leftover from a relationship that has changed or ended.

This is the question worth running once a quarter: who else has the keys to systems we depend on, and do they still need them?

Which Outside Parties Usually End Up With Access To Your Systems?

Vendor access usually accumulates the same way for every small business: someone is brought in for a project, given the credentials they need to finish the work, and then never offboarded because there was no formal end to the relationship – only an invisible drift into “we do not really talk to them anymore.”

In a typical Treasure Coast small business we walk through during a security review, the list of outside parties who still hold some form of access usually includes:

  • The accountant or bookkeeper, with admin or accountant-level access to QuickBooks Online, the payroll platform, and sometimes the business bank account.
  • A marketing or web design agency with WordPress admin, Google Analytics, Google Tag Manager, Google Ads, and the hosting control panel.
  • A prior IT consultant or managed IT provider, often holding global admin rights inside Microsoft 365 and full firewall and domain admin credentials.
  • A point-of-sale or specialty software integrator who installed a system years ago and left remote support tools running on workstations.
  • CRM or ERP implementation consultants who needed everything to migrate the data and never gave back the elevated role.
  • Contract designers, copywriters, or developers who were added to shared mailboxes, Teams channels, project tools, or chat workspaces and were never removed.
  • A former employee whose vendor mailbox, contractor login, or shared credential was technically the company’s, not theirs, and was never disabled.

Every one of those relationships ends at a different moment. Some end with a signed termination notice, others end when the project just trails off, and others fade out when the point of contact on either side changes jobs. The access almost never ends at the same time.

What About “We All Shared One Login” Accounts?

Shared logins are the most common and the most dangerous variant. The same email and password is handed to whoever needs to “get in real quick” – the accountant during tax season, the agency during a campaign push, the IT consultant during an upgrade. Because no individual feels personal ownership of a shared login, no individual ever takes responsibility for revoking it. Past employees and their associated vendor logins tend to blur together, and an honest employee offboarding checklist catches the people but rarely catches the contractors and shared credentials that lived alongside them. Once a shared login has been in place for six months, it has usually been copy-pasted into someone’s notes app, a sticky note, or a chat thread with the next contractor who needed it.

How Does Old Vendor Access Become A Security Risk?

The risk is rarely that a former vendor wakes up one morning and decides to attack the client they used to work with. The risk is that the credential they still hold becomes the foothold for someone else. There are three patterns to watch for.

The first is the vendor breach. When the vendor itself is compromised – phishing of their email, a malicious browser extension on their machine, or a wider supply chain incident – every client login they hold becomes part of that incident. Their browser-saved password for your hosting panel is now in the attacker’s hands, and unless you have multi-factor authentication on that account, the attacker is in.

The second is the stale device. The retired laptop on the contractor’s bottom shelf still has your saved passwords. So does the older iPad they pass around the office. So does the personal computer the marketing freelancer used three years ago and gave to a relative. A vendor with shared admin credentials and no second factor effectively widens your attack surface to every device those credentials have ever been typed into.

The third is credential reuse. Many vendors – especially small operators – use the same handful of passwords across all of their clients. If one of their other clients gets breached, attackers will test those credentials against every domain that vendor has ever worked with. Your account becomes collateral damage in someone else’s incident.

What ties these patterns together is a quiet truth: stale vendor logins are one of the most common ways small businesses face unauthorized access to systems they thought were locked down. The credentials still work, the accounts are still active, and nobody has looked at the login history in a long time.

Why Does This Slip Through Routine Audits?

Vendor access rarely shows up on standard IT or security checklists. The usual offboarding workflow focuses on employees: badge, laptop, mailbox, file shares, payroll, benefits. Contractors and vendors are handled by whichever staff member managed the relationship – finance for the bookkeeper, marketing for the agency, operations for the integrator – and there is no central record that tells IT or the managed IT provider that the relationship has ended. Years later, the only signal is a forgotten account named something like “OldITGuy” or “Marketing2018” inside Microsoft 365 admin or the firewall, still active and still able to log in.

What Should A Vendor Access Review Actually Cover?

A vendor access review is part inventory, part policy, and part cleanup. The point is not to write a forty-page policy document. The point is to know who is in the building. A practical review covers six steps.

Step one is the inventory. Start with finance and pull a list of every external party paid in the last twenty-four months. Cross-reference that against marketing, operations, and HR to catch the contractors who got paid through reimbursement, expense card, or one-time invoice. Then audit each system that holds business-critical data: Microsoft 365 admin roles and external collaborators, the WordPress users list, the hosting control panel users, the firewall admin list, the CRM admin roles, the payroll admin list, the banking platform users, the remote monitoring tool users, and the point-of-sale management console. For each access, capture who, what level, when granted, and whether there is a current business reason.

Step two is the named-account rule. Every vendor login should belong to a named person, not a shared mailbox. If the vendor wants three of their staff to access your environment, those are three separate logins, not one. Audit shared logins next: every shared vendor password is a candidate to move into a team-wide password manager with per-user named accounts and audit logging.

Step three is required multi-factor authentication. Every vendor account, without exception, should have a second factor enforced. If a vendor pushes back on multi-factor, that is a signal about the security maturity of every other client they touch.

Step four is least privilege. Vendors should have the smallest access that lets them do their job. Most marketing agencies do not need a WordPress administrator role; an editor role with a few selected plugin permissions works. Most accountants do not need access to your full banking platform; the bank’s accountant view does.

Step five is expiration. Each vendor account should carry a documented review date, with quarterly being the standard, at which the access is either renewed with a reason or removed.

Step six is vendor security posture. Capture, in plain English, what multi-factor the vendor uses on their side, what endpoint protection their team runs, how they would notify you if they were breached, and what their incident response window looks like. None of this needs to be a fifty-question vendor risk questionnaire. A one-page summary per vendor is enough to make the right calls.

What About Service Contract Scope?

Vendor contracts often grant broader access “for support purposes” than the vendor’s actual workflow requires. The phrase “administrative access” in a master services agreement was probably written years ago by a sales engineer who wanted maximum flexibility, not by the technician who actually does the work. During your review, look at the contract scope alongside the technical access. If the vendor only ever logs in once a month to pull a report, an admin-level account is overkill. Right-size the access first, then update the next contract renewal to match.

How Often Should You Review Third-Party Access?

The honest answer is: more often than you currently do, and on a schedule that does not depend on memory. A quarterly cadence handles roughly ninety-five percent of the work. Once a quarter, the person who owns vendor relationships pulls the current access inventory, marks each entry as keep, remove, or downgrade, and either makes the change or sends the request to IT. The first quarterly review takes most of a day because the inventory has to be built from scratch. Every subsequent review takes about thirty minutes because the inventory mostly carries forward.

The quarterly cadence should be supplemented with event-driven reviews. Anytime a vendor relationship ends, whether by formal contract termination or by quietly stopping the engagement, that is a trigger. Anytime a vendor contract renews, that is a trigger. Anytime a vendor of yours is in the news for a breach, that is a trigger. Anytime the internal staff member who manages a vendor relationship leaves, that is a trigger.

Ownership matters too. Vendor access reviews fall apart when nobody owns them. Most small businesses end up with operations or finance owning the relationship inventory and IT or the managed IT provider owning the technical revocation. Small businesses trying to manage this without outside help find vendor reviews fall off the calendar within two quarters; one of the reasons running IT entirely in-house often misses third-party risk is that the day-to-day urgent work always wins against the quarterly housekeeping.

When Should The Audit Happen Off-Schedule?

A few events should trigger an immediate review regardless of the quarterly cadence. A breach announcement involving a vendor you use. A merger or acquisition of a vendor, since the people with your credentials may change overnight. The departure of the staff member who owned the vendor relationship. A change in contract scope. A new tool the vendor is asking you to install on your network. Any of those should jump the line.

Frequently Asked Questions

How do I know which vendors currently have access to our systems?

Start with the people who pay them. Pull twenty-four months of accounts payable and circle every external party. Then have each department manager – marketing, finance, operations – confirm which of those relationships still involve any login to a business system. Cross-check that list against the actual admin and user lists inside Microsoft 365, your hosting platform, your CRM, your payroll system, your banking platform, and any specialty tools.

What is the most common vendor access mistake small businesses make?

Leaving global admin roles assigned to former IT consultants inside Microsoft 365. Global admin can read everyone’s mail, create new admin accounts, and disable security policies. It is the single highest-impact account in the environment and the one most likely to be left over from a relationship that ended years earlier.

Should every vendor have their own separate login?

Yes. Even if a vendor is staffed by two people, each person should have their own named account. Named accounts let you revoke one person’s access without disrupting the working relationship and give you a useful audit trail of who actually did what.

Do vendors need multi-factor authentication too?

Yes, without exception. The vendor’s own security maturity does not change the answer. Multi-factor on vendor accounts protects you from a vendor breach, a stolen device, and credential reuse. Any vendor who refuses multi-factor on accounts they hold inside your environment is telling you something useful about how they handle every other client.

How long should a vendor account stay active after a project ends?

Default to zero. The moment the engagement ends, the access should be removed unless there is a documented support reason to keep it. If support access is needed, set a review date no more than ninety days out so the account is reviewed before it becomes invisible.

Should vendor access show up on our cyber insurance application?

Increasingly yes. Cyber insurance underwriters now ask about third-party access controls, including whether vendors have multi-factor, whether shared logins are in use, and whether access is reviewed on a defined cadence. A clean vendor access program is one of the cheaper line items that helps hold your premium down or keeps your application approved.

Who owns vendor access reviews – IT or operations?

Both, with one clear lead. Operations or finance typically owns knowing who the vendors are and what the relationship looks like. IT or the managed IT provider typically owns the technical revocation and the admin-role inventory. Pick one role as the lead, usually operations, so the review actually happens, with IT as the technical partner.

When Should You Bring In Help Reviewing Vendor Access?

If your team has not run a vendor access audit in the last six months, it is worth bringing in outside eyes for the first pass. A practical review for a typical small business runs one to two days for the initial inventory and tighten-up. The result is a documented list of every external party with a login, the appropriate access level for each one, and a quarterly cadence the team can actually run on its own. A second set of eyes on your access list is the cheapest line item in closing the unauthorized access gaps across your business systems. If you are on the Treasure Coast and want to walk through this quietly with someone who has done it across other small businesses, that is exactly the kind of work O&O Systems does.