Included Domains are the domains or issuers whose identities are accepted as valid within a trust framework, federation, or verification process. They define the bounded set of parties a system will recognise for authentication, attribute exchange, or access decisions, often through configuration, policy, or trust lists.
What Included Domains Are
Included domains are the trusted issuers or partner domains a system is configured to accept within a federation, trust framework, or verification workflow. They define the bounded set of parties that can participate in authentication, attribute exchange, or access decisions.
Why Included Domains Matter in Trust Decisions
At a practical level, an included domain is a policy boundary. It tells the relying party which external identities, metadata sources, or assertion issuers are inside the accepted trust circle, and which are excluded even if they use similar protocols or claims.
This matters because trust in federation is not universal, it is explicitly scoped. A domain can speak the right language and still be untrusted if it is not on the accepted list, while a misconfigured inclusion can expand trust farther than intended.
How Included Domains Shape Authentication and Attribute Exchange
Included domains often sit between configuration and enforcement. During login, assertion validation, or directory synchronisation, the system checks whether the issuer or domain name is part of the approved set before it accepts identity claims, group membership, or other attributes.
That makes the concept important for both authentication and authorization workflows. If the accepted domain set is too broad, a relying party may trust assertions from an unintended issuer; if it is too narrow, legitimate users or partner systems may be blocked even though the protocol itself is healthy.
Included domains are also closely tied to trust list management, because the operational question is not just whether a domain exists, but who owns it, how it is validated, and how changes are reviewed over time.
Common Failure Modes and Configuration Boundaries
Included domains fail when operators confuse a technical domain name with a trusted identity boundary. Similar-looking domains, stale federated metadata, wildcard-style trust assumptions, or copied configuration across environments can all cause the wrong issuer to be accepted.
They also fail when the trusted set is not reviewed against business change. Mergers, vendor transitions, new partner tenants, and environment-specific differences can leave obsolete domains trusted long after they should have been removed.
In mature environments, the safest interpretation is that an included domain is not a convenience setting, it is an explicit trust decision with identity and access consequences.
Risk and Threat Considerations
Included domains create a clear trust boundary, which means mistakes can either block legitimate federation or expand trust to an unintended issuer. The security risk is greatest when a configuration drift, stale allowlist entry, or domain impersonation issue causes a relying party to accept claims from the wrong source.
Failure mechanism: An attacker or misconfigured partner domain is accepted because the inclusion rule is broader than intended, outdated, or not tightly bound to a verified issuer relationship.
Impact: The system may accept forged or inappropriate assertions, misattribute identity data, or grant access based on claims from an untrusted party.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Included domains determine which external identities are accepted for authentication. |
| AC-3 — Access Enforcement | Included domains constrain which trusted parties can influence access decisions. | |
| CM-6 — Configuration Settings | Included domains are implemented as controlled trust configuration that must be governed. | |
| Recommendation — Restrict accepted identity sources to approved issuers and validate them before granting access. Enforce access decisions only after the issuer or domain is verified against policy. Baseline and review trust-domain configuration so only approved domains remain enabled. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Included domains are a cloud trust boundary for accepted identities and federation partners. |
| Recommendation — Define and review the allowed identity domains that may participate in federation and access flows. | ||
| NIST SP 800-63 | Federation and assertion trust guidance | Included domains govern which federation partners are trusted to assert identity. |
| Recommendation — Bind federation acceptance to verified trusted parties and reject assertions from unapproved domains. | ||
Practitioner Guidance
Governance implication: Treat included domains as managed trust assets, not static configuration. Their ownership, approval, and change control should be explicit because the accepted set directly shapes who the system recognises as valid.
What to watch for: Reused trust lists, wildcard-style inclusions, tenant changes, and partner offboarding events are the points where this control most often drifts. A domain that is technically reachable is not automatically a domain that should remain trusted.
Related resources from NHI Mgmt Group
- What is the difference between blocking exfiltration domains and stopping NHI compromise?
- Should non-human identities be included in access reviews?
- What breaks when RC4-only Kerberos accounts are migrated into AES-default Active Directory domains?
- Why do custom domains make OAuth callback governance harder?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org