The device isn’t the problem anymore. The identity might be.

The Question We’ve Been Asking

For years, modern endpoint management has been built around a relatively simple goal:

• Determine whether a device can be trusted.

Whether it’s Workspace ONE, Intune, Jamf, device compliance policies, conditional access, or Zero Trust architectures, the objective is largely the same. Gather enough information about a device to make an informed access decision.

At first glance, that seems perfectly reasonable.

A managed device is generally safer than an unmanaged device. A compliant device is generally safer than a non-compliant device. The more confidence an organization has in the endpoint, the more confidence it has in the access request.

But what if we’re starting to ask the wrong question?

Over the last few years, attackers have increasingly shifted their focus away from devices and toward identities. Session theft, token theft, phishing-resistant authentication bypasses, adversary-in-the-middle attacks, and compromised credentials have become common attack paths. Meanwhile, identity platforms have become increasingly sophisticated in how they evaluate trust. Authentication strength, user risk, behavioral analysis, session controls, and continuous verification now play a significant role in access decisions.

Even the browser is becoming part of the conversation. Features such as Microsoft Edge for Business Device Signals and Google Chrome Enterprise Device Signals allow identity providers to consume device trust information directly during authentication. Taken individually, none of these developments seem particularly significant.

Taken together, they raise an interesting question:

• Are we moving toward a future where device trust becomes just one signal among many rather than the primary source of trust itself?

The Rise of Device Trust

The rise of device trust wasn’t an accident. As organizations moved away from traditional network boundaries and users began accessing resources from anywhere, security teams needed a new way to determine whether an access request should be trusted.

The device became the answer.

If a device was enrolled, compliant, encrypted, and managed according to corporate standards, it was generally considered lower risk than a device that wasn’t. This approach worked remarkably well. Modern UEM platforms evolved beyond simply deploying applications and enforcing passcodes. They became trust providers. Device posture, compliance status, certificates, and management state became key inputs for access decisions.

Identity platforms followed the same path.

Conditional access policies began asking questions such as:

• Is the device managed?
• Is the device compliant?
• Does the device possess a valid certificate?
• Is the operating system approved?

If the answers were acceptable, access was granted. For years, this model formed the foundation of modern endpoint security.

The assumption was simple:

• If the device can be trusted, the access request can probably be trusted as well.

For a long time, that assumption was difficult to argue with.

The Threat Landscape Changed

The problem isn’t that device trust stopped working. The problem is that attackers adapted. Many of today’s most successful attacks don’t require compromising the endpoint at all. Instead, they focus on the thing that ultimately matters most: the identity.

• A user clicks a phishing link.
• An attacker captures a session token.
• An OAuth application receives consent it shouldn’t have.
• A legitimate account is compromised through social engineering.

In many of these scenarios, the device itself may be completely healthy.

• The device is managed.
• The device is compliant.
• The device is encrypted.
• Every dashboard is green.

Yet the attacker still gains access. That’s what makes this shift so interesting. The organization trusted the device and yet the attacker used the identity. At some point, the security conversation quietly started moving away from endpoint health and toward identity assurance. Not because devices became unimportant, but because identities became more valuable.

The Browser Changes the Conversation

One of the more interesting developments over the last few years isn’t coming from traditional device management platforms. It’s coming from the browser. Historically, trust flowed from the device management platform to the identity provider. A device enrolled into Workspace ONE, Intune, Jamf, or another management platform would report its compliance status. That information would then be consumed by an identity provider to make an access decision.

The process was relatively straightforward.

• Manage the device.
• Determine compliance.
• Grant or deny access.

But browser-based device signals are starting to blur those lines. Features such as Microsoft Edge for Business Device Signals and Google Chrome Enterprise Device Signals allow identity providers to consume trust information directly during authentication. More recently, Omnissa Access has begun integrating these capabilities as additional signals that can be evaluated as part of an access policy.

At first glance, this may seem like a minor technical enhancement. I’m not convinced it is. What’s interesting isn’t the signal itself. What’s interesting is where trust is being evaluated. The conversation is no longer happening exclusively between the device management platform and the access platform. The browser has become part of the trust chain. The identity provider has become the decision engine. And the device is increasingly becoming one of several contributing factors rather than the sole source of trust. That’s a subtle but important distinction.

For years, the endpoint sat at the center of the trust model. Today, identity platforms can evaluate authentication strength, user risk, location, session context, browser signals, device posture, and behavioral indicators simultaneously before granting access.

The device still matters. But it is no longer the only thing that matters. And perhaps more importantly, it may no longer be the thing that matters most.

The Compliance Paradox

Imagine a user signs in from a device that is fully compliant.

• The latest operating system is installed.
• Encryption is enabled.
• The device is managed.
• Every compliance policy passes.
• Every dashboard is green.

By traditional measures, this is exactly what we want. Now imagine that same user falls victim to a sophisticated phishing attack. A session token is stolen. The attacker never compromises the endpoint. They never remove the management profile. They never disable encryption or uninstall the management agent.

The device remains fully compliant. Yet the attacker still gains access. That’s the paradox. Many of today’s most successful attacks aren’t targeting the device. They’re targeting the identity. The device may still be trusted. The identity is not.

The End of Device Trust?

To be clear, this isn’t an argument against device management.

• Devices still matter.
• Management still matters.
• Compliance still matters.

In fact, many of the signals being used by modern identity platforms still originate from device management platforms. The difference is where those signals are being evaluated. Increasingly, trust decisions are being made at the identity layer.

• Authentication strength.
• User risk.
• Session context.
• Behavioral analysis.
• Browser-based device signals.
• Device posture.

All evaluated together to determine whether access should be granted. Perhaps that’s the real shift we’re witnessing. Not the end of device management, not the end of compliance, not even the end of device trust. But the end of device trust as the primary source of trust.

For years, the question was:

• Can this device be trusted?

As identity platforms become more sophisticated and attackers continue to focus on identities rather than endpoints, the question may be changing.

• Can this identity be trusted right now?

That may seem like a subtle distinction. I’m not convinced it is.