How are AI-enabled attacks changing the consequences of weak authentication, excessive permissions, and misconfigured systems?

In August, the largest technology and security companies published one letter: AI-enabled attacks are coming fast, and the window to prepare is short. Hundreds of organizations have now signed it. AI does not change what these weaknesses are. It changes what it costs to find and use them.

A tailored attack used to take a skilled person hours or even days, so it was spent on targets worth that time. Many organizations were protected less by their defenses than by not being worth the trouble. AI makes the careful attack repeatable at almost no extra cost. The phishing email written for the CFO now goes to everyone, and Microsoft measured AI-tailored lures at 54% click-through against about 12% for ordinary ones. Once inside, attackers also move faster: CrowdStrike put average breakout time at 29 minutes in 2025, 65% faster than the year before.

So, all three weaknesses get found sooner and used further. Excessive permissions decide how far an attacker gets once in. Misconfiguration is often how they get in. The industry knows what to do about both: know what is running, cut permissions to what is needed, review configuration. In large, complex environments it is rarely done completely, but the direction is clear and agreed.

Weak authentication is different. There is an agreed direction there too, phishing-resistant sign-in, but not agreement on where the weakness actually is, or on what would make authentication strong. The industry has moved from passwords to multi-factor authentication (MFA) to passkeys, and each step was a real improvement. Attackers still get in: Proofpoint reported that almost half of the accounts taken over by attackers had MFA configured. And unless authentication is fixed, the other work is not enough. An attacker who logs in as a legitimate user gets that user’s permissions, correctly granted. Least privilege limits how far they go; it does not stop them.

Our answer to where the weakness is: security uses cryptography everywhere, but in pieces, not end-to-end. Authentication returns a verdict—yes, this is the user—and the key that protects the session is agreed separately, not bound to it. Attackers do not break the cryptography. They go around it, at the join. That is the part WinMagic fixes, starting at the login.

Why is the traditional username-and-password model becoming less suitable for an environment where cyberattacks can operate at machine speed?

A password works for anyone who has it, anywhere. It travels: out of an old breach, off a fake page, over a helpdesk call. And the model depends on a person making a judgment at the moment of login: is this the real site? Did I just ask for this code? A

person has no reliable way to verify a server. They look at a page, and AI is very good at producing a page, an email, or a voice that a careful person will believe. Machine speed means that judgment is asked for far more often, and each time more convincingly.

MFA adds a second factor, and that can be relayed too. In an adversary-in-the-middle (AiTM) attack, the attacker sits between the user and the real service and passes every step along. The user really does authenticate, both ends see a successful login, and the attacker keeps the session. Microsoft reported that campaigns using one relay kit, Tycoon2FA, were reaching more than 500,000 organizations a month, with access to the kit from $120 for ten days. Microsoft and Europol seized its infrastructure in March, and it was back at its earlier volume within days.

And whatever the method, the login ends in a yes or a no. What carries the user afterward is a session token or cookie, which is only supposed to be hard to copy. Take that, and the password is not needed at all. So, the login has to stop relying on a person’s judgment, and what it produces has to be something that cannot be copied.

How does Mutual TLS (mTLS) address authentication weaknesses that conventional identity-based approaches may leave exposed?

Mutual TLS (mTLS) is authentication done end-to-end: the proof of who you are and the key that protects the session come out of one operation. None of the methods most people use passwords, MFA, passkeys works that way.

Today’s login is two separate operations. TLS sets up the encrypted connection, and in that handshake only the server proves itself. Then authentication happens on top and returns a verdict. It does not produce the key that protects the data that follows. That key already exists, from a handshake the user was not part of. Both checks are correct. Attackers do not break either one; they work in the space between them.

Mutual TLS has no such space. Both ends prove themselves inside the same handshake, and the session key comes out of that handshake. Even if an attacker relays every message, they do not have the session key, and everything that follows needs it. The lure can succeed completely, and the attack still fails, as long as the service accepts nothing weaker.

