Vendor Directory Integration Risks

A healthcare technology company established Azure AD directory integration with their primary EHR implementation partner , a bidirectional sync that allowed partner staff to appear in the customer's directory for collaboration and access purposes, and allowed customer staff to appear in the partner's directory for coordinated support. The integration was convenient: shared calendar availability, unified address book, seamless Teams collaboration, and simpler access provisioning for the ongoing engagement. Eighteen months into the integration, the partner experienced an Azure AD compromise , an attacker gained access to the partner's Global Administrator account through a targeted phishing attack. Before the compromise was detected and the account was revoked, the attacker had created two new accounts in the partner's Azure AD tenant. Those accounts, through the directory sync relationship, propagated into the customer's Azure AD tenant within the fifteen-minute sync interval. The customer's directory now contained two attacker-controlled accounts that had been created in the partner's directory. The attacker then used those accounts to authenticate to the customer's environment through the directory trust.

What are Vendor Directory Integration Risks, Really?

Directory integration connects two identity systems through a synchronisation relationship , one directory's objects, attributes, and lifecycle events propagate to the other, and in bidirectional integrations, changes flow both ways. Azure AD Connect for hybrid environments, Azure AD B2B collaboration, and third-party directory synchronisation tools implement these integrations for legitimate operational purposes: enabling users in one organisation to access resources in another, sharing identity data for collaboration, and reducing access management friction in long-term partner relationships.

The trust extension risk is the core governance challenge. A directory integration extends the trust boundary of one identity system to include the security posture of another. When the customer's Azure AD accepts identity objects from the partner's Azure AD, the integrity of those objects depends on the security of the partner's directory , the partner's admin account security, their privileged access governance, and their identity governance practices. A partner directory compromise that creates accounts, modifies attributes, or changes group memberships propagates those changes into the customer's directory within the sync interval. The customer's directory controls are not applied to the propagated changes , those controls govern what happens in the customer's directory, not what the partner's directory sends into it.

The attribute manipulation attack surface is a specific exploitation pathway that directory integrations create beyond account propagation. User attributes in Active Directory and Azure AD are used by access control systems, conditional access policies, and application authorization logic , department, job title, group membership, and custom extension attributes may all influence what a user can access. A directory integration that propagates user attributes from a partner's directory allows a partner directory compromise to modify attributes that affect customer environment access controls. An attacker who can modify directory attributes in the partner's tenant may be able to modify the customer's access controls indirectly through the attribute propagation.

• Account propagation from compromised partner directory , attacker-created accounts in partner directory propagating into customer directory through sync
• Attribute manipulation affecting access controls , partner directory attribute changes propagating to attributes used in customer access decisions
• Group membership propagation , partner directory group changes affecting customer resource access
• Sync interval attack window , changes propagating within minutes of partner directory compromise
• No staged propagation controls , directory sync accepting all changes from partner without customer-side validation

Why this matters

Directory integration matters for TPRM because it is one of the highest-trust identity relationships an organisation can establish with a vendor , the partner's directory changes propagate directly into the customer's identity infrastructure. This is a fundamentally different risk from other vendor access patterns: rather than the vendor accessing the customer's environment through authenticated sessions, the directory integration allows the vendor's identity system to write directly into the customer's directory.

The attack scenario is not theoretical. The 2021 SolarWinds-adjacent Microsoft breach investigation found that attacker activity included the creation of accounts in target environments through trust relationships from compromised partner tenants. The 2023 Microsoft compromise by Storm-0558 exploited cross-tenant trust mechanisms. Directory integration trust relationships are a documented attack pathway , and vendors who have bidirectional directory integration with customer tenants have established a pathway that would be exploited in a vendor-side directory compromise.

Where most teams get this wrong

The most consistent failure is assessing directory integration as an operational configuration without assessing it as a security trust relationship. The integration enables collaboration and is correctly configured from an operational perspective. Whether the partner's directory security posture is adequate to be trusted as an identity source is a security governance question that operational assessment does not address.

• Assessing directory integration as operational configuration rather than security trust relationship
• Partner directory security posture not assessed before integration established
• No inbound sync filtering , all partner directory objects propagating without customer-side validation
• No monitoring of inbound sync events , new accounts and attribute changes from partner not specifically monitored
• Bidirectional sync scope not minimised , more attributes and object types syncing than operational need requires

What good looks like

