# Third-Party and Contractor Access Policy Template

Source: https://startwithidentity.com/templates/third-party-contractor-access-policy/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

A third-party access policy covers everyone and everything outside your workforce that can reach your systems: contractors, partner staff, outsourced IT and help desk providers, vendor support engineers and the integrations (OAuth apps, API keys, service accounts) that suppliers connect to your tenant. Its core rules are that every third-party identity has an internal sponsor, an end date, strong authentication and the least access needed, and that third-party integrations are approved, scoped and revocable. Many recent identity breaches started at a supplier, so this policy matters as much as the one for your own staff.

## How to use this template

1. List your third parties by access type in section 2. Include IT outsourcers and SaaS integrations, not only contractors with laptops.
2. Fill the `[bracketed fields]`. Values in brackets are suggested starting points.
3. Put the contractual clauses in section 8 into your supplier agreements and security schedule.
4. Adopt the policy under your [IAM policy](https://startwithidentity.com/templates/identity-and-access-management-policy/), section 4.8.

**Owner:** `[ ]` | **Approved:** `[date]` | **Review:** every `[12]` months

## 1. Why this policy exists

The [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/) defines a [fan-out breach](https://startwithidentity.com/glossary/fan-out-breach/) as one where a single compromised identity at a provider is used against many customer organizations. In its database, 19 of 123 incidents are fan-out breaches, and 14 of those 19 abused a non-human identity. Examples relevant to this policy:

- **Integration tokens.** In the [Salesloft Drift incident](https://startwithidentity.com/breaches/incidents/2025-salesloft-drift-oauth-token-theft/), compromised OAuth tokens for a third-party app were used to query and export data from numerous corporate Salesforce instances. In the [Gainsight case](https://startwithidentity.com/breaches/incidents/2025-gainsight-salesforce-token-abuse/), Salesforce revoked all access and refresh tokens for Gainsight-published apps.
- **Outsourced support.** [Okta via Sitel](https://startwithidentity.com/breaches/incidents/2022-okta-sitel-lapsus/) began with remote access to a subprocessor support engineer's workstation. [Caesars](https://startwithidentity.com/breaches/incidents/2023-caesars-it-vendor-social-engineering/) disclosed that social engineering of an outsourced IT support vendor gave an attacker network access.
- **Impersonating a third-party user.** [Marks & Spencer](https://startwithidentity.com/breaches/incidents/2025-marks-and-spencer-third-party-impersonation/) said attackers got in through an impersonation of one of its third-party users.

The difference matters: in a fan-out breach the provider has to rotate and revoke its credentials, while each customer limits the damage with time-bound, least-privilege access and network restrictions on connected apps. This policy is the customer side.

## 2. Scope: third-party access types

| Type | Examples | Sections |
|------|----------|----------|
| Contractors and temporary staff | Individual contractors, agency staff | 3, 4, 6, 7 |
| Partner and supplier staff | Implementation partners, managed service providers | 3, 4, 6, 7 |
| Outsourced IT and help desk | Service desk, NOC, MSSP | 3, 4, 5, 6 |
| Vendor support access | Vendor engineers accessing your tenant or systems to troubleshoot | 5 |
| Integrations | OAuth apps, API keys, service accounts used by suppliers' software | 6 |
| Guests | B2B guest accounts in collaboration tools | 3, 4, 7 |

## 3. Sponsorship and identity

1. Every third-party person must have a named sponsor who is an [ORGANIZATION] employee. The sponsor requests access, confirms continued need, and is notified of expiry.
2. Every third-party person must have an individual account. Shared accounts for supplier teams are not allowed. *(NIST AC-2)*
3. Third-party accounts must be visibly distinguishable (naming prefix, user type attribute, separate group) so policies and reviews can target them.
4. Accounts must be created with an end date no later than `[90 days]` from approval or the contract end, whichever is sooner. Extension requires sponsor reconfirmation. *(NIST AC-2(2))*
5. Identity must be verified before first access, at the same level as for employees in an equivalent role.
6. If the sponsor leaves, sponsored accounts are suspended until a new sponsor is assigned.

## 4. Authentication and access

1. Third parties must sign in through the corporate IdP or a federated partner IdP that meets our [MFA standard](https://startwithidentity.com/templates/mfa-authentication-standard/). If trusting a partner's MFA claims, record the partner and the decision.
2. Phishing-resistant MFA is required for third parties with privileged access or access to `[sensitive systems]`.
3. Access is limited to the systems and data named in the access request. Birthright employee groups must not be assigned to third parties.
4. Third-party access from unmanaged devices is limited to `[browser-only, no download / virtual desktop]`.
5. Third-party accounts are covered by conditional access policies that apply at least the same controls as for employees; see the [conditional access worksheet](https://startwithidentity.com/templates/conditional-access-policy-plan-worksheet/).

## 5. Outsourced IT, help desk and vendor support

1. Outsourced help desk staff must follow our identity verification procedure for password and MFA resets and must not reset MFA for privileged accounts. Those resets go to `[internal team]`.
2. Vendor support access to our systems is off by default. It is granted per case, just in time, for no more than `[8 hours]`, and recorded. *(NIST MA-4 Nonlocal Maintenance)*
3. Privileged third-party sessions follow the [privileged access policy](https://startwithidentity.com/templates/privileged-access-policy/): brokered, recorded, no standing access.
4. Remote access for third parties must not use shared VPN credentials. Use `[ZTNA / PAM remote access]`.

> Guidance: these rules target [help desk social engineering](https://startwithidentity.com/techniques/help-desk-social-engineering/), the technique in the Caesars and MGM incidents.

## 6. Integrations and OAuth apps

1. Connecting a third-party app to a corporate SaaS tenant requires approval from `[security]`. User consent to apps requesting `[high-risk scopes]` is disabled. *(guards against [OAuth consent phishing](https://startwithidentity.com/techniques/oauth-consent-phishing/))*
2. The approval records: the vendor, the scopes, the data reachable, the internal owner, and the token type and lifetime.
3. Where the platform supports it, restrict integration tokens to the vendor's published IP ranges and to the minimum scopes.
4. Integration credentials follow the [service account and NHI policy](https://startwithidentity.com/templates/service-account-non-human-identity-policy/).
5. When a vendor discloses an incident, revoke and reissue every token and key that vendor holds, review the integration's activity in audit logs, and keep the integration disabled until the vendor confirms the fix.
6. Review connected apps every `[quarter]` and remove those unused for `[90 days]`.

## 7. Reviews and offboarding

1. Sponsors must reconfirm each third-party account every `[90 days]`. Unconfirmed accounts are disabled.
2. Third-party access is included in [access reviews](https://startwithidentity.com/templates/access-review-checklist/) every `[quarter]`.
3. Suppliers must notify `[security contact]` within `[1 business day]` when a person with access leaves their company or no longer works on our account. *(NIST PS-7(d))*
4. At end date or engagement end, access is removed following the leaver steps in the [JML procedure](https://startwithidentity.com/templates/joiner-mover-leaver-procedure/), including sessions, tokens and devices.

## 8. Contract clauses to include

- [ ] Supplier staff use individual accounts and MFA; no credential sharing.
- [ ] Supplier notifies leavers and role changes within `[timeframe]`.
- [ ] Supplier notifies security incidents affecting our data or credentials within `[__ hours]` of discovery, and cooperates in revoking credentials.
- [ ] Supplier lists every credential, token or integration it holds for our environment, on request.
- [ ] Right to audit or receive independent assurance (SOC 2 Type II or ISO/IEC 27001 certificate).
- [ ] Subcontractors with access are approved in advance and bound by the same terms.

*(ISO 5.19 Information security in supplier relationships; 5.20 Addressing information security within supplier agreements; 5.22 Monitoring, review and change management of supplier services. NIST PS-7 External Personnel Security; SA-9 External System Services; SR-6 Supplier Assessments and Reviews)*

## Control mapping

| Section | ISO/IEC 27001:2022 Annex A | NIST SP 800-53 Rev. 5 |
|---------|----------------------------|-----------------------|
| 3 Sponsorship and identity | 5.16 Identity management | AC-2, AC-2(2) |
| 4 Authentication and access | 5.15 Access control; 8.5 Secure authentication | IA-8 Identification and Authentication (Non-organizational Users); AC-20 Use of External Systems |
| 5 Support access | 8.2 Privileged access rights | MA-4 Nonlocal Maintenance; AC-17 Remote Access |
| 6 Integrations | 5.19; 5.23 Information security for use of cloud services | SA-9 External System Services |
| 7 Reviews and offboarding | 5.18 Access rights | PS-7 External Personnel Security |
| 8 Contracts | 5.20; 5.22 | SR-6 Supplier Assessments and Reviews |

Control text: [NIST SP 800-53 Rev. 5 catalog](https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home); [ISO/IEC 27001:2022](https://www.iso.org/standard/27001).

## Related

- [Identity Breach Database](https://startwithidentity.com/breaches/incidents/)
- [Refresh token abuse](https://startwithidentity.com/techniques/refresh-token-abuse/)
- [Snowflake customer tenant campaign](https://startwithidentity.com/breaches/incidents/2024-snowflake-customer-tenant-campaign/) (a shared-platform campaign, not a fan-out breach: attackers logged into customer accounts with stolen credentials)
- [What is workforce identity](https://startwithidentity.com/guides/fundamentals/what-is-workforce-identity/)
- [Identity controls for NIS2](https://startwithidentity.com/guides/compliance/identity-controls-for-nis2/)