A passkey comes closest among today’s methods. The browser checks which site the user is on and writes that name into what gets signed, and that protection is real. But the name is only as good as the machinery that decides it: the browser, and the names and certificates it trusts to say which site this is. The signature is tied to that name, not to the connection. That machinery is large, and finding flaws in large machinery is what AI is getting better at.

The mechanism is not new, and it is not ours. mTLS has secured machine-to-machine traffic for decades. It stayed there because machines have keys and people don’t: using it for users meant smart cards and certificate management. What was missing was a client key that can stand for a person, with no smart card to hand out. That is what the endpoint provides, and what WinMagic built.

In what ways is WinMagic approaching the shift from traditional authentication assumptions to cryptographic verification?

We start from one fact. Online, cryptography is the best defense, and humans cannot do cryptography. So, the endpoint has to do it for them. The endpoint is where WinMagic has worked for nearly thirty years, and our cryptography is FIPS 140-3 validated.

You log in to your own device once, verified with strong multi-factor authentication (MFA): your phone, a security key, a smart card, or Windows Hello. After that, the device proves a key at every sign-in, and the user does nothing: no password, no code, no push to approve. People tend to like that more than the security. It also takes away what AI is good at attacking: there is no login page to imitate, no code to relay, and no judgment for the user to get wrong. Where there used to be a chain of separate steps, there is one cryptographic operation.

Our product, MagicEndpoint, does this today. It works alongside the identity provider a company already has, such as Entra ID, Okta, or Ping, so nothing is ripped out, and users carry nothing new: the credential is in the device they already use. It covers web applications, remote access, RDP and SSH, and where a company wants a deliberate act, such as opening the payments system, it can still require one.

What we do not yet close is the session after the login. Once the identity provider issues its token, that token sits outside the channel we established. Closing it requires applications to speak mTLS with the endpoint, and that needs the service providers with us. Inside a company, where one organization controls both ends, that can be done now.

That work is in the open. We published this flaw in February 2024, before AI made it urgent. We have drafts at the IETF and a proposal at the W3C, and a reference implementation is public at github.com/WinMagic/LIT.

How does WinMagic use device-bound cryptographic keys to establish greater confidence that the person and endpoint accessing a system are actually authorized?

Strictly, the key does not make anyone authorized. It proves who is there, on which device, right now that is authentication. Authorization—what someone may do is a separate question, and keeping the two apart is where the confidence comes from.

Online, authorization travels as a token, and a token is like a passport: claims about you, signed by an authority. At a border, the passport is never presented alone; the person comes with it. Online, the token usually travels alone. Proving identity remotely is hard, so the industry has used the token as if it carried the identity, and gives access to whatever endpoint presents it.

Where tokens are now tied to a device, as some large platforms have started to do, they still say nothing about whether the verified person is there.

What we add is the person with the passport. The proof is a key we call the Live Key. It is generated on the endpoint, anchored in its TPM security chip where there is one, and never leaves it. It is usable only while the verified user is using the device and the device is in the state the policy requires. Log out, or let the device fall out of policy, and the key is gone, and with it the device’s ability to sign in. So, one proof says: this user, on this device, under these conditions, now.

With that proof beside the token, both halves are there: the identity is proven now, and the token says what that identity may do. That is the division the industry should work to: the token for authorization, and not as proof of who is there.

MagicEndpoint uses this key today at login. It verifies the user, the device, and its posture with no user action, which is already a large improvement for users. It is also better security: sessions are often left open for hours or days because signing in again irritates people. Remove the prompt, and that reason goes, so sessions can be kept short and renewed silently, and a stolen cookie is worth much less.

And the key can do much more. When a service speaks mTLS with the endpoint, the key protects each transaction, and the proof comes with every request, besides the token. That will matter more as AI agents start acting for people: a request should be able to show that a verified person, on a compliant device, stands behind it. That is part of our work at the IETF.