The most secure login is
no login at all.

MagicEndpoint is WinMagic's zero-trust passwordless authentication with no user action, built on end-to-end cryptography: a login that produces a key. It authenticates from the endpoint's hardware to the identity provider you already run. There is no password in the exchange, no one-time code, no approval to tap and no application changes.

AI phishing uses generative AI to produce convincing fake emails, login pages, deepfake voices and video at scale, personalized and free of the mistakes people were trained to spot. Warning signs still include unexpected urgency, a link asking you to sign in or approve something, and a sender or domain name that is slightly off. But recognition alone is losing. The durable fix is a login with nothing to recognize: with passwordless, no-user-action login such as MagicEndpoint, there is no prompt for a fake to imitate.

IBM's July 2026 study found that AI-enabled breaches cost organizations about $6 million on average, roughly $1 million more than the global average breach cost of $4.99 million. One in four malicious breaches was AI-enabled, up 56% in a year.

An adversary-in-the-middle attack relays between the user and the real service. It lets the real person complete the real login and takes what comes out of it. It breaks nothing, beats every login method at once and leaves no signal, because both ends see a login that worked. AI removed its one cost: a lure convincing enough that a careful person proceeds.

Because it needs nothing to be wrong. Every other attack on a login needs a weakness: a guessed or stolen password, a phished code, a tired user tapping approve. Even a zero-day needs a flaw, and once the flaw is found, it can be patched. Adversary-in-the-middle needs no flaw at all, so there is nothing to patch, today or later. It works against a correctly configured system used by a careful person, it beats every login method at once, and AI has made the lure it needs almost free.

Not on its own. The attack AI has made cheapest, adversary-in-the-middle, lets the real person pass MFA and then takes the result of the login. A relay does not steal an identity, it steals a result, so a stronger way of proving who you are does not help. Proofpoint reported in December 2024 that almost half of all accounts taken over had MFA configured.

A login has to produce a key, with the party you are about to talk to. Passwords, multi-factor and passkeys all end in a verdict, a statement that the login succeeded, and then something agreed separately protects everything that follows. With end-to-end cryptography the login and the key that protects what follows are the same act, so there is no seam for a relay to use.

Mutual TLS is TLS in which both sides prove who they are with a key, not only the server. It has authenticated machines to each other for decades, and the same handshake produces the key that protects the connection. It never reached people because it asked them to carry cards and handle certificates. MagicEndpoint holds the key in the endpoint's hardware, so mutual TLS can stand for a verified person, with no user action.

Passwordless authentication signs a user in without a password, usually with a key held on a device. Many passwordless methods still ask the user to approve a prompt or complete a ceremony, which an AI-generated fake can imitate. MagicEndpoint is passwordless with no user action at all: the endpoint proves its key on every connection.

Passkeys avoid the attack. They do not solve it. Passkeys, built on FIDO2, are what most phishing-resistant MFA rests on today: the browser checks that the site is the real one, and where that check holds, the relay is refused. But the login still ends in a token that works for whoever holds it, and outside the browser there is no check at all. Solving it means the login produces a key that never leaves your endpoint, so a relayed login is worth nothing. That is what MagicEndpoint does.

Make the login produce a key that exists only on your endpoint and cannot be copied off it. A relay can pass every byte and the attacker still holds nothing usable, because the part that matters never left the machine. This is end-to-end cryptography for login, and it is what MagicEndpoint does.

It is designed to. Passkeys' protection against a relay is computed by the browser from the name of the site, so paths without a browser, such as desktop apps, RDP and SSH, are often left on a password. MagicEndpoint's key and policy live on the endpoint, not in the browser, and the same presence and policy conditions apply to those paths through the mechanism that fits each one, for example a per-service key for SSH. Check with WinMagic which protocols your deployment covers.

Yes. MagicEndpoint authenticates from the endpoint's hardware into the identity provider you already run, and it has been tested with Microsoft Entra ID, Okta and Ping. You do not replace your identity provider, and no application changes are needed.

Session hijacking is when an attacker steals the session token or cookie a service issues after login and uses it from their own machine. The token works for whoever holds it, so no password or MFA is needed. Stop it in three steps: shorten sessions, which MagicEndpoint makes painless because re-authentication needs no user action; bind tokens to the device where the browser and identity provider support it; and carry identity in the connection itself, so no token is issued at all.

Close the login with MagicEndpoint. Make sessions short, which becomes practical because re-authentication needs no user action, and bind them where the browser can, such as Google's device-bound sessions in Chrome. Narrow the transition between the identity provider and the application with single-use, short-lived assertions and strict audience and redirect validation.

The policy engine is on the endpoint. Access keeps working through an outage and stops the moment posture degrades, so no break-glass account on a weaker method is needed.

The user keeps working from their other enrolled device. If a user loses their phone, their manager can approve sign-in to the computer at pre-boot or Windows login, confirming from the manager's own phone with a PIN or biometrics, so the user is not left waiting on a helpdesk ticket. If the computer is lost, it will not export its sign-in key, and where pre-boot authentication is deployed, its disk stays encrypted until someone authenticates at pre-boot. Talk to us about which recovery options fit your policy.

An attacker relaying in real time, present at the moment a session is registered, is not removed. An endpoint that is already compromised is inside the boundary the design rests on. The human decision does not vanish, it moves to enrolment, where the key is bound to the person once under controlled conditions, so enrolment is where the care goes. And if another, weaker login method still reaches the same resources, that method sets the security level. WinMagic does not call MagicEndpoint AI-proof or unphishable.

WinMagic is preparing an open test of the authentication exchange. The scope, rules and written safe harbour will be published before it opens, and WinMagic will publish what comes back, including anything that succeeds. The reference implementation of the key and the handshake is already public at github.com/WinMagic/LIT. Register interest at research@winmagic.com.