In a new article for Biz Tech Journals, WinMagic founder and CEO Thi Nguyen-Huu explains why adding more security tools won’t fix how logins work today, and what has to change instead.
The short answer: Nearly all user authentication in use today, including passwords, multi-factor authentication (MFA) and passkeys, confirms who you are but plays no part in creating the key that encrypts your session. Nothing ties that key to the person who just logged in, and adding more tools on top doesn’t change that. Fixing it takes end-to-end cryptography, where proving who you are and creating the session key happen in one step, built on three things, in order: coverage, security and manageability.
Read the full article on Biz Tech Journals
Why won’t more security tools solve the problem?
CrowdStrike reported that AI-enabled adversaries increased their activity by 89 percent in 2025. In an open letter, the industry warns that the window to prepare is short, and calls for better tooling.
The attacks themselves are familiar. What AI changes is how closely an attacker can study a target and how many targets they can hit at once. Our earlier post, AI made the careful attack cheap. Authentication has to change., looked at that shift and at where attackers get in. Thi’s new article takes the next step: why piling on tools can’t fix it.
Thi’s answer is that the problem isn’t how many tools there are, but what they’re built on. Every patch layered on top of today’s authentication (session handling after login, more identity systems, more servers, more tools) adds complexity and cost, while users are asked to learn, train and struggle. The flaw underneath stays put.
What is the flaw underneath?
Encryption only works when the key belongs to the two parties at either end. A login doesn’t create that key. Authentication answers a single question, whether this is the right person, and gives back a yes or no.
The session that follows is encrypted with a key agreed in a separate handshake, the automatic exchange that sets up the encrypted connection, and the login plays no part in it. Each part does its own job correctly, but they are never linked. No one confirms that the encryption key belongs to the person who just signed in.
That flaw sits in passwords, MFA and passkeys alike, and it leaves a gap that AI-enabled attacks will exploit more than ever. We documented it in 2024, before AI made it urgent.
What does it take to close the gap?
End-to-end cryptography, built on three requirements, in this order.
- Coverage: prove identity inside every connection. The framework has existed for decades: mutual TLS, which machines have long used to authenticate each other. Both ends prove who they are inside the same handshake that creates the session key, so proving identity and protecting the connection become one step. Because it works at the transport layer, the level that sets up every network connection, it reaches further in two directions:
- In space: anything that opens a connection can use it, from a web session or desktop app to remote desktop, SSH or a call between services. Protection built into a browser covers only what goes through a browser.
- In time: the proof comes with every connection, not once at the start. There is no one-time login result to carry forward in a session cookie, so there is no session to steal.
- Security: a proof that can’t be taken. Any method with a human decision inside it (approve this, read this code, is this really my bank?) can be deceived, and AI will exploit that. Cryptography is the one part of security that doesn’t depend on anyone noticing anything.
NIST’s zero trust architecture has required verifying “both subject and device” (the person and the device) since 2020, but describes them as “discrete functions” performed before a session is established. Most deployments kept that shape: a stronger check up front, then a credential that travels on its own.
The alternative is a key in the device’s security chip that carries all three: the verified person, the authorized device and the conditions the organization’s security policy requires. It can’t be copied or used anywhere else, and it exists only while all three hold. Thi calls it a Live Key. When any condition stops being true, the key is gone and access goes with it: no separate login and session to manage, and no message to send to cancel access.
- Manageability: nothing asked of the user. Usually, more security means more hassle for users. Here it works the other way round. The user signs in to their own device, and from then on the device authenticates them with the key it holds: no password, no code, nothing to approve.
That is also what makes it manageable for IT. No passwords to forget, far fewer resets, lockouts and helpdesk calls. Past the initial rollout there is less to manage than before, and existing systems don’t have to be replaced to get started.
Who should be doing the authenticating?
Thi ends with a second fundamental flaw, this time in identity: why is the person the one authenticating at all? Today users wrestle with MFA, get asked for more of it whenever security tightens, and end up as the weakest link. His view is that answering this question well would deliver much stronger security without asking anything of the user.
FAQ
Do MFA or passkeys close the gap between authentication and session encryption? No. Passwords, MFA and passkeys confirm who the user is, but none of them produce the key that encrypts the session, so nothing ties the session to the person who signed in.
What three requirements does Thi Nguyen-Huu set for fixing authentication? Coverage, security and manageability, in that order: identity proven at the transport layer on every connection, a hardware-held key that binds the person, the device and the required security policy conditions, and a device that authenticates the user with nothing for them to do.
Why won’t more security tools close the authentication gap? The flaw is in authentication itself. Every patch on top of it, such as session handling after login, more identity systems, more servers and more tools, adds complexity and cost without linking the login to the key that encrypts the session.
How does this differ from NIST’s zero trust approach to subject and device verification? NIST’s zero trust architecture has required verifying both subject and device since 2020, but treats them as separate checks before a session starts. The article argues for one key that carries the person, the device and the required policy conditions on every connection and exists only while all three hold.
Who should do the authenticating, the person or the device? The article argues it shouldn’t be the person. Asking people to handle MFA, and more of it whenever security tightens, makes them the weakest link. When the device authenticates them, no user action is needed.
Do organizations have to replace existing systems? No. The article states that existing systems do not have to be replaced to get started.
