Third-Party Access Policy Template: Onboarding, Least Privilege and Revocation

Third parties often hold some of the most powerful access in an organisation, through contractor accounts, MSP admin roles and vendor integrations, yet it is the access least likely to have a named internal owner or an end date. This template gives you a third-party access policy with numbered statements for sponsoring, onboarding, scoping, monitoring and revoking access held by contractors, suppliers, managed service providers (MSPs), support vendors and SaaS or API integrations, including the non-human credentials they hold on your behalf. It assumes you already have an internal access control policy and adds the requirements that are specific to people and systems you do not employ or operate; the internal rules are in the companion Access Control Policy Template. Supplier due diligence sits in your third-party risk process. Detailed controls per access type are in the Third-Party Access Guide.

How to use this template

• Replace text in square brackets, such as [Organisation], [Vendor management office] and [X days], with your own terms and values. Bracketed values are illustrative.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a justified exception may apply.
• Agree the policy with procurement and legal first: section 4.6 only works if written into contracts.
• Count integrations as third-party access: OAuth grants, supplier API keys and vendor-run agents, even when no supplier person signs in.

1. Purpose

This policy ensures that every third-party identity and credential with access to [Organisation] systems and data is sponsored by an accountable employee, limited to the access and period the contract requires, subject to [Organisation]'s authentication and monitoring, and revoked completely when the need or relationship ends.

2. Scope

This policy applies to all access to [Organisation] systems, applications, cloud tenants, networks and data held by or on behalf of a third party, including:

• Contractors and consultants who are not [Organisation] employees.
• MSPs and outsourcers: IT support, help desk, security operations and cloud management, including delegated administration.
• Vendor support access: remote support sessions and maintenance accounts.
• Guest and partner accounts, including federated partner access.
• Third-party non-human access: OAuth applications and connected apps, API keys and tokens issued to suppliers, webhooks, vendor-operated service accounts, agents and connectors installed by vendors, and AI services acting on [Organisation] data.

3. Roles and responsibilities

4. Policy statements

4.1 Sponsorship and pre-requisites

1. Third-party access must not be granted until the supplier has completed [third-party risk assessment] at the tier matching the access requested, and a contract or written agreement containing the terms in 4.6 is in force.
2. Every third-party identity, guest account and integration must have a named internal sponsor and be recorded in [third-party access register] with the supplier, contract reference, systems, permissions, credential type and end date.
3. Each request must state purpose, systems, access level and start and end dates. Open-ended access is not permitted.
4. If the sponsor leaves, sponsorship must transfer within [5] business days or access is suspended.

4.2 Identity and authentication

1. Each third-party person must have their own named account. Accounts shared between supplier staff, and generic vendor accounts, are prohibited unless approved under section 5 with session recording and per-use check-out.
2. Third-party accounts must be identifiable as external (for example an [ext-] prefix) and placed in [external identities group].
3. Third-party users must authenticate with MFA enforced by [Organisation]. Privileged third-party access must use phishing-resistant MFA. Where federation or cross-tenant trust accepts MFA performed in the third party's own tenant, the trust must be configured explicitly per partner, not by default, and approved by [IAM team].
4. Password and MFA resets for third-party users must follow the [identity verification procedure], including call-back to a number held in the third-party access register or sponsor confirmation. A request arriving through the supplier's own help desk or email is not sufficient verification on its own.
5. Access should be from devices meeting [device compliance standard]; otherwise [Restricted] data must be reached only through [virtual desktop].

4.3 Least privilege and time-bound access

1. Third-party access must be limited to what the request names, without standing administrative or global roles unless [CISO] approves.
2. Every third-party account and grant must expire by the contract end date and within [6 / 12] months, renewable after sponsor attestation.
3. Privileged third-party access must be granted just in time for a defined task or change window, brokered through [privileged access management platform], and session-recorded on [critical systems].
4. Remote support sessions must be approved by [Organisation] per session; always-on vendor remote tools need approval under section 5.
5. MSP and partner delegated administration must use granular, time-bound roles. For Microsoft Partner Center this means granular delegated admin privileges (GDAP) with the least-privileged Microsoft Entra roles, no Global Administrator unless time-bound for a specific task, and no legacy delegated admin privileges (DAP). See the GDAP and MSP Delegated Admin Access Guide.

4.4 Third-party integrations and non-human credentials

1. Third-party OAuth and connected apps must be approved by [IAM team] before admin consent; users must not consent to [high-risk scopes].
2. Each integration must use its own credential with the minimum scopes required. Integrations must not run under a named employee's account or an administrator's personal token.
3. API keys, client secrets and tokens issued to a third party must have an expiry of no more than [90 / 365] days, must be restricted by source IP or workload identity where the platform supports it, and must be registered in [third-party access register].
4. [Organisation] credentials must never be sent through email, tickets, chat or support cases, and must be rotatable by [Organisation] without the supplier.
5. Vendor-installed agents, connectors and service accounts must run with least privilege and be included in the [NHI inventory].
6. [Organisation] must be able to revoke all tokens and credentials held by any single integration within [1 hour], and must test this for [critical] integrations at least [annually].

4.5 Monitoring and review

1. Third-party sign-ins, privileged activity, integration API calls and exports must be logged for [12] months.
2. [Security operations] must alert on: third-party access outside approved hours or windows, sign-in from a new country or device following an MFA or password reset, bulk export by an integration, use of a third-party account after its expiry or contract end,.
3. Sponsors must review third-party identities and integrations at least [quarterly] for privileged access and [every six months] for all other access. Access not confirmed must be removed within [14] days.

4.6 Contract requirements

