Home Realm Discovery in Entra ID: HRD Policy and Risks

Home realm discovery decides which identity provider authenticates a user, so whoever can influence that decision, through a domain hint, a federated domain or a DNS record, can steer sign-ins away from the controls you rely on. In Microsoft Entra ID, HRD routes a user to their home tenant, a Microsoft account, AD FS or another federated identity provider based on the name they type and the hints an application sends. Misconfigured HRD quietly blocks passkeys and guests; abused HRD becomes a persistence path when an attacker adds or changes a federated trust. This guide covers how HRD evaluates a sign-in, the HRD and DomainHintPolicy settings, the domain and federation attack paths, and how to monitor them. It is for Entra administrators and identity architects, and goes deeper on one mechanism than the Federation and Trust Relationships Guide.

Key takeaways

HRD is a routing decision with security consequences. The domain of the user name and any domain hint decide whether Entra handles authentication itself or hands it to an external identity provider whose policies you may not control.
Auto-acceleration trades away stronger methods. Microsoft advises against configuring auto-acceleration because it can hinder FIDO and collaboration; sending users straight to a federated IdP bypasses Entra's page, managed credentials and guest sign-in.
Domain hints win unless you say otherwise. A domain hint in the request overrides HRD policy auto-acceleration, and some Microsoft and SaaS apps send hints automatically, so a DomainHintPolicy is needed to finish a move to cloud credentials.
Control of a domain's DNS is control of its realm. Domain verification rests on a TXT record; an attacker who can edit DNS or who holds Domain Name Administrator rights can attach a domain to a tenant or change how it authenticates.
Federation changes are Tier 0 events. "Set domain authentication" and "Set federation settings on domain" in the Entra audit log should page someone, because converting a domain to federated is a known persistence technique (ATT&CK T1484.002).

How home realm discovery works in Entra ID

When a user starts a sign-in, Entra needs to know where that user's credentials live. Microsoft's documentation lists four destinations: the user's home tenant (which may be the resource tenant), a Microsoft account for a guest using a consumer account, an on-premises IdP such as AD FS, or another IdP federated with the tenant. The decision is driven by the user principal name the user types and by signals in the authentication request.

The user opens an application or the common sign-in page and enters a UPN.
Entra checks the domain, any domain hint, and any HRD policy that applies.
If the domain is federated and acceleration applies, the user is sent straight to the federated IdP; otherwise the Entra sign-in page is shown and Entra routes from there.

Domain hints

Applications can skip the user name step by sending a domain hint: whr=contoso.com in WS-Federation, a hint in the SAML request or whr, and domain_hint=contoso.com in OpenID Connect. Entra redirects to the federated IdP only when a hint is present and the tenant is federated with that domain; a hint that does not match a verified federated domain is ignored.

Evaluation order

Order	Signal	Effect
1	Domain hint in the request	Tenant HRD policy is checked to see whether hints are ignored; if allowed, the hint routes the user
2	HRD policy assigned to the application's service principal	Enforced for that app; only one HRD policy can be attached to a service principal
3	Organisation default HRD policy	Applies when there is no hint and no app policy
4	Default behaviour	Standard routing from the typed UPN

Since April 2023 users may see a domain confirmation dialog. Microsoft tells users to check that the domain matches the organisation they intend to sign in to and to cancel if they do not recognise it. Include that in awareness material, because it is a useful last check against sign-in redirection lures.

HRD policy settings and what they change

HRD policies are created with Microsoft Graph (New-MgPolicyHomeRealmDiscoveryPolicy, assigned with New-MgServicePrincipalHomeRealmDiscoveryPolicyByRef, or the /policies/homeRealmDiscoveryPolicies endpoint) and need the Application Administrator role with the Policy.ReadWrite.ApplicationConfiguration scope.

Property	Scope	What it does	Security note
`AccelerateToFederatedDomain`	Policy	When true, sends users straight to the federated IdP (one verified federated domain, or the `PreferredDomain` if several)	Blocks managed credentials such as FIDO keys and can stop guests signing in, even before the policy is attached to an app
`PreferredDomain`	Policy	Names the federated domain to accelerate to	If omitted with several federated domains, the policy has no effect
`AllowCloudPasswordValidation`	Policy	Lets federated users authenticate with user name and password directly against the Entra token endpoint (ROPC for legacy apps)	Enable only with password hash sync active; remove if sync is disabled to avoid stale hashes; on-premises IdP policies are bypassed
`AlternateIdLogin`	Tenant	Allows email as an alternate sign-in ID on the Entra page	Relies on users not being auto-accelerated
`DomainHintPolicy`	Tenant	Makes the sign-in page behave as if the domain hint was absent for listed domains or apps	The control that lets cloud credentials work when apps keep sending hints

DomainHintPolicy in detail

