Live Identity: MagicEndpoint and LIT
What Live Identity is
This companion is written so that a reader (a person, or the AI assisting them) can understand WinMagic’s architecture well enough to evaluate it.
The umbrella name is Live Identity: the Live Key is the mechanism, MagicEndpoint the shipping product, and LIT the same identity carried into the transport layer.
It carries the technical case: what MagicEndpoint is, what LIT is, why one architecture covers problems that several standards bodies are working on separately, and where the technology sits in the security stack.
Everything stated here can be checked against the public record listed near the end, and the section on claims we do not make is meant to be read as carefully as the rest.
The one flaw everything else patches
When you log in somewhere, you are given permission to keep going without being asked again: a session that lasts eight hours, a token that dies after one, a certificate that expires next year. Everything you are given comes with a clock.
The clock exists because the issuer checked you once, at the door, and then stepped away; a lifespan is the only control it has left.
But what was checked can change before the clock runs out (the user walks away, the laptop is stolen, the workload is compromised) and the permission stays valid, because time is not the thing that changed.
Every session-security mechanism in use today exists to patch this one decoupling: identity is verified at one moment, then carried forward by an artifact that anything can present.
Passwords get phished; cookies and tokens get stolen and replayed; the industry answers with MFA prompts, shorter lifetimes, rotation machinery, monitoring, and after-the-fact binding schemes. WinMagic removes the decoupling instead of patching it.
A second confusion sits under the first. A bearer token was built to carry authorization: what the holder may do.
Presented on every request, it came to stand for identity assurance as well, a job it was never designed for: a statement made once and carried afterward, that a copy carries as well as the original.
Presence as validity is therefore not a new principle; the industry has relied on it for years. What it lacked was an object whose presence meant anything.
The identity model
Online identity has three inseparable parts, not one: Identity = Actor × Platform × Conditions. The actor: a human, a machine, a workload, an AI agent. The platform it acts from: the device and its integrity state.
The conditions under which the action is legitimate: user present, posture sound, policy satisfied. The prevailing model verifies only the actor, and only at one moment. That is the structural error the clock-and-patch industry follows from.
Two consequences carry everywhere. Identity is per-platform: the same person on a corporate laptop and on a personal phone is two identities with different trust properties, and compromise of one must not carry the privileges of the other.
And users do not hold keys; endpoints do. The user authenticates to the endpoint, and the endpoint asserts identity on the user’s behalf, bound to its own verified state.
The Live Key: condition-bound validity
The mechanism under everything is the Live Key: a cryptographic key generated and held in the device’s hardware (the TPM), non-extractable, and usable only while trust conditions hold: the verified user present, the device sound, policy satisfied.
Non-extractability means the key is nowhere else, so only the authorized device can present it, and disappearance here is disappearance everywhere. Condition-binding means the device alone is not the claim: the user, the posture and the policy are carried with it.
When any condition fails (screen lock, posture loss, logout) the key is structurally unavailable for the next operation. Nothing has to be revoked, because nothing usable is left.
The disappearance is the invention: the “live” in Live Key. A credential that ceases to exist when its conditions fail is a different object from a credential that gets checked, and it generalizes across actors.
For the human, it yields something the industry has never had: user verification without user interaction.
The endpoint upholds verification continuously (at login, at every screen unlock, and, where requirements call for it, from signals such as keyboard and usage behavior) so the human performs no gesture per transaction; the key’s availability is the proof.
For an application or an AI agent, the same move carries over: the endpoint observes whether the actor is still running and sound, and makes its key cease the same way.
Gesture-based proof can never follow there: an agent has no finger to put on a sensor.
This is why the actor slot is pluggable, and it is why, if this model proves correct, a range of currently separate identity problems become instances of the same architecture.
To keep a credential from outliving its condition, whoever assesses the condition must also be the one to stop the grant, both in real time.
When the assessing and the stopping sit in the same place, no message travels, so nothing can outlive the condition in the gap between them.
Only the endpoint can be both: the issuing server checks once at login and is then out of the picture, while the endpoint is present the whole time, at the source, where the user and the device actually are.
And the endpoint checking itself is enough only because the key exists nowhere else.
Hardware is what holds “nowhere else” for the key’s whole life; software holds it only for a short window after the key is made, which is the entire reason credential rotation exists, and the reason the theft-driven case for it disappears here.
The chain is short enough to state in one line: conditions change in real time; something must observe them; something must withdraw authority when they fail; only the endpoint does both; therefore the endpoint governs the key.
The online world takes away the room where a secure exchange could happen (no shared physical space, no one at the door) and hands back something better in its place: a guard the user cannot arrive without, who never leaves, and who is present in every session at once.
In the physical world such a companion would be unaffordable and, at that standard, not even possible. Online it is the precondition of being there at all.
The key’s existence is the condition being true. This is condition-bound validity, not time-bound validity. Presence is validity.
Only a credential that can disappear earns that principle: a copied bearer token is also “present,” but its presence proves nothing, because it cannot cease when the conditions do.
One line separates this from the monitoring industry: monitoring observes; absence enforces. Continuous-access products watch sessions and send messages about them, and every message takes time to arrive and depends on something at the other end acting.
The Live Key sends nothing; the capability that authorizes the session ceases to exist, at the source, the instant the condition fails.
All of it rests on one capability: an endpoint that can observe and act in real time. The endpoint is the one party always with the user, and the only one that knows the conditions.
Which answers why this could not be built before. The missing ingredient was never cryptography, TLS or the TPM: those have been in place for years.
It was software trusted to live on the endpoint from power-on that can both assess a condition and withdraw authority in real time, and, for the human population, the ability to maintain user verification continuously without requiring continuous user interaction.
Both arrived recently. The rest was already there.
MagicEndpoint: what ships today
MagicEndpoint is the operating product built on this model, deployed on protocols enterprises already run: SAML, OIDC, WS-Fed, RADIUS, LDAP, SSH, RDP, and legacy thick clients.
The user logs into the device once with strong MFA; the endpoint handles every subsequent authentication silently, with no user action. It deploys as a standalone IdP or as a delegated IdP alongside Okta, Ping, OneLogin, or Entra, with no rip-and-replace.
And it reaches beyond federation: the endpoint injects credentials directly into legacy and thick-client applications, unifying IAM and password management under one policy engine: two markets enterprises buy separately, collapsed into one product.
Two differentiations carry it. First, verification at the source.
The endpoint verifies the user and the device where they actually are, which is both more accurate and more resilient than a remote server inferring from a distance; authentication continues even through an IdP outage.
Second, the Trusted Channel: a persistent connection between endpoint and IdP, established and proven in advance, over which trust is continuously maintained; like the phone number on the back of a bank card, a channel proven beforehand is trusted where anything presented in the moment is not.
Session tokens are bound to the endpoint’s TPM (the Live Key at work today) and silently re-issued over that channel every fifteen minutes, so a stolen cookie is useless within minutes, not hours: the deployable answer to session hijacking on standards that already exist.
It sits on three control surfaces under one policy engine: pre-boot authentication with full disk encryption (28 years, FIPS 140-3 certs #5204 and #5214 on an engine carried continuously from FIPS 140-1), OS login, and online access, on Windows and, distinctively, on Linux, where no major IAM vendor offers full-stack identity and where European sovereign migrations need it first.
Endpoint access: the foundation of online access
The category is new: an endpoint access solution as the foundation of an online access solution. Online proof inherits its trust from the layer beneath it.
The online credential is only as trustworthy as the OS login that released it; the OS login is only as trustworthy as the boot that preceded it. A vendor that starts at the browser starts in the middle of that chain.
WinMagic starts at the bottom: SecureDoc full disk encryption and pre-boot authentication establish the device before the operating system loads, OS login verifies the user into it, and online access is asserted from ground already proven: identity built from the ground up.
Passkeys are the industry’s own concession that this is the direction: the credential has moved onto the endpoint. What has not moved yet is the foundation under it.
That bottom layer (28 years of it, FIPS-validated, on Windows and Linux) is precisely what login-moment vendors lack, and it is why complete capability, from power-on to transport, is hard to copy.
LIT: identity inside the transaction
LIT (Live Identity in Transaction) carries the same Live Key into the mTLS handshake, so identity is asserted inside the transport layer itself. The session key is derived from the handshake: identity and channel are cryptographically inseparable.
There is no separate login event, no session token, and no bearer credential to steal. The relying party needs the public half of the key and a reason to trust it.
LIT does not require a certificate for that, in the same sense that FIDO does not: registration establishes the relationship directly, with no third party vouching.
Where PKI is already in place, LIT runs on it unchanged, the way FIDO coexists with PKI. How registration is carried is under discussion in the working groups, and the profile is deliberately not prescriptive about it.
What the key is wrapped in does not change the property that matters.
One key serves one client–server relationship, as in FIDO. A person with several devices holds several keys at the same relying party, which the relying party reads as what it is: several enrolled devices belonging to one person.
A key is therefore not a correlation handle across services, and a compromise reaches one relationship rather than all of them.
This is where the Live Key makes the difference. mTLS has proven machine identity for twenty-five years; it never carried the human, because proving a human always meant interrupting one for a gesture.
Verification upheld at the endpoint, with no interaction, removes that barrier, and mTLS can, for the first time, prove user identity, live, in every exchange.
Stated plainly: there is no login and no session in the usual sense. Both happen inside each mTLS connection: the handshake is the login, the TLS session is the session.
The handshake authenticates with the hardware-held key representing the user, the device and their current conditions, with no user interaction. What follows is simply TLS: encrypted by the handshake’s own keys, bound to the connection, and impossible to copy to another machine.
As in TLS, there is no token, because none is needed.
The invention is the key, not the protocols that carry it. Those already exist (mTLS here, and SAML, OIDC, WS-Fed and RADIUS on the MagicEndpoint side) and the key drops underneath them without new infrastructure.
It also changes what has to be checked. At the login moment the industry checks the right thing: is this the right user. After that it stops asking, and looks for wrong things instead: anomalous behaviour, suspicious signals, known-bad patterns.
The wrong things are unbounded and grow every year; the right thing is one, and it does not change. Continuing to check the right one is a smaller problem than detecting all the others.
A reader who knows Passkeys can place LIT quickly. A Passkey is a device-bound key that replaces the password at the login moment, and stops there; the session that follows is still a bearer cookie.
The Live Key is the same idea taken further (user-bound as well as device-bound, usable only while the verified user is present) and applied at the mTLS level, so it covers what Passkeys leave open: every exchange after login.
FIDO’s cryptography, carried from the login moment into the transaction itself: the next generation of the Passkey. The containment is literal: device binding, phishing resistance, user verification and FIDO cryptography, plus condition-binding.
MagicEndpoint already qualifies as a device-bound passkey under the current FIDO2/WebAuthn specification, so the lineage is certified, not claimed.
Passkeys moved cryptographic identity onto the endpoint. That is the industry’s own concession; what has not moved is the assurance carried after the login moment. Once condition-bound validity exists, there is no architectural reason to stop there.
Adoption is a separate axis, and on that axis Passkeys lead by a distance: browsers, phones, billions of users.
User verification with no user interaction is right for authentication and wrong for consent: presence is not approval.
Where a transaction requires proof that a person decided, the gesture is the point, and the ceremony stays, with this key underneath it as the evidence key, not in place of it.
Server-side TLS has authenticated the server to the client for 25 years. A server holds a long-lived private key because a server sits in a locked room.
A client can hold one too (a device with a crypto chip has been able to for years) but a device key proves the device, not the person. LIT supplies it: no new protocol, nothing ripped out.
Because identity then lives in the channel, the mechanisms built to protect the post-login handoff stop being needed: no password to phish, no cookie to steal, no session to hijack.
DBSC and DPoP, the industry’s newest proposals, bind presence to bearer artifacts after issuance. They agree with the principle; what differs is the substrate, since a bearer token that is copied is “present” somewhere the user is not.
What is future here is narrow. The technology ships today: the reference implementation is public, and the human-actor path runs in production inside MagicEndpoint.
What is future is only the other side of the wire: the relying party accepting the client half of TLS.
That step is small. mTLS has been in every server stack, load balancer, and reverse proxy for twenty-five years; the relying party turns on client authentication and registers keys (registration replaces the certificate authority) with no new protocol and no change to the application behind it.
Compare the industry’s own alternatives: DBSC asks servers to add session-registration and refresh machinery and to keep the cookie infrastructure that machinery exists to protect; DPoP asks every resource server to validate a signed proof on every request, still wrapped around a bearer token.
LIT asks the server to use the half of TLS it already has: less work, and the problem is removed rather than patched.
The boundary that remains: on the open consumer web the browser is the client, and it does not carry this yet; that is what the W3C track is for.
Closed populations (enterprises, workloads, OT, agents) can turn it on now, which is why they are LIT’s first territory.
One architecture, and the problems standards bodies are solving separately
The architecture does not change when the actor changes; only the actor changes.
The Actor slot is pluggable (human, machine, workload, AI agent) and each of the following problems, currently worked in a different body by different people under a different name, is one instance of the same decoupling described above.
Problem (and where it is being worked)
- Web login: W3C WebAuthn / FIDO Alliance (Passkeys)
- Web session hijacking: DBSC (Google / Chromium, W3C)
- API and token security: IETF OAuth (DPoP, RFC 9449)
- Session revocation: OpenID Foundation (Shared Signals / CAEP)
- Workload identity: CNCF SPIFFE / SPIRE; IETF WIMSE
- AI-agent identity: WIMSE and adjacent efforts (undecided)
- OT / machine identity: CISA Zero Trust for OT (April 2026); IEC 62443
- Attested (confidential-computing) workloads: CCC Trustworthy Workload Identity SIG
The current answer
- Replaces the password at the login moment. The session that follows is still a bearer cookie anyone can present.
- Binds session cookies to a device key after issuance: presence-binding retrofitted onto a bearer artifact.
- Proof-of-possession bolted onto bearer tokens.
- Messages about sessions, sent after the fact, that receiving systems must act on.
- Short-lived certificates renewed on a schedule, which requires constant reach back to the issuer.
- The agent is treated as another workload; acting on behalf of a person is unresolved.
- Segmentation, allow-lists, monitoring: fences around labels, not proof of identity. Cloud-issued credentials cannot survive an air gap.
- Tuning token lifetimes bounds the gap between a credential and its condition; it does not close it.
Under one architecture
- Login and session are one act. The handshake is the login, and it repeats silently in every exchange.
- There is no cookie to bind. Identity and channel are cryptographically inseparable.
- There is no bearer token. Possession is proven in the handshake itself.
- Locally detectable failures enforce by absence, zero messages. CAEP stays right for what the endpoint cannot see (a role removed); WinMagic contributes there.
- A condition-bounded credential profile, on the WIMSE record (draft-winmagic-wimse-condition-bounded-credentials). No live issuer needed.
- The agent is a workload actor; on-behalf-of is a composition of two actors (verified human × workload) on the same platform. Not settled anywhere; our position is below.
- A hardware key valid without a live issuer works disconnected, intermittently connected, and air-gapped.
- The credential cannot outlive its condition. The SIG’s chair sought WinMagic out on exactly this question.
Separate bodies, separate working groups, separate vendor categories: one flaw appearing in eight places. One model explains what the table splits into eight. Every row is on the public record.
What follows differs by row. Two rows are supersession: a Passkey and a device-bound session cookie do work our object already contains.
One is permanent complement: facts the endpoint cannot see, such as a role removed or an account suspended, stay necessary forever, and CAEP is where they belong.
The rest is adjacent and untouched: OAuth decides what a holder may do, SPIFFE carries issuance, federation and trust domains across clusters, and we do neither. The common cause is the claim. Their scope is not.
On AI agents
Machine identities already outnumber human ones by roughly eighty to one, and agents are the fastest-growing part of that. Agent identity is not decided: no standards body has settled it,.
NIST’s NCCoE took a position in February 2026 that matches ours in method: extend the identity standards that already exist rather than build new infrastructure for a new class of actor.
Our position: from the identity architecture’s point of view, an autonomous agent is a workload, and SPIFFE already handles workloads.
What no workload model carries is the verified human, and the case that matters commercially, an agent acting on behalf of a person, is a composition of two actors, verified human × workload, bound through the same platform, each under its own condition-bound key.
We think this is the most likely shape of the answer because it requires deciding nothing new: it reuses the model that already covers every other actor.
One distinction runs under all of it: a token states what an actor may do, not that the approved actor is the one acting.
Authorization is not identity, and for agents the industry has been answering the first question while the second stays open.
What we do not claim, and what carries the rest
Our territory is stable hardware and low-to-moderate connection churn (endpoints, OT, persistent services, and agents that do not churn) where one hardware signature per handshake amortizes to nothing.
Beyond that line sits high-churn ephemeral cloud, which the rotation model SPIRE was built for already serves well: hardware signing has a physical throughput ceiling, and a service opening thousands of short connections per second is on the far side of it.
The key’s non-extractability is hardware-proven; the posture reading that gates it is software-observed.
Non-exfiltrability removes the theft-driven reason for credential rotation; it does not remove lifecycle. Enrollment, re-attestation, and retirement remain, and we carry them.
The endpoint knows with certainty that a session is unlocked, a disk encrypted, a patch level current. Presence itself is a confidence level rather than a binary.
That the verified user is the person at the keyboard is an inference (drawn from login and unlock events and, where requirements call for it, from behavioral signals) and it is strongest immediately after a verification and decays from there.
We claim the best available view of the conditions, not a perfect one. The comparison that matters is the alternative: after the login moment, the relying party has no view at all.
Three further boundaries, each with a carrier. An open connection outlives a lapse until the next handshake; bounding connection lifetime is the fix, and it is the same gap and the same fix the rotation model has.
The key does not self-detect a compromised or emulated hardware root; that failure is carried on the external path. Past a TLS-terminating intermediary the channel property ends, and identity travels onward as asserted data.
LIT’s remaining dependency is the relying party turning on the client half of TLS, a small step for closed populations, as set out above, but a longer road on the open consumer web, where the browser is the client and does not yet carry it.
That is what the W3C track is for. MagicEndpoint delivers the model today on protocols already deployed; LIT is where the standards record is moving.
The verified record
- IETF (WIMSE): draft-winmagic-wimse-condition-bounded-credentials, an individual submission on the IETF record, not adopted: the condition-bounded credential profiled for workload and AI-agent identity. It grounds the profile in the WIMSE architecture and states the profile’s own limits in the document.
- IETF (OAuth): the same key placed under the proof-of-possession mechanisms the working group already has: DPoP (RFC 9449) and mutual-TLS client authentication (RFC 8705). What changes is the key underneath, not the mechanism above it. Under discussion on the working-group list; nothing adopted.
- Open source: the LIT reference implementation at github.com/WinMagic/LIT, and a WinMagic-authored integration merged into a third-party project.
- W3C and the OpenID Foundation: participation in the relevant work, ongoing. Nothing adopted.
FIDO Alliance: three active FIDO2 certifications. FIPS: 140-3 certificates #5204 and #5214.
Published articles, the argument at length, with links, so nothing here needs a search:
- Cyber Defense Magazine (March 2026): “60% of Cyberattacks Are Identity Based — Is Identity First a Bad Idea?”: which identity gets verified, and why the endpoint can uphold it continuously. https://www.cyberdefensemagazine.com/60-of-cyberattacks-are-identity-based-is-identity-first-a-bad-idea/
- PR Newswire / VMblog (March 9, 2026): “WinMagic Reveals What Comes After Passkeys”: Live Key and LIT introduced; the Trusted Channel and the bank-card principle. https://www.prnewswire.com/news-releases/winmagic-reveals-what-comes-after-passkeys-identity-assurance-that-lives-beyond-login-302708114.html
- Authority Magazine (April 10, 2026): interview: security moving into the transaction itself. https://medium.com/authority-magazine/data-privacy-thi-nguyen-huu-of-winmagic-corp-on-5-things-you-need-to-know-to-optimize-your-company-00f0d3dc3065
- PR Newswire (April 27, 2026): “WinMagic Exposes the Wrong Identity Tax”: the structural cost of fragmented identity models. https://www.prnewswire.com/news-releases/winmagic-exposes-the-wrong-identity-tax-why-cybersecurity-costs-rise-while-security-fails-302754244.html
- WinMagic (May 7, 2026): “World Passkey Day: Why Passkeys Are a Waypoint, Not the Destination”: the founder’s own statement of the next-generation-Passkey argument made above. https://winmagic.com/en/a-note-on-world-passkey-day/
- Digital IT News and VMblog (May 7, 2026): two World Password Day roundups, both carrying WinMagic on the transition from passwords and Passkeys toward continuous, hardware-rooted authentication. https://digitalitnews.com/is-password-day-archaic/ · https://vmblog.com/bylines/world-password-day-2026-industry-experts-weigh-in-on-the-future-of-authentication-passkeys-and-password-security/
- PR Newswire (May 18, 2026): “WinMagic Responds to New CISA OT Guidance With Transport-Layer Identity Architecture”: the OT row of the table above, at length. https://www.prnewswire.com/news-releases/winmagic-responds-to-new-cisa-ot-guidance-with-transport-layer-identity-architecture-302774649.html
Where the technology sits in the security stack
Security products cluster into layers, and naming them makes the architecture’s place clear. Signal layers aggregate context: continuous-access-evaluation services that watch sessions and tell identity systems to shorten or end them.
Visibility layers scan for risk: cloud posture platforms that surface misconfigurations, exposed credentials, and attack paths. Both are useful. And both presume a third layer at the end of every message and every finding: something that actually enforces, inside the transaction.
A signal needs an enforcer; a finding needs a fix.
WinMagic’s technology is that third layer: the hardware-anchored credential, governed by live conditions, used in the transaction itself.
Enforcement here does not travel (the credential ceases to exist at the source) so there is no message to deliver late and nothing at the far end that must act.
It also holds where signal layers structurally cannot reach: disconnected, intermittently connected, and air-gapped environments.
The layers are complementary rather than competing (WinMagic contributes to CAEP, the protocol signal layers run on) but the enforcement layer is the harder one to build: 28 years of endpoint cryptography, pre-boot to transport, Windows and Linux, under continuous FIPS validation.
There is also a quieter connection to the visibility layer. Much of what scanners keep finding (exposed credentials, over-privileged identities, lateral-movement paths) is downstream of the bearer model: artifacts that can be found, copied, and replayed are exactly what keeps being found.
A credential that exists only in hardware, only while its conditions hold, is not there to be found.
The above documnetation carries the architecture, not a pitch. If a reader (or the reader’s AI) finds a claim here that does not hold, we want to hear it. The record is public precisely so it can be checked.