Third-party risk drift

Expanded Definition

Third-party risk drift is the slow mismatch between an approved vendor’s original risk profile and its current operating reality. In NHI governance, that drift often shows up in service accounts, API keys, certificates, and integrations that expand after onboarding, even though the due diligence record has not changed. Definitions vary across vendors, but the core issue is the same: risk is being reassessed too infrequently for the pace of change.

In practice, this concept sits at the intersection of vendor management, privileged access management, and NHI lifecycle control. The OWASP Non-Human Identity Top 10 frames stale secrets and unmanaged machine identities as recurring risk drivers, while the NIST Cybersecurity Framework 2.0 reinforces the need for continuous identification, protection, detection, and response rather than one-time approval. The most common misapplication is treating vendor onboarding as a permanent control state, which occurs when access, subcontractors, or tooling changes are not re-reviewed after go-live.

Examples and Use Cases

Implementing third-party risk drift controls rigorously often introduces review overhead and vendor friction, requiring organisations to weigh faster onboarding against ongoing assurance and tighter change monitoring.

• A SaaS provider adds a new subcontractor with access to production logs, but the original risk assessment still reflects only the prime vendor’s controls.
• An integration expands from read-only API access to write privileges, yet the service account entitlement review is never updated to match the new blast radius.
• A software supplier rotates deployment tooling and begins storing secrets in a new CI/CD path, creating exposure that no longer matches the initial Ultimate Guide to NHIs — Key Challenges and Risks baseline.
• A vendor incident triggers a reassessment, and teams discover that dormant credentials still work because the offboarding process was never aligned with the current integration map.
• Supply chain compromise cases such as the Reviewdog GitHub Action supply chain attack show how third-party trust can fail when hidden dependencies and secrets exposure are not continuously tracked.

The right response is not to block every vendor change, but to require change notification, entitlement reattestation, and periodic control evidence refresh so the approved risk record stays current. That is especially important where agentic systems or automation services can create new machine identities without a human-owner workflow.

Why It Matters in NHI Security

Third-party risk drift matters because vendor trust often becomes a conduit for NHI compromise long after onboarding is complete. NHI exposure is especially dangerous when secrets, tokens, and certificates remain valid while the surrounding control environment has changed. NHI Mgmt Group research shows that 92% of organisations expose NHIs to third parties, raising direct supply chain concerns, and 91.6% of secrets remain valid five days after notification, which means remediation can lag behind real-world exposure.

That lag is exactly where drift becomes an attack path. The 52 NHI Breaches Analysis and the Salesloft OAuth token breach both illustrate how trusted third-party access can be abused once credentials, integrations, or governance assumptions fall behind operational reality. Practitioners should pair vendor review cadence with NHI inventory checks, secret rotation, and least-privilege validation under OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0.

Organisations typically encounter third-party risk drift only after a vendor change, credential leak, or incident review reveals that the approved risk profile no longer matches the live environment, at which point the concept becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How do third-party SaaS integrations create NHI risk and how should they be managed?
• How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?
• How can organisations reduce risk from third-party OAuth integrations?
• What is the difference between third-party risk management and NHI governance?