Why SMB Is the Weakest Link in OT File Sharing

Server Message Block – SMB – is the protocol that every OT environment depends on and no security architect fully trusts. It moves firmware files from engineering workstations to PLCs. It transfers configuration backups from HMI panels to Historian servers. It shares recipe files between MES systems and batch controllers. It runs on every Windows server in every industrial network on the planet.

And it is the protocol that ransomware uses to destroy those same networks.

Dragos documented it explicitly in their 2026 OT Cybersecurity Report: throughout 2025, ransomware affiliates authenticated into VPN portals using infostealer-harvested credentials, then used RDP and SMB/PsExec to move laterally toward VMware ESXi hypervisors and OT-support servers hosting SCADA, HMI, Historian, and engineering workloads. The operational impact did not come from ICS-specific malware – it came from the encryption of the virtualization infrastructure that OT depends on. SMB was the transport.

CISA added CVE-2025-33073 – a Microsoft Windows SMB Client improper access control vulnerability – to the Known Exploited Vulnerabilities catalog on October 20, 2025, with a federal patching deadline of November 10. The vulnerability allows attackers to escalate to SYSTEM privileges and, according to researchers at Synacktiv, functions as authenticated remote command execution on any machine that does not enforce SMB signing. CVE-2025-55234, disclosed at September 2025 Patch Tuesday, exposed NTLM relay attack paths against SMB servers that do not require signing or Extended Protection for Authentication.

This is not an isolated pattern. It is the structural reality of standard SMB in 2026.

For security architects designing OT network defenses, the question is no longer whether to patch SMB – the question is whether the SMB protocol itself can meet the identity-based access, continuous authentication, and audit requirements that Zero Trust architectures demand. The answer, architecturally, is no. This article explains why, documents what zero trust SMB replacement OT networks actually looks like, and provides a practical migration path from standard Microsoft SMB to Heimdall SMB – TerraZone’s Zero Trust–compliant SMB protocol replacement.

What Makes Standard SMB Incompatible with Zero Trust

Zero Trust is defined by continuous verification, identity-based access, least privilege, and assumed breach. Standard SMB – whether SMB 1.0, 2.x, or 3.x – was designed under a fundamentally different security model: local network trust, static authentication, and broad resource access after initial login.

The incompatibilities are architectural, not configurational. No amount of hardening makes SMB meet Zero Trust requirements.

Authentication limited to NTLM and Kerberos. Standard SMB authenticates through NTLM or Kerberos via Active Directory. In OT environments where many devices cannot join AD domains – third-party HMIs, vendor laptops, legacy engineering workstations – this creates one of two outcomes: either those devices cannot access shared resources, or local accounts with static passwords are configured to bridge the gap. The second outcome is standard practice. It is also a Zero Trust violation.

No identity-based MFA. Standard SMB does not support per-session MFA. A user authenticates once to Windows or to the domain, and that authentication carries forward to SMB access. If the credential is compromised – stolen from infostealer malware, phished, harvested from an exposed NetScaler – the attacker authenticates to every SMB share the user had access to, with no additional challenge.

Protocol vulnerabilities are continuous. The CVE history of SMB is extensive: EternalBlue (CVE-2017-0144) enabled WannaCry and NotPetya, which together caused over $10 billion in damages. Recent CVEs include CVE-2020-0796 (SMBGhost), CVE-2025-33073, CVE-2025-55234 (NTLM relay), and a list that grows with every Patch Tuesday. SMB 1.0 and 2.0 remain in use across OT networks because legacy devices require them – even though both are end-of-life from a security standpoint.

Broad resource exposure. A standard SMB server exposes file shares, printer shares, and administrative shares (C$, ADMIN$, IPC$) on TCP port 445. Once an attacker reaches the server, the entire share hierarchy is enumerable. In OT networks where Historian servers, patch distribution servers, and engineering file shares share a network segment, a single compromised endpoint can reach every SMB share in the zone.

