Your identity platform stopped three suspicious logins this morning. Two came from unfamiliar IP addresses. One presented valid credentials and passed Multi-Factor Authentication. All three happened while your users were at their desks, working from their registered devices.
Which one was the real threat?
These questions arise in security team channels, post-incident reviews, and budget planning meetings. They highlight a practical problem: traditional identity signals tell you less than they used to, and your team needs to decide what comes next. Here's what we're hearing from practitioners working through device trust implementation.
Q1: "We already use MFA. Why isn't that enough anymore?"
MFA is a strong control, but it verifies that someone has a second factor, not that they should be logging in from wherever they are.
Attackers bypass MFA through adversary-in-the-middle phishing, which relays credentials and MFA responses to the legitimate service in real time. They also steal session cookies after authentication, skipping the MFA challenge entirely. Push notification fatigue is another vector: users approve prompts without scrutiny after repeated requests.
The gap isn't that MFA failed. It's that MFA alone doesn't confirm whether the login is happening from an approved device in a known state. A valid credential plus a valid MFA response can still originate from attacker-controlled infrastructure.
Q2: "How does device trust actually stop an attack that credentials and MFA don't?"
Device trust adds a binding requirement: access depends not just on what you know or have, but on where you're presenting it from.
When an attacker uses stolen credentials, even with a captured MFA response, they're typically operating from their own infrastructure. That device isn't registered in your identity platform. It hasn't been validated for security posture. It doesn't match the hardware profile your user normally authenticates from.
Earlier this year, IGN's Twitch stream was hijacked using Restream.io credentials that had been sitting in infostealer dumps for roughly a month. The credentials were valid. The attacker knew how to use them. What they didn't have was the device context those credentials were issued to.
If access had been tied to approved hardware, the stolen credentials would've triggered a policy violation instead of a successful login.
Q3: "Our users work remotely and travel. Won't device binding create support tickets every time someone logs in from a hotel?"
Not if you separate device registration from location-based controls.
Device trust doesn't care where the device is. It cares whether the device itself is known and meets your security baseline. Your user can authenticate from a hotel, a coffee shop, or a different country, as long as they're using their registered laptop and it's still in compliance.
NIST SP 800-207 states that organizations should not grant implicit trust based solely on physical or network location. The architecture treats user and device authentication as separate functions that should both occur before access is granted.
The friction comes when someone tries to log in from an unregistered device. That's the scenario where you want friction, because it's also the scenario attackers rely on.
Q4: "What happens if a registered device falls out of compliance mid-session?"
Your response should match the severity of the posture change.
Continuous evaluation means you're not just checking device health at login. You're monitoring it throughout the session. If endpoint protection gets disabled or the device suddenly fails a compliance check, you have options beyond immediately terminating access.
For a missing patch, you might reduce privileges or give the user a grace period to remediate. For disabled antivirus or a rooted device, you block access until the issue is resolved.
The principle is proportionality. A minor configuration drift shouldn't be treated the same way as evidence of compromise. Your policy engine should distinguish between "this needs to be fixed soon" and "this is a blocking condition right now."
Q5: "How do we handle personal devices and BYOD without making registration a compliance nightmare?"
You don't need to apply the same device trust policy to every class of hardware.
Corporate-managed endpoints can require full posture validation: encryption, endpoint detection, patch compliance, the works. Personal devices accessing lower-sensitivity resources might only need basic registration and a health attestation. Contractor or third-party devices might be limited to specific applications with stricter session controls.
The registration process itself should be self-service. Users authenticate, register their device, and confirm it meets the baseline you've defined for that device class. If posture degrades, they get clear remediation steps, not a ticket queue.
Q6: "We're already using conditional access policies. Is device trust really that different?"
Conditional access is the framework. Device trust is one of the conditions.
Most conditional access implementations rely on IP reputation, geolocation, or user risk scores. Those signals still matter, but attackers know how to work around them. Residential proxies, mobile networks, and compromised systems let them present traffic that looks geographically plausible and comes from clean IP space.
Device trust shifts the question from "does this login look suspicious?" to "is this login happening from hardware we've explicitly approved?" That's a harder signal to fake, because the attacker would need to compromise the actual registered device, not just steal the credentials that unlock it.
Where to Go From Here
If your team is asking these questions, you're already thinking past the limitations of credential-based trust. The next step is deciding what your device trust baseline looks like: which devices get registered, what posture checks apply to each class, and how you handle violations without creating operational friction.
Start with your highest-risk access paths: privileged accounts, financial systems, anything touching cardholder data. Extend device binding there first, measure the support impact, and expand the policy as your team builds confidence in the control.
The attacks are already industrialized. Your identity controls need to assume that credentials will be stolen and MFA will be bypassed. Device trust is how you make those compromises insufficient.
