Who Else Has the Keys? Managing Vendor and MSP Access in a Small Organization

A trusted technology provider may know more about your systems than anyone on your payroll. That can be useful. It should not make the provider the owner of your business technology.

Small organizations often depend on managed service providers, software consultants, website developers, alarm companies, accountants, copier vendors, and industry-specific support teams. These partners may need powerful access to keep systems running. Over time, however, temporary access becomes permanent, individual accounts become shared passwords, and services get registered under a vendor's name because that was the fastest way to finish a project.

The arrangement may work for years. The weakness appears when an account is compromised, the relationship deteriorates, a provider closes, or the one technician who understood everything leaves. The organization then discovers that it cannot sign in, contact support, restore a backup, renew a domain, or even identify what the vendor controlled.

Administrative access is not the same as ownership

A provider needs enough authority to perform the work you hired it to do. That may include deploying software, supporting users, maintaining a firewall, reviewing alerts, or restoring data. It does not automatically need exclusive control of the cloud tenant, domain, billing relationship, licenses, recovery methods, or every administrator account.

Ownership means the organization is recognized as the customer, can see what it is paying for, has an independent route to support, and can authorize another qualified party to take over. Management means a provider uses delegated access to deliver a defined service. Keeping those roles separate is not a sign of distrust. It is basic continuity planning.

Contracts help, but technical reality matters too. A document saying the organization owns its data is of limited use during an outage if the only global administrator and MFA device belong to the vendor.

Begin with a vendor-access inventory

Start by asking a direct question: Which outside organizations and people can make consequential changes? Look beyond the MSP. Include software vendors, consultants, contractors, web developers, payment and payroll support, physical-security installers, former providers, and anyone offering remote support.

For each vendor, document:

• the service provided, business owner, and vendor contact;
• the systems, sites, devices, and data the vendor can reach;
• the accounts and roles used, including remote-management tools;
• the authentication method, MFA owner, and recovery path;
• when access was approved, last reviewed, and expected to end;
• where activity logs and configuration records can be found; and
• what operations could fail if the access were disabled.

This does not need to become an enterprise database. A protected spreadsheet or register with a responsible owner can be enough. Do not place live passwords in it; keep credentials in an organizational password manager or other approved credential system.

The inventory should cover indirect access too. A vendor may not have an account in the email tenant but may control a remote-management platform that can run commands on every computer. Another may control DNS and redirect email or web traffic. Access should be measured by what it can accomplish, not only by the label on the account.

Use named accounts instead of one shared “admin”

Every person performing administrative work should normally use an identifiable account. Named accounts make it possible to grant the right role, require MFA, review activity, and remove one person's access without disrupting everyone else.

A shared administrator login creates ambiguity. When a setting changes, the log may show only “admin.” When a technician leaves the vendor, the organization must trust that the password was changed everywhere and that no saved copy remains. Shared MFA adds another problem: the approval prompt or recovery code may be routed to a phone, inbox, or vault the organization cannot see.

Some older systems support only one local administrator. When that limitation cannot be removed, document it, keep the credential in a controlled vault, rotate it after personnel or provider changes, and use compensating records such as work tickets and device logs. A product limitation may explain shared access; it should not make shared access opaque.

Vendor personnel should not use an employee's identity. Likewise, daily user accounts should not carry administrative privilege simply because it is convenient. Separate routine work from privileged work and grant only the roles needed for the service.

Retain an organizational administrator account

The organization should retain protected administrative access to critical services even when the provider handles daily operations. At least two authorized people should know that access exists and how to retrieve it under an approved process. That does not mean the owner should casually use a global administrator account for email and web browsing.

Emergency or owner access should use a unique credential, strong provider-supported authentication, and monitoring. Store recovery materials securely and independently from the system they recover. Test access periodically without making unnecessary production changes. Any use should generate an alert or review.

Be precise about what organizational access can do. A billing login may not administer users. A portal contact may not restore data. A reseller relationship may prevent direct support from the underlying provider. Confirm the account and role in the actual system rather than accepting a screenshot or an assurance that “you are listed.”

Know who owns the control points

A handful of systems can determine whether the organization remains operational and recoverable. Record each provider, account identifier, legal customer, billing contact, renewal method, primary administrator, and recovery process.

• Domain and DNS: The domain should be registered to the organization with current organizational contact and payment details. The organization should know the registrar and DNS host.
• Email, identity, and cloud tenant: Confirm the tenant belongs to the organization and that it retains an administrator and an independent recovery path.
• Backups: Know where they are stored, who can delete them, how retention is configured, and whether restoration is possible without the incumbent provider.
• Licenses and subscriptions: Understand whether licenses are owned, leased, or bundled through a reseller and what happens to them at termination.
• MFA and recovery: Identify whose devices, phone numbers, addresses, security keys, and vaults hold the second factor or recovery codes.
• Network and security tools: Preserve current configurations, diagrams, encryption or recovery keys, warranty details, and vendor support information.

An invoice is not always proof of technical control, and technical access is not always proof of legal ownership. Preserve both.

Design access so it can be disabled safely