No content inspection. Standard SMB does not inspect file content during transfer. Firmware files uploaded from a compromised engineering workstation to a PLC, configuration backups restored from an encrypted Historian, and malicious payloads disguised as legitimate updates all pass through standard SMB without content validation. This is how ransomware spreads across OT networks – not through sophisticated exploits, but through SMB writing malicious files to shares that PLCs and HMIs then execute.

No granular policy enforcement. SMB permissions are file-system level – NTFS ACLs, share permissions, or group memberships. They do not consider time of day, user location, device posture, or operational context. A vendor who needs access to specific PLC configuration files during a scheduled maintenance window gets the same SMB access at 3 AM on a Sunday as during the maintenance window – unless external controls limit it.

Put together, these properties describe a protocol that actively contradicts every principle of Zero Trust. Ransomware groups have noticed. SMB remains the primary lateral movement protocol in OT environments because the protocol itself is designed to support exactly the access patterns Zero Trust is designed to prevent.

What Zero Trust File Sharing in OT Actually Requires

Zero Trust file sharing in OT networks is not a product category – it is a set of architectural requirements that any file sharing platform serving OT must meet. The requirements derive from NIST SP 800-207 (Zero Trust Architecture), IEC 62443 (industrial cybersecurity), CISA’s ZTMM guidance, and the operational realities of OT environments.

The requirements that matter for SMB replacement:

Identity-based access at every file operation. Every file operation – open, read, write, delete, rename – must be authorized against verified identity, current device posture, and active policy. Not once per session. Every operation.

Multi-factor authentication per session. Session establishment requires MFA. The MFA mechanism should integrate with agency identity infrastructure (PIV/CAC for government, Entra ID / Okta / PingFederate for enterprise) and support identity-based MFA rather than legacy shared tokens.

Content Disarm and Reconstruction for every file. Every file crossing the IT/OT boundary – and every file moving between OT security zones – must be scanned and sanitized. Known-bad content is not the bar. Unknown-structure content is the bar. CDR strips active content (macros, embedded scripts, exploit structures) from files before they enter the protected zone.

Protocol-level encryption and signing. AES-128-CCM encryption for SMB 3.0+, mandatory SMB signing to prevent relay attacks, and end-to-end encryption that does not depend on network-layer protections.

Fine-grained access policies. Beyond file-system permissions: which user, from which device, at what time, from what network location, with what device posture, can perform which specific operation on which specific file. Policy defined by operational context – not just by group membership.

Full audit trail per file operation. Every operation logged with user identity, device identity, timestamp, source and destination, operation type, file name, file hash, and policy decision. The audit trail must export to enterprise SIEM for correlation with other security events.

Zero standing SMB ports exposed to IT. The OT file sharing service should not require inbound port 445 exposed to the IT network. The architectural pattern that enables every SMB-based lateral movement technique is the architectural pattern that must be eliminated.

A comprehensive Zero Trust approach to the Purdue Model addresses these requirements at the IT/OT convergence boundary – particularly at the Level 3–4 transition where SMB-based attacks most frequently cross into OT.

How Heimdall SMB Addresses Each Zero Trust Requirement

Heimdall is TerraZone’s Zero Trust–compliant replacement for the standard Microsoft SMB protocol. It is not a wrapper around SMB, not an SMB proxy, and not a gateway that filters SMB traffic. It is a replacement protocol that provides the same file sharing functionality – the same mapped drive experience, the same file I/O operations, the same application compatibility – with the identity, authentication, and policy controls that standard SMB cannot provide.

The architectural distinction matters. An SMB proxy still speaks SMB on both sides and inherits SMB’s security properties. Heimdall terminates SMB at the client boundary and enforces Zero Trust policies before any file operation reaches the backend storage.

Heimdall’s Zero Trust Capabilities

Identity-based Multi-Factor Authentication. Heimdall supports MFA integration with Microsoft Authenticator, Telegram, WhatsApp, Duo, Okta, and any RADIUS-compatible MFA provider. The MFA challenge occurs at session establishment, and policy can require re-authentication for privileged operations.

