Overview
Conventional password-plus-OTP or push MFA was designed to reduce the risk of a stolen password. It adds another factor, but manually entered codes and approval prompts are not inherently bound to the legitimate service. Attackers can relay OTPs through adversary-in-the-middle phishing, pressure users with repeated push requests, or steal a bearer session after authentication.
Device-bound authentication changes the credential itself. A device-bound passkey keeps its private key in a particular authenticator—such as a security key, TPM, or Secure Enclave—and does not allow that key to be exported or synchronized. WebAuthn also binds each authentication assertion to the relying party and a fresh challenge, making the authentication ceremony phishing-resistant and replay-resistant.
Those protections stop credential phishing and copying of the private authentication key. They do not automatically make every resulting application session device-bound. Many applications still use bearer session cookies that may be replayable if stolen. Protecting those sessions requires separate measures such as short lifetimes, risk-based reauthentication, proof-of-possession, or device-bound session credentials.
Device binding is also not the same as managed-device trust. A non-exportable credential can exist on an unmanaged personal device. Attestation may provide evidence about the authenticator's provenance and security properties at registration, while current compliance—such as patch level, disk encryption, or endpoint-agent health—comes from separate device-management and posture signals.
Five controls that answer different questions
- User presence. Did a person perform an authorization gesture, such as touching a security key?
- User verification. Did the authenticator locally verify the user with a biometric, PIN, or equivalent method?
- Credential binding. Is the private authentication key non-exportable and limited to a particular authenticator?
- Managed-device trust. Does the organization recognize, manage, and currently trust the endpoint using the credential?
- Session binding. After authentication, must the client continue proving possession of a cryptographic key, or is a bearer cookie sufficient?
How the controls compare
| Control | What it establishes | Phishing-resistant | Stops replay of a stolen bearer session |
|---|---|---|---|
| Password plus OTP | Knowledge of a password and access to an OTP source | No | No |
| Password plus push | Knowledge of a password and ability to approve on an enrolled authenticator | Not necessarily | No |
| Synced passkey | Possession of a passkey available through its provider plus local authorization | Yes | No |
| Device-bound passkey | Possession of a non-exportable credential key in a particular authenticator | Yes | No |
| Managed-device conditional access | The endpoint satisfies organizational registration and posture policy | Depends on the authentication method | No |
| Device-bound session | Continued possession of a session-specific cryptographic key | Not an authentication method | Reduces replay risk when correctly implemented |
Attack coverage
- Credential phishing and relay. WebAuthn uses verifier-name binding so an impostor site cannot obtain an assertion valid for the legitimate relying party.
- Prompt fatigue. Passkey authentication removes the reusable push-approval pattern that attackers can repeatedly trigger.
- Authentication replay. A fresh server challenge makes a captured WebAuthn assertion unusable for a later authentication ceremony.
- Session-token theft. Treat this as a separate post-authentication risk. Device-bound credentials do not transform an ordinary bearer cookie into a device-bound session.
- Unmanaged-device access. Enforce this through device registration and conditional-access policy; credential binding alone does not prove that IT manages the endpoint.
What to evaluate
- Required assurance. Decide which roles need device-bound passkeys and where enterprise-controlled synced passkeys provide sufficient assurance.
- Attestation policy. Document whether attestation is requested, which trust roots and authenticator models are accepted, how privacy is protected, and what happens when attestation is unavailable.
- Managed-device recognition. Define how MDM enrollment, device certificates, platform attestation, or another registration mechanism identifies approved endpoints.
- Posture freshness. Specify which signals are evaluated, how current they must be, and whether missing or stale posture causes denial, step-up authentication, or a limited session.
- Session protection. Assess cookie lifetime, token storage, reauthentication, anomaly detection, revocation, and any proof-of-possession or device-bound session mechanism.
- Recovery and replacement. Keep lost-device recovery phishing-resistant and make credential revocation, replacement, and audit evidence explicit.
- Exceptions. Design controlled paths for BYOD, contractors, shared devices, break-glass access, and platforms without supported hardware protection.
How to use this resource
Use this explainer to align security, IT, and procurement stakeholders on what conventional MFA, device-bound credentials, managed-device posture, and session binding each protect. Turn the distinctions into measurable acceptance criteria for an Identity and Endpoint Management proof of concept.