Notifications
Clear all
Topic starter
18/08/2026 2:18 pm
TL;DR: Device binding cryptographically ties authentication to one verified physical device, closing the gap that credential-only MFA leaves open, according to Ory. It matters because banks and regulated mobile-first businesses need assurance that access comes from the approved handset, not merely from a copied credential or synced passkey.
NHIMG editorial — based on content published by Ory: The case for device binding: what it actually protects
Questions worth separating out
Q: How should security teams decide when to use device binding instead of passkeys?
A: Use device binding when policy requires access from one approved handset and the business cannot accept synced credentials across multiple devices.
Q: Why do generic MFA controls leave device risk unresolved?
A: Generic MFA often proves only that a credential was presented from somewhere, not that the approved device was present.
Q: What breaks when passkeys are synced but policy requires one-device access?
A: The authentication layer can become stronger on paper while the governance model becomes weaker in practice.
Practitioner guidance
- Define the device trust boundary first Decide which account types and transaction types must remain on one approved device, then document that boundary in your CIAM policy before selecting an authentication flow.
- Require attestation at enrolment Reject devices that cannot produce validated attestation from Apple or Google, and block emulator-based or tampered-device enrolments from reaching production access.
- Use device binding for high-risk step-up paths Apply the control first to high-value actions such as transfer approval, beneficiary changes, and account recovery so that the strongest assurance protects the riskiest events.
What's in the full article
Ory's full article covers the protocol detail this post intentionally leaves for the source:
- Native app enrolment flow details for iOS and Android, including how the key pair is generated and registered
- Attestation checks and server validation logic that decide whether a device is trusted at login time
- PIN and biometric unlock behaviour, including failure handling and key destruction after repeated wrong attempts
- Platform support notes for iOS and Android SDKs, useful when teams are planning implementation
👉 Read Ory's analysis of device binding and mobile authentication assurance →
Device binding and mobile login: what IAM teams should verify?
Explore further
18/08/2026 3:11 pm
Device binding is a response to the fact that credential possession is not device assurance. A password, token, or code can prove that a secret was presented, but not that the login originated on the approved hardware. That distinction is now central to mobile fraud defence, especially where account takeover often begins with credential replay or support-channel compromise. Practitioners should treat device binding as a control for session origin, not as a replacement for identity proofing.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to the 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which shows how uneven identity assurance still is across machine estates.
A question worth separating out:
Q: Who should own device binding policy and exception handling?
A: CIAM, IAM, fraud, and risk teams should own it together, because the control affects login assurance, customer recovery, and transaction approval. Exception handling must be explicit for older devices, accessibility needs, and regulated recovery scenarios, otherwise users will bypass the policy through unsupported channels.
👉 Read our full editorial: Device binding closes the gap between credentials and hardware
