Provider due diligence is the recurring review of a supplier’s architecture, ownership, regulatory posture, and operational controls before and after adoption. For identity services, it is not just procurement validation. It is part of ongoing trust assurance because the provider influences real security and compliance outcomes.
Expanded Definition
Provider due diligence is the disciplined review of a third party’s technical architecture, governance, ownership, compliance posture, and operational controls before onboarding and throughout the relationship. In NHI security, the term is broader than procurement approval because the provider may issue, store, rotate, observe, or broker credentials and service access that directly affect trust boundaries.
Industry usage is still evolving, but the practical standard is increasingly aligned with continuous assurance rather than one-time questionnaires. That means teams should assess how the provider handles secrets, tenant isolation, logging, incident response, sub-processors, and administrative access, then validate whether those controls still hold after product changes or ownership changes. Guidance from the NIST Cybersecurity Framework 2.0 supports this posture by treating supplier risk as part of enterprise governance, not a static procurement task.
The most common misapplication is treating due diligence as a one-time vendor questionnaire, which occurs when organisations stop review after contract signature and miss drift in the provider’s controls.
Examples and Use Cases
Implementing provider due diligence rigorously often introduces review latency and evidence-gathering overhead, requiring organisations to weigh faster onboarding against a smaller but better understood trust surface.
- Before adopting a secrets management platform, a team reviews whether the provider enforces tenant isolation, HSM-backed key handling, and clear admin separation, then rechecks those controls after major product releases.
- During a SaaS renewal, security staff examine the provider’s breach history, audit reports, ownership changes, and subcontractor model to confirm that inherited NHI access still matches the intended risk appetite.
- After discovering token leakage in a CI/CD pipeline, investigators compare the provider’s logging and revocation workflow with evidence from the JetBrains GitHub plugin token exposure to determine whether similar blast-radius conditions exist.
- For identity federation or agent tooling, teams validate whether the provider documents credential rotation, emergency revocation, and administrative access review so that machine-to-machine trust can be withdrawn quickly when needed.
- Security teams often map the review against NIST Cybersecurity Framework 2.0 categories to keep supplier oversight tied to governance and incident readiness.
Why It Matters in NHI Security
Provider due diligence matters because NHI security failures rarely stay confined to the supplier boundary. A weak provider can expose service accounts, API keys, automation tokens, and credential logs that customers assumed were protected elsewhere. NHIMG research shows that 92% of organisations expose NHIs to third parties, which makes supplier oversight a direct control point for reducing attack paths.
That exposure becomes more serious when teams underestimate the persistence of secrets and the speed of privilege misuse. The same research reports that 97% of NHIs carry excessive privileges and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage. Due diligence therefore needs to test not only policy claims, but also whether the provider can prove secure lifecycle management, rapid revocation, and safe recovery after compromise.
Organisations typically encounter the operational necessity of provider due diligence only after a token leak, compromised integration, or sudden vendor incident, at which point the ability to reassess trust becomes operationally unavoidable to address.
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-01 | Covers third-party NHI exposure and supplier-driven identity risk. |
| NIST CSF 2.0 | GV.SC | Supplier risk governance is a core CSF 2.0 outcome. |
| NIST AI RMF | AI RMF emphasizes trustworthy third-party dependencies and lifecycle risk. |
Require vendors to prove how they protect, rotate, and revoke machine credentials before and after onboarding.
