It is also a governance arrangement in which your trust in authenticated users is entirely dependent on the security and integrity of an identity provider you do not operate, may not audit, and whose security incidents may not be disclosed to you in time to act before the consequences arrive in your environment.
What Federation Actually Means for Trust
When an organization federates identity — accepting authentication assertions from an external identity provider — it delegates the authentication decision to that provider. The access decision remains in the organization's control: the organization defines what authenticated users can access. But the identity assertion that drives the access decision is produced by a system the organization does not control.
The security of the federated authentication chain is the security of its weakest link. If the identity provider's authentication is compromised — through credential theft, session token manipulation, or the provider's own security failure — the compromise produces authentication assertions that your access control system treats as valid. The access control is working correctly. The identity it is controlling access for is not who it appears to be.
The 2023 Microsoft Entra ID token forging incident illustrated this at scale. A compromised Microsoft signing key allowed an attacker to forge authentication tokens that Microsoft's own systems accepted as valid. Organizations whose access controls accepted Microsoft authentication tokens accepted those forged tokens. The access controls were correctly implemented. The identity assertions they were accepting were fraudulent. The governance failure was not in the access control system — it was in the assumption that the identity provider's signing infrastructure was inviolable.
Federation is a trust relationship, not a technical integration. When you federate identity, you are asserting that you trust the identity provider's security to the degree that you will grant access to your resources based on their authentication decisions. That trust needs to be governed, not assumed.
The Governance Gaps Federation Creates
The Provider Whose Security You Have Not Assessed
Most organizations assess their direct vendors' security posture. Identity providers that are integrated through federation are often treated as infrastructure rather than as vendors subject to TPRM assessment. The major identity providers — Microsoft Entra ID, Okta, Google Workspace — have established security programs and publish security documentation. Smaller or regional identity providers may have less mature security postures that have not been assessed. Even the major providers have had significant security incidents that demonstrate that no identity provider can be trusted unconditionally.
The Incident You Will Not Hear About in Time
When an identity provider experiences a security incident that affects the integrity of their authentication assertions, the organizations that federate with them have a window of exposure between the incident and the provider's disclosure. During that window, compromised authentication assertions may be accepted as valid. The disclosure timeline for identity provider security incidents has varied widely — from hours to weeks in documented cases. The organization's ability to detect the incident independently, through monitoring of authentication anomalies, determines whether it can act before the disclosure arrives.
The Stale Federation Configuration
Federation configurations — the trust relationships, the signing certificates, the attribute mappings — are established at implementation time and often remain unchanged for extended periods. The identity provider may rotate their signing certificates. The federation configuration may not be updated to reflect the new certificates. Attribute mappings that were accurate when established may no longer reflect the current structure of the identity provider's directory. The federation configuration is a governance artifact that requires maintenance as both the provider and the consuming organization change.
Governing the Federation Relationship
Governing identity federation requires treating the identity provider as a security-critical vendor relationship rather than as infrastructure. This means assessing the provider's security posture — including their incident history, their disclosure timeline practices, and their security architecture for the specific services used — with the rigor applied to other critical vendors.
It means monitoring federated authentication for anomalies that might indicate compromise of the provider's authentication integrity: unusual authentication patterns, authentication from unexpected locations, use of tokens with unexpected properties. Anomaly detection for federated authentication cannot distinguish between a legitimate user whose behavior is unusual and an attacker using a forged token — but it can surface authentication events that warrant investigation.
It means having a response plan for the scenario where the identity provider is compromised. What access can be suspended immediately if the provider's authentication integrity is in question? What is the timeline for moving to alternative authentication if a provider incident requires it? Which federated access is critical enough that the organization needs a backup authentication path?
Federate with eyes open. The trust boundary extends to the provider's security. Govern the relationship accordingly.
Treat your identity provider as a critical vendor. Assess their security. Monitor their authentication events. Plan for their compromise. Federation is a trust relationship. Govern it.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.