1. Contracts for suppliers holding access must require the third party to: comply with this policy; notify [Organisation] within [1 business day] when a person with [Organisation] access leaves or changes role; notify [Organisation] of a suspected security incident affecting [Organisation] access or data within [24 hours]; obtain approval before subcontracting work that requires access; and flow these requirements down to approved subcontractors.
2. Contracts must give [Organisation] the right to suspend access immediately and to receive activity logs and evidence of credential controls.
3. Contracts must specify the return and deletion of [Organisation] information, credentials and assets at the end of the contract, with written confirmation.

4.7 Revocation and offboarding

1. Access for a third-party person must be disabled within [4 hours] of [Organisation] being notified that they have left the engagement, and immediately where misconduct or compromise is suspected.
2. When a contract ends, [Vendor management office] must notify [IAM team] at least [10] business days before the end date, and all access must be removed by the end date. Removal must cover accounts, guest objects, roles, delegated admin relationships, OAuth grants, API keys, certificates, VPN profiles and vendor agents, and shared credentials the supplier knew must be rotated.
3. If a third party is compromised, [Security operations] must suspend its access and rotate any [Organisation] credential it held.

5. Exceptions

Where a requirement cannot be met (for example a vendor product needing a shared maintenance account), the sponsor must request an exception through [exception process] stating the requirement, the reason, the risk, compensating controls (such as session recording, check-out with rotation after each use, network restriction) and an expiry date no later than the contract end or [12] months. Exceptions are approved by [CISO] for privileged access and by [Security team] otherwise, recorded in [exception register] and reviewed before expiry. See the Security Exceptions and Risk Acceptance Guide.

6. Compliance and monitoring

• Register reconciliation: [IAM team] reconciles the third-party access register against directory guest and external accounts, delegated admin relationships and OAuth grants at least [monthly].
• Metrics reported [quarterly] to [Risk committee]: percentage of third-party identities and integrations with a sponsor and end date; accounts active after contract end; median time from supplier leaver notice to disablement; standing privileged roles held by third parties; percentage of privileged sessions recorded.
• Assurance: [Internal audit] tests a sample of onboarded and offboarded suppliers [annually].
• Non-compliance: third-party access found in breach may be suspended without notice. Supplier breaches are handled under the contract.

7. Review and approval

This policy is owned by [CISO] jointly with [Head of Procurement] and approved by [Executive committee]. It must be reviewed at least [annually] and after a security incident involving a third party, a change in regulation affecting supplier oversight, or a significant change in outsourcing.

Implementation guidance

Third-party access types and the controls that matter most

Rolling it out

1. Build the register. List external and guest accounts in the directory, delegated admin relationships, OAuth grants and enterprise applications from third parties, VPN and remote support accounts, and API keys issued to suppliers. Anything without a contract or sponsor goes on a removal list.
2. Disable the obvious. Disable accounts for ended contracts and long-unused integrations; wait [14] days before deleting so mistakes can be reversed.
3. Enforce expiry and sponsors. Set expiry on every guest and contractor account and require sponsor attestation to renew. Pilot with one business unit first.
4. Tighten privileged paths. Move MSP and vendor administration to just-in-time roles brokered through PAM, and review delegated admin relationships for over-broad roles. In Microsoft 365, GDAP relationships last at most two years, and relationships that include Global Administrator cannot be set to auto-extend.
5. Configure partner trust deliberately. Microsoft Entra cross-tenant defaults do not trust other tenants' MFA or device claims; enable trust only for assessed partners and check sign-in logs before enforcing a block.
6. Update contracts at renewal. Add the 4.6 clauses to the procurement template.
7. Test revocation. For one critical integration and one MSP, run a timed exercise to suspend all access and rotate credentials, and record the time against the [1 hour] target.

Decision guidance

• Guest accounts or federation: guests give you direct control of expiry and MFA; federation scales better but depends on the partner's leaver process, so review the partner group.
• Vendor remote tools or your own path: prefer your own brokered access (PAM, virtual desktop) so sessions are recorded and revocable by you. See the Privileged Session Management Guide.
• Small organisations: focus on the register, MFA, expiry dates and contract leaver notification. A single MSP often holds all admin access, so prioritise 4.3.5 and the revocation test.
• Large or regulated organisations: tie the register to the third-party risk platform and IGA so that contract end dates drive access expiry automatically. See the Third-Party Risk Management Guide.

Common failure patterns

• Contractor credentials on unmanaged devices: in the Uber breach, an external contractor's password, likely stolen by malware on a personal device, was combined with repeated MFA push requests until one was accepted.
• Weak verification for third-party users: M&S described the entry point of the Marks and Spencer cyberattack as sophisticated impersonation of a third-party user; M&S estimated a £300 million reduction in profit before recoveries.
• Integration tokens nobody inventoried: in the Salesloft Drift breach, OAuth tokens stored in the vendor's environment reached customers' Salesforce tenants; many could not list which integrations held standing access.
• Access that outlives the contract: nobody connected the contract end date to access removal.

Framework mapping

In MITRE ATT&CK, third-party access abuse is T1199 Trusted Relationship, usually followed by T1078 Valid Accounts.

Standards and references

• NIST: SP 800-53 Rev. 5 (PS-7, SA-9, AC-20, SR-6)
• NIST: Cybersecurity Framework 2.0 (GV.SC)
• NCSC: 10 Steps to Cyber Security, Supply Chain Security
• NCSC: Supply Chain Security Guidance, Principles
• NCSC: Secure System Administration
• CIS: Control 15, Service Provider Management
• Microsoft Learn: GDAP frequently asked questions
• Microsoft Learn: Cross-tenant access overview

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Access Control Policy Template · IAM and IGA Basics · Privileged Access Management Guide · Top 10 NHI Risks · Third-Party AI Risk Guide