They rely on self-reported answers, so they can show what a vendor says it does without proving what actually happens in production. Risk falls only when organisations validate the claims with logs, certifications, audits, or monitoring data and then link those findings to access decisions.
Why This Matters for Security Teams
Vendor questionnaires are useful only as an intake step. They help a team compare claims, but they do not verify whether a vendor actually enforces least privilege, rotates secrets, monitors NHI activity, or blocks misuse in production. That gap matters because attackers do not care what is written in a spreadsheet. They care whether a secret is exposed, whether an API key is active, and whether an identity can be abused before anyone notices. NHIMG research on compromised NHIs shows the scale of the problem: 72% of organisations have experienced or suspect a breach of non-human identities, and two-thirds have suffered a successful cyberattack resulting from compromised NHIs, according to Ultimate Guide to NHIs — Why NHI Security Matters Now. That is why questionnaires must be paired with evidence, not treated as evidence themselves. Current guidance from NIST Cybersecurity Framework 2.0 supports risk-based verification rather than trust-by-assertion. In practice, many security teams encounter the failure only after a vendor credential has already been used in production.
How It Works in Practice
A questionnaire should be treated as a claim register, then validated against operational proof. For NHI and secrets risk, that proof usually includes authentication logs, secret-scanning results, cloud audit trails, certificate inventories, PAM records, and evidence of JIT provisioning. If a vendor says tokens are short-lived, the team should ask for TTL settings and revocation logs. If it says access is role-based, the team should verify whether those roles are actually bounded, reviewed, and enforced at runtime. This is especially important where autonomous software entities and AI agents exist, because their tool use and access paths are dynamic. For that reason, the control conversation should map to OWASP NHI Top 10 and not stop at policy language alone.
A practical workflow looks like this:
- Collect the questionnaire response as the vendor’s assertion.
- Request logs, screenshots, certifications, audit extracts, or monitoring exports.
- Check whether secrets are ephemeral, rotated, and revoked on task completion.
- Confirm that access decisions are tied to workload identity and current context, not only static RBAC.
- Make the outcome affect onboarding, access scope, and renewal decisions.
This approach aligns with the verification mindset in NIST Cybersecurity Framework 2.0 and with the broader NHI governance patterns discussed in Top 10 NHI Issues. These controls tend to break down when the vendor has many ephemeral workloads, because evidence is distributed across short-lived containers, SaaS integrations, and fast-changing CI/CD pipelines.
Common Variations and Edge Cases
Tighter verification often increases procurement friction and operational overhead, so organisations have to balance speed against assurance. That tradeoff is real, especially for small vendors that cannot produce enterprise-grade evidence packs on demand. Best practice is evolving here, and there is no universal standard for how much proof is enough. Some buyers accept a certification plus targeted control evidence; others require live monitoring data and recurring attestations for higher-risk services.
The hardest edge cases are vendors that rely on subcontractors, shared platforms, or agentic workloads. A questionnaire may be accurate for the named supplier but miss downstream NHI sprawl, such as API keys embedded in automation, stale service accounts, or an AI agent that can call tools beyond its intended scope. That is where intent-based authorisation, JIT secrets, and workload identity become more useful than static role descriptions. Security teams should also be cautious with “compliant” answers that do not say who reviews access, how often secrets rotate, or what happens after a breach is suspected. For agentic systems, the relevant lens is the runtime behaviour of the workload, not only the policy text. NHIMG’s DeepSeek breach is a reminder that exposed secrets and exposed data often coexist, which is why questionnaires alone are not a control.
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 | Relevant to secret rotation and validation of NHI access claims. |
| NIST CSF 2.0 | PR.AC-4 | Directly supports least-privilege verification for vendor and NHI access. |
| NIST AI RMF | Useful where vendor services include autonomous or agentic AI behaviour. |
Verify secret rotation, revocation, and workload access evidence before granting or renewing vendor access.
