Vendor Identity Compromise Scenarios

In late 2023, a cloud security vendor disclosed that a threat actor had gained access to their customer support system , specifically the tool their support engineers used to access customer tenants for troubleshooting. The attacker had compromised support engineer credentials and used the vendor's own legitimate remote support infrastructure to access customer environments. From the customer's perspective, the access events appeared completely normal: a support engineer connected using the vendor's standard support tool from a known IP range at business hours, authenticated correctly, and performed actions consistent with support activity. The attacker used the access to harvest customer environment data, configuration details, and in some cases customer credentials stored in the environments. The breach was discovered weeks later through indirect signals , anomalies in downstream systems, not in the vendor access logs themselves. Each customer's access log showed legitimate support access. The compromise was the support engineer identity, not any aspect of the access that the log would have flagged as unusual.

What are Vendor Identity Compromise Scenarios, Really?

Vendor identity compromise is the category of attack in which a threat actor gains control of a vendor employee's credentials , or compromises the vendor's identity management infrastructure , and uses those credentials to access customer environments through the vendor's legitimate access pathways. Unlike direct attacks against customer environments, vendor identity compromise is difficult to detect because the access it produces is authenticated, authorised, and consistent with the access patterns that the compromised identity would legitimately generate. The security controls that detect unauthorised access , failed authentication alerts, unfamiliar IP detection, unusual access time anomalies , are largely ineffective against access that passes authentication, comes from known IP ranges, and occurs at normal business hours.

The attack surface for vendor identity compromise is diverse and has expanded significantly as vendor environments have grown in complexity. A threat actor who wants to compromise vendor access to customer environments has multiple pathways: phishing vendor support engineers for their credentials, compromising the vendor's identity provider through vulnerabilities or supply chain attacks, exploiting weaknesses in the vendor's MFA implementation, compromising the vendor's remote access infrastructure itself, or attacking the vendor's CI/CD pipeline to insert credentials that provide platform access. Each pathway has different detection signatures and different mitigations, but all produce the same outcome: valid credentials for legitimate vendor-to-customer access being used by an attacker.

The multi-customer blast radius is what makes vendor identity compromise categorically different from direct customer compromise. An attacker who directly compromises a customer's environment has access to that customer's data. An attacker who compromises a vendor support engineer identity may have access to every customer environment that the engineer's role can reach , dozens or hundreds of customers simultaneously. The vendor's customer support infrastructure, designed for operational efficiency, concentrates the attacker's access to a scale that direct customer compromise would require attacking each customer separately to achieve.

• Credential theft of vendor support engineers , phishing, credential stuffing, or social engineering of staff with broad customer environment access
• Vendor identity provider compromise , attacking the IdP to forge identity assertions or create new privileged identities
• MFA bypass on vendor accounts , MFA fatigue, SIM swapping, or real-time phishing defeating vendor employee MFA
• Remote access infrastructure compromise , attacking the vendor's support tool or remote access platform rather than individual credentials
• Supply chain compromise of vendor tooling , compromising tools that vendor engineers use to access customer environments

Why this matters

Vendor identity compromise matters for TPRM because it represents the access threat that customer-side security controls are least equipped to detect. Customers can monitor for unusual access patterns from vendor systems. They cannot easily distinguish a compromised vendor identity from a legitimate one when the compromised access uses the same tool, the same IP range, and the same general behavioural profile as legitimate support access. The detection capability for vendor identity compromise must exist at the vendor side , in the vendor's own identity anomaly detection, session monitoring, and employee security posture , rather than at the customer side.

The operational response dimension is equally significant. When a vendor identity compromise is discovered, the response requires the vendor to immediately revoke all potentially compromised credentials, determine which customer environments were accessed, reconstruct the access timeline for each affected customer, and provide investigation support for each customer's incident response. This is a massive operational undertaking that depends on the vendor having comprehensive session logging, individual account attribution, and the incident response capability to support dozens of simultaneous customer investigations. Vendors without these capabilities produce the 'unknown scope' incident disclosures that regulators and customers find most concerning.

Where most teams get this wrong

The most consistent failure is assuming that customer-side access monitoring is sufficient to detect vendor identity compromise. Customer monitoring detects unusual access patterns. Vendor identity compromise produces usual access patterns , the attacker is operating the compromised identity as it would normally be operated, at least initially. The detection capability for this threat lives at the vendor's identity security controls, not at the customer's access monitoring.

• Assuming customer-side monitoring detects vendor identity compromise
• Not assessing vendor identity security posture , how the vendor protects its own employees' credentials
• No vendor-side anomaly detection capability assessed
• Multi-customer blast radius not considered , scope of compromise through vendor support access
• Vendor incident response capability not assessed , ability to support simultaneous multi-customer investigations

What good looks like