Domainless authentication protocols. Beyond NTLM and Kerberos, Heimdall supports OpenID, SAML, RESTful, and RADIUS authentication – enabling OT devices that cannot join AD domains to authenticate through modern identity protocols. Third-party HMIs, vendor laptops, and legacy engineering workstations authenticate without local account workarounds.

Federated Identity Management. Cloud IAM integration allows users with non-AD identifiers to access multiple organizations through federated identity. For OT environments serving multiple sites, multiple plants, or multiple business units with separate identity infrastructures, federation eliminates the local-account sprawl that standard SMB creates.

Content file type and extension filtering. Policy-defined filtering by file type and extension, applied per user and per group. Engineering workstations uploading to PLCs can be restricted to specific firmware file extensions. Vendor access can be restricted to configuration files only. The policy engine enforces content policies before files reach the backend storage.

Per-operation I/O policy enforcement. Create, Modify, View, Delete, Encrypt, and Compress operations are evaluated individually against policy. A user may be authorized to view configuration files but not modify them. A vendor may be authorized to upload firmware but not delete existing files. The granularity is per-operation, not per-share.

Integration with third-party security applications. Heimdall integrates with CDR scanning engines, DLP platforms, anti-malware engines, and SIEM systems through its SDK and standard integration points. Every file operation can be scanned before completion; every operation logged for enterprise correlation.

Unified file hierarchy across multiple SMB servers. Heimdall can logically group shares from multiple backend SMB servers into a single hierarchical namespace. Users see one logical file system; the backend may span dozens of physical servers in different OT zones. The access boundary moves from each individual server to the unified Heimdall layer.

Clientless endpoint access. No software installation required on OT endpoints. Heimdall operates as a drop-in SMB protocol replacement that preserves the mapped drive experience. Legacy PLCs, RTUs, and HMIs that cannot support agent installation continue to operate without modification.

Dialect support across SMB 1.0 through 3.0. Heimdall supports CIFS / SMB 1.0, SMB 2.0.2, SMB 2.1, and SMB 3.0. OT environments with mixed equipment – modern Windows Server 2019/2022 hosts alongside legacy Windows XP Embedded or Windows 2000 industrial PCs – can migrate incrementally without forcing endpoint upgrades.

OS compatibility from Windows 2000 through Server 2022. Heimdall supports the full Windows version range present in OT environments, including legacy Windows XP / Server 2003 systems that continue to operate because the underlying industrial applications cannot be upgraded.

The Standard SMB vs. Heimdall Comparison

Security architects evaluating standard Microsoft SMB against Heimdall for OT file sharing need a structured comparison across the security dimensions that Zero Trust demands.

Dimension	Standard Microsoft SMB	Heimdall SMB	Why It Matters for OT
Authentication protocols	NTLM, Kerberos only	NTLM, Kerberos, OpenID, SAML, RESTful, RADIUS	Non-AD devices (HMIs, vendor laptops, legacy systems) can authenticate without local accounts
MFA support	Not native to protocol	Per-session MFA with major providers	Credential compromise does not translate to file access
Identity integration	Active Directory only	Federated identity + cloud IAM	Multi-site, multi-plant, multi-tenant OT environments
Content filtering	None	Per-user, per-group file type and extension filtering	Prevents ransomware file drops via SMB writes
I/O operation policy	Read/Write at file-system level	Create, Modify, View, Delete, Encrypt, Compress – per user/group	Granular control aligned with operational context
SMB signing enforcement	Configurable, often not enforced	Enforced by design	Prevents NTLM relay attacks (CVE-2025-55234 class)
CDR integration	None	Integrated with third-party CDR engines	Every file scanned before reaching backend storage
DLP integration	External only	Built-in integration points	Data exfiltration controls applied at SMB layer
Encryption	SMB 3.0+ only, negotiable	Enforced for all dialects	Legacy SMB 1.0 / 2.0 traffic protected
Namespace unification	Per-server shares	Logical hierarchy across multiple servers	Single access boundary for multi-server OT environments
Audit trail granularity	File-system level, requires separate tooling	Per-operation, identity-attributed, SIEM-ready	Complete forensic record for IR and compliance
Attack surface exposure	Port 445 exposed to accessing networks	Policy-enforced with no standing port exposure	Eliminates the primary lateral movement protocol
Legacy OT compatibility	Supported but insecure (SMB 1.0 EOL)	Full dialect support with Zero Trust enforcement	Legacy equipment continues to operate under Zero Trust
Ransomware propagation path	Primary lateral movement protocol	Policy-enforced at every operation	Blocks the technique that defines OT ransomware in 2025

