Supplier questionnaires cannot see the stale key that exposes your systems
Published October 6, 2026·4 min read
Ask a supplier how they enforce multifactor authentication and you will receive a policy document. Ask what the service account connecting their system to yours can delete in production, and the conversation gets slower. The second question is the one that matters now.
According to a Global Sources report published on 30 September, the common thread in recent supply chain incidents is a valid login used against tools the target already trusts. The report draws together the widely used Axios JavaScript package, a compromised release of the Trivy vulnerability scanner, and a logistics firm whose breach reached several customers. The mechanics are familiar: someone found a working keycard and used it to move through connected areas.
For an organisation that buys from hundreds or thousands of suppliers, the report is easy to misread. It is tempting to turn inward and review your own access. The more useful reading is outward. Your suppliers hold credentials to your systems, and those credentials are now the route in.
The gap between what is installed and who can change it
Global Sources makes a useful distinction between inventory and access. A software bill of materials shows which components are installed, but it does not show who can change or publish them. Vendor assurance has the same blind spot. A questionnaire asks whether a supplier has an access-control policy. It rarely asks which accounts can write to the customer's tenant, whether those accounts require MFA on the actual connection path, or who revokes them when a contractor leaves.
Policy documents are too slow for this problem. They are written once, reviewed annually, and they describe intent. A stolen credential works in minutes. If the only evidence you hold is a signed assertion that MFA is enforced, the gap will surface during an incident rather than a review. The report is specific about what works: expiring keys, limited permissions, secure storage and regular rotation. Most third-party teams have never asked a supplier to produce any of those for the accounts that touch their data.
Questions that reveal the answer
The practical line to draw sits around the suppliers with persistent access to your estate. These are often a small group: the managed IT provider, the logistics platform, the billing service, the integration partner with an API key into your ERP. Separate that group from firms that simply deliver a product. The first needs evidence; the second can be handled with policy and attestation. The two groups rarely belong in the same assessment track.
Four questions matter most for any supplier with standing access:
- Which accounts can reach our environment, and does each one require MFA on every path, including service accounts and API calls?
- What can each credential do? Does the account that deploys code also hold permission to delete production data?
- When did each credential last rotate, and who can approve a change?
- Who removes the account when the contract or the contractor ends?
The answers usually live in the identity administrator's console, not in the security policy. A supplier that can answer quickly has already walked through its own access before you asked. A supplier that cannot answer, or that treats the question as intrusive, is telling you something about how it will behave later.
Renewal is the moment to ask
Contract renewal is when the leverage is highest. Rather than sending the same questionnaire, attach the account inventory and rotation record for any connection that touches your systems. Name a person at the supplier who owns offboarding and set the number of days they have to do it. For the firm that cannot produce that record, the sensible response is to limit the connection until it can.
This is the kind of verification a managed third-party risk programme is built to run repeatedly: checking what suppliers claim about access against their live controls, validating findings before they reach you, and pushing remediation directly with the third party. Most of it does not have to be done by hand.
Where NIS2 applies, the NIS2 supply-chain duties point in the same direction, though how far they reach into individual supplier credentials will depend on sector and on the member state's implementation. That variation is all the more reason to make your own contract requirements explicit rather than waiting for a standard to settle.
If you do not know how many suppliers hold standing credentials today, start with the free scored self-assessment. It will not fix the issue, but it will show whether your current approach is carrying more exposure than your risk appetite says you accept.
A supplier that stalls before signature will be harder to hold to account after an incident.
- third-party risk
- supply chain security
- credential management
- vendor due diligence
- mfa
- offboarding