Third-party credentials increase supply chain risk because they often combine standing privilege with broad operational reach. A vendor token or support account may touch production systems, sensitive data, or automation workflows. If that identity is stolen or misused, the attacker does not need to defeat your primary perimeter first. They can operate through an allowed path.
Why This Matters for Security Teams
Third-party credentials are risky because they extend trust beyond the organisation’s own identity controls. A supplier token, support account, or automation secret can reach production services, data stores, and CI/CD workflows without traversing the normal user perimeter. That makes the credential itself a supply chain dependency. OWASP’s Non-Human Identity Top 10 frames this as an identity governance problem, not just a vendor management problem.
NHIMG research shows how quickly this becomes real: in LLMjacking: How Attackers Hijack AI Using Compromised NHIs, exposed AWS credentials were targeted in as little as 9 minutes. That speed matters because third-party secrets are often copied into multiple systems, embedded in pipelines, and shared across teams. Once one account is compromised, attackers can pivot through allowed paths instead of breaking in from the outside. In practice, many security teams discover this only after a vendor account has already been used to access production data or automation.
How It Works in Practice
Third-party risk increases when external identities are granted standing privilege, long-lived secrets, and broad tool access. The issue is not merely that a vendor exists, but that the credential can authenticate as a trusted actor across systems with little runtime scrutiny. NIST’s Cybersecurity Framework 2.0 emphasises governance and access control, while current NHI guidance suggests moving toward short-lived, tightly scoped access for external parties.
In operational terms, security teams should treat supplier credentials like high-risk workload identities:
- Issue just-in-time access for a specific task, rather than reusing a standing vendor token.
- Bind the credential to device, workload, or session context so the same secret cannot be replayed everywhere.
- Use short TTLs and automatic revocation when the task ends or the contract changes.
- Prefer workload identity and federated trust over shared passwords, static API keys, or copied certificates.
- Monitor for unusual lateral movement, privilege chaining, and access outside the vendor’s normal support window.
NHIMG’s The State of Secrets in AppSec shows why this persists: organisations face fragmented secrets management and slow remediation, which gives exposed third-party credentials time to be abused. The practical lesson is that vendor access should be evaluated as an active runtime control, not a one-time procurement checkbox. These controls tend to break down in legacy environments where shared service accounts, hard-coded secrets, and uncoupled vendor integrations cannot support per-session issuance or immediate revocation.
Common Variations and Edge Cases
Tighter third-party access often increases operational overhead, requiring organisations to balance vendor uptime against reduced exposure. That tradeoff is real, especially for managed service providers, SaaS integrations, and emergency support workflows. There is no universal standard for this yet, but best practice is evolving toward context-aware authorisation and ephemeral access rather than permanent third-party privilege.
The edge cases are usually the hardest ones. Some vendors need machine-to-machine access for telemetry or automated patching, while others require break-glass support during incidents. In those scenarios, the question is not whether access exists, but whether the credential can be constrained by purpose, duration, and environment. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets and Guide to the Secret Sprawl Challenge both reinforce the same pattern: static secrets create broad blast radius, while dynamic secrets narrow it. The same applies to vendor accounts. In practice, the strongest control is to avoid shared third-party credentials wherever possible and replace them with scoped federation, approvals, and time-boxed access.
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 overprivileged and long-lived non-human credentials used by third parties. |
| NIST CSF 2.0 | PR.AC-4 | Covers access control for external identities and shared service accounts. |
| NIST AI RMF | Helpful where third-party access supports AI or automated workflows. |
Replace standing vendor secrets with short-lived, least-privilege NHI access and revoke on completion.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
