They should move from document-based assurance to live monitoring of third-party identities, tokens, and integrations. The practical question is whether a vendor connection is behaving inside its expected scope today, not whether it passed a questionnaire months ago. Runtime evidence must drive containment and review.
Why runtime behaviour changes the third-party risk decision
When third-party risk is judged by runtime behaviour, the control question shifts from “Did the vendor look safe at review time?” to “Is the vendor connection acting safely right now?” That matters because integrations, tokens, and delegated access can drift after approval. The real risk is not just supplier posture, it is live scope, live privilege, and live abuse potential.
Document-based assurance still has value, but it becomes a starting point rather than the decision engine. A questionnaire can tell you what a supplier claims about process and controls; it cannot prove whether an API token is still active, whether a support channel is overbroad, or whether a connection is being used outside its intended purpose.
For that reason, organisations should treat the runtime path as the unit of trust. Monitoring should focus on which third-party identities are authenticating, what tokens or keys they present, what resources they touch, and whether the activity matches the narrow business function originally approved. That is the difference between static vendor confidence and operationally defensible access control.
What must change in monitoring, containment, and review
The practical shift is to instrument the integration itself, not just the supplier questionnaire. Teams need visibility into authentication events, token usage, unusual scopes, atypical timing, new source locations, and sudden changes in access patterns. Where possible, this should be joined to the owning business process so reviewers can tell whether the activity is expected, tolerated, or immediately suspicious.
This is also where containment becomes faster and more precise. If runtime evidence shows that a vendor connection is overreaching, the response should be to narrow the integration, rotate or revoke the credential, and isolate the affected path rather than waiting for a formal supplier reassessment cycle. The review process should be triggered by observable behaviour, not by calendar cadence alone.
The strongest programs also distinguish between evidence of control design and evidence of control operation. A vendor can have a written control on paper and still generate unsafe behaviour in production. Runtime review closes that gap by asking whether the live identity, token, or integration is still acting within the expected blast radius.
Where organisations usually misread third-party behaviour
The most common mistake is assuming that approved equals bounded. Third-party access often begins with a legitimate integration and ends up wider through token reuse, excessive scopes, stale credentials, or a forgotten support path. Over time, the approval record becomes less informative than the live permission state.
Another failure mode is treating alerting as sufficient without defining what “normal” looks like for each vendor path. Runtime monitoring only helps if the organisation can distinguish approved automation from anomalous use, otherwise every deviation becomes noise and no one knows when to escalate. Clear scope definitions, ownership, and revocation thresholds are what make runtime evidence actionable.
This matters even more when a third party has delegated access into sensitive systems, because the compromise of a vendor identity can turn into lateral movement, data access, or operational disruption. In those cases, the question is not only whether the supplier is trustworthy, but whether the trust relationship is still constrained enough to survive misuse.
Risk and Threat Considerations
Runtime-dependent third-party risk is dangerous because the thing being trusted is not a static organisation, it is a live access path. If that path is not monitored continuously, stale scopes, stolen tokens, or unexpected tooling changes can turn an approved integration into a stealthy entry point.
Failure mechanism: A vendor identity or token drifts outside its approved scope, remains active after it should have been cut off, or is abused through a trusted integration path before periodic review catches the change.
Impact: The organisation can lose data, suffer unauthorised actions, or miss early signs of compromise because the access looked legitimate on paper while it was operationally unsafe.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Runtime third-party risk hinges on live identity and access control over vendor paths. |
| Recommendation — Enforce live IAM controls for third-party identities, scopes, and revocation. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Runtime monitoring depends on logging vendor authentication and access events. |
| AC-6 — Least Privilege | The question is about shrinking live third-party access to expected scope. | |
| IA-5 — Authenticator Management | Tokens and keys are the live control point for third-party runtime access. | |
| Recommendation — Log third-party authentication and access events for continuous review. Apply least privilege to every third-party integration and token. Rotate and revoke third-party authenticators when runtime use changes. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero trust fits runtime-dependent third-party trust because access must be verified continuously. |
| Recommendation — Continuously verify third-party access instead of trusting prior approval. | ||
Practitioner Guidance
What to prioritise: Build your review around the most privileged and most business-critical third-party connections first. Those paths deserve continuous monitoring, tighter scope limits, and faster revocation authority than low-impact supplier links.
What to verify: Confirm that each vendor connection has an owner, an explicit purpose, a defined scope, and a way to detect when live behaviour exceeds that scope. If you cannot state those four items, the integration is not ready for runtime-based assurance.
Decision rule: If a third-party identity can still reach production assets after the business need has changed, treat that as a containment issue, not a procurement issue. Revoke or narrow access first, then complete the formal review.
Practitioner takeaway: Static supplier assurance can support the decision, but runtime evidence must decide whether the trust relationship is still safe enough to keep active.
Related resources from NHI Mgmt Group
- How do organisations reduce compliance risk when PKI depends on HSMs, SCEP, and third-party components?
- When should organisations treat an NHI as a high-priority risk?
- How can organisations reduce risk from third-party OAuth integrations?
- Should organisations treat third-party access as a privileged identity risk?