Ask what would happen if you disabled the vendor's access today. If backups stop, security monitoring fails, licenses expire, employees cannot sign in, or nobody can administer the firewall, access and operations are too tightly coupled.

The goal is not a dramatic cutoff test in the middle of the workday. Map dependencies first. Separate vendor user accounts from service accounts, and identify automations that depend on vendor credentials. Service accounts should have a documented purpose, owner, credential location, rotation procedure, and replacement plan. Do not use a former technician's personal account to run a permanent business process.

Where platforms allow it, use time-limited or approval-based privileged access. Disable dormant accounts rather than leaving them available “just in case.” Restrict remote access to the systems and times needed, require MFA, and preserve logs somewhere the vendor cannot unilaterally erase.

Plan the exit while the relationship is healthy

Every vendor relationship ends eventually through a planned transition, acquisition, retirement, closure, performance problem, or emergency. Define the transition before pressure is high.

An offboarding plan should identify what the provider must return or transfer: administrator roles, credentials, configurations, diagrams, inventories, logs, backup data, encryption keys, licenses, warranties, open tickets, and support contacts. It should explain the format and timing of data exports, reasonable transition assistance, deletion of retained copies, final billing, and verification that remote tools and accounts were removed.

Confirm what will not transfer. A vendor may use its own ticketing, monitoring, backup, security, or documentation platform across many customers. The organization may receive its records rather than the platform itself. Knowing this early provides time to arrange replacements.

During a transition, coordinate changes instead of immediately deleting everything. Inventory service accounts and dependencies, create and test replacement access, export required records, rotate shared secrets, remove remote agents where appropriate, revoke sessions and tokens, and then review logs for unexpected activity. Keep a record of what was completed and who approved it.

Create an escalation path that does not depend on one person

Record the provider's normal support route, emergency number, after-hours process, service address, contract contact, and escalation point. Keep this information somewhere available during an email, internet, or identity outage. The vendor should also have more than one current authorized contact for the organization.

Identify what happens if the provider cannot be reached. Who can contact the software publisher, cloud provider, ISP, insurer, equipment manufacturer, or another qualified technician? Are customer or tenant numbers available? Can the organization prove it owns the account? Is there a current network diagram and a protected configuration backup?

A secondary provider does not need standing administrator access merely to be an emergency option. It needs a clear authorization process and enough maintained information to begin responsibly when called.

Review access as a recurring business process

Vendor access changes when projects finish, people change jobs, systems are retired, and contracts evolve. Review privileged vendor access at least periodically and after significant personnel, provider, or technology changes.

The review should bring together a business owner and someone who understands the technology. Confirm that each vendor is still engaged, each named user still works for the provider, each role is still necessary, MFA remains appropriate, and contact and recovery information is current. Investigate dormant accounts, unexpected logins, new remote tools, and privileges broader than the work requires.

Do not make the review a search for someone to blame. Treat findings as maintenance. Remove what is no longer needed, narrow what is too broad, document legitimate exceptions, and set a date to revisit them. As explained in Cybersecurity Is a Business Process, Not an IT Project, ownership and repeatable routines matter more than a one-time cleanup.

What a healthy vendor relationship looks like

A capable provider should be able to explain what it can access, how its staff authenticate, how personnel changes are handled, where activity is logged, and how the organization can recover or transition. Reasonable questions about ownership and offboarding should not be treated as hostility.

The organization also has responsibilities. It should maintain current contacts, approve changes promptly, protect its own administrator access, pay for necessary documentation and transition work, and avoid demanding insecure shortcuts. Good governance supports the provider rather than obstructing it.

Trust and verification belong together. The objective is a relationship in which the provider can work efficiently while the organization retains visibility, authority, and a practical way forward.

Apply GRIT

• Growth: Use every new service, contract renewal, and vendor change to improve the access inventory.
• Resilience: Keep organizational administrator access, recovery information, and critical records independent of any one provider.
• Instinct: Question shared accounts, unknown remote tools, unexplained MFA prompts, and services registered to somebody else.
• Tenacity: Review access, contacts, documentation, and exit procedures until they become routine.

A practical vendor-access checklist

Can your organization confidently say:

• We know which vendors and individuals have administrative or remote access.
• Vendor technicians use named accounts with appropriate roles and MFA.
• We retain protected organizational administrator access to critical systems.
• Our organization owns its domain, cloud tenant, data, backups, and essential records.
• We know who controls licenses, MFA methods, recovery codes, and billing relationships.
• We can disable vendor access without accidentally stopping undocumented services.
• Our contract and technical plan explain how access and information transfer at the end.
• We have an independently accessible emergency contact and escalation path.
• Someone reviews vendor access and resolves what is no longer necessary.

If one answer is no, begin with the domain, email or identity tenant, backups, and remote-management system. Those control points can affect nearly everything else.

Keep the help; keep the keys

Small organizations do not need to bring every technical skill in-house. A good vendor or MSP can provide depth, continuity, and experience that would otherwise be out of reach. The lesson is not to distrust outside help.

The lesson is to remain a capable owner. Know who has access, give each person only what is needed, retain an independent route back in, preserve the records required to recover, and make the exit path part of the relationship from the beginning.