Give each partner, and ideally each integration, its own credential with its own scope and expiry. A shared key cannot be revoked for one party without breaking the rest, cannot tell you who did what, and exposes every partner when any one of them leaks it.
What goes wrong with a shared key
Shared keys are tempting. One key goes in a document, one in a vendor portal, and onboarding is quick. The trouble appears later.
| Event | With a shared key | With a key per partner |
|---|---|---|
| One partner leaks the key | Everyone is exposed, rotation breaks all | Revoke one key, others keep working |
| A partner contract ends | You cannot remove access cleanly | Revoke that credential |
| Suspicious activity appears | You cannot tell who made the calls | The key names the caller |
| A partner needs more access | All partners get it, or none | Scope only that credential |
| Audit asks who accessed what | No answer | Logs show the credential |
OWASP's guidance on broken authentication adds a caution: API keys should be used to authenticate API clients, not users. A partner key says which integration is calling. It does not say which person at that partner acted.
A model that works
- Issue one credential per partner at least, and one per integration where a partner has several systems.
- Scope each credential to the operations and data that partner needs. RFC 9700 says access token privileges should be restricted to the minimum required, which reduces the impact of leakage.
- Prefer short lived tokens obtained with client credentials over long lived static keys, where partners can support it.
- Set an expiry on every credential and a calendar reminder for rotation.
- Support two active credentials per partner during rotation, so a switch does not need a hard cutover.
- Record an owner on your side and a named contact on the partner side for each credential.
- Log the credential ID on every request, never the secret itself.
- Rate limit per credential, so one partner's bug cannot starve the others.
Offboarding is where it pays off
When a partner relationship ends, you want one action: revoke that credential and check the logs for its last use. With shared keys that action does not exist. Add the credential list to your vendor offboarding checklist and review it on a schedule, since forgotten credentials are common.
Sandbox and production
Issue separate credentials for sandbox and production. A key that works in both makes it easy to send test traffic with real data, and for a leaked sandbox key to become a production problem.
Tradeoffs
Per partner credentials mean more to manage. Reduce the load with a self service portal for rotation, a standard onboarding template, and a registry that lists each credential, scope, owner and expiry. The effort is smaller than untangling a shared key after an incident.
Related reading
- What to check before giving a software partner API access
- Safe defaults for new API keys: scope and expiry
Safeguard's agent identity capability applies the same per credential approach to automated callers, and its asset discovery helps you see which services accept which keys. A free scan is at gold.safeguard.sh/scan.
Quick check
Is one key per partner enough?
It is a good start. If a partner runs several systems, one per integration gives finer revocation and clearer logs.
Can I log the key to know who called?
Log a credential ID or a hash prefix, not the secret itself.
Sources
- OWASP API Security Top 10 2023, API2 Broken Authentication
- RFC 9700, OAuth 2.0 Security guidance (BCP 240)
Last reviewed: 19 October 2026.
