Device binding ties a credential or session to a specific physical device so that stealing the credential alone is not enough; the attacker would need the hardware too. Bindings range from cryptographic (a key held in the device's secure element) to network-level (the carrier confirming which device holds a line).
The strength of a binding is the strength of what holds the key. A key in a hardware secure element cannot be copied by software running on the same machine; a key in application storage can. Both are described as device binding, and the difference decides whether malware on the device defeats it.
The term covers a wide range of strengths, which is why it is worth asking what specifically holds the key and what an attacker would need to extract it. A key in a hardware-backed secure element resists software running on the same device; a key in application storage protected by obfuscation does not, and both ship under the same phrase in product copy.
Network-level binding answers a different question from cryptographic binding. A secure element proves that this device participated; a carrier confirming which handset currently holds a line proves something about the channel attached to the account, which is the fact a stolen credential cannot supply. Pairing them covers more than either does alone, which is the argument behind number verification.
Binding also has a lifecycle that deserves as much attention as its strength. Enrolling a new device, replacing a lost one and unbinding an old one are all paths that must not become the weak link, and they usually run through the same recovery flow that account recovery fraud targets.
Asking what specifically holds the key, and what an attacker would need to reach it, is a question with a concrete answer that product copy rarely contains.
Related terms
PasskeyBridge verifies identity signals like these inside the request, with zero PII stored. See how the platform works or test the live API.