Because approval does not equal containment. Once a vendor is inside the environment, the material questions are what they can reach, how long the access lasts, and whether activity is visible. If those controls are weak, a compromise on the vendor side can turn into lateral movement, data exposure, or service disruption inside your own estate.
Why This Matters for Security Teams
Third-party access is risky because the approval step only answers who signed off, not what the external party can actually do once access exists. Security teams need to think in terms of blast radius, session duration, visibility, and revocation, because those are the controls that decide whether a vendor login is a bounded task or an open-ended foothold. In practice, many organisations discover the real exposure only after a vendor account has been active long enough to be reused, overextended, or quietly abused.
The problem compounds when third parties touch production systems, data stores, support tooling, or identity-adjacent control planes. A vendor with legitimate access can still create material exposure if permissions are broader than necessary, credentials are long-lived, or activity is poorly logged. That is why approval workflows must be treated as only one layer in the control stack, not the control itself. OWASP Non-Human Identity Top 10 is useful here because it highlights how overprivilege, secret sprawl, and weak lifecycle controls turn access into a persistent risk surface.
Approval answers governance; containment answers security.
How It Works in Practice
In a working third-party access model, the approval record should trigger a constrained access path, not a standing entitlement. The practical question is whether the access is tied to a named business purpose, time-bounded, scoped to the minimum systems needed, and observable enough to reconstruct activity after the fact. If any of those conditions are missing, the approval process may be compliant on paper while still leaving the environment exposed.
Teams usually need to control four things at once:
- Scope: limit the vendor to the smallest set of applications, data sets, and administrative actions required for the task.
- Time: make access expire automatically, especially for break-fix work and temporary integrations.
- Visibility: log sessions, commands, file transfers, and privilege changes so activity can be reviewed or investigated.
- Revocation: remove access quickly when the task ends, the contract changes, or the vendor posture changes.
This is where approval workflows often fail in practice, because they are detached from the operational mechanics that actually limit damage. A ticket can say “approved,” yet the vendor still has reusable credentials, broad role membership, or indirect access through shared tooling. If the organisation cannot answer which systems were reached, what was changed, and when the access ended, then it has approval without control. CIS Controls v8 is a strong reference point for translating that into account management, access control, and audit logging discipline.
These controls tend to break down when vendors need broad emergency privileges across multiple environments, because the operational pressure to “just make it work” usually defeats scope, time limits, and review.
Common Variations and Edge Cases
Tighter third-party control often increases operational overhead, so organisations have to balance speed against the risk of uncontrolled reach. That tradeoff becomes more pronounced with managed service providers, embedded support teams, and software integrations that rely on persistent access rather than human logins. In those cases, the access pattern may look routine, but the risk profile is closer to an always-on trust relationship than a simple approval workflow.
There is also a real difference between low-risk read-only access and privileged access that can change configurations, exfiltrate data, or create new credentials. Best practice is evolving toward treating these cases differently rather than applying one generic approval path to all third parties. Some environments also blur the line between human vendor access and automated third-party access, which makes lifecycle control and revocation even more important because the account may outlive the person or task it was created for.
NIST SP 800-207 Zero Trust Architecture is relevant when the access model needs continuous verification rather than one-time trust, and Ultimate Guide to NHIs helps frame the lifecycle issues that arise when access is long-lived, third-party exposed, or difficult to inventory. The common failure mode is assuming the approval boundary is the security boundary, when the real boundary is whether the access can be contained after it is granted.
Risk and Threat Considerations
Third-party access creates concentration risk because one external relationship can open paths to multiple internal systems, data stores, or administrative functions. That makes the control failure more consequential than a normal user approval, especially when the vendor account is overprivileged, poorly monitored, or difficult to revoke.
Failure mechanism: the attacker compromises the vendor side, reuses legitimate access, and then moves through trusted interfaces that defenders are less likely to challenge. The same mechanism applies when a vendor goes beyond the originally intended task because the access model never enforced hard boundaries.
Impact: the organisation can face lateral movement, data exposure, credential theft, service disruption, or persistence that survives the original approval window. Once that happens, the incident is no longer about whether the access was approved, but whether it was actually constrained.
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 ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Visibility and Inventory | Third-party access risk rises when vendor identities and access paths lack inventory. |
| NHI-03 — Secrets and Credential Management | Vendor access often relies on long-lived credentials that expand exposure after approval. | |
| NHI-05 — Overprivileged Access | Approved vendor access still becomes risky when permissions exceed the task scope. | |
| Recommendation — Inventory third-party identities, map their access, and remove any unmanaged pathways. Rotate vendor credentials, eliminate shared secrets, and enforce short-lived access where possible. Apply least privilege to vendor access and strip any unnecessary administrative rights. | ||
| CIS Controls v8 | 6 — Access Control Management | Third-party access is a lifecycle and entitlement control problem that needs enforced restriction. |
| 8 — Audit Log Management | Visibility into vendor activity is essential for detecting misuse after approval. | |
| Recommendation — Restrict vendor access to approved needs and revoke it immediately when no longer required. Log vendor sessions and privileged actions so access can be reviewed and investigated. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Continuous Verification and Policy Enforcement | Zero trust is directly relevant when approved access must still be continuously constrained. |
| Recommendation — Enforce policy at each request and re-check vendor access continuously instead of trusting approval alone. | ||
| MITRE ATT&CK | T1199 — Trusted Relationship | Attackers commonly abuse trusted third-party relationships to reach internal environments. |
| Recommendation — Hunt for abused trusted relationships and monitor vendor access for unusual follow-on activity. | ||
Practitioner Guidance
What to prioritise: Treat every third-party approval as the start of a containment design review. The first question should be whether the vendor can reach only the systems and data needed for the task, and whether access will expire without manual intervention.
What to verify: Confirm that approvals map to explicit scope, time limit, and revocation logic. If the access path depends on shared credentials, standing roles, or an exception process to remove access later, the control is weaker than the approval record suggests.
Common mistake: Assuming ticket approval equals acceptable risk. The stronger test is whether an incident responder could reconstruct and shut down the access quickly if the vendor account were abused.
Practitioner takeaway: The right design objective is not “approved access,” it is “approved access that can be bounded, observed, and removed before it becomes a foothold.”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
