How should security teams build a third-party risk programme that actually reduces identity risk?

Why This Matters for Security Teams

Third-party risk programmes often fail because they focus on contract checks and questionnaire scores while missing the identity paths vendors actually use. When a supplier can reach SaaS admin consoles, CI/CD systems, or cloud resources through OAuth apps, API keys, service accounts, or support access, the real risk is not the vendor itself but the identities it can activate. Current guidance suggests treating third-party identity exposure as a control problem, not a procurement exercise.

This is where the gap becomes visible in practice. NHIMG research shows that Astrix Security & CSA found 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which means many programmes do not know what access exists, let alone whether it is still needed. That aligns with the broader identity risk picture in the Ultimate Guide to NHIs, where exposed and over-privileged non-human identities are a recurring failure mode.

Security teams that do not map vendor identities, monitor active entitlements, and revoke access reliably are usually operating with an incomplete risk model. In practice, many teams discover third-party identity exposure only after a vendor account is abused or a stale token is found during incident response.

How It Works in Practice

A third-party risk programme reduces identity risk when it follows the identity lifecycle end to end: discover, classify, approve, monitor, and revoke. Start with a living inventory of every third party that can touch systems, data, or credentials. That inventory should include human vendor users, machine identities, delegated OAuth grants, service accounts, support accounts, API keys, certificates, and any agentic workflows that act on behalf of the vendor.

From there, tier vendors by what their identities can reach. A supplier with read-only access to a non-production app does not need the same scrutiny as one with write access to production secrets or cloud control planes. Tie each tier to evidence-based controls, such as proof of MFA for human access, proof of vaulting and rotation for secrets, and proof of logging for every privileged action. The OWASP Non-Human Identity Top 10 is useful here because it frames the common control failures around discovery, privilege, lifecycle, and secret hygiene.

Operationally, the programme should require:

• named business and technical owners for every vendor identity
• time-bound approvals with explicit purpose and scope
• JIT or short-lived access where feasible instead of standing credentials
• continuous review of OAuth grants, token scopes, and dormant accounts
• offboarding triggers that revoke access when the contract, task, or support case ends

Use policy and inventory data together. NIST’s risk and control models in the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls support this approach by linking asset governance, access control, and monitoring to measurable outcomes. These controls tend to break down when vendor access is embedded in ad hoc integrations, because no single team owns the approval trail or the revocation path.

Common Variations and Edge Cases

Tighter vendor controls often increase onboarding time and operational overhead, so organisations have to balance speed against assurance. That tradeoff is real, especially for SaaS-heavy environments where vendors self-provision integrations, or where support teams need temporary elevated access during incidents. Best practice is evolving here, and there is no universal standard for every vendor type.

One common edge case is delegated access through platform integrations. A vendor may never log in directly, yet its OAuth app can still read mailboxes, manipulate tickets, or reach cloud data. Another is subcontractor chains, where the primary supplier is assessed but downstream identities remain invisible. The 52 NHI Breaches Analysis and Top 10 NHI Issues both reinforce the same lesson: excessive privilege and poor lifecycle control are persistent drivers of compromise.

For high-risk vendors, current guidance suggests adding stronger evidence requirements such as independent attestations, scoped access reviews, and token rotation SLAs. For lower-risk vendors, lighter-weight controls may be acceptable if access is genuinely minimal and continuously observed. The important point is consistency: every exception should still have an owner, an expiry, and a revocation path. Third-party identity risk becomes manageable only when the programme can prove that access is removed as reliably as it is granted.

Related resources from NHI Mgmt Group

• How should security teams build a patch compliance programme that actually reduces risk?
• How should security teams build a phishing programme that actually reduces risk?
• How should security teams build a permission concept that actually reduces risk?
• How should security teams start a third party risk management programme from scratch?