The integration your biggest customer relies on was built four years ago by a developer who has left, authenticates with a static key that has never been rotated, and is not in anyone’s test scope because it is not really an application. It moves customer data twice an hour. The NCSC’s supply chain security guidance is built around this problem: risk arrives through connections you set up and stopped thinking about.
How these connections drift
A B2B integration starts as a project with attention and a deadline. Once it works, ownership evaporates. The partner changes their platform and the credentials get copied across. Somebody adds a second endpoint for a new report and reuses the same key. The IP allowlist gains an entry for a supplier’s new office and never loses the old one. None of these changes is reviewed, because the integration is not a system anyone is responsible for. Five years later the connection has broader access than the customer relationship justifies and no owner to ask.
The authentication patterns we find
Static API keys dominate, usually shared by every environment the partner runs and stored in a configuration file that several of their staff can read. IP allowlisting frequently stands in for authentication rather than supplementing it, which fails the moment the partner moves to cloud hosting with shared address ranges. Mutual TLS is better and brings its own trap, because certificate expiry causes an outage and the pressure of that outage produces a quick fix that weakens the check. Webhooks are the reverse direction and often have no verification at all, so anyone who learns the URL can post data into your systems.
“Ask your team for a list of every partner that holds a credential to your systems, and watch how long it takes. If the answer needs a week and a spreadsheet reconstruction, that is the finding. You cannot rotate a key you cannot find, and you certainly cannot revoke it quickly on the day a partner tells you they have had an incident.”
William Fieldhouse, Director, Aardwolf Security Ltd
Scoping data as tightly as access
Check what each integration actually sends, not just who can call it. Partner endpoints are frequently built by reusing an internal service, so the response includes every field on the customer record when the partner needs four of them. That is a data protection question as much as a security one, and it is the sort of detail that surfaces during due diligence at the worst possible moment. Build partner-specific responses, and where a partner needs bulk data, agree a schedule and a field list in the contract rather than handing over a general purpose endpoint.
Getting them into a test programme
Bring integrations into scope by inventory first. List every partner connection with its authentication method, the data it moves, the owner on both sides and the date the credential was last changed. That document is usually eye-opening on its own. Then include the endpoints in an API penetration testing engagement, testing them the way a partner with a compromised key would be able to use them. If you are budgeting this for the first time, get a quote for API testing based on endpoint count rather than partner count, since one partner may touch a dozen routes.
Frequently asked questions about partner integrations
These questions come up when a partner relationship is reviewed after an incident elsewhere.
Can you test a partner’s side of the connection?
Only with their written permission, and it is worth asking for a right to test in the contract. Without it, you test your own endpoints and rely on their assurances for the rest.
How often should partner credentials be rotated?
Annually at minimum, and immediately when someone on either side leaves the project. Build the rotation process before you need it, because doing it under incident conditions with a live integration is far harder.