Third Party Access Review: Vendor Accounts and Tokens

Third-party access survives longest because nobody inside the organisation feels responsible for removing it. Vendor engineers leave their employer without you hearing about it, pilot integrations are abandoned with their tokens still live, and remote support tools stay installed long after the contract that justified them. This guide covers the vendor-specific variant of an access review: how to recertify the accounts third parties use, the tokens and keys they hold for your systems, and the remote access paths and sessions they use. It is written for identity governance, third-party risk and infrastructure teams who already run access reviews. For campaign design, reviewer fatigue and evidence in general, read the Access Reviews Guide; this page covers only what changes when the access holder is outside your organisation.

Key takeaways

Review three populations, not one. Vendor user accounts, credentials held by vendors (API keys, tokens, OAuth grants, cross-account roles) and remote access paths each live in different systems and need their own data pull.
Start from the contract, not the directory. Every item must trace to an active agreement and a named internal sponsor; anything that cannot is revoked, whatever the reviewer thinks.
The vendor's word is an input, not evidence. Ask the supplier to confirm its staff list, but decide on your own evidence: last sign-in, last token use, session logs.
Tokens are reviewed by use, not by name. A token issued for a pilot and unused for months is the classic forgotten credential; review last-use dates and scopes, and revoke on inactivity.
Triggers beat calendars. Contract end, a sponsor leaving, a vendor security incident and dormancy should each start a targeted review immediately, between the scheduled campaigns.

What makes a third-party review different

A standard user access review asks a manager whether their report still needs an entitlement. For third parties, that question has no natural owner: the vendor's manager cannot see your systems, and your staff cannot see the vendor's HR records. Three further differences shape the method:

No leaver feed: employee access is cut when HR records a leaver. Vendor staff changes reach you, at best, through a contractual notice, so a review is often the only control that catches them.
Credentials outside your perimeter: keys and tokens you issued to a supplier sit in the supplier's systems, where you cannot see how they are stored. ATT&CK tracks abuse of this route as T1199 Trusted Relationship.
Access hidden in tools: remote support and remote monitoring and management (RMM) agents, VPN profiles and jump hosts grant access that never appears as an entitlement in the identity platform. ATT&CK tracks these paths as T1133 External Remote Services.

The Third-Party Access Guide covers onboarding and governance of third-party identities overall; the review described here is its recurring check.

The three populations to recertify

Population	Examples	Where to find it	Who decides	Key evidence
Vendor user accounts	B2B guests, contractor accounts in the directory, local accounts in vendor-run or partner-hosted applications, named accounts in a vendor PAM broker	Identity provider, application user lists, PAM system, partner portals	Internal sponsor, with application owner for privileged roles	Last sign-in, MFA status, roles held, contract end date
Credentials held by vendors	API keys and personal access tokens issued to a supplier, OAuth grants to vendor apps, service accounts a vendor operates, cross-account cloud roles, SSH keys	Secrets manager, credential register, OAuth consent and app inventories, cloud IAM trust policies, code platform token lists	System or data owner, with the sponsor confirming the business need	Last use, scopes or permissions, creation date, expiry, who at the vendor holds it
Remote access paths and sessions	Site-to-site and client VPN profiles, jump hosts, VPAM broker entries, remote support and RMM agents, firewall rules for vendor IP ranges	Network and VPN configuration, PAM and session recording logs, endpoint software inventory, firewall rule base	Infrastructure owner	Sessions in the period, recordings sampled, approval tickets, installed agents

The credentials population is the one most often missed, because it rarely appears in an identity governance tool. Keep it in one place: the Third-Party Credential Register Template gives the fields to record for keys you issued to suppliers, and becomes the review population.

Building a complete review population

The quality of the review depends on the list. Build it from the systems, then reconcile it against the supplier register, never the other way round.

Pull every source: export external and guest identities from the identity provider, user lists from in-scope applications (including partner-hosted ones), PAM and VPN accounts, token and OAuth app inventories, cloud role trust policies and the endpoint inventory for remote access software.
Tag each item with a supplier: by email domain, account naming convention, trust policy principal or app publisher. Items you cannot attribute go to a separate "unknown owner" list, which is reviewed first.
Join with the supplier register: add contract status, end date, tier and sponsor. Any item tied to an expired contract or a supplier not in the register is a revocation candidate before the campaign starts.
Add usage evidence: last interactive sign-in for accounts, last API call or token use for credentials, last session for remote access paths. Mark anything beyond your dormancy threshold (90 days is a common choice) for default removal.
Ask the supplier to attest: send each tier one supplier the list of its named users and credentials and ask it to confirm who still works on your account and who holds each credential. Differences between its answer and your evidence are findings in their own right.