IgnoreDomainHintForDomains: array of domains whose hints are ignored; supports all_domains.
RespectDomainHintForDomains: domains whose hints are always honoured, used to keep some domains accelerated during a phased rollout.
IgnoreDomainHintForApps: application IDs whose hints are ignored; supports all_apps.
RespectDomainHintForApps: application IDs whose hints are honoured even when the domain is in the ignore list, for apps that break without hints.
Precedence: respect beats ignore for both domains and apps.

Two platform limits catch teams out. HRD policies do not apply to brokered authentication on mobile platforms and macOS, where the calling app must pass a domain hint itself. And during a staged rollout from federation to cloud authentication, Microsoft states that users in flows carrying domain_hint continue to use federation, so a DomainHintPolicy is part of finishing the migration, not an optional extra.

Attack paths through realms, domains and federation

Path	What the attacker changes	Prerequisite	Primary control
Federation backdoor on a verified domain	Converts a managed domain to federated, or edits the signing certificate or endpoints of an existing federation, so an IdP they control issues accepted tokens	Global Administrator, Hybrid Identity Administrator or Domain Name Administrator rights	Least privilege and PIM for those roles, alert on federation audit events
Token signing key theft	Uses a stolen AD FS token signing certificate to forge SAML assertions for any user (T1606.002)	Access to the federation server or its key	Treat federation servers as Tier 0, protect keys in an HSM, move to cloud authentication
Hybrid authentication tampering	Backdoors pass-through authentication or AD FS processes (T1556.007)	Admin access to the hybrid identity servers	Tier 0 isolation, Defender for Identity or equivalent monitoring
Extra IdP in another identity tenant	Adds a new federated identity provider to Okta or AWS IAM Identity Center, as ATT&CK T1484.002 describes	Admin access in that platform	Alert on IdP configuration changes in every identity platform, not just Entra
Domain or DNS takeover	Uses control of public DNS to pass TXT verification, for example an external admin takeover of an unmanaged directory with `forceTakeover`	Write access to the domain's DNS or a lapsed registration	Registrar lock, DNS change monitoring, domain renewal ownership
Domainless or loose B2B federation	A SAML or WS-Fed IdP trusted for guests without a domain check	Partner IdP compromise or a weak partner	Prefer domain bound federation; Microsoft notes domainless federation enforces no email domain check and allows one such IdP per tenant

The SolarWinds compromise showed the end state: with the trusted SAML token signing certificate, intruders signed their own tokens and logged in as any user to federated services without a password or MFA prompt. Every federated domain in your tenant is a place where that trust lives. See the Golden SAML and Federation Trust Abuse Defence Guide.

Domains and DNS

Microsoft's admin takeover documentation makes the dependency explicit: both internal and external takeover rely on an MS= TXT record in public DNS, and an external takeover moves the domain, users, subscriptions and licences to the claiming tenant, with the unmanaged directory deleted 10 days later. B2B federation uses DNS the same way, with a DirectFedAuthUrl TXT record when the partner's sign-in endpoint is on a different domain. Practical consequences:

Registrar and DNS accounts are identity infrastructure: put them behind phishing-resistant MFA, registrar lock and change alerts, and give them named owners.
Unmanaged directories for your domains: check whether staff created self-service tenants with your domain, and claim them deliberately rather than leaving them for someone else.
Retired domains: remove domains from the tenant and from partner federations before letting the registration lapse; a lapsed domain can be bought and its DNS used to answer verification.

Choosing an HRD strategy

Situation	Recommended HRD posture	Why
All users on cloud authentication (PHS, PTA or certificate based)	No auto-acceleration; DomainHintPolicy ignoring hints for retired federated domains	Lets passkeys, Windows Hello and Conditional Access apply everywhere
Migrating from AD FS	Staged rollout for pilot groups, then a phased DomainHintPolicy, then domain conversion to managed	Staged rollout is a temporary test mechanism and hint carrying apps keep users on federation
Must remain federated (regulatory or third party IdP)	Accelerate only the apps that need it with an app level policy, keep guest and admin flows on Entra	Limits the blast radius of auto-acceleration
Multi-domain tenant after mergers	Inventory each domain's authentication type; set `PreferredDomain` only where justified	Mixed domains are where forgotten federations survive
Small organisation, single domain	Managed domain, no HRD policy	Fewer moving parts; federation adds Tier 0 servers to protect

How to implement

Inventory realms: export every verified domain with its authentication type (managed or federated), the federation endpoints and signing certificates, and every external SAML or WS-Fed IdP configured for B2B.
Inventory HRD policies: list all homeRealmDiscoveryPolicies, the service principals they apply to, and whether any is the organisation default. Remove orphaned policies and any AllowCloudPasswordValidation policy for apps that no longer need ROPC.
Lock down who can change realms: make Global Administrator, Hybrid Identity Administrator, Domain Name Administrator and Application Administrator eligible only through PIM with approval and phishing-resistant MFA.
Pilot the DomainHintPolicy: follow Microsoft's four phases: ignore hints for one tolerant domain, add breaking apps to RespectDomainHintForApps, expand domain by domain, then ignore all domains with explicit exceptions.
Test sign-in journeys: member, guest, passkey, mobile broker and macOS flows for each changed app, including the domain confirmation dialog.
Convert domains to managed: once no flows depend on federation, convert the domain and decommission the federation servers and their certificates.
Roll back: keep the previous policy definition; rollback is a PATCH back to the earlier definition or removing the service principal assignment (DELETE .../homeRealmDiscoveryPolicies/{policyId}/$ref), so record the IDs before each change.

