Vendor Identity Monitoring

The night before a data breach was discovered at a financial technology vendor, the compromised support engineer's account had received sixty-three failed authentication attempts from an IP address in Eastern Europe between 11 PM and 2 AM. At 2:15 AM, a successful authentication occurred from a US-based IP that had been used by the engineer previously , consistent with a credential stuffing attack that had eventually found the right password, or a VPN-masked access event following credential theft. The vendor's identity platform had logged all sixty-three failed attempts and the anomalous successful authentication. These signals were in the vendor's SIEM but had not generated a priority alert. The customer organization's access logs showed the engineer's first connection at 9:03 AM the following morning , a normal business hours connection from a known IP. From the customer's perspective, nothing was unusual. The attack chain was entirely in the vendor's authentication infrastructure , sixty-three failed attempts, one anomalous success, then nine hours of attacker persistence in the vendor environment before the first customer environment access. The customer had visibility into the outcome. The vendor had visibility into the attack. Neither saw the complete picture without the other.

What is Vendor Identity Monitoring, Really?

Identity monitoring at the vendor boundary encompasses two distinct but complementary monitoring domains. Customer-side monitoring captures what vendor identities do within the customer environment , access events, data queries, configuration changes, session duration, and access patterns that deviate from baseline. Vendor-side monitoring captures the authentication events, credential activities, behavioral signals, and anomaly detections that occur in the vendor's own identity infrastructure before and between connections to customer environments. Neither domain alone provides the complete picture required for effective threat detection and investigation.

The split visibility problem is the structural challenge. Customer access logs show the session after authentication succeeds. They do not show the authentication events that preceded the session , whether MFA was required and satisfied, whether there were preceding failed attempts suggesting credential stuffing, whether the authentication came from an unusual location relative to the vendor's normal employee geography, or whether the credential was flagged with elevated risk signals by the vendor's identity platform. This pre-session intelligence lives entirely in the vendor's authentication infrastructure and is not transmitted to the customer environment when the session begins.

The temporal gap compounds the visibility problem. The attack in the hook scenario traversed a nine-hour gap between the anomalous authentication in the vendor's IdP and the first customer environment access. During those nine hours, the attacker established persistence in the vendor's environment, identified customer environment access pathways, and prepared for the customer-targeting phase. The customer had no visibility into this period. The vendor had visibility but did not act on it. Effective monitoring requires both visibility and action , the vendor's identity signals reaching a detection capability that can recognize the attack pattern and respond before the customer environment is reached.

• Pre-session authentication intelligence not visible to customers , failed attempts, risk signals, and anomalous authentication preceding vendor connections
• Vendor-side identity monitoring gaps , failed authentication alerting not properly configured or not generating priority alerts
• No bilateral monitoring arrangement , no mechanism for vendor to share identity security signals with customer
• Customer monitoring starting at session initiation , attack chain before session not visible
• No vendor identity threat notification obligation , vendor not required to notify customer of identity security events affecting staff with customer access

Why this matters

Vendor identity monitoring matters for TPRM because the detection capability for vendor identity compromise must span the vendor-customer boundary , customer monitoring alone cannot detect the pre-session attack chain, and vendor monitoring alone may not act on signals before customer environments are reached. The split visibility requires either coordination between vendor and customer monitoring systems or a contractual obligation for the vendor to notify customers when identity security events affect staff with customer environment access.

The notification obligation dimension is where governance can partially compensate for the inherent visibility gap. A vendor contractually required to notify customers within hours of detecting identity security events affecting staff with customer environment access creates a communication channel that partially bridges the split visibility problem. The notification may arrive after the attacker has already accessed the customer environment , as the hook scenario illustrates , but it at least enables the customer to begin investigation and containment rather than remaining unaware for the weeks or months that undetected compromises often persist.

Where most teams get this wrong

The most consistent failure is treating customer-side access monitoring as comprehensive vendor identity monitoring. Customer access logs show vendor identity behavior in the customer environment. They do not show the attack chain that may be unfolding in the vendor's authentication infrastructure before and between customer environment sessions. Comprehensive monitoring requires acknowledging this split and asking about the vendor-side monitoring capability that covers the gaps customer monitoring cannot reach.

• Treating customer-side access monitoring as comprehensive vendor identity monitoring
• Vendor-side identity monitoring capability not assessed
• No identity security notification obligation in contract
• Failed authentication alerting at vendor not assessed
• No bilateral monitoring or coordination mechanism

What good looks like