What reviewers decide, item by item

Item	Question for the reviewer	Revoke or change when
Vendor user account	Is this person still assigned to our contract and does the work still need this role?	Contract ended, person not confirmed by supplier, no sign-in beyond the dormancy threshold, shared login used by several people
Privileged vendor account	Can this access move to just-in-time, brokered sessions instead of standing rights?	Standing admin rights used only occasionally; see the Vendor Privileged Access Management (VPAM) Guide
API key or personal access token issued to a vendor	Which integration uses it, is it still running, and are the scopes the minimum?	No use in the period, pilot or project closed, write scope where read would do, no expiry date
OAuth grant to a vendor app	Is the app still used, by whom, and are its scopes and data objects proportionate?	No internal owner, broad scopes such as full mailbox or full CRM access with no recent business use
Cross-account cloud role	Is the trusted account the right supplier, does the trust require an external ID, and is the permission policy still right?	Trusted account unknown, external ID condition missing, permissions broader than the service needs
Remote access path or agent	Is there an approved, current reason for this route, and do session records show only expected use?	No sessions in the period, agent not on the approved tool list, sessions outside approved windows

Two rules keep these decisions honest. First, the default for an item with no owner and no use is removal, not "keep pending clarification". Second, a vendor's attestation can justify removal on its own but cannot justify keeping access that your own evidence shows is unused.

Reviewing remote access sessions

Paths are recertified like entitlements, but sessions need a sampled look at what actually happened. For each in-scope supplier, sample recorded sessions from privileged brokers and remote support platforms and check them against approval tickets: right person, right system, right time window, and actions consistent with the stated work. Review the endpoint inventory at the same time. CISA, NSA and MS-ISAC advisory AA23-025A advises defenders to audit remote access tools on the network to identify which RMM software is in use and authorised, to review logs for RMM software running as portable executables, and to use application control so only approved RMM programs can run. Any remote access agent not tied to a current contract and an approved tool list is removed at review. For session controls themselves, see Remote Support Sessions.

Platform examples

Platforms are listed alphabetically. Each offers native ways to see and act on third-party access; the review uses them as data sources and as the place where removals are carried out.

Amazon Web Services: AWS documents granting third parties access through an IAM role that names the supplier's AWS account as principal and requires an sts:ExternalId condition in the trust policy, rather than an IAM user with long-term keys. The external ID is not a secret; it prevents the confused deputy problem. At review, list roles trusted by external accounts (IAM Access Analyzer reports principals outside your zone of trust), confirm each account maps to a current supplier, and check the permission policy.
GitHub: organisation owners can view every fine-grained personal access token that can access organisation resources, filter by owner, repository or permission, and revoke tokens individually or in bulk. Revoking a token leaves SSH keys created with it working, so remove those separately. Classic personal access tokens are governed by the organisation's token policy; set that policy so classic tokens cannot reach organisation resources, which brings every token into the reviewable view.
Microsoft Entra ID: access reviews can ask guests to confirm their own continued need, or send the decision to a sponsor or owner, and can run as recurring reviews of guests across all Microsoft 365 groups. For selected teams and groups, a review can block a denied guest from signing in and delete the B2B account after 30 days, and can also remove guests who did not respond. See the Entra ID Cross-Tenant Access and B2B Guest Governance Guide.

Availability: Microsoft documents Entra ID P2 or Microsoft Entra ID Governance as the prerequisite for access reviews. AWS and GitHub document no separate licence requirement for the features described here; confirm against your own plan.

Cadence and triggers

Trigger	Scope of the review	Target time to complete
Scheduled campaign, tier one suppliers	All three populations	Quarterly
Scheduled campaign, other suppliers	All three populations	Six-monthly or annual, by tier
Contract end or non-renewal	Everything attributed to the supplier	On the end date; see the Vendor Offboarding and Termination Guide
Supplier reports a security incident	All credentials held by the supplier, plus its accounts' recent activity	Same day; rotate first, review after
Internal sponsor leaves or moves	Items sponsored by that person	Within the leaver process
Dormancy threshold reached	The dormant item	Automatic disable, then owner decision

The cadences are NHI Mgmt Group recommendations; set yours by supplier tier and by the obligations that apply to you. Smaller organisations with a handful of suppliers can run one combined review per quarter in a spreadsheet built from the steps above. Larger organisations should load vendor accounts and the credential register into their identity governance platform so third-party items follow the same workflow and evidence trail as internal reviews.

