Because access often outlives the business relationship that justified it. Shared credentials, support accounts, and API keys can remain active after contracts change, creating a trust gap that questionnaires do not close. The risk grows when no one owns revocation, review cadence, or proof of removal.
Why This Matters for Security Teams
Third-party access is risky because it is usually provisioned for a business purpose, but deprovisioned on a different timeline, if at all. That mismatch affects human admins, support portals, vendor service accounts, API keys, and machine tokens alike. Current guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both point toward continuous access governance, not one-time approval.
NHIMG research shows the scale of the gap: the 52 NHI Breaches Analysis documents how secrets and service accounts frequently persist after their original purpose expires, leaving a silent trust boundary in place. For practitioners, the key issue is not whether a supplier was trusted at onboarding, but whether that trust is still justified after renewal, scope changes, or contract termination.
In practice, many security teams discover the problem only after an incident review, rather than through intentional third-party offboarding.
How It Works in Practice
A third-party relationship creates persistent risk when access is distributed across multiple control planes and nobody owns the full lifecycle. The vendor may hold an API key, a support login, a certificate, a CI/CD secret, or a delegated workload identity. Even if the contract says access should end, the operational reality often includes hidden copies in ticket notes, scripts, vaults, and message threads. NHIMG has repeatedly shown that weak secret handling is a recurring failure mode in the Top 10 NHI Issues, especially where secret sprawl outpaces ownership.
Best practice is to treat third-party access as a controlled identity relationship, not a checkbox in procurement. That means:
- issuing access with a named business owner and expiry date
- preferring JIT credential provisioning over standing access
- binding secrets to the smallest viable scope and shortest viable TTL
- requiring evidence of revocation, not just attestation of policy
- reviewing machine and human access together so a vendor cannot keep one path after another is removed
This is where workload identity matters. Instead of relying only on shared credentials, teams should use cryptographic proof of what the workload is, then apply intent-based authorisation at request time. That approach aligns with the direction of the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, both of which emphasise least privilege, lifecycle control, and continuous verification.
These controls tend to break down when third parties share credentials through email or chat, because revocation cannot reliably reach every copy.
Common Variations and Edge Cases
Tighter access control often increases integration overhead, requiring organisations to balance fast vendor support against stronger revocation discipline. There is no universal standard for every third-party pattern yet, especially where suppliers need emergency access, managed services, or cross-cloud automation. In those cases, current guidance suggests using time-bound approvals, explicit break-glass paths, and separate identities for support versus production operations.
The hardest edge case is legacy connectivity. Older SaaS, SFTP, and batch interfaces often cannot support modern JIT or workload identity, so teams fall back to static secrets and periodic password rotation. That may reduce exposure, but it does not eliminate persistence risk unless ownership and revocation are still enforced. NHIMG’s breach coverage in The 52 NHI breaches Report shows why this matters: compromised identities often persist long enough to be reused across environments.
For governance, the practical question is whether the relationship is bound to proof of need, or merely documented trust. Security teams that rely on questionnaires alone usually miss the operational details that matter most: who can still log in, which tokens still work, and which secrets were never fully removed. In mature programmes, that evidence sits alongside Ultimate Guide to NHIs guidance and external baselines such as OWASP Non-Human Identity Top 10, then gets enforced through review cadence rather than annual paperwork.
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 | Persistent third-party secrets and accounts are a core NHI lifecycle risk. |
| NIST CSF 2.0 | PR.AC-4 | Third-party access should be limited and continuously reviewed as least privilege. |
| NIST AI RMF | Autonomous agents and AI-enabled vendors need governance for dynamic access use. |
Apply AI RMF governance to define ownership, monitoring, and escalation for third-party automation.
