Teams often treat certifications as blanket proof that a vendor is safe, when they are only evidence within a defined scope and time period. The mistake is not using certifications. The mistake is failing to check service coverage, report freshness, and whether the certification actually matches the access being granted.
Why This Matters for Security Teams
Certifications are useful, but they do not answer the question security teams actually need to settle: does this provider’s control evidence match the exact service, data flow, and access path being approved? A SOC 2 report, ISO certificate, or similar attestation can be legitimate and still miss the most relevant risk if the scope is narrow, the control window is stale, or the vendor has changed architecture since the audit.
This matters most when the approved connection involves secrets, API access, or delegated automation. A team that accepts a certificate as a substitute for targeted due diligence may overlook whether privileged access is rotated, whether third-party OAuth exposure is visible, or whether the control set covers NHI-adjacent access. NHIMG research on the State of Non-Human Identity Security shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is exactly where blanket trust assumptions tend to fail.
Security questionnaires still matter because they force context: what is connected, who can reach it, which environments are in scope, and what operational exceptions exist. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports evidence-based assessment, but not evidence-by-credential alone. In practice, many security teams discover the mismatch only after an integration has already been granted broad access and the audit report is no longer describing the thing being used.
How It Works in Practice
The operational mistake is treating a certification as a binary trust signal instead of one input into a scoped risk review. A strong process starts by matching the certification to the actual service, region, data type, and control boundary. If the vendor is presenting a SOC 2 report, the team should confirm whether the specific product, subsidiary, or platform instance is included. If the question concerns automated access, the team should verify controls over tokens, service accounts, and delegated OAuth grants, not just the corporate perimeter.
Questionnaires work best when they translate the certification into operational questions:
- Is the certified environment the same one that will process the company’s data?
- Are the relevant logs, retention settings, and escalation paths in scope?
- Do access reviews cover non-human identities, not only employee accounts?
- Has the report expired, or has architecture changed since the assessment period?
For agentic and API-driven environments, the distinction is even sharper. An attestation can show that a vendor had controls at audit time, while a questionnaire can expose whether the current integration uses a privileged service principal, a long-lived secret, or an overbroad OAuth grant. That is why NHIMG’s Ultimate Guide to NHIs is useful as a framing aid: it helps teams recognize when the “vendor account” is actually a non-human identity with its own lifecycle and blast radius. Best practice is to combine certification review with contract language, technical validation, and periodic re-attestation rather than relying on a single report. These controls tend to break down in fast-moving SaaS environments because integrations change faster than audit cycles and the certified scope lags the live configuration.
Common Variations and Edge Cases
Tighter vendor review often increases procurement friction, requiring organisations to balance speed against assurance. That tradeoff becomes more visible when the vendor is small, newly acquired, or running multiple service tiers under one certification umbrella.
There is no universal standard for when a certificate alone is enough. For low-risk tooling with no sensitive data and no privileged access, a current certification may be sufficient as a screening step. For systems handling regulated data, production secrets, or agentic automation, current guidance suggests a questionnaire plus evidence review is the safer baseline.
Edge cases usually involve scope drift. A vendor may be certified for one product but not for the add-on module being purchased. A platform may have passed an audit before a major cloud migration. Or a report may be technically valid while the access path relies on a third-party integration that the audit never evaluated. In those cases, the right response is not to reject certifications, but to narrow the claim: ask what exactly was assessed, when, and whether the control extends to the service being connected. For teams handling identity-heavy integrations, the same principle explains why breach patterns such as the Sisense breach and similar incidents matter: the failure is often not the absence of a certificate, but the assumption that certification automatically covers every access path and every downstream identity.
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 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Vendor certifications must be validated against actual scope and current risk. |
| NIST SP 800-53 Rev 5 | SA-9 | External system services need security terms and evidence beyond a certificate. |
| OWASP Non-Human Identity Top 10 | NHI-4 | Non-human identities often sit behind vendor integrations and need explicit review. |
| NIST AI RMF | GOV-4 | Assurance claims should be tied to accountable governance and evidence management. |
| MITRE ATLAS | AML.T0058 | Attackers exploit overtrusted integrations and weak validation around connected systems. |
Use certification evidence as one input, then verify live scope, ownership, and ongoing oversight.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
