The set of vendors, contractors, tools, and services that can reach an organisation’s systems or data. It matters because the real risk is not the number of relationships, but the privilege each relationship carries and how far an attacker could move if one is compromised.
What the third-party access graph actually shows
A third-party access graph is not just a list of outside organisations. It is a map of who can reach what, through which accounts, integrations, and support paths, and with what level of privilege. That distinction matters because two vendors with the same “access” label can have radically different blast radii.
The graph becomes useful when it reflects real operational relationships, not paperwork. A contractor with read-only access to one portal is very different from a support provider that can reset credentials, impersonate users, or reach production data through a delegated tool chain.
Why privilege and reach matter more than headcount
The main analytic value of a third-party access graph is that it turns vendor inventory into exposure analysis. The important question is not how many external parties exist, but whether any of them sit on a path to sensitive systems, administrative functions, or shared data stores.
This is why third-party access should be read together with entitlement depth, session type, and trust boundary. A low-trust supplier with narrow permissions creates a very different security posture from a business-critical integration that can act on behalf of the organisation across multiple applications.
NHIMG’s IAM and IGA Basics is a useful companion for understanding why access graphs are really about entitlements, not just identities.
How access graphs expose hidden dependency chains
Third-party access often becomes risky because the graph is multi-step rather than direct. A vendor may not log in to your core system itself, but may reach it through federation, a support platform, an API token, or an application credential that was originally issued for a narrow purpose and later reused.
Those dependency chains are what make access graphs operationally valuable. They can reveal dormant relationships, overbroad delegation, and pathways where a compromise in one external service can pivot into internal data, admin functions, or downstream systems.
NHIMG’s Third-Party, B2B and Contractor Access Guide shows the governance patterns that usually need to be reflected in the graph, including sponsorship, least privilege, and time bounds.
Where the graph becomes a security control
When maintained well, the graph supports review, escalation, and offboarding. It helps teams answer which outside parties still have active access, which paths are justified, which credentials are shared across services, and which relationships should be retired before they become an incident path.
That makes the graph more than documentation. It becomes a control surface for access governance, third-party risk, and incident response, especially when organisations need to trace exposure quickly after a partner compromise or token theft.
NHIMG’s Ultimate Guide to NHIs, key challenges and risks is relevant where third-party access is carried by service accounts, tokens, or other machine-facing credentials.
Risk and Threat Considerations
Third-party access graphs are security-relevant because the compromise of one outside relationship can create reach far beyond the original entry point. A vendor account, integration token, or support channel may give an attacker a legitimate-looking way to move into sensitive systems, especially when access has accumulated over time.
Failure mechanism: Overprivileged, reused, or poorly retired third-party access creates an attack path that blends into normal business connectivity, making compromise, lateral movement, and data access easier to sustain.
Impact: The result can be credential theft, unauthorized access, data exfiltration, operational disruption, or a broader supply-chain incident if the third party is a trusted gateway into multiple environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Third-party access graphs depend on knowing which external accounts exist and remain active. |
| Recommendation — Inventory and review external accounts so unused third-party access is removed quickly. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The graph maps third-party accounts, owners, and lifecycle states that AC-2 requires to be controlled. |
| IA-5 — Authenticator Management | Third-party access commonly relies on tokens, keys, and other authenticators that must be governed across their lifecycle. | |
| Recommendation — Maintain third-party account records and disable access when the business need ends. Rotate and revoke third-party authenticators on a defined schedule and after compromise. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Third-party access graphs directly support supplier relationship security oversight and ownership. |
| A.5.18 — Access rights | The graph is a practical way to track and review external access rights over time. | |
| Recommendation — Document supplier access paths and review them as part of supplier security governance. Review third-party access rights regularly and remove anything no longer justified. | ||
Practitioner Guidance
What to watch for: The most important signal is not the existence of a third party, but whether its access path is still needed and still bounded. If the graph cannot explain why an external party has the level of reach it has, the organisation likely has an ownership or governance gap.
Governance implication: Treat the graph as a living access record, not a procurement artefact. It should reflect sponsorship, business justification, privilege level, and termination state so reviews can focus on exposure rather than names alone.
Practitioner takeaway: If the graph cannot show who can reach production, reset access, or consume sensitive data on behalf of the organisation, it is incomplete for security purposes.