Mature vendor identity security programs protect support engineer credentials with phishing-resistant MFA, monitor for behavioural anomalies in support engineer activity that would distinguish attacker behaviour from legitimate use, implement session recording for all customer environment access that enables post-compromise investigation, and have incident response playbooks specifically designed for the multi-customer identity compromise scenario.

• Phishing-resistant MFA for all staff with customer environment access , FIDO2/WebAuthn for support engineers
• Behavioural analytics on support engineer activity , baseline of normal customer environment access patterns with alerting on deviations
• Session recording for all customer access , complete record of every customer environment session
• Vendor-side impossible travel and concurrent session detection , alerts when vendor staff credentials are used simultaneously from multiple locations
• Multi-customer identity compromise incident response playbook , defined response procedures for the breach scenario that affects multiple customers simultaneously

Tooling

Phishing-Resistant MFA , FIDO2/WebAuthn, YubiKey, Microsoft Entra

Phishing-resistant hardware MFA for vendor support engineers eliminates the credential phishing vector that is the most common pathway to vendor identity compromise. Hardware keys cannot be captured through real-time phishing proxies because the authentication is cryptographically bound to the legitimate domain. For TPRM practitioners, requiring phishing-resistant MFA specifically for vendor staff with customer environment access is the single highest-impact control for vendor identity compromise risk.

Identity Threat Detection , Microsoft Entra ID Protection, Okta ThreatInsight

Identity threat detection platforms monitor sign-in behaviour for anomalies , impossible travel, concurrent sessions, unfamiliar device, atypical behaviour patterns , and generate risk signals that can trigger step-up authentication or session termination. For TPRM practitioners, asking whether the vendor's identity platform has real-time threat detection specifically for their staff accessing customer environments provides a specific identity compromise detection capability question.

Governance challenges

The governance challenge with vendor identity compromise risk is the assessment limitation. Customers cannot directly evaluate the internal security posture of vendor support engineers' individual credential management, phishing susceptibility, or endpoint security. The controls that protect against vendor identity compromise are the vendor's own , and assessing them requires asking questions about internal security practices that go beyond what most TPRM questionnaires reach.

• Require phishing-resistant MFA for all vendor staff with customer environment access , contractual requirement
• Ask about vendor-side identity anomaly detection , does the vendor detect when support credentials are used anomalously
• Ask about vendor-side session recording for customer environment access
• Ask about the multi-customer identity compromise incident response procedure
• Include vendor identity security posture in risk tiering , vendors with broad multi-customer access rated higher for this scenario

If you are a small team

Ask your managed services and support vendors two questions that specifically address the identity compromise scenario. First: if one of your support engineers' credentials were compromised and an attacker was using them to access customer environments, what would detect that , specifically, what behavioural anomaly detection exists on your support staff's customer access activity? Second: do your support engineers use phishing-resistant MFA , specifically FIDO2 hardware keys , for their own authentication, or do they use push notification or TOTP MFA that can be defeated through real-time phishing? Those two questions assess detection capability and attack surface for the most consequential identity risk scenario.

• Ask what detects compromised vendor support credentials being used in customer environments
• Ask whether support engineers use phishing-resistant MFA
• Ask about session recording for all customer environment access
• Ask about the multi-customer breach incident response procedure

What to require

Ask directly:

"If a threat actor compromised one of your support engineers' credentials and was accessing customer environments using that identity, what detection capability would identify that , specifically, what behavioural analytics exist on your support staff's customer access activity?"

"Do all staff who access customer environments use phishing-resistant MFA , specifically FIDO2 hardware keys , rather than push notification or TOTP methods that can be defeated through real-time phishing?"

Expect as evidence

• Behavioural analytics description for support staff customer access
• Phishing-resistant MFA deployment confirmation for staff with customer access
• Session recording confirmation for customer environment access
• Multi-customer identity compromise incident response procedure

A vendor who responds with 'access is controlled and monitored' should be asked specifically what would be different in the access log if the attacker described in the hook scenario were operating. If the honest answer is 'nothing would look different initially,' the detection depends on something other than access log monitoring , and that something needs to be identified and confirmed.

How to evidence it

• Phishing-resistant MFA requirement documentation for vendors with customer environment access
• Vendor identity security assessment records
• Multi-customer breach response capability assessment
• Session recording confirmation for vendor access

Key Takeaway

Vendor identity compromise produces legitimate access , the attacker has the right credential, authenticates correctly, and operates through the approved channel. The customer's access monitoring sees exactly what it should see when the vendor's support engineer connects. The detection has to happen on the vendor's side , in the anomaly detection that notices the support engineer's access pattern changed, the impossible travel signal that fires when the same credential is used from two countries, the session recording that captures what the 'support engineer' actually did during the session. The vendor's identity security posture is the defence against this scenario. Asking about it is not paranoia. It is the assessment the Okta breach made obvious was overdue.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations