Vendor risk assessment checklists expose the NHI governance gap

At a glance

What this is: This is a checklist-driven guide to vendor risk assessment, with the key finding that incomplete review processes can leave third-party access, security practices, and offboarding gaps exposed.

Why it matters: It matters because vendor governance now intersects with NHI lifecycle control, third-party access reviews, and broader identity programmes that must account for both human and non-human access paths.

👉 Read Zluri's vendor risk assessment checklist and seven control areas

Context

Vendor risk assessment is a governance process for deciding which third parties can access data, systems, or operations, and under what conditions. The article's core warning is that partial review can leave critical gaps in security practice, access control, and responsibility, which turns supplier onboarding into an identity and risk problem rather than a procurement exercise.

For IAM teams, the connection is wider than traditional vendor management. Third-party access often includes service accounts, API keys, credentials, and delegated permissions, so vendor review becomes part of NHI governance as well as human access oversight. The checklist framing is useful, but the programme question is whether organisations can actually verify, monitor, and revoke access across the full supplier lifecycle.

Key questions

Q: How should security teams assess vendor access that includes service accounts or API keys?

A: Security teams should treat vendor access with service accounts or API keys as delegated identity, not just supplier onboarding. That means verifying ownership, documenting the purpose of access, checking rotation and revocation procedures, and ensuring access is removed when the relationship changes. The review should cover both contract risk and identity risk.

Q: Why do vendor risk assessments fail when offboarding is not built in from the start?

A: They fail because access often outlives the business purpose that justified it. If offboarding is not defined at onboarding, teams may know how to grant access but not how to revoke it cleanly. That leaves stale credentials, unresolved permissions, and unclear responsibility when the vendor relationship ends or changes.

Q: What do security teams get wrong about vendor risk scoring?

A: The common mistake is treating the score as documentation instead of a decision trigger. A score should determine whether a vendor can onboard, must remediate, or should be blocked. If thresholds are vague, teams accumulate findings without changing access, which turns assessment into a reporting exercise rather than control enforcement.

Q: Who should own third-party access risk in an identity programme?

A: Ownership should sit with a business sponsor and an identity or security control owner, because vendor access cuts across procurement, compliance, and operational security. The business sponsor understands why access exists, while the control owner makes sure permissions, credentials, and reviews are actually enforced over the vendor lifecycle.

Technical breakdown

Vendor risk assessment as a lifecycle control

A vendor risk assessment is not a single approval event. It is a lifecycle control that starts before onboarding, continues through periodic monitoring, and ends with offboarding and access revocation. The article breaks this into gathering information, classifying risk, scoring it, setting thresholds, and reviewing vendors over time. That sequence matters because risk changes after the contract is signed, especially when the supplier's access, controls, or operating environment change mid-tenure.

Practical implication: treat vendor risk review as an ongoing governance process, not a one-time intake checklist.

Security practice evidence versus self-reported assurance

The article puts real weight on verifying what vendors claim, including authentication controls, authorization measures, vulnerability testing, and data disposal practices. That reflects a common failure mode in third-party governance: self-attestation without corroboration. In identity terms, the question is whether the vendor can prove who or what is allowed to access what, and whether that access can be revoked quickly when the relationship changes. Without evidence, the assessment becomes paperwork rather than control.

Practical implication: require verifiable control evidence before granting supplier access, especially for authentication, authorization, and data handling.

Risk scoring and thresholds turn judgment into enforcement

The checklist uses quantitative and qualitative scoring to translate vendor findings into action. That is the bridge between analysis and governance. A matrix can separate tolerable from unacceptable risk, but only if the thresholds are tied to enforcement decisions such as onboarding, remediation, or termination. In practice, scoring is where many programmes fail, because they record findings without defining what score blocks access or triggers review.

Practical implication: define decision thresholds in advance so vendor scores lead to consistent access and contract actions.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vendor risk review becomes identity governance when third parties are granted access. The article is really about who gets trusted, what evidence is sufficient, and when that trust ends. Once a supplier can touch data or systems, the checklist becomes part of access governance, not just procurement hygiene. Practitioners should treat vendor review as a control over delegated identity, not a documentation exercise.

