Security teams should treat vendor access with service accounts or API keys as delegated identity, not just supplier onboarding. That means verifying ownership, documenting the purpose of access, checking rotation and revocation procedures, and ensuring access is removed when the relationship changes. The review should cover both contract risk and identity risk.
Why This Matters for Security Teams
Vendor access built on service accounts or API keys is not ordinary supplier onboarding. It is delegated machine identity, and that changes the risk profile. A vendor key can authenticate silently, bypass interactive controls, and remain valid long after the business need ends. That is why teams should assess not only who the supplier is, but what the credential can do, how it is stored, how it is rotated, and whether revocation is actually enforced.
This is also where identity governance and secrets governance converge. The Guide to the Secret Sprawl Challenge shows how quickly credentials become operationally invisible once they leave the original owner’s system, while the OWASP Non-Human Identity Top 10 frames the core issue as unmanaged non-human access rather than simple third-party risk. GitGuardian’s The State of Secrets Sprawl 2026 reports that 64% of valid secrets leaked in 2022 are still valid today, which underscores why detection without revocation is an incomplete control.
In practice, many security teams discover the problem only after a vendor credential has outlived the contract, the integration, or the employee who created it.
How It Works in Practice
Start by classifying the credential as a delegated identity with a defined business purpose. That means the review should answer four questions: who owns it, what system it authenticates to, what actions it can perform, and what event causes it to be removed. Treat those answers as mandatory evidence, not optional context.
From there, test the mechanics. Verify whether the service account or API key is unique to one vendor, whether scope is limited to the minimum required resources, and whether the vendor can prove rotation and revocation procedures. Current guidance suggests short-lived credentials are preferable where the platform supports them, because static secrets are hard to monitor and even harder to retire cleanly. If the vendor supports workload identity, that is usually stronger than a shared long-lived key because access can be bound to workload characteristics rather than manual distribution.
- Confirm the credential has an owner inside the customer organisation, not only at the vendor.
- Require a documented purpose, system boundary, and data classification for each credential.
- Check whether rotation is automatic, manual, or effectively nonexistent.
- Test revocation, including the ability to disable access when the contract changes.
- Review logs for authentication source, frequency, and anomalous usage.
For higher-risk vendors, compare this control set with LLMjacking: How Attackers Hijack AI Using Compromised NHIs, because API keys that reach AI or automation services are often abused minutes after exposure. The CISA guidance on securing AI and ML systems is also useful when vendor credentials connect to model endpoints, orchestration layers, or automated toolchains. These controls tend to break down when multiple teams share one vendor key across environments, because ownership and revocation become ambiguous.
Common Variations and Edge Cases
Tighter vendor credential governance often increases operational friction, requiring organisations to balance faster integrations against stronger revocation and auditability. That tradeoff is real, especially when a supplier insists on a shared API key or a legacy service account that cannot support modern identity features.
Best practice is evolving, but the direction is clear: replace shared static credentials with scoped, per-environment identities wherever possible, and use compensating controls when that is not feasible. For example, if a vendor cannot support short-lived tokens, the review should require stricter network controls, log review, and explicit renewal dates. If the credential is used by an automation platform or agentic workflow, the bar should be higher because machine actions can scale mistakes faster than human users.
Edge cases also arise when access is technically “vendor-owned” but operationally embedded in a customer process. In those cases, contract terms alone are not enough. The access review should verify that revocation is possible without waiting on a support ticket, that emergency disablement exists, and that offboarding includes evidence of token deletion. NHIMG breach analysis has repeatedly shown that exposed non-human credentials are often found only after abuse has already begun, not during routine vendor reassessment.
Where a supplier cannot meet these expectations, the risk should be recorded as an exception with an expiry date, compensating controls, and a plan to eliminate the static credential path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses rotation and revocation of non-human credentials used by vendors. |
| NIST CSF 2.0 | PR.AC-1 | Vendor credentials are access permissions that must be governed and reviewed. |
| NIST AI RMF | Delegated machine access to AI systems needs risk management and accountability. |
Inventory vendor service accounts and API keys, then enforce rotation, expiry, and verified revocation.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- What problem does ownership attribution solve for service accounts and API keys?
- How should security teams govern Active Directory service accounts?
- How should security teams govern service accounts and API keys across cloud platforms?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