Mature vendor identity monitoring programs combine robust customer-side access monitoring with vendor-side identity security monitoring that covers pre-session authentication events, behavioral anomaly detection on staff with customer access, and a contractual notification obligation for identity security events affecting customer environment access.

• Vendor-side failed authentication alerting , sixty-three failed attempts generates priority alert, not background noise
• Pre-session anomaly detection , risk signals on vendor staff identities detected before customer environment access
• Identity security notification obligation , vendor contractually required to notify customer of identity events affecting staff with customer access
• Customer-side session monitoring , session recording, behavioral analytics, and anomaly detection on vendor sessions
• Investigation coordination , defined process for joint vendor-customer investigation of identity security events

Tooling

SIEM with Identity Analytics , Microsoft Sentinel, Exabeam

SIEM platforms with identity analytics provide the vendor-side detection capability for pre-session authentication anomalies , correlating failed attempts, successful authentications from unusual locations, and behavioral deviations into actionable alerts. For TPRM practitioners, asking whether the vendor's SIEM includes identity analytics with priority alerting for authentication anomalies affecting staff with customer access provides a specific pre-session detection capability question.

PAM Session Recording , CyberArk, BeyondTrust

PAM platforms provide customer-side session recording that captures what vendor identities do during customer environment sessions , providing the post-initiation monitoring that complements the vendor-side pre-session monitoring. For TPRM practitioners, asking whether customer environment access goes through a PAM platform with session recording provides the most direct customer-side monitoring question.

Governance challenges

The governance challenge with vendor identity monitoring is the bilateral coordination requirement. Effective monitoring requires both parties to maintain their respective monitoring domains and to have a communication channel that bridges them when identity security events occur. The customer cannot impose monitoring requirements on the vendor's internal infrastructure , only contractual obligations and assessment questions can surface whether the vendor-side capability exists. The notification obligation bridges the gap between the vendor's monitoring capability and the customer's awareness.

• Add identity security notification obligation to vendor contracts , timely notification of identity events affecting customer access staff
• Assess vendor-side identity monitoring , failed authentication alerting, behavioral analytics, pre-session anomaly detection
• Implement customer-side session monitoring for all vendor access
• Define investigation coordination process for identity security events
• Include vendor identity monitoring in security assessment , not just customer-side monitoring

If you are a small team

Ask your highest-risk vendors one question about the pre-session visibility gap: if one of your support engineers' credentials were being attacked through credential stuffing overnight , receiving dozens of failed authentication attempts , would that generate a priority alert in your SIEM, and would you notify us before that engineer connected to our environment the following morning? The answer describes whether the vendor-side monitoring exists and whether it generates timely notification before the attack chain reaches the customer environment.

• Ask whether failed authentication attempts against vendor staff generate priority SIEM alerts
• Ask whether the vendor would notify the customer before an at-risk staff member connects to the customer environment
• Add identity security notification obligation to vendor contracts
• Implement session recording for all vendor access to customer environments

What to require

Ask directly:

"If a member of your staff with access to our environment experienced significant failed authentication attempts suggesting a credential stuffing attack overnight, would that generate a priority alert in your monitoring , and would you notify us before that staff member connected to our environment?"

"What identity security events affecting staff with access to our environment trigger a notification obligation to us , and what is the timeline for that notification?"

Expect as evidence

• Vendor-side identity monitoring capability , failed authentication alerting and priority thresholds
• Identity security notification obligation and timeline
• Customer-side session monitoring confirmation
• Investigation coordination process documentation

A vendor whose monitoring detects sixty-three failed authentication attempts against a staff member but does not generate a priority alert and does not notify the customer has monitoring that captures the signal without acting on it. Both halves matter: the signal and the response. Ask about both.

How to evidence it

• Identity security notification obligation in vendor contracts
• Vendor-side identity monitoring capability assessment
• Customer-side session monitoring records
• Identity security event response time records

Key Takeaway

You see what happens after the door opens. The vendor sees everything that happened before it , the sixty-three failed attempts, the anomalous successful authentication, the nine hours of attacker persistence before the first customer environment connection. Comprehensive identity monitoring at the vendor boundary requires both domains. Customer-side monitoring covers the customer environment. Vendor-side monitoring covers the attack chain that precedes it. The contractual notification obligation bridges the visibility gap when the vendor detects the pre-session signals that the customer cannot see. Both parties monitoring their respective domains and communicating when events warrant is the architecture. One party monitoring their domain in isolation is incomplete. Ask what the vendor sees on their side. Ask what they do with it. Ask when they tell you.

More on Security

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