Federation in Microsoft Entra ID allows your organisation to delegate authentication to an external identity provider. When a federated domain is added, users with email addresses in that domain can authenticate using tokens issued by the external provider — rather than being validated directly by Entra ID. This is a powerful and legitimate capability used for hybrid environments and SSO with external partners.

However, if an attacker has Global Admin access, adding a rogue federated domain is one of the most persistent and hard-to-detect backdoors available. Using a technique known as Golden SAML, an attacker who controls the external identity provider can forge authentication tokens for any user in the federated domain — including admin accounts — without those users needing to authenticate at all. This backdoor can survive password resets and MFA changes, because the trust relationship bypasses Entra ID's own credential validation.

• Attacker with Global Admin access adds a rogue federated domain linked to an identity provider they control
• Using Golden SAML, attacker forges valid authentication tokens for any user in the federated domain — including admins — without those users authenticating at all
• Forged tokens are trusted by Entra ID, generating sign-in events that appear fully legitimate in audit logs with no failed authentications
• Backdoor survives password resets and MFA re-enrolments because the trust relationship bypasses Entra ID’s own credential validation entirely
• Technique used in the SolarWinds/SUNBURST attack to maintain persistent access across victim organisations undetected for months
• All accounts in the federated domain can be impersonated — a single domain addition grants access to every user’s data and active sessions
• No visible compromise indicator in standard sign-in logs — detection requires specifically monitoring for domain federation change events
• Rogue domain registered cheaply and configured within minutes, meaning persistence can be established before the alert is even triaged

Federated domain additions are a legitimate part of configuring hybrid identity environments and SSO integrations. Legitimate scenarios include:

• Initial setup of a federated domain as part of an ADFS, Okta, or Ping Identity SSO deployment
• Adding a new subsidiary or acquired company's domain under a federated identity model
• Adding a domain as part of a planned migration from on-premises Active Directory to Entra ID hybrid

In all cases, domain federation is a significant architectural change that should have a corresponding project ticket, change management record, or configuration review. Any addition that cannot be immediately matched to an approved change is suspicious.

• In Entra ID, go to Custom domain names and confirm which domain was federated and when
• Check the audit logs for the administrative account that made the change — is this a known admin who regularly performs identity configuration work?
• Verify with your identity/Azure team whether this change was planned and approved
• Check whether the federated domain corresponds to a real domain your organisation controls or has a legitimate relationship with — a domain you don't recognise is an immediate red flag
• Review the admin account that made the change for signs of compromise — unusual sign-in location, recent MFA changes, or session anomalies
• If the domain is unfamiliar, check who owns it using WHOIS and whether it was recently registered

1. If the federated domain cannot be matched to an approved change, remove it immediately via Entra ID > Custom domain names > select domain > Convert to managed
2. Revoke all sessions for the admin account that made the change, reset credentials, and audit all actions that account took in the preceding 24-48 hours
3. If the federation was in place for any period of time, treat all accounts in the federated domain as potentially compromised — SAML tokens may have been issued and used
4. Review Entra ID audit logs for any sign-ins using federated authentication to that domain during the period the federation was active
5. Consider engaging Microsoft incident response or a third-party forensics provider if the federation was active for an extended period, given the potential scope of token abuse
6. After removing the malicious federation, ensure all Global Admin accounts have phishing-resistant MFA (FIDO2 or certificate-based) to prevent re-compromise
7. Review all other federated domains in your tenant to confirm each has a legitimate, documented purpose

Overe Auto-Response: The New Federated Domain Added alert can be configured in Overe to trigger automatic session revocation or account block for the initiating admin when this activity is detected. Review your Auto-Response settings under Org Config > Auto-Response — given the severity of this indicator, an automated response is strongly recommended.

Microsoft: What is federation with Entra ID?

Microsoft: Managing identity in hybrid environments

Microsoft: Protecting Microsoft 365 from on-premises attacks

After investigating a new federated domain alert, review these related risk areas:

• Admins with Risky MFA Settings — the admin account used to add the domain should be reviewed for MFA strength immediately
• Break-Glass Accounts — ensure emergency access accounts are managed-domain accounts not subject to federation
• User Created and Made Admin — attackers who add federated domains often also create backdoor admin accounts
• Unprotected Admin Portals — review admin access controls to ensure future configuration changes require strong authentication
• CA MFA Bypass Paths — confirm Conditional Access policies apply to federated domain accounts appropriately