Where identity fits: non-human paths through HRD

Legacy service accounts on ROPC: scripts and appliances that post a user name and password are often why AllowCloudPasswordValidation exists. Replace them with workload identities, managed identities or certificate credentials, then delete the policy. See the Legacy Authentication and ROPC Retirement Guide.
Federation signing certificates and partner metadata: machine credentials with tenant wide reach. Track expiry and ownership, and use metadata URLs so Entra can renew partner certificates instead of manual uploads.
Automation that manages domains: any app registration holding Domain.ReadWrite.All can verify domains or change their authentication. Review those grants alongside the admin roles. See the Entra ID Applications and Consent Guide.

Detection and measurement

Federation changes: alert on the DirectoryManagement audit activities "Set domain authentication" and "Set federation settings on domain", plus "Add unverified domain", "Verify domain", "Add verified domain" and "Remove verified domain".
HRD and app policy changes: alert on creation, update or assignment of HRD policies, especially new AllowCloudPasswordValidation or organisation default policies.
Hybrid infrastructure: Microsoft's security operations guidance treats federation servers as Tier 0 and recommends monitoring AD FS extranet lockout, failed sign-ins and Entra to AD FS correlation; it also notes that in federated domains failed legacy authentications are not recorded in Entra sign-in logs.
Tenant sprawl: the "Create Company" audit event shows a user in your tenant creating a new tenant, a known way to stand up attacker controlled realms.
DNS: monitor TXT and NS changes on every verified domain.

Metrics:

Federated verified domains remaining, trending to zero or to a documented exception list.
Applications with an HRD policy, and those with AllowCloudPasswordValidation enabled.
Sign-ins redirected to a federated IdP as a share of all interactive sign-ins.
Time to triage a federation or domain change alert.
Verified domains with registrar lock and named DNS owners.

Framework mapping

Framework	Reference	Relevance
MITRE ATT&CK	T1484.002 Trust Modification; T1606.002 SAML Tokens; T1556.007 Hybrid Identity; T1078.004 Cloud Accounts	Federation backdoors, forged tokens and abuse of the resulting accounts
NIST SP 800-53 Rev. 5	IA-2; IA-8; IA-5 Authenticator Management; AC-20 Use of External Systems; CM-3 Configuration Change Control	Authenticating users and external users, managing federation keys, controlling trust changes
NIST CSF 2.0	PR.AA-01, PR.AA-02, PR.AA-03; PR.PS-01; DE.CM-03	Identity management, configuration management and monitoring of admin activity
ISO/IEC 27001:2022 Annex A	5.16 Identity management; 5.17 Authentication information; 8.5 Secure authentication; 8.32 Change management	Identity, credential and change controls for realms and trusts
CIS Controls v8.1	Control 5 Account Management; Control 6 Access Control Management	Centralised authentication and admin access control

Common failure patterns

Organisation wide auto-acceleration: set years ago for convenience, it now prevents FIDO keys and guest sign-in and keeps every user dependent on AD FS.
Migration stalled by hints: the domain was meant to move to cloud authentication, but apps sending domain_hint keep staged users on federation, so the federation servers can never be retired.
Forgotten federated domain: an acquired company's domain still federated to an unmonitored IdP whose signing certificate nobody owns.
ROPC exception left behind: AllowCloudPasswordValidation enabled for a legacy app after password hash sync was turned off, leaving stale hashes valid.
DNS outside identity governance: registrar accounts shared by marketing or a web agency without MFA, despite DNS being the proof of domain ownership.
No alert on federation changes: the audit events exist but nobody watches them, so a converted domain or new signing certificate goes unnoticed.

Practitioner checklist

List every verified domain, its authentication type and federation certificate owner.
List every HRD policy and the service principals it applies to; remove unused ones.
Avoid auto-acceleration except for named apps with a documented need.
Deploy a DomainHintPolicy in phases until cloud credentials work for all apps.
Remove AllowCloudPasswordValidation wherever the legacy client has been replaced.
Put realm changing admin roles and Domain.ReadWrite.All apps behind PIM or review.
Alert on federation, domain verification and HRD policy changes, and on "Create Company".
Protect registrar and DNS accounts with phishing-resistant MFA and registrar lock.
Plan conversion of remaining federated domains to managed and retire the federation servers.

Home realm discovery in Entra ID and federation: Control where every sign-in is sent