The governance assumption that a vendor remains safe after onboarding is the weak point. This checklist assumes the risk picture established at intake stays broadly stable, but vendor security, compliance posture, and operational resilience can change mid-contract. That assumption fails whenever access persists beyond the moment the assessment was made. The implication is that lifecycle governance, not initial approval, is the real control boundary.

Third-party risk becomes NHI risk the moment credentials, tokens, or service access are involved. Vendor management language often obscures the identity layer underneath, but the actual exposure is frequently non-human. Shared secrets, delegated accounts, and API access are all governance objects that need ownership, review, and revocation. Practitioners should fold supplier access into NHI controls rather than leaving it in a separate procurement workflow.

Risk matrices matter only when they map to enforceable access decisions. The article correctly distinguishes tolerable, manageable, unacceptable, and intolerable risk, but many programmes stop at scoring. That creates the appearance of control without the authority to act. A vendor risk score should determine whether onboarding proceeds, remediation is mandatory, or access is revoked. Practitioners should make the score operational, not descriptive.

Lifecycle governance gap: Vendor assessments fail when they do not prove who is responsible for revoking access after the business relationship changes. The article repeatedly emphasizes monitoring, offboarding, and reassessment, which is exactly where many third-party programmes break. Access outlives accountability unless offboarding is explicit, testable, and owned. Practitioners should regard revocation as part of the original assessment, not a future administrative step.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That makes the NHI Lifecycle Management Guide the next step for teams that need to connect vendor review to credential lifecycle control.

What this signals

Vendor access is now an identity problem as much as a procurement problem: the more suppliers can reach sensitive systems, the more your programme depends on proving ownership, revocation, and review. Teams that keep third-party risk in a separate spreadsheet will miss the point that delegated access is part of the identity surface.

The practical shift is toward lifecycle evidence, not checklist completion. If a vendor cannot demonstrate who can access what, how that access is monitored, and how it is removed, the assessment is incomplete regardless of how polished the questionnaire looks.

For practitioners

• Map every vendor to an access owner Assign a named business and technical owner for each supplier that can reach data, applications, or infrastructure, and make that owner responsible for reviews, exceptions, and revocation decisions.
• Require evidence for security claims Do not accept questionnaires alone for authentication, authorization, vulnerability management, or data disposal. Ask for control evidence that can be verified during onboarding and review.
• Define score-to-action thresholds Pre-set the risk score ranges that allow onboarding, require remediation, trigger escalation, or block the vendor entirely so scoring produces consistent governance outcomes.
• Review third-party access as part of NHI governance Include API keys, service accounts, tokens, and other delegated access in the same review cycle as vendor contracts so non-human access cannot evade lifecycle controls.
• Test offboarding before a relationship changes Validate that access removal, credential revocation, and contract termination steps work in practice before the vendor relationship ends, not after an incident exposes the gap.

Key takeaways

• Vendor risk checklists fail when they stop at intake and do not govern the full supplier lifecycle.
• The real exposure is delegated access, because third-party credentials and permissions behave like NHI controls once they reach production systems.
• A useful risk assessment produces enforceable outcomes, including remediation, escalation, or revocation, not just a scored worksheet.

Key terms

• Vendor Risk Assessment: A vendor risk assessment is the process of evaluating the security, operational, compliance, and financial risks introduced by a third party before and during the relationship. In identity terms, it also includes deciding what access the vendor gets, how that access is reviewed, and how it is revoked when the business need changes.
• Third-Party Access: Third-party access is any permission granted to an external supplier to reach systems, data, or services. It often includes accounts, credentials, API keys, or delegated permissions that must be governed like identity assets, because the business relationship does not guarantee the access remains appropriate over time.
• Risk Threshold: A risk threshold is the pre-agreed point at which a vendor risk score triggers a specific action, such as remediation, escalation, or rejection. Without a threshold, scoring becomes descriptive only and does not create a reliable governance decision.
• Offboarding: Offboarding is the controlled removal of access, permissions, and related dependencies when a relationship ends or changes. For vendors, it should include revoking credentials, removing accounts, confirming residual access is gone, and documenting ownership so access does not survive the contract.

Deepen your knowledge

Vendor access, lifecycle control, and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is trying to connect third-party review with identity control, it is worth exploring.

This post draws on content published by Zluri: Vendor Management Vendor Risk Assessment Checklist: 7 Key Components. Read the original.