# Device Trust: Why MFA Alone Isn't Enough

> Stolen sessions walk past MFA, so device trust became the answer. But device registration is self-service and compliance is self-reported. Here is what holds.

By Lucas · August 28, 2026 · 12 min read · Business

Source: https://bluwarden.com/blog/device-trust-what-it-actually-stops

---

There is a kind of incident that looks like nothing at all in the logs. Correct password. MFA satisfied. A sensible IP address. A browser the tenant has seen a hundred times. Every signal the identity platform is built to check comes back green, and the person whose account it is has not touched a keyboard all morning.

Nothing was broken to get in. The attacker held a valid session, and every trust signal in that list is just data that can be presented by whoever holds it.

That is the argument for device trust, and it is a good argument. It is also where most write-ups stop, which is the problem, because device trust as it ships by default is considerably weaker than it sounds. This post covers what it genuinely stops, what it does not, and the handful of settings that separate the two.

---

## Where credential attacks actually sit in 2026

Two things are true at once, and most articles quote only the half that suits the pitch.

The first: credentials lost the top spot this year. The [Verizon 2026 DBIR](https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/) found vulnerability exploitation overtook credential abuse as the leading initial access vector for the first time in the report's 19-year history, with exploitation at 31% of breaches and credential abuse [falling from 22% to 13%](https://www.descope.com/blog/post/verizon-dbir-2026).

