Organisations now give access to far more people and systems they do not employ than they used to. Contractors, consultants, outsourced help desks, managed service providers, suppliers, partners, auditors, B2B customers and their SaaS integrations all hold accounts, tokens or API keys in your environment. Third-party identities are harder to govern because the HR system does not know about them, their employer controls their lifecycle, and their access often outlives the contract. Many recent breaches ran through exactly this gap. This guide covers how to onboard, govern, monitor and offboard third-party identities, human and non-human, including AI agents and MCP integrations supplied by vendors, and what DORA, NIS2 and NIST expect. It is written for identity governance, third-party risk, procurement and security operations teams.
Key takeaways
- Every third-party identity needs an internal sponsor who requested it, knows why it exists and is accountable for it until it is removed.
- Time-limit by default. Set an end date on every external account, grant and token, and require re-approval to extend it.
- Federate, but keep control. Let partners use their own identity provider, while you decide which tenants to trust, what MFA to require, what they can reach and how fast you can cut them off.
- Third parties hold non-human identities too. OAuth grants, API keys, service accounts and integration tokens held by vendors were the route in the Salesloft Drift and Klue incidents.
- Put identity obligations in the contract and check them. MFA, leaver notification, incident reporting, credential protection, audit rights and exit plans; DORA makes several of these mandatory for financial entities.
Types of third-party access
| Type | Example | Main risk |
|---|---|---|
| Contractors and consultants | Staff working inside your systems | Access not removed when the engagement ends; unmanaged devices |
| Outsourced operations and MSPs | Help desk, IT operations, support centres, managed service providers | Broad privileges; social engineering; insider risk |
| Vendor remote support | Suppliers maintaining equipment or software | Permanent, unmonitored remote access |
| B2B customers and partners | Partner portals, shared workspaces, guest users | Guest sprawl; weak partner security |
| SaaS and integration providers | OAuth apps and API connections holding tokens | Token theft from the provider's environment |
| Suppliers holding your secrets | Consultancies and MSPs with keys and connection strings | Your credentials exposed in their breach |
| Vendor AI agents and MCP servers | Agents and tool servers acting on your data with delegated tokens | Over-broad scopes; a compromised third-party agent or server |
CISA and its partners describe the MSP case plainly: MSP services "usually require both trusted network connectivity and privileged access to and from customer systems", so a vulnerable MSP can become an initial access vector to many customers at once. See the Third-Party Risk Management (TPRM) Guide for the wider supplier risk process.
Lessons from incidents
- Marks and Spencer Cyberattack 2025: According to Trium Cyber's summary of its evidence to a House of Commons sub-committee, M&S said initial access on 17 April 2025 came through sophisticated social engineering and impersonation of an individual combined with a third-party vector. The summary also notes an attack surface of about 50,000 users and multiple contractors and third parties.
- Coinbase Insider Breach 2025: Coinbase said the data of nearly 70,000 customers was handed over by overseas support staff who were bribed by criminals, as reported by The Register.
- Salesloft Drift Breach 2025: Google's Threat Intelligence Group reported that the actor UNC6395 used compromised OAuth tokens for the Drift application to export data from Salesforce instances between 8 and 18 August 2025, then searched it for credentials. GTIG later advised customers to treat all tokens stored in or connected to Drift as compromised.
- Klue OAuth Breach 2026: Klue told TechCrunch the credential used "was originally provided to a third-party in 2022, for a limited pilot". Its investigation summary describes a compromised GitHub personal access token used to insert code into its integration service and collect customers' Salesforce OAuth access and refresh tokens.
- Red Hat Consulting GitLab Breach 2025: Red Hat confirmed unauthorised access to a GitLab instance used by its consulting team. The attackers claimed, as reported by BleepingComputer, that customer engagement reports held authentication tokens and database URIs; Red Hat did not verify those claims.
- Snowflake Breach 2024: Mandiant found that in several cases the infostealer infection occurred on contractor systems also used for gaming and pirated software, and that the affected accounts had no MFA and no network allow lists.
Onboarding third-party identities
- Sponsorship: an employee requests the access, states the purpose, scope and end date, and remains accountable. No sponsor, no account.
- Identity verification: confirm the individual's identity, especially for privileged or remote access, and repeat it when credentials are reset. See the Identity Proofing and KYC Guide.
- Named accounts, marked as external: no shared vendor accounts. NIST SP 800-53 IA-4(4) asks organisations to identify user status, such as contractors and non-organisational users, so external identities are visible in every report.
- Federation with conditions: B2B federation lets people use their own organisation's identity. In Microsoft Entra, B2B collaboration with other Entra organisations is enabled by default, so set cross-tenant inbound rules for named partner tenants and decide whether to trust their MFA and device claims. See the Federation and Trust Guide.
- Managed devices where it matters: the Snowflake findings show the risk of contractors using personal laptops shared across clients. Require managed or compliant devices, or a hardened virtual desktop, for privileged access.
- Least privilege: separate third-party roles with access to named applications, not the whole network. See the Remote Access Identity Guide.
| Option | Best for | Your controls | Watch out for |
|---|---|---|---|
| Federated B2B guest | Partners and suppliers with their own identity provider | Tenant allow list, MFA trust settings, access packages with expiry | Partner MFA quality; guests invited ad hoc by any user |
| Account in your directory | Contractors working like staff | Your MFA, devices, lifecycle and reviews | No HR feed; end dates missed |
| Brokered privileged session | Vendor support and MSP administration | Approval, recording, time limits, no credential disclosure | Standing VPN or remote tools that bypass the broker |
| Scoped integration credential | SaaS and API integrations | Scopes, IP restrictions, expiry, revocation | Tokens stored in the vendor's systems |
Governing access during the relationship
- Expiry on everything: set an end date on every third-party account and grant, with reminders to sponsors. Entra entitlement management, for example, lets a policy remove all access from an access package after a set period, such as 180 days, unless it is extended, and can then block and remove the external user.
- Reviews by sponsors: include third parties in access reviews; guests can be asked to re-attest or a sponsor decides. See the Access Reviews Guide.
- Leaver notification: NIST SP 800-53 PS-7 asks that external providers notify you of transfers or terminations of their staff who hold your credentials or privileges, within a time you define. Reconcile regularly against supplier staff lists.
- Brokered privileged sessions: broker and record privileged third-party sessions and grant them just in time. CISA advises customers to keep MSP accounts out of internal administrator groups and restrict them to the systems the MSP manages. See the Privileged Session Management Guide.
- No privilege for guests: SP 800-53 AC-6(6) prohibits privileged access by non-organisational users, a useful default for partners and B2B guests, as distinct from contractors treated as staff.
- Help desk parity: apply the same verification to third-party users as to employees, and extra scrutiny to outsourced help desks with reset powers. See the Account Recovery and Help Desk Security Guide.
Detection and monitoring
NIST CSF 2.0 DE.CM-06 expects that "External service provider activities and services are monitored to find potentially adverse events". CISA recommends storing the most important logs for at least six months, because "It can be months before incidents are detected", and contracts that give customers visibility of the provider's presence, activities and connections. MITRE ATT&CK tracks this abuse as T1199; see the T1199 Trusted Relationship Guide for detection.
| Signal | Source | What it may indicate |
|---|---|---|
| Sign-in from a new country, network or unmanaged device | IdP and VPN logs | Stolen contractor credentials |
| Bulk export or unusual query volume by a vendor account or integration | SaaS audit logs, data access logs | Data theft through a trusted connection, as with Drift |
| Activity outside the agreed support window | Session broker, remote access logs | Misuse or compromised vendor access |
| Use of an account after its end date or a contract ends | Inventory joined to authentication logs | Missed offboarding |
| New OAuth consent or scope change for a third-party app | IdP and SaaS admin audit logs | Over-privileged or malicious integration |
| Password or MFA reset requests for third-party users | Help desk tickets, IdP logs | Social engineering of support staff |
Insiders at suppliers are part of the threat model, as Coinbase shows. See the Insider Threat and Identity Guide.
Third-party non-human identities
OWASP lists NHI3 Vulnerable Third-Party NHI: if a third-party extension or SaaS is compromised, attackers can "steal these credentials or misuse the granted permissions." Govern them as identities, not as configuration:
- Inventory: OAuth apps, API keys, service accounts and webhooks that belong to or are used by third parties, each with an internal owner. See the SaaS and OAuth App Governance Guide.
- Scope and restrict: limit scopes, review consent regularly, and prefer integrations that use short-lived tokens and IP restrictions.
- Plan revocation: know how to revoke every grant for one vendor within hours. In the Drift case, Salesloft and Salesforce revoked all active access and refresh tokens for the application on 20 August 2025.
- Do not hand over long-lived secrets: never send suppliers credentials in documents, reports or email; provision scoped, expiring access instead. See the Secrets Management Guide.
- Close pilots: credentials issued for a trial or pilot get the same end date as the trial. Klue's 2022 pilot credential is the cautionary case.
Vendor AI agents and MCP integrations
Vendors increasingly connect AI agents and MCP servers to your data. OWASP's Top 10 for Agentic Applications (2026) lists ASI04 Agentic Supply Chain Vulnerabilities, including a "Vulnerable Third-Party Agent" invited into multi-agent workflows and a compromised MCP or registry server serving malicious manifests or descriptors. Treat each vendor agent or MCP server as a third-party NHI: an owner, a contract, the narrowest scopes, short-lived tokens and the same revocation plan. See the Third-Party AI Risk Guide and the MCP Security Guide.
Offboarding
- Automatic end dates: disable accounts at the end date unless the sponsor extends them.
- Revoke everything together: on contract termination, revoke accounts, federation trust, OAuth grants, API keys, VPN profiles and remote support tools in one change. CISA notes that disabling MSP accounts "can be overlooked when a contract terminates."
- Rotate what they knew: rotate shared or privileged credentials the third party knew or could have copied.
- Confirm deletion: obtain confirmation that the supplier has deleted your credentials and data, and that data has been returned where the contract requires it.
- Plan the exit in advance: NIST CSF 2.0 GV.SC-10 expects supply chain plans to cover "activities that occur after the conclusion of a partnership or service agreement", and DORA Article 28 requires exit strategies for services supporting critical or important functions. See the Joiner-Mover-Leaver Guide.
Contract and assurance
- Identity requirements: MFA for supplier staff accessing your systems and for their own systems holding your credentials; CISA's first tactical actions include enforcing MFA on MSP accounts that access the customer environment.
- Notification: set times for leaver and security incident notification, and include suppliers in incident planning (CSF GV.SC-08).
- Clear roles: contracts should "transparently identify ownership of ICT security roles and responsibilities", in CISA's words.
- Assurance: include rights to audit or receive evidence, and ask identity-specific questions in supplier assessments. See the Vendor Security Assessment Template.
For EU financial entities, DORA Article 30 lists minimum contract terms for ICT services, and NIS2 Article 21 makes supply chain security part of required risk-management measures.
| DORA Article 30 element | Identity angle |
|---|---|
| Provisions on availability, authenticity, integrity and confidentiality of data (30(2)(c)) | MFA, credential protection, least privilege for provider staff |
| Assistance when an ICT incident related to the service occurs (30(2)(f)) | Rapid token revocation and log sharing |
| Termination rights and notice periods (30(2)(h)) | Access removal tied to termination |
| Participation in security awareness and resilience training (30(2)(i)) | Phishing and help desk social engineering training for supplier staff |
| Unrestricted rights of access, inspection and audit, for critical or important functions (30(3)(e)) | Evidence of identity controls on request |
| Exit strategies with a transition period (30(3)(f)) | Planned handover and revocation of credentials |
See the DORA Guide, the NIS2 Directive Guide and the Identity Security Regulatory Map.
Common failure patterns
- The shared vendor account: one login for a supplier's whole team, so no action is attributable and leavers keep access.
- No end date: contractor accounts that survive the engagement because nothing in HR triggers removal.
- Pilot credentials that never expire: access issued for a trial and forgotten, as in the Klue case.
- Tokens trusted forever: OAuth integrations with broad scopes, no review and no revocation plan, the pattern behind Drift.
- Unmanaged contractor devices: one infected laptop with access to several clients, as Mandiant saw in the Snowflake investigations.
- Outsourced help desks without verification: reset powers given to staff who can be impersonated or bribed.
- Offboarding the person, not the access: accounts disabled while API keys, federation trust and remote tools stay live.
Framework mapping
This is an indicative NHI Mgmt Group alignment. IDs were checked against the NIST CSF 2.0 text, the SP 800-53 Rev. 5 catalogue, the ISO/IEC 27001:2022 Annex A control list and the CIS Controls assessment specification (safeguard numbers unchanged in v8.1).
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A | CIS Controls v8.1 | OWASP |
|---|---|---|---|---|---|
| Supplier inventory and criticality | GV.SC-04, ID.AM-04 | SA-9, SR-6 | A.5.19 | 15.1, 15.3 | NHI3 |
| Due diligence and contracts | GV.SC-05, GV.SC-06 | SA-9, SR-6, PS-7 | A.5.20, A.5.21 | 15.2, 15.4, 15.5 | NHI3 |
| Sponsored, verified, named accounts | PR.AA-01, PR.AA-02 | AC-2, IA-4(4) | A.5.16 | 6.1 | None |
| Authentication and federation | PR.AA-03, PR.AA-04 | IA-2, IA-5 | A.5.17, A.8.5 | 6.3, 6.4 | NHI4 |
| Least privilege and remote access | PR.AA-05 | AC-6(6), AC-17, AC-20 | A.5.15, A.8.2 | 6.5, 6.8 | NHI5 |
| Monitoring providers | DE.CM-06, GV.SC-07 | SA-9, SI-4, AU-6 | A.5.22 | 15.6, 8.11 | None |
| Incident coordination | GV.SC-08 | IR-4(10), SR-8 | A.5.24 | 17.2 | None |
| Offboarding and exit | GV.SC-10 | PS-7, AC-2(3) | A.5.18, A.5.20 | 6.2, 15.7 | NHI1 |
| Third-party NHIs and agents | GV.SC-07, PR.AA-01 | IA-9, AC-6 | A.5.19, A.5.21 | 5.5 | NHI3, ASI04 |
Metrics that show progress
| Metric | What it shows | Target direction |
|---|---|---|
| Third-party accounts with a current sponsor and end date | Basic accountability | Up, towards 100% |
| Accounts active after their end date or contract end | Offboarding gaps | Down to zero |
| Median days from supplier leaver to access removal | Leaver notification working | Down |
| Third-party privileged sessions brokered and recorded | Control over the riskiest access | Up, towards 100% |
| Third-party OAuth apps and keys with an owner and recent review | NHI governance coverage | Up |
| Guests and external users reviewed in the last cycle | Review coverage | Up |
| Time to revoke all access for one vendor (tested) | Readiness for a supplier incident | Down, measured in hours |
Implementation roadmap
| Phase | Actions | Exit criteria |
|---|---|---|
| First 30 days | Inventory external accounts, guests, vendor remote tools, OAuth apps and API keys; find accounts with no sponsor or end date; disable unused MSP and vendor accounts | One list of third-party identities, human and non-human, with sponsors named for privileged access |
| Days 31 to 90 | Require sponsorship and end dates for new access; restrict partner tenants and set MFA trust; broker privileged vendor sessions; add third parties to access reviews | No new external access without sponsor and expiry; privileged vendor access brokered |
| Days 91 to 180 | Add identity clauses to contract templates; agree leaver notification times; rehearse revoking one vendor end to end; extend governance to vendor AI agents and MCP servers | Revocation drill passed; contracts and assessments include identity requirements; metrics reported |
Practitioner checklist
- Inventory all third-party human and non-human identities, each with an internal sponsor or owner.
- Require sponsorship, named accounts and verified identity for every third-party user.
- Restrict which partner tenants can federate and decide which MFA and device claims to trust.
- Set end dates by default and include third parties in access reviews.
- Broker, record and time-limit third-party privileged and remote sessions.
- Monitor third-party activity and keep key logs for at least six months.
- Govern third-party OAuth apps, API keys, service accounts, AI agents and MCP servers, with a tested revocation plan.
- Automate offboarding at contract end, revoke all access together and rotate shared credentials.
- Put identity obligations, notification times, audit rights and exit plans in supplier contracts and check them.
Standards and references
- NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
- NIST: The NIST Cybersecurity Framework (CSF) 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- EIOPA: Digital Operational Resilience Act (DORA)
- DORA text: Article 28, General principles (ICT third-party risk)
- DORA text: Article 30, Key contractual provisions
- NIS2 text: Article 21, Cybersecurity risk-management measures
- CISA: Protecting Against Cyber Threats to Managed Service Providers and their Customers
- OWASP: Non-Human Identities Top 10 2025
- CIS: Control 15, Service Provider Management
- Microsoft: Cross-tenant access overview
- Microsoft: Govern access for external users in entitlement management
Related NHI Mgmt Group resources: SaaS and OAuth App Governance Guide · Third-Party Risk Management (TPRM) Guide · Joiner-Mover-Leaver Guide · Access Reviews Guide · Remote Access Identity Guide