Identity Federation Trust Risks

A financial services firm established identity federation with a consulting partner , configuring a trust relationship between their Azure Active Directory tenant and the consulting firm's Okta-based identity provider. The federation enabled consulting firm employees to access specific internal applications using their consulting firm credentials, eliminating the need to create and manage internal accounts for the consulting engagement. The security team reviewed the federation configuration and confirmed the trust relationship was technically correct. What they did not review was the consulting firm's identity governance posture , their MFA enforcement policies, their credential lifecycle management, or their account review cadence. Six months into the engagement, a threat actor compromised the consulting firm's Okta environment through a vulnerability in their MFA implementation , a technique that had been used in several high-profile attacks on Okta customers. The threat actor created a new identity in the consulting firm's Okta tenant and authenticated to the financial services firm's applications through the federation trust , using a consulting firm identity that had been legitimately created in the consulting firm's IdP but had never been provisioned in the financial services firm's own directory. The financial services firm's own MFA was not invoked because the federated user had already authenticated to the consulting firm's IdP. The consulting firm's compromised IdP was now asserting unauthorized identities into the financial services firm's environment.

What are Identity Federation Trust Risks, Really?

Identity federation is a trust relationship between identity providers that enables users from one organization to access resources in another organization using their home organization's credentials. Federation eliminates the need to create and manage accounts for external users in the resource organization's directory , the partner authenticates their user, and the federation trust allows the authenticated identity to be accepted in the resource organization's environment. The efficiency and security benefits are genuine: fewer accounts to manage, centralized credential lifecycle with the partner, and elimination of the password management burden of maintaining separate credentials for each partner relationship.

The trust extension risk is the dimension that efficiency-focused federation assessments miss. When an organization federates with a partner IdP, the identity assurance of every federated access event depends on the security of the partner's identity provider , not just the technical correctness of the federation trust configuration. If the partner's IdP enforces strong MFA, the federated authentication carries the security of that MFA enforcement. If the partner's IdP has weak MFA, a dormant account problem, or a compromised certificate, the federated authentication carries the security of those weaknesses. The resource organization's own identity controls apply to the federation trust relationship. They do not apply to the individual identities within the partner's IdP.

The identity assertion trust problem is the specific attack vector that the Okta breach scenarios have made concrete. When an attacker compromises a partner's IdP, they can create new identities in the partner's directory and use the federation trust to assert those identities into the resource organization's environment. The resource organization's security controls see a valid assertion from a trusted IdP. They do not see that the asserting IdP is under adversary control, that the asserted identity was created by the attacker, and that the federated access event has nothing to do with the legitimate consulting engagement it was configured to support.

• Partner IdP compromise enabling unauthorized identity assertion , attacker who controls partner IdP can assert any identity through the federation trust
• MFA policy discrepancy , resource organization requiring MFA for all access, federated access relying on partner IdP's potentially weaker MFA enforcement
• Federated user lifecycle visibility gap , resource organization unaware of identity creation and deactivation in partner IdP
• Certificate and metadata trust vulnerabilities , federation metadata that, if compromised, could enable trust relationship manipulation
• Overly broad federation scope , federation trust providing access to resources beyond those required for the partner engagement

Why this matters

Identity federation trust risks matter for TPRM because they represent the IAM equivalent of the supply chain attack , the adversary who cannot breach the target directly compromises a trusted partner and uses the trust relationship to gain access. The Okta compromise of 2022 demonstrated this attack pattern at scale: attackers who compromised Okta's support environment gained access to customers' Okta tenants, and customers who had federated with affected partners were exposed to identity assertion through compromised IdPs. Federation trust is a trust in the partner's security posture, and the partner's security posture is not governed by the resource organization's own controls.

The MFA bypass dimension is particularly consequential for organizations that require MFA for all access. Federation trust relationships frequently result in federated users bypassing the resource organization's MFA requirement , because the federated user authenticated to the partner IdP, and the resource organization trusts that authentication. If the partner's MFA enforcement is weaker than the resource organization's policy , shorter MFA validity periods, MFA fatigue vulnerability, or push notification MFA susceptible to social engineering , the federated access does not receive the MFA protection the resource organization's policy requires.

For TPRM practitioners, identity federation with vendors and partners is a trust extension that requires assessment of the partner IdP's security posture , not just the technical correctness of the federation configuration. A federation trust is only as secure as the least secure identity provider in the trust chain.

Where most teams get this wrong

The most consistent failure is assessing the federation trust configuration without assessing the partner IdP security posture. A correctly configured federation trust with a weakly governed partner IdP provides no more identity assurance than the partner IdP's security controls can deliver. Technical federation configuration assessment confirms the trust relationship is correctly established. It provides no assurance about what happens inside the partner's IdP.

