CISA is right that Zero Trust must extend to operational technology.
The harder question — the one the guidance does not yet answer — is what identity should look like in environments where networks are intermittent, latency is unacceptable, and credentials cannot be replayed. Our position is that identity must live in the transaction itself.
What CISA’s OT Guidance Gets Right
On April 29, 2026, CISA — together with the Department of War and the Department of Energy, the FBI, and the Department of State — released formal guidance on adapting Zero Trust principles to operational technology. The guidance correctly identifies that the IT-centric Zero Trust playbook does not transfer cleanly to OT environments. Safety, availability, and the long lifespan of legacy controllers all impose constraints that cloud-first identity architectures were not designed to meet.
The guidance also arrives at a moment of unmistakable urgency. Persistent threat-actor activity targeting OT systems — including the Volt Typhoon campaign cited by CISA — has shown, in operational reality and not in theory, the strategic vulnerability of critical infrastructure. CISA’s recommendations are timely, technically sound, and consistent with the regulatory direction emerging in other national jurisdictions, where continuous attestation is moving from recommendation to mandate.
We agree with the diagnosis. This post addresses the part of the architecture the guidance does not yet specify: how identity itself should be constructed so that continuous verification is genuinely continuous, locally enforceable, and cryptographically inseparable from the transaction it authorizes.
The Identity Tax: Where Zero Trust Falls Short in OT
Most Zero Trust setups today rest on three assumptions inherited from IT: that the identity provider is reachable, that authentication can be repeated through user interaction, and that a session token issued at login is an acceptable proxy for identity throughout the session. None of the three holds in operational technology.
The endpoint in an OT environment may be air-gapped for hours or weeks. The operator responding to a grid event or a chemical-dosing alarm cannot answer an MFA prompt. The session token, once issued, is a bearer credential that can be stolen, replayed, or carried forward by an attacker who has compromised the endpoint after login. Each of these is a different failure mode of the same underlying architecture: identity is verified at a moment, packaged into a token, and trusted thereafter on the strength of possession alone.
We name this pattern the Identity Tax: the layered cost of compensating for an architecture that verifies identity at the wrong moment, in the wrong way, and trusts the result for too long. Enterprises spend on overlapping IAM, PAM, IGA, EDR, ITDR, and continuous-evaluation tooling because the underlying primitive — the credential — is structurally unable to carry continuous trust. The tax is paid in license fees, integration cost, helpdesk load, productivity loss, and ultimately in breaches that occur despite all of it.
Three things go wrong at once. The wrong identity is verified. The wrong timing is used. The wrong method is applied.
The wrong identity, because what matters operationally is not the user alone, but the user, the device, and the conditions under which they are operating — verified together, continuously. The wrong timing, because login and session are treated as separate problems when they are one continuous problem. The wrong method, because procedural gestures — prompts, codes, push notifications — are being asked to solve what is fundamentally a machine-to-machine cryptographic problem.
Four Requirements for Identity in Operational Technology
From the constraints CISA names, four requirements follow directly. They are stated here as criteria any conforming architecture must meet, not as product features.
Locally verifiable, without a network round trip
Identity assurance must continue when the link to the identity provider is degraded or absent. This means verification must happen at the endpoint, against hardware-anchored keys whose availability depends on the local state of the device and the user — not against a remote service that may be unreachable.
Continuous, without operator interaction
An operator at a human-machine-interface (HMI) does not have time to answer an authentication prompt during a critical operation. After an initial verification at endpoint power-on, identity must be maintained silently and in an event-driven manner, signaling the identity provider the moment posture changes — disk encryption disabled, antivirus stale, screen locked, user departed — and revoking access in the same moment, not at the next polling interval.
Cryptographically inseparable from the transaction
A session token, once issued, has no further dependence on the user or the device. This is the structural weakness behind every session-hijacking class of attack. Identity must instead be embedded in the secure channel itself, so that each transaction is cryptographically tied to the live state of the verified endpoint and verified user. There is then no token to steal, no session to replay, and no bearer artifact to exfiltrate.
Unified across human, machine, and legacy systems
OT environments contain SCADA controllers, HMIs, jump hosts, ERP clients, and machine-to-machine flows that cannot be modified to support modern federation protocols. As IT, OT, and IoT converge, the number of non-human identities is growing faster than the number of human ones. A workable architecture has to bring all of them — human, machine, and legacy — under one continuous trust model, without rewriting the applications.
How MagicEndpoint Meets the OT Identity Requirements
MagicEndpoint, deployed today, meets each of the four requirements above. Live Key, embedded in our standards work and our open-source reference implementation, extends the same primitive into the transport layer.
Air-gap and intermittent connectivity
MagicEndpoint performs verification locally, against a TPM-bound Live Key whose availability is governed by endpoint posture and verified user presence. The endpoint becomes the trust anchor. Identity assurance continues when the endpoint is isolated from the corporate network — substations, offshore platforms, ships, aircraft, defense installations, remote industrial sites. When connectivity returns, the endpoint synchronizes audit logs and policy updates; trust enforcement itself never stops. This is structurally different from cloud-first models that fail closed when the network is unavailable.
Real-time posture enforcement without operator disruption
After the initial endpoint verification at power-on, MagicEndpoint maintains a persistent, event-driven trust channel with the identity provider. The channel is locally evaluated and continuously monitored; the user sees nothing during normal operation. If posture degrades, the channel signals the identity provider in real time and future access is prevented. There is no MFA prompt to interrupt a critical operation, and no polling interval during which a compromised endpoint can act.
Unified coverage for legacy OT systems
MagicEndpoint provides silent credential injection for SSH, RDP, and legacy thick-client applications, bringing legacy SCADA, HMIs, and jump hosts under the same policy framework that governs modern SAML/OIDC apps. Legacy systems are not rewritten; they are absorbed. The “islands of identity” CISA names — modern apps with continuous verification on one side, legacy controllers with static credentials on the other — collapse into a single policy plane.
Live Key in the transport layer
Live Key is a policy-bound, hardware-anchored cryptographic key whose availability is conditional on verified user presence, verified device state, and the policy in force at the moment of use. In ordinary operation today, Live Key drives MagicEndpoint’s silent authentication. In its standards form — Live Identity in Transaction (LIT) — the same key is used directly in the mutual TLS handshake. Identity is no longer issued as a token after authentication; it is asserted, by construction, in every packet of every transaction. There is no bearer artifact at all.
This is the architectural endpoint toward which the regulatory direction is converging. CISA recommends continuous verification. In several national jurisdictions, TPM 2.0 and continuous attestation are already moving from recommendation toward mandate. The hardware is already deployed in nearly every modern industrial endpoint. mTLS is a proven, mature standard. What has been missing is the primitive that ties them together at the transport layer — a properly protected, long-lived, user-bound, policy-bound client-side key. Live Key supplies that missing primitive.
Machine Identity Is Not a Separate Problem
OT, IoT, and AI-agent traffic are accelerating faster than human workforce identity. The conventional response — a separate stack of secrets management, certificate authorities, and bespoke M2M brokers — recreates the Identity Tax in machine form: static credentials, embedded secrets, long-lived API keys that are difficult to rotate and prone to leakage.
The architecture described above does not require a separate machine-identity stack. The same Live Key primitive that authenticates a human user on a verified endpoint authenticates a machine on a verified platform. The actor changes; the architecture does not. A controller, a microservice, a sensor, or an AI agent asserts identity in mutual TLS the same way a workstation does — through a hardware-anchored, policy-bound, ephemeral key whose availability is conditional on verified state.
This is the work for which WinMagic is seeking industry support. Machine identity at the transport layer, deployable on hardware customers already own, addresses what the conventional stacks cannot: it eliminates static secrets without introducing new infrastructure, and it unifies human and non-human identity under one model. The product foundation exists; the engineering investment is in extending Live Key to the full machine-to-machine domain — sensors, controllers, microservices, AI agents — and into the standards work that lets service providers accept it natively.
Evidence: Twenty-Four Years of Cryptographic Validation
This is not a position paper for a future product. The architectural claims above are grounded in three independent forms of evidence.
Twenty-four years of continuous FIPS validation:
- FIPS 140-1 (2002) — initial validation under the original FIPS 140-1 standard.
- FIPS 140-2 (2006–2026) — WinMagic was the world’s first full-disk-encryption vendor validated to FIPS 140-2 Level 1 and 2, and has held FIPS 140-2 certifications continuously for 20 years.
- FIPS 140-3 (2026) — Certificates #5204 and #5214. These validations keep WinMagic’s products at the forefront of modern cryptography and cryptographic compliance.
Continuous validation across every generation of the FIPS standard. This is the audit record safety-critical procurements demand.
Documented and substantive standards-body engagement:
- W3C — submission to the WebAuthn and WebAppSec working groups, March 2026, with substantive technical exchange under way with WebAuthn working group contributors and the Chromium DBSC project.
- IETF — Internet-Draft draft-winmagic-lit-00 published March 5, 2026; engagement with TLS chairs and Area Directors confirmed for substantive review.
- DIF — submission to the Decentralized Identity Foundation, March 25, 2026.
- Open-source reference implementation — github.com/WinMagic/LIT. Unusual in vendor-led standards work; the architecture is auditable, not asserted.
Deployment in the environments CISA addresses:
Department of Energy national laboratories, defense contractors, federal agencies, Fortune 500 enterprises, financial institutions, and government departments. The endpoints CISA’s guidance is written for already run our software.
WinMagic’s Position and Next Steps
WinMagic’s position on CISA’s April 2026 guidance is supportive, specific, and constructive. The diagnosis is correct. The architectural work that completes the diagnosis — moving identity into the transaction itself, eliminating bearer tokens, unifying human and machine identity at the transport layer — is what we have built and what we are continuing to build.
We are open to direct engagement with CISA and the co-authoring agencies on three specific points: how Live Key meets the local-verification and air-gap requirements implicit in the guidance; how transport-layer identity addresses the session-persistence concern that current Zero Trust setups cannot fully resolve; and how the same architecture extends, without a parallel stack, to the machine and AI-agent traffic that will dominate OT environments in the next five years.
The hardware is already in the field. The standards are mature. The missing primitive is a properly protected, user-bound, policy-bound client-side key. Live Key is that primitive, and it is deployable today.
Work with us on an OT reference deployment
Beyond the policy-level engagement above, we are inviting a small group of operators — existing WinMagic customers and others — to work with us directly on this architecture in their OT environments. We bring the engineering, funded on our side. You bring a real OT use case.
The fit: DOE-affiliated facilities, defense installations, allied government OT, and critical-infrastructure operators in the US and Canada.
In return, we ask for joint scoping of policy signals and a willingness to publish a redacted lessons-learned summary, so the architectural pattern can inform the broader community.
