For each third-party integration, record where its credential is stored, what scope it grants, who rotates it, when it was last rotated and how to revoke it. Do not store the secret value in the inventory. The record exists to answer "whose key is this and can we kill it?"
Why credentials belong in the row
When a vendor reports a problem or an employee leaves, the first question is which credentials are affected. If the inventory ties each integration to a credential location and owner, the answer is a filter. If it does not, the answer is a Slack thread.
This post is about recording metadata. It does not describe finding secrets in code, which is a separate control.
The fields
| Field | Example answer | Why |
|---|---|---|
| Credential type | API key, OAuth client, service account, mutual TLS certificate | Decides how it is rotated |
| Storage location | Name of the secrets manager entry | Where to go in an emergency |
| Scope or permissions | Read only, write, admin | Shows blast radius |
| Environment | Production, staging, test | Prevents shared keys across environments |
| Holder | Service or team, not a person's personal account | Avoids orphaned access |
| Rotation owner | Named person or team | Someone accountable |
| Last rotated | Date | Shows staleness |
| Expiry | Date, if the vendor sets one | Avoids outages |
| Revocation steps | Link to the runbook | Speeds response |
Rules that save trouble
- One credential per environment. A production key used in staging means a leaked staging log exposes production.
- Service holders, not people. If the key is tied to one engineer's account at the vendor, it breaks or lingers when they leave. Create a service or team account.
- Smallest scope that works. If the vendor offers read only keys, use them for read only features.
- Write the revocation step now. The vendor console path to revoke a key is easy to document today and hard to find at 2 a.m.
- Review shared keys. Two services using one key cannot be rotated independently.
Using the data
Once the fields exist, three reports are easy to build: credentials not rotated within your own policy window, integrations with admin scope that only need read access, and credentials held by accounts that no longer exist. Start with the last, since it is usually the shortest list and the most urgent.
When the vendor offers short-lived tokens
Where an API supports short-lived tokens or workload identity, record that instead, along with the identity that requests them. It removes rotation as a manual task and shrinks the record.
Quick check
Should the inventory hold the API key?
No. Store only the location, scope, owner and dates. The secret stays in a secrets manager.
What about keys inside SDK config files?
Record where the SDK reads its key from, and move it to your secrets store if it is committed in a config file. Fixing that is separate from the inventory.
Safeguard offers SBOM and dependency scanning and asset discovery that can feed this kind of inventory. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
