A device and platform trust configuration that binds an app to specific web domains for links and credentials. In practice, it enables reliable return paths for OAuth, magic links, and passkeys so that authentication can move between app and web without breaking the session.
Expanded Definition
Associated Domains is the trust binding that lets an app declare which web domains it is allowed to handle for universal links, credential sharing, and passkey or password handoff. In NHI and IAM design, it matters because the app, the browser, and the identity provider must agree on a narrow set of domains before an authentication flow can be completed safely. That boundary reduces phishing risk and helps preserve a reliable session return path across mobile and web surfaces.
The concept is often discussed alongside app links, device trust, and federation, but it is not the same as general domain allowlisting. Associated Domains is specifically about cryptographically and operationally proving that a given app should be trusted to receive a domain-bound interaction. Definitions vary across vendors when they describe how much of the flow is enforced by the OS versus the app runtime, so implementation details should be checked carefully. For adjacent context, NIST SP 800-53 Rev 5 Security and Privacy Controls and the ENISA Threat Landscape both reinforce why tightly scoped trust paths reduce misuse of authentication artifacts.
The most common misapplication is treating Associated Domains as a generic security feature, which occurs when teams register broad domains or reuse configuration across unrelated apps.
Examples and Use Cases
Implementing Associated Domains rigorously often introduces deployment friction, requiring organisations to balance smoother sign-in journeys against stricter domain ownership checks and certificate hygiene.
- An iOS app uses an associated domain to open a magic link in the correct app instead of a phishing lookalike browser page, preserving the intended login flow.
- A consumer app binds passkey sign-in to its verified web domain so the credential challenge returns to the right origin after browser interaction.
- An internal workforce app uses domain association to route OAuth authorization codes back to a trusted native client rather than a malformed redirect target.
- A product team separates production and staging domains to prevent a test build from receiving production authentication callbacks, reducing accidental trust leakage.
- Security teams review the domain association file and redirect chain during release validation, using guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls alongside NHIMG research such as the DeepSeek breach analysis to understand how weak trust boundaries can cascade into broader identity exposure.
Why It Matters in NHI Security
Associated Domains sits at the boundary between user trust and machine-to-machine trust, which makes it easy to overlook until an attacker exploits a misbound flow. If the mapping is too broad, a malicious or compromised app can intercept login redirects, harvest session artifacts, or redirect users into credential theft. If it is too narrow or broken, legitimate authentication fails and teams create insecure workarounds that bypass the intended control.
In NHI operations, this becomes especially important when secrets, tokens, and passkeys must move across app and web surfaces without exposing replay opportunities. NHIMG research shows how quickly exposed credentials can be abused: attackers may attempt access within 17 minutes of public AWS key exposure, and in some cases as quickly as 9 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs. That urgency is one reason trust-boundary mistakes are operational, not theoretical.
Organisations typically encounter the consequences only after a redirect hijack, login failure, or credential replay incident, at which point Associated Domains becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Domain-bound app trust helps prevent redirect abuse and credential interception. |
| NIST SP 800-63 | Digital identity guidance supports secure binding of authenticators to relying parties. | |
| NIST CSF 2.0 | PR.AC-1 | Identity and access policies depend on trustworthy authentication routing. |
| NIST Zero Trust (SP 800-207) | Zero trust requires explicit verification of each trust edge, including app-web handoff. | |
| NIST AI RMF | AI-assisted identity flows still need risk controls for routing and credential exposure. |
Ensure associated domains only route authentication to the intended relying party and app origin.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
