Security teams should use delegated authentication, where the browser starts the flow and a trusted native client performs the device ceremony on its behalf. The design should keep sensitive material out of the browser, require user confirmation, and bind the exchange to the same machine and session. That combination preserves device trust without weakening browser isolation.
Why Browser-Bound Device Trust Needs a Delegated Model
When a web application needs to trust a device, the browser is usually the wrong place to hold that trust anchor. Browsers are intentionally isolated from hardware-backed keys and from the operating system ceremonies that prove local device possession. A delegated model lets the browser initiate the exchange while a native client, companion app, or platform broker performs the cryptographic step that the browser cannot do safely on its own.
This matters because device trust is not just another login feature. It is a way to reduce impersonation, strengthen conditional access, and keep sensitive material out of scriptable browser state. If teams try to force browser-only proofs, they often end up weakening isolation, storing reusable secrets in unsafe locations, or accepting signals that can be replayed across sessions. Current guidance suggests that the trust decision should be tied to a real machine, a real user action, and a short-lived exchange rather than a persistent browser token. In practice, many teams discover the flaw only after they have already built a browser flow that can be copied, proxied, or reused outside the intended device boundary.
The core design question is therefore not whether the browser can “do device trust,” but how it can safely hand off to a trusted local component without losing the binding to the user session.
See also Ultimate Guide to NHIs.
How Delegated Authentication Preserves the Device Signal
In practice, delegated authentication splits the flow into two parts. The browser remains the user-facing start point, handling discovery, redirects, and session state. A native client, operating-system service, or enterprise broker then performs the device ceremony using hardware-backed keys, platform attestation, or a local trust check that the browser cannot access directly. The result is a proof that is stronger than a browser-held secret but still usable in a web application.
The key implementation principle is to make the browser a coordinator, not a custodian. Sensitive material should stay in the native trust boundary, and the browser should receive only a bounded assertion that can be validated by the server. That assertion should be short-lived, single-purpose, and tied to the same session context so it cannot be replayed from another machine or reused after the user’s original interaction. For higher assurance, teams often combine this with user presence, device binding, and policy checks that confirm the machine is enrolled and in a known state.
- Start the flow in the browser, but complete the cryptographic proof in a native or platform-managed component.
- Bind the returned assertion to the current session, origin, and device context.
- Prefer ephemeral proofs over long-lived browser tokens or stored secrets.
- Require user confirmation where the device ceremony could otherwise be triggered silently.
- Log the handoff and validation steps so the trust decision is auditable.
For implementation detail on machine-identity and secret-handling patterns, Ultimate Guide to NHIs — Key Challenges and Risks is a useful reference. This model breaks down when the native client cannot reliably establish local possession, because the web tier then has no durable way to distinguish a real device ceremony from a relayed or automated request.
Common Variations, Trade-offs, and Failure Boundaries
Tighter device binding often improves assurance, but it also raises deployment and support overhead, so teams have to balance security strength against user friction and platform complexity. The exact pattern varies by environment: managed endpoints may support richer attestation, while bring-your-own-device fleets often need a lighter assertion model and stronger server-side policy checks.
There is no universal standard for this yet, so teams should treat the native client as an assurance layer rather than a universal identity source. If the local component can be removed, disabled, or replaced without the server noticing, the trust model is too weak. If the browser can replay the assertion outside the original session, the binding is too loose. And if user consent is reduced to a one-time enrollment step, the ceremony may be technically sound but operationally hollow because it no longer reflects a current, intentional action by the user.
What practitioners underestimate: the hardest part is usually not the cryptography, but the lifecycle. Device trust has to survive browser updates, client revocation, endpoint re-enrolment, and recovery from lost or replaced hardware without creating a permanent bypass path.
Practitioner takeaway: Design for a verifiable handoff from browser to native trust boundary, then make the server enforce short-lived, session-bound proofs so the device signal remains meaningful even when the browser cannot touch the hardware key directly.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Inventory and Ownership | Device trust depends on controlled machine-bound identities and their ownership. |
| NHI-03 — Secrets and Credential Management | The pattern avoids exposing reusable credentials in the browser. | |
| Recommendation — Inventory device-bound identities and assign clear ownership before allowing delegated trust. Keep hardware-backed credentials out of browser storage and use short-lived proofs only. | ||
| OWASP Agentic AI Top 10 | A2 — Identity and Access Control | Browser-to-native delegation is an access-control design for autonomous client flows. |
| Recommendation — Bind delegated assertions to session context and enforce least-privilege validation at the server. | ||
| CIS Controls v8 | 6 — Access Control Management | Device trust should restrict access based on verified device and user state. |
| 8 — Audit Log Management | Delegated trust flows need auditable evidence of the handoff and validation steps. | |
| Recommendation — Restrict web app access to devices that pass a verified local trust ceremony. Log device ceremony outcomes and assertion validation for later review and incident response. | ||
| NIST Zero Trust (SP 800-207) | SC-4 — Policy Decision and Enforcement | Device trust is strongest when policy evaluates each access request in context. |
| Recommendation — Evaluate each delegated trust assertion against current policy and session context before granting access. | ||
Related resources from NHI Mgmt Group
- How should security teams bound delegated AI agent sessions so the agent cannot exceed the human's access or its own defined scope?
- How should security teams implement Zero Trust access when policy must satisfy federal cybersecurity mandates?
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams prevent a channel member from using an AI agent to reach resources they cannot access directly?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