The comparison reveals a pattern: every control that Zero Trust requires is either missing from standard SMB or available only through supplementary products. Heimdall integrates the controls into the protocol itself.

How Ransomware Actually Uses SMB in OT – And How Heimdall Breaks the Chain

Understanding why the SMB replacement matters requires understanding the actual attack pattern documented in 2025 incidents. This is not a hypothetical threat model – this is the documented behavior of ransomware affiliates targeting OT environments.

The Attack Chain with Standard SMB

Step 1 – Initial access. Attacker authenticates to VPN portal using credentials harvested from infostealer malware on an employee workstation. Claroty documented that 82% of verified OT intrusions in 2025 used internet-facing remote access as the initial vector.

Step 2 – Credential harvesting. Attacker accesses the Level 4 enterprise network, dumps credentials from memory using Mimikatz or equivalent tools, or exploits NTLM relay (CVE-2025-55234 class) to capture privileged credentials.

Step 3 – SMB enumeration. Using captured credentials, attacker enumerates accessible SMB shares across the enterprise network and the IDMZ (Level 3.5). Standard SMB exposes share structure to any authenticated user.

Step 4 – Lateral movement via SMB. Attacker uses SMB/PsExec or equivalent techniques to execute commands on reachable systems. Jump servers, Historian servers, patch distribution servers, and engineering workstations in the IDMZ are primary targets. Dragos documented this pattern consistently throughout 2025.

Step 5 – OT boundary crossing. From the IDMZ Historian server, attacker moves to Level 3 OT systems that accept SMB connections from the IDMZ – typically patch servers, backup servers, or engineering file shares. The SMB access required for legitimate operations is the same SMB access the attacker uses.

Step 6 – Ransomware deployment. Attacker writes ransomware executable to SMB shares. The ransomware encrypts files on reachable systems, spreads via SMB to additional systems, and ultimately reaches the ESXi hypervisors that host SCADA, HMI, Historian, and engineering workloads. The operational disruption comes from encrypting the virtualization infrastructure – not from OT-specific malware.

Step 7 – Exfiltration. Before or during encryption, attacker exfiltrates sensitive files via the same SMB paths – engineering documentation, configuration backups, credentials, and operational data that enable secondary extortion.

How Heimdall Breaks the Chain

The same attack against Heimdall-protected SMB infrastructure fails at multiple points.

Step 3 fails. SMB enumeration against Heimdall requires authentication that succeeds per-session, with MFA applied. Credentials harvested from a compromised workstation do not satisfy the MFA requirement. The enumeration attempt fails at authentication.

Step 4 fails. If the attacker somehow obtains a valid MFA token (through session hijacking or compromised MFA device), the identity-based policy engine evaluates the lateral movement attempt. A workstation in Level 4 authenticating to reach IDMZ SMB resources must match an authorized identity policy. Attack-pattern traffic – rapid enumeration, elevated privileges, off-hours access – triggers policy-based denial.

Step 5 fails. The IDMZ-to-OT SMB path is explicitly policy-controlled. Heimdall enforces per-operation policy – the Historian server’s SMB access to OT systems is scoped to specific file types, specific paths, and specific operations. Writing arbitrary executables to OT file shares fails at the Create operation policy.

