Who else has the keys? Vetting and managing vendor and app access for manufacturers, contractors, and DoD suppliers

Your vendors hold keys to your business

Last week a credential belonging to a Microsoft 365 backup service, ConnectWise Cloud Backup (formerly SkyKick), was used to sign in to customer tenants. Huntress reported that the sign-ins were app-only: no person logged in, so there was no MFA prompt to stop them. The app already had broad access to mail, files, and Teams, and whoever held its credential inherited that access.

Those customers did nothing wrong. They hired a vendor and granted it the access the job needed. That is the point. Every vendor and app with access to your systems is part of your security whether you think about it or not.

Back in April we wrote about the big-name software supply chain attacks and why they matter. This post is the hands-on side: how a manufacturer, contractor, or DoD supplier actually keeps track of who has access, keeps that access small, and reacts the day a vendor says it has been breached.

Step one: write down who has access

Most companies have more outside access than anyone realizes, because it piles up one project at a time. Start a simple list. A spreadsheet is fine. For each vendor or app, write down what it connects to, how it connects, and who on your side owns the relationship.

The usual places to look:

• Your IT provider or MSP. Remote management tools, admin accounts, and any tools they have connected to your Microsoft 365. We are one of those vendors for our clients, so this applies to us too.
• Backup and security tools. These often hold some of the broadest access in your environment, because backup has to read everything and restore has to write it.
• ERP and accounting vendors. Support accounts, VPN access, and remote sessions for upgrades and troubleshooting.
• Machine builders and OEM remote support. CNC, PLC, robot, and test equipment vendors frequently have a remote access box or software on the plant network so they can support the machine.
• Construction and project software. Estimating, scheduling, document control, and the integrations between them and your accounting system.
• Microsoft 365 connected apps. Every app someone approved with "Sign in with Microsoft" or that an admin consented to. These live under Enterprise applications in Microsoft Entra, and they keep their access until someone removes it.
• Shared and service accounts that a vendor set up years ago and nobody has touched since.

If nobody can say what an entry is for, flag it. Those are the ones to look at first.

Questions to ask a vendor before you give it access

You do not need a 200-question security questionnaire for every vendor. You need straight answers to a few questions that tell you how they treat the access you are handing over:

• What exactly do you need access to, and why? Can it be less?
• How do your people sign in to our systems? Is MFA required for every one of them?
• Is your access always on, or only when we open it for a support session?
• Who at your company can use it, and how do you remove someone who leaves?
• Do you log what you do in our environment, and can we see those logs?
• If you have a security incident that could affect us, how fast will you tell us, and who will call?
• Do you use subcontractors or other tools that would also touch our data?

A vendor that answers these clearly and quickly is usually a vendor that has thought about it.

Keep access small and check it on a schedule

Least privilege is a fancy name for a simple rule: give each vendor only the access it needs, only for as long as it needs it.

In practice that looks like:

• Separate accounts for each vendor. No shared logins, and never a vendor using one of your employees' accounts.
• MFA on every remote session. For DoD suppliers handling CUI, NIST SP 800-171 requires MFA for nonlocal maintenance sessions and requires those connections to be terminated when the work is done (3.7.5 in Rev 2). That is a good rule for everyone, not just defense work.
• Remote access that is off by default. Turn on the OEM remote support box or the vendor's VPN account when there is a ticket, and turn it off when the job is closed.
• Scoped app permissions. When a Microsoft 365 app asks for access to every mailbox and every file, ask whether it really needs that.
• A regular access review. Quarterly works for most companies. Go down the list, confirm each entry is still needed, and remove what is not. Put a name on the review so it actually happens.

Offboarding a vendor

When you stop working with a vendor, the contract ending does not end their access. Someone has to remove it. Make it a checklist:

• Disable or delete their accounts in your systems and in Microsoft 365.
• Remove their apps from Entra Enterprise applications, and review any credentials those apps added.
• Uninstall their remote access agents from servers, PCs, and plant equipment.
• Change any shared passwords they knew, including local admin, Wi-Fi, firewall, and equipment passwords.
• Get your data back, and get written confirmation they have deleted their copies.
• Update your vendor list.

What to put in the contract

The contract is where you turn the questions above into commitments. Talk to your attorney about the exact language, but the topics worth covering are:

• Breach notice: how fast they must tell you about a security incident that could affect you, and how.
• Security basics: MFA, separate accounts, and access limited to what the work requires.
• Subcontractors: whether they can use them, and that the same requirements flow down.
• Your data at the end: return and deletion when the relationship ends.
• Cooperation: help with logs and information if something goes wrong.

For DoD suppliers, there is a specific reason to care. DFARS 252.204-7012 defines "rapidly report" as within 72 hours of discovery of a cyber incident, and it requires the clause to flow down to subcontracts that involve covered defense information. If a vendor touches that information, your contract with them needs to support that clock.

The day a vendor announces a breach

It will happen eventually. When it does, work the problem in this order:

1. Find out if you use it. Check your vendor list and your Microsoft 365 Enterprise applications. Ask your IT provider directly.
2. Cut the access. Disable the vendor's accounts or apps. In Microsoft 365, disable rather than delete when the vendor or your IT team advises it, so the app can be restored cleanly later.
3. Look for what changed. Review sign-in and audit logs for the window the vendor names: new admin roles, new credentials added to other apps, new accounts, and mailbox rules. Huntress made the point last week that disabling an app does not remove credentials an attacker already added elsewhere.
4. Change what the vendor knew. Passwords, keys, and shared secrets.
5. Write it down. What you checked, when, and what you found. If CUI could be involved, bring in whoever owns your DFARS reporting right away.
6. Do not turn it back on until the vendor confirms the problem is fixed and tells you how.

With the inventory done, most of this takes hours instead of days.

Where to go from here

If your DoD supplier work puts vendor access in scope, our defense and DoD supplier page and NIST 800-171 overview cover how it fits together. AI tools are vendors too, and our AI governance policy template covers the approval side. You can score yourself in about ten minutes with the free compliance checklist, or book the 45-minute Gap Audit and have a senior engineer walk through your vendor and app access with you.