For years, cybersecurity has shifted from network perimeters to identity first approaches. Zero Trust calls for verifying identity before every access, and the industry embraced this idea and tried to implement it, or at least set it as an objective for the future.
As identity became the focus of defense, attackers adapted to it. Identity based attacks now dominate. Sixty percent of cyberattacks succeed by breaking identity. This is negative, but it also shows that the industry has worked hard, pushed Zero Trust forward, and invested heavily in identity-based defense.
But it leads to the question that starts it all:
Is identity first a bad idea?
The answer is no. It is not a bad idea. It is a good idea.
However, we have found a few shortcomings in how the industry approaches identity first, and even how the industry understands it. So we should begin with the most basic question, which is rarely asked:
Identity first. Yes. But which identity?
Today’s solutions verify the user yet give access to the device. By not granting access to the specific object that was verified, these systems demonstrate that their definition and application of identity are incorrect.
The industry made two foundational mistakes.
- Identity was never clearly defined.
Accounts, credentials, machine identity, and now AI agents were used in various ways, but the actual identity object was never defined. - Identity’s purpose was not always clear.
Identity has two roles:
- the object systems verify, and
- the object they give access to
These must be the same. If they are different, the identity model is wrong.
This mismatch has real consequences, as seen in push attacks. The definition, and how it is used, must be clear and applied in practice.
Login and Session
There are more issues hidden in the current approach. Some are understandable because they were the best options available without a complete identity model.
Let us look at the two separate cases the industry created:
The current approach:
| What are we securing | The identity to verify | How to verify that identity |
| Login | User | User login, traditional MFA, Passkeys |
| Session (after login) | Endpoint | Verify the session token. If the endpoint has the token, it is verified. The industry added OAuth tokens, token and channel binding, holder of key assertions, DBSC, and similar methods to make this stronger. |
What were we trying to do in the first place?
The basic idea is simple. It is also the idea Zero Trust repeats:
Verify identity before giving access or data.
Because verifying the user before every session, or every transaction, is not practical, systems split the problem into two parts:
- Login: verify the user once
- Session: give access to the device
These two flows look different, but they come from the same need.
And because verifying the device using a session token is weak, attackers have focused on it, and this area has received more attention. The industry has worked on token and channel binding standards, but they are complex, and the problem is not fully solved.
The good approach:
| What are we securing | The identity to verify | How to verify / uphold that identity |
| Login & Sessions (post-login) – Verify identity before giving access. Each transaction must include identity assurance. | User x device x conditions (More generally: Actor – human, machine or AIagent – x execution platform x conditions) | Identity is verified at endpoint login (OS login, MFA). Thereafter, the endpoint upholds the required conditions, so identity assurance remains available without user interaction. Each transaction inherits that assurance. |
Identity in the Online World
Identity has often been misunderstood because we carried assumptions from the physical world into the online world. In the physical world, identity belongs to the person. Online, it is different.
Online identity must represent the full entity that performs actions. That entity is not just the user. It is composed of three parts:
- The actor. This can be a human, a machine, an application, or an AI agent.
- The execution platform. This is the endpoint or environment where the actor operates.
- The conditions. These are the requirements that keep the platform trusted, such as posture, policy, and context.
All three parts are needed. They determine who should be verified and who should be given access.
This becomes clear when we look at common situations. Would you give access to an authentic user if the device is compromised? Or if the user and device are in a prohibited location? The answer is no. These examples show why identity must include the platform and the conditions. Without them, the system is verifying only a small part of the real identity.
This definition is not theoretical. It is the identity object that systems must verify, give access to, and manage through its lifecycle.
Today’s solutions verify the user, then give access to the device. That mismatch is real, and we see the outcome in push attacks. Verification and access must refer to the same identity object. When they do not, the model is incomplete.
Passkeys: Real Progress Within Today’s Model
Passkeys are real progress. They use strong cryptography and remove many identity-based attacks at the login. Stolen credentials, phishing, and replay become harder. With broad adoption, these attacks should decrease. The direction is correct.
Passkeys also verify the user more effectively than traditional MFA. They strengthen the verification step at login, and this is important.
However, Passkeys still follow a usercentric model and verify a single moment.
A stronger identity must hold across the timeline of actions.
And once identity is defined correctly, another limitation becomes clear: the same user needs distinct identities on different devices, because the execution platform and its conditions differ. These perdevice identities must be managed on the server through their lifecycle. Passkeys do not model these distinctions. Even with secure enclaves or synced credentials, Passkeys remain usercentric rather than “user on this device, under these conditions.”
Passkeys also do not address the session. This is expected because it was not their original goal. Passkeys were designed for login, not for continuity of identity during access. But now that we understand login and session are two attempts to solve the same issue, this becomes a limitation.
There are ways to address both login and session with one correct identity model. We will come back to this later.
The Endpoint
With the correct identity definition, the role of the endpoint becomes clear. Every online action begins on an endpoint. It is the only place where the actor, the platform, and the conditions can be observed together.
The endpoint knows who is present and how the device is being used. It knows whether the platform remains trusted. It also knows whether the required conditions continue to hold. These are the parts of identity that matter for access, and the endpoint can uphold them directly. When those conditions remain true, identity remains valid; when they change, identity assurance becomes unavailable.
Because conditions are enforced locally, updates are eventdriven and realtime (not polling).
Transactions carry identity assurance, so each request naturally reflects the same verified identity while conditions hold.
This also reduces the need for user prompts. The endpoint already tracks local signals such as lock state, usage, posture, and policy. It can maintain identity without asking the user to do anything unless something important changes.
This matches the idea of Zero Trust, which asks for continuous verification of both user and device. With the correct identity definition, these checks are not separate. The platform is verified directly, and the platform verifies the user through its own signals. Identity stays aligned with what is happening on the endpoint, with assurance always available while conditions remain true.
In short, the endpoint is the place where identity can remain correct over time, without additional steps.
Zero Trust
Zero Trust mandates explicit verification and continuous validation. Misinterpreting ‘verify’ and ‘continuous’ often leads to complex polling and intrusive re-authentication. However, when identity is correctly defined as the actor × platform × conditions, the endpoint upholds these requirements automatically. This ensures identity assurance is always available, updating in real-time based on events and attaching to every transaction without repeated user interaction.
A simple example makes this clear. A user may log in with a strong method, but if the device becomes compromised or moves to a location that is not allowed, the identity behind the access is no longer the same. A user only identity cannot represent these changes. An identity built from the actor, the platform, and the conditions can. Trust adjusts naturally.
With the correct identity model, Zero Trust becomes easier to implement. It does not require repeated prompts or separate mechanisms. Assurance stays accurate because conditions are upheld by the endpoint and reflected in the transaction, not because the user is asked again. This resolves the tension many teams feel between strong assurance and user burden and prepares organizations for nonhuman actors that cannot participate in repeated verification steps.
AI Agents and Machine Identity
The same identity model applies to AI agents and machine workflows.
An agent acts on a platform under conditions. If the platform or conditions change, the identity changes. If trust breaks, access stops. No human gestures are required.
The actor changes. The identity model does not.
This prepares organizations for machine-to-machine communication and automated systems without introducing separate identity frameworks.
Closing
Identity first remains the right idea. Attackers focused on identity because identity became the place where trust is decided. Strengthening verification at login helps, and Passkeys improve that step. But verification alone is not enough if the identity object is incomplete.
Defining identity as the actor on a trusted platform under enforceable conditions brings the architecture back into alignment. Login and session no longer require different handling. The endpoint becomes the natural place to uphold identity. Assurance stays accurate without repeating authentication. This is what Zero Trust expects.
The same definition applies to AI agents and machine workflows. Identity does not need a new model. Only the actor changes. One definition can support humans, machines, and automated systems.
With the correct identity definition, identity first becomes practical, continuous, and simpler. The next steps in cybersecurity become easier to see.
About the Author
Thi Nguyen Huu, Founder and CEO of WinMagic Corp. since 1997, is a leading figure in data protection and encryption solutions. His commitment to high standards has propelled WinMagic to the forefront of the industry, delivering innovative and sophisticated solutions that are trusted globally by governments and enterprises.
Under Thi’s leadership, WinMagic has cultivated a culture of continuous innovation and customer focus. His visionary approach and dedication to high standards have raised the bar in disk encryption with notable advancements including PKCS#11 standards, key labeling, MFA, networking at pre-boot authentication and unattended deployment for multi-platforms.
WinMagic’s expertise in securing the endpoint has proven pivotal in solving online access and security. Over the past two years, he advocated that online access can be completely secure without burdening the user — in fact, with no user action at all. In the quest to resolve cybersecurity attacks, Thi has discovered shortcomings in the industry, including a fundamental flaw in protocols that are used trillions of times a day. A correct solution will not only eliminate all cyberattacks today but can do so without user action. Thi appeals to the industry to strengthen TLS, FIDO, federated authentication, and other standards, not only to eliminate current cyber threats but also to build a more secure future by advancing digital security practices.
Thi can be reached online at https://www.linkedin.com/in/thi-nguyen-huu-591bb9/ and at our company website https://winmagic.com/en/home/