Step 6 fails. CDR scanning applied to every file operation prevents ransomware executable delivery. The SMB write operation carries file content through CDR inspection. Executable payloads, script content, and suspicious file structures are blocked or stripped before reaching backend storage.

Step 7 fails. The same audit trail that enables CDR scanning generates alerts on anomalous exfiltration patterns. Rapid enumeration of high-value files, mass file access outside normal patterns, and access to files the user has not previously accessed generate SIEM alerts within seconds.

At each step, standard SMB offers no control. Heimdall enforces controls that derive from Zero Trust principles – identity verification, continuous authorization, content inspection, and full audit – which together break the attack chain that defined OT ransomware in 2025. The same approach applied more broadly is documented in a prevention-first architecture for lateral movement.

The Migration Path from Microsoft SMB to Heimdall

Security architects planning this migration face a core operational constraint: SMB is load-bearing in OT environments. Firmware updates depend on it. Historian data ingestion depends on it. Configuration backup depends on it. The migration cannot disrupt production operations.

The following migration path is structured for a typical OT environment with 50–500 SMB endpoints, multiple Purdue zones, and mixed legacy/modern Windows systems. Total duration: 12–16 weeks.

Phase 1: Discovery and Baseline (Weeks 1–3)

Inventory every SMB share, every SMB client, and every SMB communication path in the OT environment. The discovery phase is often the first time OT security teams have complete visibility into what SMB is actually doing in their networks.

Key deliverables:

• Map of all SMB servers by Purdue level
• List of all SMB clients with OS version, SMB dialect, and last activity
• Matrix of which clients connect to which servers for which purposes
• Identification of legacy systems (SMB 1.0, Windows XP Embedded, etc.) that require special handling
• Documentation of existing MFA coverage (almost certainly limited to domain login only)

Phase 2: Heimdall Deployment and Policy Design (Weeks 4–6)

Deploy Heimdall infrastructure alongside existing SMB servers. No production traffic is migrated yet – this phase stands up the platform and develops the policy model based on Phase 1 discovery.

Key activities:

• Deploy Heimdall Core servers with HA configuration
• Integrate with enterprise identity infrastructure (AD, Entra ID, Okta, PingFederate)
• Configure MFA integration (Duo, Okta Verify, PIV/CAC for government)
• Integrate with CDR scanning engine, DLP platform, and SIEM
• Define policy groups by user role, device type, and operational function
• Define per-operation policies for file types relevant to OT (firmware, configurations, backups, logs)

Phase 3: Pilot Migration (Weeks 7–9)

Migrate a controlled pilot workload – typically a non-critical SMB share used by a limited user group. The pilot validates the Heimdall deployment, policy enforcement, and user experience before broader migration.

Pilot selection criteria:

• Non-critical share (not firmware distribution, not Historian)
• Defined user population (typically 5–20 users)
• Measurable success metrics (authentication success rate, MFA completion time, policy enforcement accuracy, user feedback)
• Easy rollback if issues arise

The pilot runs for minimum 2 weeks. Policy adjustments based on pilot feedback feed into Phase 4.

Phase 4: Phased Migration by Purdue Zone (Weeks 10–14)

Migrate SMB workloads in reverse Purdue order – Level 4 (enterprise) first, Level 3.5 (IDMZ) second, Level 3 (OT site operations) third, and Level 2 (area supervisory) last. This sequence prioritizes the highest-risk attack paths first while preserving production operations until last.

Each zone migration follows the same pattern:

• Deploy Heimdall in parallel with existing SMB
• Migrate user populations incrementally – not all at once
• Validate each migration with 2-week parallel operation
• Decommission the legacy SMB share only after Heimdall operation is validated
• Document policy adjustments before proceeding to the next zone

During this phase, the existing SMB infrastructure remains operational. No user loses access to required file shares; they gain access through the Heimdall path while the legacy path is still available as fallback.