• Assessing federation configuration without partner IdP security posture
• MFA requirement not applied to federated access , partner IdP authentication accepted without resource organization's MFA enforcement
• No visibility into partner IdP identity lifecycle , unable to detect account creation, modification, or compromise in partner directory
• Overly broad federation scope , trust providing access beyond minimum required for the engagement
• No step-up authentication for sensitive resources , federated access to high-risk resources without additional authentication requirements

What good looks like

Mature identity federation governance programs assess the partner IdP security posture as a condition of federation trust establishment, apply resource organization MFA requirements to federated access regardless of partner IdP authentication, scope federation access to the minimum resources required for the engagement, and monitor federated access for anomalous patterns.

• Partner IdP security assessment , MFA enforcement, credential lifecycle management, and account review practices assessed before federation is established
• Step-up MFA for federated access , resource organization's own MFA applied for sensitive resource access regardless of partner authentication
• Federation scope restriction , trust relationship scoped to specific applications required for the engagement
• Federated access monitoring , monitoring for anomalous identity assertion patterns through federation trust
• Partner IdP compromise response plan , defined process for revoking federation trust if partner IdP compromise is detected

Tooling

Conditional Access with Federation , Microsoft Entra Conditional Access, Okta Adaptive MFA

Conditional access policies can be applied to federated access , requiring resource organization MFA regardless of partner IdP authentication, restricting federated access to specific device compliance states, and limiting federated access by location. Microsoft Entra Conditional Access can enforce MFA for all external (federated) identities, ensuring that the resource organization's authentication policy applies even to users who have already authenticated to a partner IdP. For TPRM practitioners, asking whether the organization applies its own MFA requirements to federated users in addition to partner IdP authentication provides a specific step-up authentication question.

Identity Threat Detection , Microsoft Entra ID Protection, Okta ThreatInsight

Identity threat detection platforms monitor authentication patterns for anomalies , detecting impossible travel, credential stuffing, and unusual federation assertion patterns that may indicate partner IdP compromise. For TPRM practitioners, asking whether federated identity assertions are monitored for anomalous patterns provides a specific federation-aware detection capability question.

Governance challenges

The governance challenge with identity federation is the shared responsibility gap. The resource organization controls the federation trust configuration on their side. The partner controls the identity governance practices in their IdP. Neither party has full visibility into the security posture of the other's identity management, and the attack scenario exploits the trust relationship that bridges the gap between the two.

• Assess partner IdP security posture before federation , MFA enforcement, lifecycle management, and incident response capability
• Apply step-up MFA for sensitive resource access , resource organization authentication not waived for federated users
• Scope federation to minimum required applications
• Monitor federated access for anomalous patterns
• Maintain partner IdP compromise response plan , rapid federation trust revocation process

If you are a small team

For every active identity federation trust relationship with a vendor or partner, ask two questions. First: does our conditional access policy require our own MFA for federated users accessing sensitive resources, or does it rely entirely on the partner IdP's authentication? Second: what is our process for detecting and responding to a partner IdP compromise , specifically, how quickly can we revoke the federation trust and what resources become inaccessible to federated users when we do? Those two questions determine whether the federation trust is governed with the same rigor as direct access.

• Confirm conditional access applies MFA to federated users for sensitive resources
• Establish partner IdP compromise detection and response process
• Review federation scope , minimum required applications only
• Assess partner IdP security posture for active federation relationships

What to require

Ask directly:

"For our identity federation trust relationship, what MFA policy does your identity provider enforce for users who authenticate through the federation , and is that policy equivalent to or stronger than our own MFA requirements for sensitive resource access?"

"What is your process for notifying us if your identity provider is compromised or if there is a reason to believe that unauthorized identities may have been asserted through our federation trust , and what is your response timeline?"

Expect as evidence

• Partner IdP MFA policy documentation , enforcement level and any exceptions
• Partner IdP compromise notification process with timeline
• Identity lifecycle governance , account review cadence and deprovisioning process
• Federation scope documentation , applications accessible through the trust

A vendor who responds to the MFA policy question with 'our users authenticate securely through our IdP' has described the authentication mechanism. Ask specifically what MFA method is enforced, whether phishing-resistant MFA is required, and whether any user category is exempt from MFA. The federation trust means their authentication policy is now part of your security perimeter. Understanding what that policy requires is understanding what your perimeter currently enforces for their users.

How to evidence it

• Partner IdP security assessment records for active federation relationships
• Conditional access policy confirmation for federated user MFA
• Federation scope documentation
• Partner IdP compromise response plan

Key Takeaway

Identity federation extends your trust boundary to your partner's identity provider. Their MFA enforcement, their credential lifecycle management, their account review practices , these are now part of your identity perimeter for the users who access your environment through the federation trust. A correctly configured federation with a weakly governed partner IdP provides no more identity assurance than the partner IdP's security controls can deliver. Assessing the federation configuration without assessing the partner IdP security posture is assessing the lock without assessing the key. The lock is correctly installed. Who made the key, how securely they store it, and whether an attacker can request a copy from their identity provider are the questions that determine whether the locked door protects anything.

More on Security

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