When a supplier is breached or a contract ends, the first question is which of your credentials that supplier holds and which of its credentials you hold, and most organisations cannot answer it in under a day. Credentials cross the supplier boundary in two directions. Outbound: API keys, OAuth client secrets, service accounts, SSH keys and federated roles that [Organisation] issued so a supplier can reach its systems. Inbound: API keys, tokens and certificates that suppliers issued to [Organisation] so it can use their services, usually stored in pipelines and secrets managers. This template gives one register for both, with the fields needed to revoke fast, rotate on schedule and prove at exit that nothing was left behind. It is written for third-party risk, identity and platform teams. For why third-party identities are a distinct risk, see the OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide.
How to use this template
- One row per credential, not per supplier. A supplier with three integrations and a support account has at least four rows. Link rows to the supplier's entry in the supplier inventory by a shared supplier ID.
- Record metadata, never secret values. The register holds where a secret lives (a vault path or secret name), never the secret itself. Restrict the register to need-to-know: it is a map of what an attacker would want.
- Replace the bracketed placeholders ([Organisation], [Register Owner], [N days]) and delete fields you cannot populate yet rather than leaving them blank and misleading.
- Use the field codes. Codes such as O-05 or I-03 let you build the register in a spreadsheet, a CMDB class or an identity governance tool without losing the structure.
- Thresholds are our suggestions. Rotation periods, review cycles and revocation targets below are NHI Mgmt Group recommendations; set your own from your risk appetite and any regulatory requirement.
1. Purpose
1.1 This register records every credential that crosses the boundary between [Organisation] and its suppliers, in both directions, so that each has an accountable internal owner, a known scope, a rotation and expiry date, and a tested revocation path.
1.2 It supports supplier incident response, contract exit, access reviews and audits. It evidences NIST SP 800-53 Rev. 5 IA-5 Authenticator Management, AC-2 Account Management, SA-9 External System Services and PS-7 External Personnel Security, and NIST CSF 2.0 GV.SC-07 and GV.SC-10. It also gives practical effect to the supplier directory and end-of-contract duties in NIS2 Implementing Regulation 2024/2690 Annex points 5.2 and 5.1.4(h); see the NIS2 Supply Chain Security Guide.
2. Scope
2.1 Outbound credentials (issued by [Organisation] to suppliers): API keys and OAuth client credentials for [Organisation] APIs; service accounts or user accounts created for supplier staff or tools in [Organisation] directories, cloud accounts and SaaS tenants; SSH keys and deploy keys; cross-account or federated cloud roles that suppliers can assume; VPN, remote support and privileged access accounts; and OAuth grants that [Organisation] users approved for supplier applications.
2.2 Inbound credentials (issued by suppliers to [Organisation]): API keys, personal or organisation access tokens, OAuth client secrets, webhook signing secrets, client certificates and SFTP or data feed credentials that [Organisation] systems use to call supplier services.
2.3 In scope suppliers: all suppliers in the supplier inventory, including intragroup providers, contractors and AI or model providers. Credentials for internal-only systems belong in the general NHI inventory.
2.4 Out of scope: human employee accounts, unless the account is used by supplier staff.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [Register Owner] (third-party risk or identity team) | Maintains the register, runs reconciliation, reports metrics |
| Credential owner (named individual in the business or platform team) | Keeps each row accurate; approves scope; performs or triggers rotation and revocation |
| Supplier relationship owner | Obtains the supplier's list of credentials it holds; confirms deletion at exit |
| Security operations | Uses the register during supplier incidents; monitors usage of outbound credentials |
| Procurement and legal | Ensure contracts require credential inventory, compromise notification and revocation at exit |
4. Common fields (both directions)
| Code | Field | Example or allowed values |
|---|---|---|
| C-01 | Credential ID | [Organisation]-TPC-0001 |
| C-02 | Direction | Outbound / Inbound |
| C-03 | Supplier ID and name | Matches the supplier inventory |
| C-04 | Supplier tier | Critical / Strategic / Routine |
| C-05 | Credential type | API key, OAuth client, OAuth grant, service account, SSH key, certificate, federated role, token, password |
| C-06 | Business purpose | One line: what the integration does |
| C-07 | Internal credential owner | Named person and team, not a mailbox |
| C-08 | Contract reference and end date | Links rotation and revocation to the contract life |
| C-09 | Created date and created by | Date; ticket number |
| C-10 | Expiry date | Hard expiry, or "none" (which triggers review) |
| C-11 | Last rotated and next rotation due | Dates |
| C-12 | Status | Active / Suspended / Revoked / Pending revocation |
| C-13 | Revocation method and time to revoke | Console path or API call reference; tested time in minutes |
| C-14 | Last review date and reviewer | Date; name |
5. Outbound fields (keys you issued to suppliers)
| Code | Field | Why it matters |
|---|---|---|
| O-01 | Target system and environment | Production, staging, tenant or account ID; drives blast radius |
| O-02 | Identity or principal name | The account, client ID or role ARN as it appears in logs |
| O-03 | Scopes and permissions granted | Exact scopes or roles; flag any administrative or write scope |
| O-04 | Privileged (yes/no) | Privileged rows follow the Vendor Privileged Access Management (VPAM) Guide |
| O-05 | Authentication method | Static secret, certificate, federation or OIDC, MFA for human use |
| O-06 | Network restrictions | Source IP allowlist, private connectivity, none |
| O-07 | Where the supplier stores it (as declared) | Supplier's vault, CI system or "unknown"; "unknown" is a finding |
| O-08 | Supplier subcontractors with access | Named fourth parties that can use the credential |
| O-09 | Last used date | From [Organisation] logs; unused for [90] days triggers removal |
| O-10 | Monitoring in place | Alert rule ID for use outside expected sources or times |
6. Inbound fields (keys suppliers issued to you)
| Code | Field | Why it matters |
|---|---|---|
| I-01 | Supplier service and account | The supplier tenant or account the credential belongs to |
| I-02 | What it can do at the supplier | Read data, write data, billing, administration; drives impact if leaked |
| I-03 | Storage location | Vault path or secret name; never a value. See the Secrets Management Guide |
| I-04 | Consuming systems | Every pipeline, service or job that reads it; needed to rotate without outage |
| I-05 | Supplier-side controls applied | IP restriction, scoped key, spend limit, expiry, as offered by the supplier |
| I-06 | Rotation procedure | Link to the runbook; see the Secrets Rotation Runbook Template |
| I-07 | Supplier support route for compromise | Where to report a leaked key and request revocation |
| I-08 | Secret scanning coverage | Whether repository and pipeline scanning detects this key format |
7. Rotation, expiry and review rules
7.1 Every row has an expiry or a next rotation date. Our suggested maximums: [90] days for static secrets with write or administrative scope, [180] days for read-only static secrets, and the platform default for federated or short-lived credentials, which should be preferred wherever the supplier supports them.
7.2 Credential owners review their rows every [quarter] for critical suppliers and every [six months] for others, confirming purpose, scope, last use and storage.
7.3 Outbound credentials unused for [90] days are suspended, then revoked after a further [30] days unless the owner justifies them.
7.4 Rows with no owner, no expiry, or a storage location of "unknown" are reported to [Register Owner] as findings and closed within [30] days.
8. Supplier incident procedure
8.1 When a supplier reports or is reported to have a security incident, [Register Owner] filters the register by supplier ID within [1 hour] and gives security operations the list of outbound and inbound rows.
8.2 Outbound credentials for the affected supplier are reviewed for use since the earliest suspected compromise date and rotated or suspended in priority order: privileged first, then write scope, then read.
8.3 Inbound credentials issued by the affected supplier are rotated if the supplier's incident may have exposed them, using I-06 and I-04 to avoid outages.
8.4 Actions and timestamps are recorded against each row as incident evidence. See Your vendor was breached.
9. Contract exit procedure
9.1 At least [30] days before contract end, the supplier relationship owner exports all rows for the supplier and confirms them with the supplier.
9.2 On the exit date, all outbound credentials are revoked (not just disabled), OAuth grants are removed and federated trust is deleted; all inbound credentials are deleted from vaults and pipelines.
9.3 The supplier confirms in writing that it has deleted copies of [Organisation] credentials, including from subcontractors listed in O-08.
9.4 Rows move to status Revoked with the revocation date, and are kept for [the audit retention period]. See the Vendor Offboarding and Termination Guide.
10. Discovery and reconciliation
10.1 The register is reconciled every [month] against sources of truth: identity provider and directory accounts tagged as external; cloud cross-account roles and trust policies; OAuth application grants in SaaS tenants; API gateway client lists; and secrets manager paths named for suppliers.
10.2 Credentials found in a source but not in the register are added with an owner within [10] working days or revoked. Rows not found in any source are investigated and closed. The method is described in NHI Inventory Reconciliation.
10.3 Critical suppliers are asked [annually] to provide their own list of [Organisation] credentials they hold, which is compared with the outbound rows.
Implementation guidance
- Start with critical suppliers: populate rows for the top tier first; a complete register for twenty critical suppliers is worth more than a partial one for five hundred.
- Seed from technical sources, not questionnaires: cloud trust policies, OAuth grants and external accounts give the outbound list; secrets manager paths and pipeline variables give the inbound list. Then ask owners to fill purpose and scope.
- Put the duty in contracts: require suppliers to maintain an inventory of [Organisation] credentials, notify suspected compromise and confirm deletion at exit. See Vendor contract clauses for credential revocation and breach notice. Financial entities can map this to DORA Article 30; see the DORA Article 30 Contract Provisions Guide.
- Measure it: share of rows with an owner and expiry (target 100%); outbound credentials unused for [90] days; median time to revoke at contract exit; supplier incidents where the affected credential list was produced within [1 hour].
- Follow OWASP's NHI3 mitigations: the OWASP Non-Human Identities Top 10 recommends security reviews before integrating third-party tools, least privilege, monitoring third-party activity, short-lived credentials with automated rotation, and a process to revoke and reissue connected OAuth tokens. This register is where those decisions are recorded.
- Framework alignment: NIST SP 800-53 Rev. 5 IA-5, AC-2, SA-9 and PS-7; NIST CSF 2.0 GV.SC-07 and GV.SC-10.
- Key sources: OWASP: NHI3:2025 Vulnerable Third-Party NHI; EUR-Lex: Implementing Regulation (EU) 2024/2690; NIST: SP 800-53 Rev. 5.
Related NHI Mgmt Group resources: Third-Party AI Risk Guide · Top 10 Third-Party Risk Mistakes · Privileged Account Inventory Template · API Key Management Standard Template