Rolling it out

Pilot with three to five tier one suppliers: build the population for each, run the review manually and record how many items had no owner, no use or no contract.
Fix the sources: enforce a sponsor and end date on every new guest and vendor account, and require every credential issued to a supplier to be entered in the register with an expiry.
Automate dormancy: disable vendor accounts and flag tokens beyond the dormancy threshold before the campaign, so reviewers see only live access.
Extend to all tiers: load the populations into the governance platform, add supplier attestation requests, and wire contract end dates to automatic revocation tasks.
Close the loop: verify each removal in the target system (account disabled, token revoked, agent uninstalled, firewall rule deleted) rather than accepting the ticket closure.

To limit disruption, disable rather than delete in the first cycle and keep a record of what was removed, so a wrongly revoked integration can be restored quickly with a new, scoped credential instead of the old one.

Detection and measurement

Between reviews, monitor for third-party access that should not exist: sign-ins by vendor accounts after their contract end date, use of a token after the supplier said it was retired, new OAuth grants to unknown publishers, new trust relationships in cloud roles, and remote access software appearing on endpoints outside the approved list. These alerts also feed the next review's population.

Metric	What it shows
Third-party items revoked per campaign, by population	Whether the review removes access or only signs it off
Items with no supplier attribution or sponsor at campaign start	Quality of onboarding controls; should fall each cycle
Vendor-held credentials without an expiry date	Exposure to forgotten tokens
Days from contract end to verified removal of all access	Offboarding effectiveness
Discrepancies between supplier attestation and your evidence	How far supplier notifications can be relied on

For a ready-made metric set with thresholds, use the Third-Party Access Health Check.

Framework mapping

Framework	Reference	Relevance
NIST CSF 2.0	PR.AA-05	Access permissions are managed, enforced and reviewed with least privilege
NIST CSF 2.0	GV.SC-07; GV.SC-10	Supplier risk assessed and monitored over the relationship; activities after the partnership ends
NIST SP 800-53 Rev. 5	AC-2 Account Management; AC-2(3) Disable Accounts; AC-6(7) Review of User Privileges	Recertifying accounts and privileges, disabling inactive ones
NIST SP 800-53 Rev. 5	PS-7 External Personnel Security; SA-9 External System Services	Requirements on external personnel and provider services, including notice of staff changes
NIST SP 800-53 Rev. 5	AC-17 Remote Access; MA-4 Nonlocal Maintenance	Authorising and monitoring remote and vendor maintenance sessions
MITRE ATT&CK	T1199 Trusted Relationship; T1133 External Remote Services; T1528 Steal Application Access Token	The attack routes that unreviewed third-party access leaves open
OWASP Non-Human Identities Top 10 2025	NHI3 Vulnerable Third-Party NHI	Inventory third-party integrations, scope tokens, revoke unused ones; see OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide

Common failure patterns

Reviewing only directory guests: the campaign covers B2B guests in the identity provider but not local accounts in partner-hosted applications. In the Scania Insurance Portal Breach, an external user's credentials, probably stolen by infostealer malware, were used to download claim documents from an application run by an IT partner.
Pilot tokens never expired: a credential issued for a short trial stays live for years because no review covers tokens. In the Klue OAuth Breach, a GitHub personal access token provided for a 2022 pilot was never revoked and was later used to inject code that harvested customers' Salesforce OAuth tokens.
Trusting the supplier's list: accepting the vendor's confirmation of current staff without checking sign-in and token use, so shared or orphaned logins survive.
Approving by contract, not by use: keeping all access while a contract is active, even when an account or token has not been used in months.
Remote tools outside scope: recertifying VPN accounts while RMM agents and remote support clients installed for past projects remain on servers.
Revocations not verified: tickets closed without confirming the token was revoked or the agent removed in the target system.

Practitioner checklist

Build the review population from systems for all three populations, then reconcile it against the supplier register.
Revoke anything with no current contract, no sponsor or no supplier attribution before the campaign starts.
Record every credential issued to a supplier in a credential register with owner, scope and expiry.
Include accounts in partner-hosted and vendor-run applications, not just directory guests.
Use last-use evidence for tokens, OAuth grants and cloud roles, and disable on dormancy.
Sample recorded vendor sessions against approval tickets each campaign.
Remove remote access agents and firewall rules not tied to a current contract and approved tool list.
Trigger targeted reviews on contract end, sponsor departure and supplier security incidents.
Verify each removal in the target system and keep that evidence.

Third Party Access Review Guide: Recertifying Vendor Accounts, Tokens and Remote Sessions