The second: that is a statement about the front door, not the rest of the house. Counted anywhere in the breach chain rather than just at the entry point, credential abuse still appears in 39% of breaches, and credentials show up as compromised data in 28%. Flashpoint counted [1.7 billion credentials harvested by infostealers](https://www.infosecurity-magazine.com/news/infostealers-17-billion/) from 7.4 million infected hosts in the first six months of 2026 alone, a 27% rise in infected hosts over the previous half-year.

So the accurate framing is not "attackers log in, they don't break in". It is narrower and more useful: **attackers are now more likely to get their first foothold through something unpatched, and then use credentials and stolen sessions to turn that foothold into a breach.** Identity is not the only perimeter. It is the thing that decides how far an intrusion travels once it starts, which is why it still deserves the attention. The [techniques doing that travelling](/blog/what-actually-breaks-company-security-2026) - adversary-in-the-middle proxies, session cookie theft, infostealer logs - have not changed much. Their supply has just become effectively unlimited.

---

## Phishing-resistant MFA is necessary, and it is not a finish line

The standard advice is to move critical accounts to FIDO2 or passkeys, and it is correct. A WebAuthn credential is bound to the real origin, so an adversary-in-the-middle proxy sitting on a look-alike domain cannot get a usable assertion out of it. That is a real cryptographic property, not marketing, and nothing about the attacks below changes it. If you take one thing from this post, take that one: [phishing-resistant factors first](/blog/password-best-practices-2026), on admin, finance and email accounts.

What is wrong is the sentence that usually follows: that phishing-resistant MFA is the end of the conversation. Attackers have not broken the cryptography. They have gone around the flows that surround it.

**Cross-device sign-in abuse.** FIDO's hybrid transport lets you sign in on a desktop by scanning a QR code with the phone that holds your passkey. The PoisonSeed operators [relayed that QR code through a phishing page](https://thehackernews.com/2025/07/poisonseed-hackers-bypass-fido-keys.html), so the victim scanned a genuine code presented by an attacker. It works when proximity checks such as Bluetooth are not enforced. Worth noting honestly, since the headlines were louder than the finding: Expel retracted its original write-up in July 2025 after establishing that the subsequent MFA challenges failed and the attackers did not get access. The technique is real, the "FIDO bypassed" framing was not.

**Downgrade to a weaker method.** Proofpoint demonstrated an Evilginx phishlet that [spoofs an unsupported user agent](https://www.bleepingcomputer.com/news/security/new-downgrade-attack-can-bypass-fido-auth-in-microsoft-entra-id/) - Safari on Windows - so Microsoft Entra ID disables FIDO and offers a fallback such as an authenticator code, which the proxy then relays. Microsoft's position is that this is not a product vulnerability, and there is no confirmed in-the-wild use yet. The lesson stands regardless: **a phishing-resistant method you can fall back from is only as strong as the weakest method still enabled on the account.**

**Device code phishing.** Microsoft's Storm-2372 campaign, [documented in February 2025](https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/) and later reassessed as an initial-access sub-cluster of Midnight Blizzard, abuses the OAuth device authorisation flow. The victim authenticates on a genuine Microsoft page and enters a code the attacker generated, and the attacker collects the resulting access and refresh tokens. MFA does not help, because MFA succeeded. This is the one people miss, and it is not fixed by better factors - it is fixed by blocking the flow.

The pattern across all three: the credential held, and the process around it did not. Removing fallback methods, enforcing authentication strength in Conditional Access, and blocking device code flow are configuration decisions, not product purchases.

---

## What device trust actually means

The idea comes out of zero trust, and it predates the current marketing by some years. [NIST SP 800-207](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf), published in August 2020 as guidance rather than a standard, sets out seven tenets. Two matter here: access is determined by dynamic policy "including the observable state of client identity, application/service, and the requesting asset", and the enterprise "monitors and measures the integrity and security posture of all owned and associated assets" with no asset inherently trusted.

In practice that becomes a Conditional Access rule of the form "this resource requires a device that is registered or joined to our tenant and reported compliant by our MDM". The reasoning is that a password can be bought and a session cookie can be stolen, but a physical managed laptop cannot be posted to an attacker in Belarus.

That reasoning is sound. Whether your implementation delivers it is a separate question.

---

## The part most write-ups skip: device trust is forgeable by default

Cyderes published research showing how [a device-based Conditional Access policy can be defeated with credentials alone](https://www.cyderes.com/howler-cell/azure-ad-conditional-access-device-identity-abuse). The mechanism is worth understanding, because the fix follows directly from it.

The Device Registration Service does not verify that the caller is a real Windows machine. It verifies the token. Using the open-source `roadtx` tool, an operator with a valid username, password and satisfied MFA can register a device that exists only as an RSA keypair and a certificate. No TPM, no hardware, no administrator approval. That certificate then mints a Primary Refresh Token carrying `deviceid` and `amr: rsa` claims, and every policy demanding a joined or compliant device evaluates the resulting token as satisfied. Direct authentication was blocked; the token-derived path was not.

Two further gaps make it worse. Intune enrollment restrictions exempt devices that claim hybrid domain-join status, without checking whether the machine exists in on-premises Active Directory. And device compliance is largely **self-reported**: Intune treats a missing response as "not applicable" rather than "non-compliant", so a Linux host returning empty values for BitLocker, Secure Boot and TPM attestation can come back marked compliant.

Be fair about the limits of this. It requires valid credentials to begin with, so it is a control bypass rather than a way to conjure access from nothing. But that is exactly the scenario device trust was bought to handle. A control that fails precisely when its threat model arrives is worth knowing about before you write it into your architecture diagram.

---

## What makes device trust hold

None of this argues against device trust. It argues against deploying it as a checkbox and assuming the checkbox is a wall. The difference between a signal an attacker can assert and one they cannot comes down to whether hardware is involved in the claim, and whether registration is a privilege or a self-service default.

| Control | What it changes |
|---|---|
| **Require MFA for device registration, and restrict who may register** | Removes registration as a free action available to any credential holder |
| **Require TPM 2.0-backed device identity for PRT issuance** | Makes the device claim depend on hardware the attacker does not have |
| **Device Health Attestation instead of self-reported compliance** | Compliance is validated externally rather than asserted by the endpoint |
| **Autopilot or pre-registered hardware hashes for enrollment** | Closes the hybrid-domain-join exemption that enrollment restrictions leave open |
| **Block OAuth device code flow in Conditional Access** | Removes the token-harvesting path that MFA cannot see |
| **Move report-only policies to enforced** | A measurement tool is not a control, however good the dashboard looks |

The last row is the one that quietly catches most organisations. Report-only mode is the right way to test a policy and the wrong way to leave it. Every policy in report-only needs an enforcement date attached to it.

---

## Bind the session, not just the sign-in

Device trust evaluated once, at sign-in, still leaves the stolen-cookie problem untouched. Three mechanisms address it, and all three have limits worth knowing before you promise them to anyone.

**Entra token protection** ties sign-in session tokens to the device that obtained them, so a replayed token from elsewhere fails. Read the [support matrix](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection) before relying on it: it is generally available for native applications on Windows, iOS and macOS covering Exchange Online, SharePoint Online, Teams, Azure Virtual Desktop and Windows 365. Browser-based support is still in preview and limited to selected web apps reaching Azure Resource Manager. That is a meaningful control for desktop Office clients and close to nothing for the browser, which is where session theft usually lands.

**Continuous access evaluation** is generally available and revokes access near real time on five critical events: the account being deleted or disabled, a password change or reset, MFA being enabled, an administrator revoking refresh tokens, and high user risk from ID Protection. [Microsoft's documentation](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation) puts event propagation at up to 15 minutes, and notes that CAE only has insight into IP-based named locations, not country or region conditions. CAE-capable clients also receive long-lived tokens of up to 28 hours, so it is a trade: faster revocation on specific events, longer tokens in between.

**Chrome's Device Bound Session Credentials** is the development the current crop of device-trust articles has largely missed. Since [Chrome 146 on 10 April 2026](https://www.helpnetsecurity.com/2026/04/10/google-chrome-device-bound-session-credentials/), Chrome on Windows can bind a session to a key pair held in the TPM, with macOS and the Secure Enclave following. Google is [explicit about the boundary](https://blog.google/security/protecting-cookies-with-device-bound-session-credentials/): malware on the machine can still read cookies out of local storage, but the exfiltrated cookie is useless elsewhere without the non-exportable private key. It requires the site to add registration and refresh endpoints, so its usefulness to you depends entirely on whether the services you care about have implemented it. Ask your SaaS vendors. It is a reasonable thing to have on a renewal checklist this year.

---

## What to do, in order

- **Enforce authentication strength, and remove the fallbacks.** Phishing-resistant methods on admin, finance and email accounts first, with weaker methods disabled on those accounts rather than merely deprioritised.
- **Block device code flow** for everyone who does not demonstrably need it. This is a single Conditional Access policy and it closes a route that MFA cannot see.
- **Make device registration a privilege.** Require MFA to register, restrict who can, and alert on new device registrations. Treat an unexpected registration as an incident, not an inventory update.
- **Check whether your compliance is attested or asserted.** If Intune is reporting compliance from values the endpoint supplies about itself, you have a reporting system rather than a control. Health attestation and TPM-backed identity change that.
- **Enable token protection where it genuinely applies,** which today means desktop clients, and do not describe it internally as browser session protection.
- **Turn on CAE and shorten admin sessions,** accepting the 15-minute propagation window as the realistic figure rather than "instant".
- **Give every report-only policy an enforcement date.**
- **Ask your SaaS vendors about DBSC support** at renewal, and prefer same-device sign-in over QR-based cross-device flows where you can configure it.

Most of this is configuration you already own. The spend, if there is any, is on hardware attestation and on the time to test policies without locking out the finance team on a Friday afternoon.

---

## Summary

1. **Credentials are no longer the top initial access vector, but they still carry the breach.** Exploitation leads at 31%; credential abuse appears in 39% of breaches somewhere in the chain.
2. **Phishing-resistant MFA is necessary and not sufficient.** Cross-device QR relays, user-agent downgrade to weaker fallbacks, and device code phishing all work without touching the cryptography.
3. **Disable the fallbacks and block device code flow.** A strong factor with a weak alternative still enabled is worth roughly the weak alternative.
4. **Device trust is forgeable by default.** Device registration validates a token, not a machine, and Intune compliance is largely self-reported.
5. **Hardware is what makes the device claim real.** TPM-backed identity, health attestation and pre-registered hardware hashes turn an assertion into evidence.
6. **Restrict and monitor device registration.** An unexpected device registration is one of the highest-signal alerts available in an identity estate.
7. **Session binding is arriving but is not universal.** Entra token protection is desktop-first, CAE covers five events with a 15-minute window, and Chrome DBSC needs the service to support it.
8. **Report-only is not enforcement.** Give every policy a date.

---

*This is general guidance, not an assessment of your tenant. Identity misconfiguration is the kind of thing that reads as fine in a policy list and fails in a test - a [security assessment or phishing simulation](/blog/phishing-simulation-why-companies-need-it) will tell you which of the policies above are actually holding in your environment. See [what we do](/#services), then [get in touch](/#contact).*