Phase 5: Legacy SMB Decommission (Weeks 15–16)

With all user populations migrated and validated on Heimdall, the existing SMB infrastructure is decommissioned.

Decommission activities:

• Block inbound port 445 access to legacy SMB servers from client subnets
• Monitor for legitimate authentication attempts that indicate missed migration
• Remove SMB 1.0 and SMB 2.0 support from all servers
• Decommission legacy file servers whose only purpose was SMB hosting
• Export final audit logs for compliance retention
• Update network diagrams, firewall rules, and System Security Plans

The final deliverable is not just a migrated file sharing platform – it is the removal of SMB as an attack surface in the OT environment.

Compliance Mapping: SMB vs. Heimdall Against OT Standards

Security architects must justify this migration against explicit compliance requirements. The following mapping addresses the standards most commonly cited in OT environments.

Standard	Standard SMB Compliance	Heimdall Compliance
IEC 62443 FR1 (Identification and Authentication)	Meets basic requirement with AD authentication	Exceeds with MFA, federated identity, and domainless authentication
IEC 62443 FR2 (Use Control)	Limited to file-system permissions	Per-operation policy enforcement aligned with operational context
IEC 62443 FR3 (System Integrity)	No content inspection	CDR scanning integrated into file operations
IEC 62443 FR5 (Restricted Data Flow)	Does not enforce at protocol level	Enforced per-file, per-operation, per-identity
IEC 62443 FR6 (Timely Response to Events)	Requires external audit tooling	Native audit trail with SIEM integration
NIST SP 800-82 Rev 3	Meets baseline file sharing recommendation	Exceeds advanced recommendations for identity-based access to OT assets
NIST SP 800-207 (Zero Trust)	Does not align – implicit trust after authentication	Directly aligned – per-session verification, identity-based policy
CISA ZTMM – Data Pillar	Scores at Traditional maturity	Scores at Advanced/Optimal maturity
NERC CIP-005 (Electronic Security Perimeters)	Meets perimeter definition only	Enforces perimeter at each file operation
TSA Security Directive (Pipeline)	Meets basic access control requirement	Meets advanced requirement for dynamic access control
EO 14028 / OMB M-22-09 (Federal)	Does not align – network-level file sharing	Directly aligned with application-level Zero Trust access

For government agencies, the compliance gap is particularly stark. Standard SMB cannot meet the Zero Trust requirements that EO 14028 and OMB M-22-09 mandate – agencies running standard SMB in OT environments have a documented compliance gap. Heimdall closes the gap architecturally. A more comprehensive view of the full connectivity consolidation approach is available in a guide on replacing multiple OT security vendors with a single Zero Trust platform.

How Heimdall Integrates with the Broader TerraZone Architecture

Heimdall is not deployed as an isolated product – it is one layer of TerraZone’s truePass platform architecture, which provides integrated coverage for the full range of OT connectivity requirements:

Layer 1 – Reverse Access. Zero-inbound-port architecture eliminates the firewall attack surface that SMB and other protocols traditionally require. The internal OT network is not reachable from outside except through policy-authorized sessions.

Layer 2 – Heimdall SMB Proxy with CDR. The Zero Trust SMB replacement documented in this article. Content Disarm and Reconstruction applied to every file operation. Identity-based access with MFA.

Layer 3 – Zero Trust Application Access. Per-session RDP, SSH, HTTP, and TCP access with MFA, recording, and unified audit – the companion capability to Heimdall for interactive access scenarios.

The three layers together address the full range of IT/OT connectivity requirements – file sharing (Heimdall), interactive access (ZTNA), and infrastructure protection (Reverse Access) – in a single architecture. For OT environments with SCADA, critical infrastructure, or strict isolation requirements, truePass Gravity delivers all three layers as a purpose-built OT platform.

Frequently Asked Questions

Do we have to migrate all SMB at once?

