Why do third-party breaches keep increasing even when vendors have attestations and questionnaires?

Why point-in-time attestations do not keep pace with third-party breach paths

Attestations and questionnaires are governance artifacts, not live controls. They can confirm what a vendor said at a moment in time, but they do not verify whether the vendor’s tokens, permissions, integrations, or admin paths are still valid today. That is why breach risk keeps rising even when procurement evidence looks clean on paper.

In practice, the failure is often not the questionnaire itself, but the assumption that it proves operational security state. A vendor can answer “yes” to policy questions and still retain stale access, overbroad scopes, or unattended secrets that make the connection usable by an attacker.

What actually changes the breach outcome: access, privilege, and enforcement

The real determinant is whether the third party can still reach your environment and what it can do once inside. Current authorization, session validity, secret rotation, and enforcement boundaries matter more than historical assurances, because attackers target the surviving path of least resistance. NHIMG’s IAM and IGA Basics is useful background for separating authentication, authorization, provisioning, and review, which are often conflated in vendor assessments.

This is especially true for SaaS-to-SaaS links, delegated access, and service credentials. If an OAuth grant, API key, certificate, or support account still works, then the question is not whether the vendor once passed a review, but whether the active trust relationship is still appropriate. NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide and Third-Party, B2B and Contractor Access Guide both address the controls that questionnaires usually fail to prove in operation.

That gap is why breach narratives often center on stolen tokens, unmanaged integrations, or privileged support channels rather than on a missing policy statement. A vendor can be compliant on paper and still have a current access path that is too broad, too long-lived, or too weakly monitored to survive an attacker’s first attempt.

Why third-party assurance breaks down in real incidents

Most assurance programs are built around evidence collection, not runtime validation. They ask whether controls exist, but they rarely test whether access is actually narrowed, whether secrets have been rotated, or whether dormant grants have been removed. Once a third party sits inside an integration chain, that gap becomes an exposure problem, not a documentation problem.

Useful practitioner reading is the Ultimate Guide to NHIs, Key Challenges and Risks, because the same failure patterns show up repeatedly: secret sprawl, overprivilege, poor visibility, and weak offboarding. Those issues are common in third-party breaches because machine and integration identities are often treated as setup tasks instead of living assets.

The most common operational mistake is treating vendor due diligence as if it were equivalent to continuous access governance. It is not. A clean questionnaire does not tell you whether the vendor’s current permissions still match the minimum necessary for the business relationship, or whether compromise elsewhere has turned a legitimate connection into an attacker’s bridge.

Risk and Threat Considerations

Third-party connections are attractive to attackers because they concentrate trust: one compromised vendor credential, token, certificate, or support path can unlock multiple downstream environments. That creates both persistence risk and blast-radius risk, especially when access is federated or reused across systems.

Failure mechanism: the control failure is usually stale or overbroad trust, where the active credential, grant, or permission set remains valid long after the original review, or where the review never exercised the current path at all.

Impact: compromise can lead to unauthorized data access, lateral movement, service abuse, and incident response delays because defenders initially trust the relationship that has actually been abused.

Practitioner Guidance

What to verify: treat vendor assurance as a starting point, then verify the live access graph. Confirm which third parties still have active credentials, which grants can reach production, and which privileges are broader than the business purpose requires.

Decision rule: if a vendor can authenticate to a system that matters, prioritize token rotation, permission reduction, and offboarding checks before you spend time on questionnaire remediation. If you cannot revoke or narrow the access quickly, the finding is operationally material regardless of the paper trail.

What practitioners underestimate: third-party risk is often an identity and access problem disguised as a procurement or compliance process. The strongest signal is not that the vendor answered correctly once, but that your team can continuously prove the relationship is still bounded, current, and observable.

Practitioner takeaway: attestations document governance intent, but breach prevention depends on whether every third-party path is still valid, least-privileged, and actively enforced today.

Related resources from NHI Mgmt Group

• Why do third-party breaches keep happening even when MFA is in place?
• How should fintech security teams prioritise third-party risk controls when breaches still originate with vendors?
• Why do third-party vendors so often become the entry point for larger breaches?
• Why do third-party vendor breaches create risk for the buying organisation even when the vendor caused the incident?