An attacker who compromises your IT provider, SaaS vendor or partner tenant does not need to break into you: they arrive through access you already granted and often watch less closely than your own staff. MITRE ATT&CK T1199 Trusted Relationship is the Initial Access technique for this route, and in ATT&CK v20 it covers IaaS, identity provider, SaaS, Office Suite, Windows, Linux and macOS platforms. This guide explains how the technique works, where third-party access hides, what to log and alert on in each platform, and which controls reduce the blast radius when a supplier is breached. It is written for detection engineers, identity teams and third-party risk owners, and goes deeper on detection than the Third-Party Access Guide.
Key takeaways
- The access is legitimate, the operator is not. T1199 abuses an existing connection that, in MITRE's words, may receive less scrutiny than standard routes in, so controls tuned for intruders often stay silent.
- Machine credentials are a growing share of the route. MITRE's procedure examples include stolen vendor API keys, partner certificates and delegated administrator relationships, not only contractor passwords.
- Detection is a three-step chain. MITRE's v20 detection strategy looks for a third-party session, then privilege use atypical for that identity, then lateral movement or data access from the same session.
- Least privilege and time limits shrink the blast radius. Microsoft GDAP caps partner relationships at two years and removes default Global Administrator; AWS external IDs stop a vendor being tricked into using your role for someone else.
- Offboarding is a detection control too. The joint MSP advisory warns that customers often forget to disable MSP accounts when the contract ends.
How the attack works
ATT&CK describes T1199 as adversaries breaching or leveraging organisations that have access to the intended victims. Organisations grant elevated access to IT services contractors, managed security providers and infrastructure contractors (MITRE names HVAC, elevators and physical security), and that access may sit on the same network as the rest of the enterprise. The Valid Accounts used by the third party can then be compromised and reused.
In defensive terms the sequence is:
- Compromise the trusted party. The adversary breaches a provider, steals a provider credential, or socially engineers a provider's staff.
- Use the existing trust path. They authenticate as the provider through VPN, remote support tools, federated sign-in, a cross-account cloud role, a delegated admin relationship or an OAuth integration.
- Act with the provider's rights. Because the access is expected, privileged actions may pass without challenge. From there they may add persistence (T1098 Account Manipulation, including T1098.001 Additional Cloud Credentials) or move laterally.
- Repeat across customers. One provider often serves many customers. MITRE lists GOLD SOUTHFIELD delivering malware to MSP customers and menuPass using access granted to MSPs to reach victims of interest.
T1199 sits close to related techniques. T1078 Valid Accounts is the credential being used; T1133 External Remote Services is the remote access path; T1195 Supply Chain Compromise is tampering with a product or update rather than using access. In practice incidents chain them, and classification matters less than detection.
Where it shows up
| Trust path | Typical identity | ATT&CK v20 example |
|---|---|---|
| MSP or IT contractor remote access (VPN, RDP, remote support tool) | Named or shared contractor accounts, remote support service keys | VOID MANTICORE relying on compromised VPN accounts of IT and service providers |
| Microsoft partner delegated administration | Partner admin agents via DAP or GDAP | MITRE notes adversaries may send new delegated administrator offers to clients |
| Cloud cross-account roles and federation | Vendor AWS account assuming a role; SAML or OIDC federation | Detection analytic for AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity |
| SaaS integrations and OAuth apps | Connected apps, marketplace apps, API keys | HAFNIUM using stolen API keys of PAM, cloud app and data management providers |
| Vendor-issued certificates and service accounts | Certificates and credentials customers gave a vendor | APT29 using certificates issued by Mimecast in the SolarWinds campaign |
| Network interconnects | Dedicated links between organisations or providers | Salt Typhoon pivoting through provider-to-provider and provider-to-customer connections |
Several rows are non-human identities: API keys, certificates, cloud roles and OAuth apps. That is why T1199 sits squarely in third-party NHI risk. See the OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide and the GDAP and MSP Delegated Admin Access Guide.
Impact
- Privileged entry on day one: provider access is often administrative, so the attacker skips privilege escalation.
- Many victims from one breach: a single provider credential can open many customer environments, as the vendor API key in the BeyondTrust incident showed.
- Slow detection: activity looks like routine support work and may come from known provider IP ranges.
- Hard containment: cutting off the provider can stop business services, so response needs a planned way to suspend access without losing operations. See the Compromised MSP Playbook.
Detection
ATT&CK v20 publishes a detection strategy, "Detect abuse of Trusted Relationships (third-party and delegated admin access)", with analytics per platform. Each follows the same chain: a third-party session starts, privileges or resources atypical for that identity are used, then lateral movement or data access follows from the same session. The table lists the log sources MITRE names.
| Platform | Log sources and events (from ATT&CK v20) | What to look for |
|---|---|---|
| Windows | Security event IDs 4624, 4648 (logon); 4776, 4771, 4770 (credential validation and Kerberos); 4663, 4670, 4656 (object access); Sysmon 3 and 22 (network connection, DNS) | Third-party account logons outside agreed hours or hosts, then access to sensitive objects |
| Linux | sshd "Accepted publickey/password" in syslog; auditd execve, connect, openat; flow logs from third-party CIDRs | Logins from vendor ranges followed by quick sudo or su and east-west SSH |
| Identity provider | Entra sign-in logs (interactive and service principal); audit events for adding delegated admins, assigning admin roles, updating application consent | External identity establishing a session, then role elevation or consent grants |
| Microsoft 365 | Unified audit log: Set-PartnerOfRecord, New-DelegatedAdminRelationship, Add-MailboxPermission, Set-OrganizationRelationship | New or changed partner relationships and mailbox delegation |
| IaaS | CloudTrail AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity, then CreateUser, AttachRolePolicy, CreateAccessKey, UpdateAssumeRolePolicy, CreateLoginProfile; GCP generateAccessToken | Cross-account principal making privileged IAM calls in quick succession from new networks |
| SaaS | Google Workspace OAuth grants and admin role assignments; Salesforce Connected App policy changes and "Login as user" | High-privilege scopes granted, then mass reads, exports or admin changes |
Making the detections work
- Label third-party identities: the analytics depend on knowing which accounts, roles, apps and IP ranges belong to which provider. Tag them in the IdP and the SIEM from onboarding.
- Baseline per provider: record what each provider normally touches, when, and from where. An MSP that patches servers should not read finance file shares.
- Alert on trust changes: new partner relationships, new cross-account trust policies, new federation trusts and new OAuth grants are rare and high value.
- Join with the provider's notification: the MSP advisory asks providers to notify customers of confirmed or suspected events; feed those notices into triage.
- Keep logs long enough: the joint MSP advisory recommends storing the most important logs for at least six months.
Metrics: share of third-party identities tagged with an owner and provider; share of provider sessions covered by alerting; number of standing (always-on) third-party privileged accounts; dormant third-party accounts older than 30 days; mean time to suspend a provider's access in an exercise.
See the ITDR Guide for identity detection beyond this technique.
Prevention and hardening
ATT&CK v20 maps three mitigations to T1199: M1032 Multi-factor Authentication (require MFA for all delegated administrator accounts), M1018 User Account Management (manage accounts and permissions used by trusted parties) and M1030 Network Segmentation (isolate infrastructure that does not need broad access). The controls below put them into practice.
| Control | Specific setting or practice | Framework |
|---|---|---|
| MFA on all provider access | Treat MSP accounts as privileged and enforce MFA; check for fail-open and re-enrolment gaps (joint MSP advisory) | M1032; NIST AC-17 |
| Least privilege, time-bound | Microsoft GDAP: customer consent, granular roles, maximum two-year relationship, no auto-extend with Global Administrator; tiered admin accounts | M1018; NIST AC-6 |
| Bind cross-account trust | AWS role trust policy condition sts:ExternalId; aws:SourceArn, aws:SourceAccount or aws:SourceOrgID for service principals | NIST AC-6, SA-9 |
| Control tenant trust | Entra cross-tenant access settings: scope inbound access to named users, groups and apps; trust MFA and device claims only from known partners; tenant restrictions v2 | NIST AC-17 |
| Segment provider access | Dedicated VPN or equivalent for MSP connections; segregate trust-relationship networks from the rest | M1030 |
| Contract and offboarding | Contract terms for security measures, incident notification and no credential reuse across customers; disable provider accounts at contract end | NIST SA-9, PS-7, AC-2(3); CSF GV.SC-07 |
| Ongoing review | Supplier assessments and monitoring of provider activity | NIST SR-6, AU-6; CSF DE.CM-06 |
Rollout order
- Inventory trust paths. List every provider account, remote tool, partner relationship, cross-account role, federation trust and OAuth app. Review partner relationships in Microsoft 365 as ATT&CK suggests.
- Remove what is unused. Disable dormant provider accounts and relationships first; this is low risk and closes the easiest routes.
- Enforce MFA and scope. Move delegated admin to GDAP with minimal roles, add external IDs to vendor roles, and restrict inbound cross-tenant access. Pilot with one provider and agree a rollback (temporary broader role, time-boxed) before changing all.
- Turn on detections. Tag identities, then enable the analytics above in alert-only mode for a few weeks before paging.
- Exercise. Run a tabletop where a key provider reports a breach: who suspends access, how fast, what breaks.
Small organisations that depend on one MSP should focus on contract terms, MFA, a named list of MSP accounts and the right to audit their use. Large organisations with hundreds of suppliers need automated inventory and tagging, and a tiered approach that applies the strictest controls to providers with administrative access. See the Third-Party Risk Management Guide.
Lessons from incidents
- A vendor API key reached a government department. In the BeyondTrust breach, a stolen infrastructure API key for a Remote Support SaaS product could reset local application account passwords on customer instances, leading to a major incident at the US Treasury. One machine credential at a provider was a path into several customers.
- A vendor certificate opened customer tenants. In the Mimecast certificate compromise, a certificate customers trusted for Microsoft 365 connections was stolen, and a small number of tenants were targeted. ATT&CK cites this as part of APT29's T1199 activity.
- A support provider's staff were the weak point. In the Caesars Entertainment breach, attackers reportedly socially engineered an outsourced IT support vendor before reaching the loyalty database; many details remain unconfirmed.
Practitioner checklist
- Keep an inventory of every third-party trust path, with provider, owner, identity type and privilege level.
- Tag third-party accounts, roles, apps and IP ranges in the IdP and SIEM.
- Enforce MFA on every provider account with administrative access.
- Replace standing delegated admin with scoped, time-bound access such as GDAP, and avoid Global Administrator.
- Add
sts:ExternalIdto vendor role trust policies and scope cross-tenant inbound access. - Alert on new partner relationships, trust policy changes, federation changes and OAuth grants.
- Retain key logs for at least six months and baseline normal activity per provider.
- Disable provider accounts and relationships on contract end and review dormant ones monthly.
- Rehearse suspending a key provider's access without stopping critical services.
Standards and references
- MITRE ATT&CK: Trusted Relationship
- NCSC, CISA and partners: Protecting Against Cyber Threats to Managed Service Providers and their Customers
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- Microsoft Learn: GDAP frequently asked questions
- Microsoft Learn: Cross-tenant access overview
- AWS: The confused deputy problem
- NCSC: Supply chain security guidance
Related NHI Mgmt Group resources: Third-Party Access Guide · OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide · GDAP and MSP Delegated Admin Access Guide · Compromised MSP Playbook · ITDR Guide