No. The phased migration plan specifically supports incremental migration. Users migrate by group and by Purdue zone. Existing SMB infrastructure remains operational until each population is validated on Heimdall. A fully phased migration typically completes in 12–16 weeks for 50–500 endpoints.

Will Heimdall break legacy OT applications that depend on SMB?

Heimdall is a drop-in SMB protocol replacement – it preserves the mapped drive experience and supports SMB dialects from 1.0 through 3.0. Legacy applications that use standard SMB calls continue to operate. The controls happen at the Heimdall layer, not at the application layer.

What about our Historian servers that pull data from 40+ PLCs?

Historian data flows are a common Heimdall use case. The Historian authenticates once (with MFA) to the Heimdall server and reads data from the unified namespace that presents all 40 PLCs as a single hierarchical file system. Policy restricts the Historian’s access to read operations on specific file types from specific PLC paths. The access is more controlled than standard SMB, not less functional.

How does Heimdall handle vendor access for firmware updates?

Vendor access is a defined policy scenario in Heimdall. The vendor authenticates with a named account (not shared credentials) through MFA. Policy grants the vendor specific write access to specific firmware directories on specific PLCs during a defined maintenance window. CDR scans the firmware files before they reach PLC storage. The full operation is recorded in the audit trail with vendor identity attribution.

Can Heimdall coexist with Microsoft Defender for Endpoint and our existing AV?

Yes. Heimdall integrates with enterprise security tooling through defined integration points – CDR engines, DLP platforms, SIEM systems, and endpoint security tools. The integration extends existing security investments rather than replacing them. Defender for Endpoint on OT Windows hosts continues to operate normally; Heimdall adds the network-layer controls that endpoint security cannot provide.

What is the performance impact on file operations?

File operations through Heimdall include MFA at session establishment and per-operation policy evaluation. The policy evaluation adds low-millisecond latency per operation. For bulk file transfers (firmware distribution, backup jobs), the per-operation overhead is negligible. For interactive file access (user browsing, occasional reads), the user experience is indistinguishable from standard SMB. Initial MFA adds a one-time challenge at session start.

How does Heimdall handle air-gapped or isolated OT networks?

Heimdall is deployed on-premises and operates entirely within agency or enterprise-controlled infrastructure. No cloud dependency, no external data path. For genuinely air-gapped networks, Heimdall can deploy in isolated mode with local identity infrastructure and local audit storage. For networks with controlled IT/OT connectivity, Heimdall provides the policy-enforced, auditable file transfer path that replaces both the file share and the supplementary products that typically surround it.

Conclusion

For security architects designing OT network defenses in 2026, standard Microsoft SMB is no longer a defensible protocol choice for file sharing between IT and OT – or between OT security zones. The CVE history is continuous. The ransomware propagation pattern is documented. The Zero Trust compliance gap is architectural. CISA has added SMB vulnerabilities to the Known Exploited Vulnerabilities catalog with federal remediation deadlines. Dragos has documented SMB as the primary lateral movement protocol for OT ransomware in 2025.

Patching addresses specific CVEs. It does not address the architectural reality that SMB was designed under a pre-Zero-Trust security model and cannot be retrofitted to meet current requirements. A zero trust SMB replacement OT networks can actually deploy – not a proxy, not a filter, not a compensating control – requires a protocol replacement that integrates identity-based access, MFA, CDR, per-operation policy, and full audit into the file sharing layer itself.

Heimdall provides that replacement. The migration is phased, non-disruptive, and maps directly to the compliance standards – IEC 62443, NIST SP 800-207, CISA ZTMM, EO 14028 – that OT environments must meet. The 12-to-16-week migration path preserves production operations throughout. The outcome is an OT environment where SMB is no longer the ransomware propagation protocol it has been for the last decade – it is a controlled, audited, Zero Trust–compliant file sharing layer that meets the architecture’s security requirements by design.

The protocol that ransomware affiliates used to turn credential compromise into OT shutdown becomes the protocol that stops them at the authentication, authorization, content, and audit boundaries – all at once, all per operation.