By Thi Nguyen-Huu, Founder and CEO of WinMagic
1. Why has the cybersecurity industry remained fixated on login events instead of rethinking identity as a continuous process?
Because login was easy to model, and continuous identity was hard to build. A login event has a clean shape—a credential is presented, a server evaluates it, and a token is issued. You can sell it, audit it, and put it on a vendor comparison chart. Continuous identity has no clean shape unless you sit on the endpoint, and the cybersecurity industry made an early decision to live in the cloud, at a distance from the device.
That decision had an economic logic. Server-side software is written once and deployed everywhere. Endpoint software is operating-system-dependent, hardware-fragmented, and expensive to maintain across device generations. So, vendors built around the login moment they could reach and treated everything after login as somebody else’s problem. The result is the architecture we live with now: one industry sells login security—MFA, SSO, passkeys—and a second industry sells session security—risk engines, behavioral analytics, token binding. Both exist because the underlying definition of identity was wrong, and neither side is incentivised to point that out.
The honest answer is that the fixation on login is not a security choice. It is a side effect of where the industry chose to live.
2. In what ways are passwords, MFA, and passkeys incremental fixes masking a fundamentally broken authentication model?
Each one is a real improvement over the thing it replaced, and each one leaves the same architectural error in place. Passwords are a shared secret—anything the user knows, the server also stores, and any party in between can intercept. MFA layered a second factor on top, which closed the easy attacks but kept the model: verify the human at the door, then hand off to a token for the rest of the session. Passkeys finally bound the credential to a device, which is a genuine step forward—but the assertion is still a one-time gesture at login. The session that follows is still carried by a bearer token. The architecture has not changed.
The error these fixes all mask is that authentication is treated as a moment rather than a state. A user is verified at a single point in time and trusted for hours afterward. Attackers learned this long ago. They no longer try to crack passwords or bypass MFA—they wait for the user to complete the credential check, then steal the session cookie that proves it. The destination service cannot cryptographically distinguish between an authorized endpoint and an attacker’s machine presenting that same valid cookie. The mechanism has a name now—adversary-in-the-middle, or AiTM—and it is no longer rare. Tycoon2FA, the phishing-as-a-service kit that Microsoft, Europol, and partners disrupted in March 2026, was reaching more than 500,000 organizations a month at its peak, generating tens of millions of phishing emails monthly, and by mid-2025 accounted for roughly 62% of all phishing attempts Microsoft blocked. None of it required defeating MFA. It required being there when MFA succeeded.
Passkeys do not change that calculus. They protect the login gesture; they do not protect the token handed out after it. I want to be careful about the people building these mechanisms. The engineers working on Passkeys, DBSC, and the broader stack are skilled and thoughtful, and they are working within constraints that make the architectural fix politically difficult. The critique is of the architecture, not of them.
3. What critical flaw persists when systems validate credentials instead of verifying true user identity?
That is a perfect question, and it lets me bring up one of the core ideas behind our approach: even verifying the true user is not enough for the online world. In the real world, a true user is enough—you are physically there, and the room around you is implicit. Online, none of that is implicit. The device, its posture, the conditions of use—they are not the background of identity, they are part of identity itself. The industry has spent twenty years arguing about credentials versus true user identity, as if verifying the human harder is the answer. It is closer to right than verifying a credential—but it is still incomplete. Real identity online is a live equation—the actor, the platform they are operating on, and the conditions of that operation—bound together cryptographically and continuously. Verifying the true user, by itself, still misses two-thirds of what identity actually is online.
And whatever you verify, you verify only once. This is where the session problem lives, and it is the part the industry has neglected because it has nowhere clean to address it. The attacks have moved with the architecture—they exploit the session, not the login. Even passkeys, the strongest login gesture available today, do not change this. A perfect login is still a single moment. Whatever happens next—the user walks away, the screen unlocks for someone else, malware on the same machine quietly exfiltrates the session—the protocol has no way to know. It validated what it was asked to validate, and then stopped looking.
Identity that is verified once and then assumed is not identity in any meaningful sense. It is a guess that ages badly. What systems actually need is identity in the present tense—a continuous, cryptographic statement that the right actor, on the right platform, under the right conditions, is still acting, right now. Not a token that says they were, hours ago.
4. Why does session persistence remain one of the most overlooked vulnerabilities in modern security architectures?
Let me unpack what “session persistence” means, because it is a phrase that can sound benign until you turn it over. It refers to the fact that once you log in, the system trusts you for hours afterward without checking again. The trust window persists. The verification does not.
The comfortable answer for why this is overlooked is usability. Long sessions exist because re-authentication prompts every fifteen minutes were untenable, so vendors stretched session windows to eight, twelve, and twenty-four hours, and everyone agreed to look the other way. That answer is real. It is also partial.
The deeper answer is that the industry cannot solve session persistence from where it currently sits. There are serious efforts underway—Device Bound Session Credentials, CAEP, and earlier work on token binding—and they are all converging on the same instinct: make the token harder to steal, or make stolen tokens easier to detect. Each is a genuine improvement. None of them asks the harder question, which is whether there should be a long-lived identity token at all.
Here is the move the industry has not yet made, and which I think is now overdue to say plainly: stop using the token as the carrier of identity assurance. Tokens are excellent at what they were designed for—stateless coordination between services, request routing, and session continuity as a user-experience convenience. They are not, and never were, a sound foundation for the statement “this is the right user, on the right device, under the right conditions.” A token can carry a reference to that fact. It cannot be that fact. The moment we asked tokens to carry identity assurance, we created the gap modern attackers operate in.
The corrective is not a better token. It is identity that lives where the user and the device actually are—on the endpoint, anchored in hardware, asserted continuously by the protocol rather than handed out at the door and then forgotten. Short sessions only become safe when re-authentication has zero user friction. That is an architectural requirement, not a marketing one.
5. What role does hardware-rooted trust play in closing identity gaps that software-based methods cannot?
If the previous answer’s argument is right—that the industry should stop using the token as the carrier of identity assurance—then the obvious next question is what carries it instead. The answer is hardware.
Software-based credentials can be copied. That is not a flaw in any particular product; it is a property of software. A key held in software can be read by sufficiently privileged code on the same machine, exfiltrated, and replayed elsewhere. Infostealer logs—the raw material of half the credentials traded on the underground today—are built on exactly this primitive. Defenders can make this harder. They cannot make it categorically impossible.
Hardware-rooted trust changes the category. A key anchored in a TPM, or in a secure enclave, or in a similarly protected element, never leaves the hardware. Cryptographic operations happen inside that boundary; only the result comes out. Even an attacker with full administrator rights on the endpoint cannot extract the key—they can only ask the hardware to use it, and only while the policy bound to that key permits use. When the verified user logs out, when the screen locks, or when the device leaves an approved posture, the key becomes structurally unavailable for the next operation. There is no revocation message to send. The capability simply ceases to exist.
That last point is the part that the industry has not articulated clearly. Monitoring observes; absence enforces. CAEP and behavioural analytics observe a session and react when something looks wrong; hardware-rooted, policy-bound keys are enforced by removing the capability the moment conditions fail. The difference is not just speed. It is whether the protection depends on noticing a problem in time, or whether the problem cannot occur in the first place.
The hardware to do this is already deployed. Microsoft has called TPM 2.0 a “non-negotiable standard” for the future of Windows, and that chip ships in virtually every modern Windows endpoint. Apple Secure Enclave, ARM TrustZone, embedded secure elements in mobile and IoT devices—the substrate exists across every major platform. The architectural work is to use it as a continuous trust anchor, not as a place to store one more credential.
6. How do endpoint-based identity models redefine accountability and traceability in cybersecurity incidents?
In today’s token-based systems, audit is a reconstruction performed after the fact. Logs record that a token was issued, used, and expired. Security teams then infer who did what. If the token was stolen, the logs cannot tell them—they only record who appeared to have done what. Forensic certainty is impossible in principle because the protocol does not carry the information needed to provide it.
Endpoint-based identity changes this at the protocol layer. When every action is bound—by the channel it arrived in—to a cryptographic statement about the user, the device, and the conditions, made at the moment the channel was established and continuously enforced by endpoint policy, the question who did this is no longer answered by inference. It is answered by the protocol, and the log is just the record of the answer. Audit becomes deterministic. Accountability stops being a reconstruction and becomes a property of the system itself.
This matters far beyond breach forensics. It matters for compliance frameworks—CMMC, SOC 2, FedRAMP, NIST 800-53—which all rest on the assumption that logs can establish what happened. It matters for insider-threat investigation, where the question is rarely whether a credential was used but whether the right person used it. And it will matter enormously for AI agents acting on enterprise networks, where the only acceptable answer to who did this is a cryptographic one. Traceability is not a layer added for compliance. In a properly architected system, it is what the protocol already provides, because the protocol could not have functioned without it.
There is a quieter benefit too, and it is one the industry rarely talks about. When users know that the action attributed to them is provably theirs—verifiable, traceable, bound to the device in their hand—they are protected from the most common false accusation in security: that they did something an attacker actually did. Endpoint-anchored identity not only protects systems from breach, but it also protects users from the consequences of breach. That is a humane property of the architecture, not a marketing feature of it.
7. As AI-enabled cyberattacks become more sophisticated, why must continuous identity verification be viewed as urgent among enterprises, and what can they do to counter AI-powered cybersecurity threats?
AI changes the economics of attack. Phishing emails that used to be detectable by their grammar are now indistinguishable from internal correspondence. Reconnaissance, credential stuffing, and lateral movement that used to require human attackers are now performed by automated agents at machine speed. And the deepfake threat is no longer hypothetical: in early 2024, an employee at the engineering firm Arup transferred approximately 25 million dollars to fraudsters after a video conference call in which the company’s CFO and several colleagues were AI-generated impersonations. None of Arup’s systems was compromised. Every participant on that call, other than the victim, was synthetic. The fundamental flaws being exploited are not new—stolen credentials, hijacked sessions, social-engineered approvals—but the rate, scale, and credibility with which they can be exploited have changed by orders of magnitude.
Continuous identity verification is the only structural defence against this, because it removes the gestures AI is good at faking. Deepfakes, synthetic identities, and impersonation attacks all rely on tricking the human or the prompt. Architecture that does not depend on human gestures at the moment of access closes that attack surface. If identity is asserted continuously by the endpoint through hardware-rooted cryptographic signals that the attacker does not possess, there is no prompt to spoof and no token to steal.
There is also a deeper question coming, which enterprises should start preparing for now: AI agents will increasingly act on enterprise networks on behalf of humans. The identity infrastructure today has no coherent answer for verifying who or what is acting—and the long-lived bearer token is exactly the artifact AI-driven attacks will exploit at scale. The right architecture handles human, machine, and AI-agent identity in the same way—each is an actor, operating on a verified platform, under known conditions, asserted as a continuous cryptographic signal. The architecture does not change when the actor changes; only the actor changes.
What enterprises can do, practically, today:
- Move identity to the endpoint. The endpoint is the only entity present for every moment of a session, the only place where the user, the device, and the conditions are all simultaneously known. Cloud-only identity cannot see what the endpoint sees.
- Shorten session windows and remove the user friction that made long sessions necessary in the first place. Short sessions only work when re-authentication is silent, which requires endpoint-based, hardware-rooted identity.
- Use the hardware you have already paid for. The TPMs and secure enclaves are already in your devices. The architectural work is to activate them as continuous trust anchors, not to buy new infrastructure.
- Stop treating login security and session security as separate problems. They are one problem—identity over time—and the industry has not yet found a way to solve it without rethinking where identity actually lives.
The technology to do this exists. It does not require a forklift upgrade of the internet. It requires the willingness to fix a definition error the industry has spent twenty years working around—and, plainly, to stop using the token as the carrier of identity assurance.
About Thi Nguyen-Huu:
Thi Nguyen-Huu is Founder and CEO of WinMagic, where he has led endpoint encryption innovation since 1997. His three decades of work in cryptography and pre-boot authentication have evolved into a broader mission: proving that online access can be completely secure without any user action at all. His writing on these topics has appeared in Forbes, Authority Magazine, The Fast Mode, PR Newswire, and Cyber Defense Magazine. He can be reached on LinkedIn at https://www.linkedin.com/in/thinguyenhuu/, and for more information, please visit https://winmagic.com/en/home/.
About WinMagic:
WinMagic’s mission is to secure the digital world through high standards and strong ethics. For more than two decades, the organization has led innovation in encryption and endpoint security. Today, WinMagic is advancing a new paradigm for online access—anchoring the endpoint as the foundation of trust. By letting endpoints speak for users, WinMagic turns cumbersome logins into seamless, automated exchanges. What was once user-to-machine communication now becomes a machine-to-machine relationship, governed by policy and anchored in cryptography. This evolution eliminates friction, reduces risk, and lays the groundwork for the Secure Internet—where security is continuous, effortless, and requires no user action. Learn more at https://winmagic.com/en/home/.