Mature directory integration governance programmes assess partner directory security posture before establishing sync relationships, limit sync scope to the minimum required for operational needs, implement customer-side validation of inbound sync events, and monitor for anomalous inbound changes that may indicate partner directory compromise.

• Partner directory security assessment , admin account security, privileged access governance, and identity security posture assessed before integration
• Minimum scope sync , only the object types and attributes required for collaboration syncing, not full directory objects
• Inbound sync monitoring , new accounts and attribute changes from partner directory specifically monitored with alerting on anomalous patterns
• Inbound sync validation , customer-side controls on what partner directory changes are accepted
• One-way sync preference , unidirectional sync where possible to limit partner directory write access to customer directory

Tooling

Azure AD B2B Governance , Microsoft Entra External Identities, Cross-Tenant Access Settings

Microsoft's cross-tenant access settings enable granular control over what syncs between tenants , limiting inbound sync to specific object types and attributes, controlling which partner users can access which customer resources, and configuring trust settings for MFA and device compliance claims from partner tenants. For TPRM practitioners, asking whether cross-tenant access settings are configured to limit the scope of inbound sync from partner directories provides a specific integration scope minimisation question.

Directory Sync Monitoring , Microsoft Entra Audit Logs, Azure Monitor

Audit logs for directory sync events capture account creation, attribute modifications, and group membership changes that originate from connected directories. Monitoring specifically for inbound sync events , distinguishing locally-created accounts from partner-propagated accounts , enables detection of anomalous partner directory changes. For TPRM practitioners, asking whether inbound directory sync events are specifically monitored with alerting on new account creation provides a specific compromise detection question.

Governance challenges

The governance challenge with directory integration is the convenience-versus-security tension. Bidirectional directory integration enables seamless collaboration that reduces friction for long-term partner engagements. Each additional object type and attribute synced increases operational convenience and increases the attack surface that a partner directory compromise can exploit. The minimum-scope sync principle , syncing only what is operationally necessary , applies the same logic to directory integration that least privilege applies to access provisioning.

• Assess partner directory security posture before establishing any directory integration
• Limit sync scope to minimum operational need , specific object types and attributes only
• Monitor inbound sync events for anomalous account creation and attribute changes
• Prefer one-way sync where bidirectional is not operationally required
• Include directory integration in vendor identity assessment

If you are a small team

For every bidirectional directory integration your organisation has with a vendor, ask two questions. First: if the partner's Global Administrator account were compromised, could an attacker create accounts in your directory through the sync relationship , and how quickly would those accounts appear? Second: are inbound sync events , specifically new account creation from the partner directory , monitored with alerting that would detect anomalous propagation? Those two questions surface the attack scenario and the detection capability for it.

• Ask whether a partner directory compromise could propagate attacker accounts into your directory
• Ask whether inbound sync events are monitored with anomaly alerting
• Review cross-tenant access settings to minimise sync scope
• Assess partner directory admin account security before maintaining directory integration

What to require

Ask directly:

"For our directory integration, if your Azure AD environment were compromised and an attacker created new accounts in your tenant, how quickly would those accounts propagate into our directory , and do you have monitoring that would detect that scenario before the sync occurs?"

"What is the scope of your directory integration with our tenant , specifically, what object types and attributes are included in the sync, and is the scope limited to what is operationally required for collaboration?"

Expect as evidence

• Directory sync scope documentation , object types and attributes included
• Inbound sync monitoring confirmation with anomaly alerting
• Partner admin account security posture for accounts with directory sync access
• Cross-tenant access settings documentation

A vendor who confirms directory integration is well-configured should be asked specifically what happens to that integration if their Global Administrator account is compromised. The configuration is correct. The security of the identity that controls the configuration is the governance question.

How to evidence it

• Partner directory security assessment records
• Directory sync scope documentation
• Inbound sync monitoring records
• Cross-tenant access settings configuration

Key Takeaway

Directory integration is a trust relationship between two identity systems. It is only as secure as the less-secure system in the sync. The customer's directory controls govern what happens in the customer's directory , they do not govern what the partner's directory sends into it through the sync. A partner directory compromise that creates accounts propagates those accounts into the customer's directory within the sync interval. The integration was well-configured. The trust it extended was the attack pathway. Assess the partner's directory security posture before establishing integration. Monitor inbound sync events. Limit sync scope to the minimum required. The trust relationship is as consequential as any other access grant , treat it with equivalent governance.

More on Security

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