Why Are CISOs Rethinking Data Diode Architectures in 2026?
The data diode market is projected to reach $1.37 billion in 2026, growing at 11.2% CAGR. Organizations are buying more diodes, not fewer. So why are CISOs simultaneously planning migrations away from diode-centric architectures?
Because the diode is not the problem. The patchwork around it is.
Dragos tracked 119 ransomware groups targeting industrial organizations in 2025 – up 64% from 80 groups in 2024. These groups did not attack data diodes. They attacked the VPN concentrators, jump servers, and remote access tools that organizations deploy alongside diodes because the diode cannot handle interactive sessions, bidirectional file sharing, or vendor remote access. The Waterfall Threat Report 2026 documented 57 cyber attacks causing physical consequences in heavy industry in 2025. The Jaguar Land Rover ransomware event in September 2025 shut down global production for over a month at a reported cost of $2.5 billion.
The CISO playbook data diode migration is not about abandoning the security principles that diodes represent. It is about extending those principles – zero inbound ports, invisible infrastructure, deny-all by default – to the 70–80% of IT/OT connectivity that diodes structurally cannot handle.
This playbook provides a week-by-week execution plan for completing that migration in 6 months, with parallel operation, rollback criteria at every phase, and measurable success metrics.
What Does the Current State Look Like in Most Organizations?
Before building a migration plan, CISOs need an honest inventory of what is actually deployed at the IT/OT boundary. In most critical infrastructure organizations, the picture includes:
The diode layer – handling unidirectional data flows: historian replication, syslog forwarding, SCADA telemetry to enterprise analytics. This works. The physics is sound. It stays until proven replaceable.
The supplementary layer – everything the diode cannot handle:
Product | What It Handles | Why It Exists | Security Risk |
VPN concentrator | Employee and vendor remote access | Diode cannot support interactive sessions | Most exploited OT attack vector (Claroty: 82% of OT intrusions) |
Jump server | RDP to SCADA, historian, engineering workstations | VPN grants network access; jump server provides RDP | Lateral movement enabler – network-level access to SCADA zone |
SMB proxy / file gateway | Bidirectional file sharing (firmware, configs, vendor deliverables) | Diode is unidirectional; files must flow both directions | Separate product, separate logs, separate policies |
Point TCP connectors | Specific application integrations | Each bidirectional app needs its own connector | Often undocumented, unmonitored, embedded in vendor products |
The gap layer – connectivity that exists but nobody owns: embedded vendor tunnels, persistent SSH sessions that were “temporary” three years ago, direct TCP connections between IT applications and OT databases with no access policy.
The CISO playbook data diode migration starts by documenting all three layers – not just the first two.
Can You Migrate from Data Diodes to Zero Trust Without Downtime?
Yes. The migration is designed as parallel operation – the diode and the platform run simultaneously throughout. At no point does the CISO remove a security control before its replacement is proven operational. The diode continues handling one-way flows unchanged while the platform takes over interactive access, file sharing, and vendor connectivity.
The migration is not a cutover. It is a progressive transfer of connectivity types from supplementary products (VPN, jump server, SMB proxy, TCP connectors) to the consolidated platform – with the diode retained for regulated unidirectional flows.
What Are the Prerequisites Before Starting?
Do You Have a Complete Connectivity Map?
Most CISOs discover that their IT/OT connectivity is 30–50% larger than documented. Before starting the migration, complete a connectivity inventory that covers:
- Every firewall rule permitting inbound traffic to OT zones (not just the rules you know about – export the full rule set)
- Every VPN tunnel terminating in or near OT environments
- Every jump server with RDP or SSH access to OT resources
- Every file transfer mechanism: SMB shares, SFTP servers, SCP scripts, manual USB transfers
- Every embedded vendor connector or persistent session
- Every user and service account with access to OT resources
This inventory typically takes 2–3 weeks and produces surprises. The 2025 SANS ICS/OT survey found that 40% of OT security incidents caused operational disruption – and many of those incidents entered through connectivity paths the organization did not know existed.
Do You Have Executive Sponsorship?
The migration touches IT infrastructure (VPN), OT operations (SCADA access), vendor management (third-party access), compliance (audit trails), and procurement (vendor consolidation). Without a C-level sponsor – typically the CISO with CIO endorsement – cross-functional decisions will stall.
Have You Identified the Regulatory Constraints?
For each one-way data flow currently handled by the diode, determine whether the applicable regulation mandates physical unidirectional enforcement or simply requires outbound-only data transfer with appropriate controls. This distinction determines which flows can migrate to the platform and which flows the diode must retain.
Regulatory Requirement | Physical Diode Mandated? | Platform Eligible? |
NRC RG 5.71 (nuclear) | Yes – hardware-enforced unidirectional | No – retain diode |
IEC 62443 SL4 (state-sponsored threat) | Yes – physical isolation required | No – retain diode |
IEC 62443 SL3 (dedicated attacker) | No – logical isolation acceptable | Yes |
NIST SP 800-82 Rev. 3 (OT segmentation) | No – recommends diodes, does not mandate | Yes – reverse-access satisfies segmentation requirements |
NERC CIP (energy) | No – requires electronic access controls | Yes |
NIS2 (EU essential entities) | No – requires risk-based access controls | Yes |
DoD DTM 25-003 (Zero Trust for OT) | No – mandates Zero Trust implementation |
In most organizations, 80–90% of IT/OT connectivity flows are platform-eligible. The remaining 10–20% stay on the diode because regulation requires it.
The 6-Month Playbook: Week-by-Week Execution
Month 1: Foundation (Weeks 1–4)
What happens in Month 1?
Month 1 is assessment and deployment – no production traffic moves to the platform yet. The goal is to deploy the infrastructure, integrate identity, and validate connectivity in a test configuration.
Week 1–2: Deploy Infrastructure
Task | Details | Success Criteria |
Deploy Access Controller | IDMZ or SCADA zone; outbound HTTPS only | Controller establishes outbound TLS tunnel to Gateway |
Deploy Access Gateway | DMZ; public-facing HTTPS for authentication | Gateway reachable for authentication; no inbound rules to OT |
PKI configuration | Mutual TLS between Controller and Gateway | Certificate-based trust established; no self-signed certs in production |
Firewall validation | Verify no new inbound rules were created | Firewall rule export matches baseline – outbound 443 only |
Week 3: Identity Integration
Connect the Access Gateway to the organization’s identity provider (Active Directory, Okta, Entra ID). Map existing user groups to OT resource access policies. Configure MFA (FIDO2 preferred; authenticator app as fallback; SMS OTP for vendors who cannot use hardware tokens).
Week 4: Test Configuration
Configure 3–5 test RDP sessions to non-production OT resources (test SCADA workstation, historian dev instance). Validate the complete path: authentication → MFA → device posture check → policy evaluation → RDP session → session recording → auto-termination at time limit. Do not touch production traffic yet.
Rollback criteria for Month 1: If the outbound tunnel cannot be established without opening inbound firewall rules, stop and resolve. If MFA integration fails with the identity provider, stop and resolve. The platform must operate with zero inbound ports or the migration does not proceed.
Month 2: Interactive Access Migration (Weeks 5–8)
What is the highest-risk component to replace first?
The VPN concentrator – because it is internet-facing, it is the primary initial access vector for ransomware in OT environments, and its removal produces the largest immediate reduction in attack surface.
Week 5–6: Migrate Employee RDP/SSH Access
Move employee interactive sessions (RDP to SCADA workstations, SSH to engineering servers, HTTP to internal web applications) from the VPN + jump server path to the platform. Per-workstation policies replace network-level VPN access. Each session now requires named identity + MFA + device posture + session recording.
Session Type | Before (VPN + Jump Server) | After (Platform) |
RDP to SCADA-HMI-01 | VPN → jump server → RDP (network-level) | Direct RDP via outbound tunnel (application-level) |
SSH to ENG-SERVER-03 | VPN → jump server → SSH (network-level) | Direct SSH via outbound tunnel (application-level) |
HTTP to internal web app | VPN → browser (network-level) | Direct HTTPS via outbound tunnel (application-level) |
Week 7: Migrate Vendor Access
Vendor access requires different policies than employee access: named individual accounts (not shared), pre-approved time windows, mandatory session recording, approval workflows, and auto-termination at the maintenance window boundary.
Week 8: Decommission VPN and Jump Server
Once all interactive sessions route through the platform:
- Remove VPN inbound firewall rules
- Decommission VPN concentrator
- Remove jump server inbound firewall rules
- Decommission jump server
- Run external scan (Shodan, Censys) – verify zero discoverable services
Rollback criteria for Month 2: If any user cannot establish an RDP session through the platform within the acceptable latency threshold (typically < 10ms additional), the VPN remains operational for that user until resolved. Rollback is per-user, not system-wide.
Success metrics at Month 2 completion:
Metric | Target |
Inbound Port Exposure Index | Reduced by 60–80% (VPN and jump server ports removed) |
VPN concentrator status | Decommissioned |
Jump server status | Decommissioned |
Session Attribution Coverage | 90%+ for interactive sessions |
External scan results | Zero discoverable services related to VPN or jump server |
Month 3–4: File Sharing Migration (Weeks 9–16)
How do you migrate bidirectional file sharing without disrupting operations?
File sharing migration is the most operationally sensitive phase because it touches daily workflows: firmware updates, configuration backups, vendor deliverables, engineering document exchange. The migration path is parallel: the platform’s SMB Proxy runs alongside the existing file gateway for 4 weeks before cutover.
Week 9–10: Configure SMB Proxy on the Platform
Set up the platform’s integrated SMB Proxy with Kerberos/NTLM authentication, SMB Signing, end-to-end encryption, and CDR (Content Disarm & Reconstruction) scanning. Map existing SMB shares to the new proxy.
Week 11–12: Parallel Operation
Both the existing file gateway and the platform SMB Proxy operate simultaneously. New file transfers route through the platform. Existing automated transfers continue on the legacy gateway. Monitor for compatibility issues, performance differences, and CDR scanning impact on file integrity.
Week 13–14: Cutover
Migrate remaining file transfers to the platform. The three-layer approach to securing IT-to-OT connectivity now handles both interactive sessions (Layer 3) and file sharing (Layer 2) through a single platform.
Week 15–16: Decommission Legacy File Gateway
Remove standalone SMB proxy / file gateway. Update firewall rules. Validate that all file transfers complete successfully through the platform with CDR scanning, encryption, and full audit trails.
Rollback criteria for Month 3–4: If CDR scanning corrupts a specific file type critical to operations (certain proprietary SCADA configuration formats), create a CDR exception rule for that file type with compensating controls (AV scanning only) rather than rolling back the entire migration.
Month 5: One-Way Flow Evaluation (Weeks 17–20)
Should you replace the data diode for historian replication and syslog forwarding?
This is a case-by-case decision based on regulatory requirements. For each one-way flow currently on the diode, evaluate:
Question | If Yes | If No |
Does regulation mandate physical unidirectional enforcement for this flow? | Retain diode for this flow | Proceed to evaluation |
Does the platform’s outbound-only architecture provide equivalent security for this flow? | Migrate to platform | Retain diode |
Does migrating this flow to the platform add identity-based access control and unified audit? | Strong case for migration | Weaker case – evaluate operational benefit |
For historian replication and syslog forwarding – where the requirement is outbound data transfer, not physical unidirectionality – the platform’s reverse-access architecture typically provides equivalent protection with the added benefit of identity, policy, and unified audit. Most organizations migrate these flows.
For nuclear safety data (RG 5.71) and defense classified data (SL4) – retain the diode. This is not optional. The regulation mandates hardware-enforced unidirectional flow.
Month 6: Steady State and Hardening (Weeks 21–24)
What does the end state look like?
Connectivity Type | Where It Runs | Security Controls |
Interactive sessions (RDP, SSH, HTTP) | Platform | Named identity + MFA + device posture + per-workstation policy + session recording |
Bidirectional file sharing (SMB) | Platform | Kerberos/NTLM + SMB Signing + encryption + CDR scanning + audit trail |
Historian replication (non-regulated) | Platform | Outbound-only transfer + identity + unified audit |
Syslog forwarding (non-regulated) | Platform | Outbound-only transfer + unified audit |
Nuclear/defense one-way flows (regulated) | Data Diode | Hardware-enforced unidirectional – unchanged |
Week 21–22: Final Hardening
- Set all OT zone firewalls to deny-all inbound – no exceptions other than the diode’s regulated flows
- Run comprehensive external scan across all facility IP ranges – target: zero discoverable services
- Penetration test targeting IT/OT boundary connectivity
- Validate session recording completeness for every connectivity type
Week 23–24: Documentation and Compliance
- Complete IEC 62443 FR mapping for all connectivity types
- Document the regulatory decision for each flow (platform vs. diode retention)
- Export unified audit trail samples for compliance reviewers
- Finalize the CISO board presentation: current state → target state → migration evidence → KPI improvements
What Are the Most Common Migration Failures and How Do You Prevent Them?
Failure 1: Incomplete Connectivity Inventory
What goes wrong: The migration plan covers known VPN tunnels and jump servers but misses embedded vendor connectors, persistent SSH sessions, and direct database connections. After VPN decommission, these “shadow connectivity” paths remain – unmonitored and unprotected.
How to prevent it: In Week 1, export the full firewall rule set (not just the rules you know about) and run an internal network flow analysis for 7 days to capture all active connections crossing the IT/OT boundary. Every flow that appears in the traffic analysis but not in the documented inventory is a migration gap.
Failure 2: Vendor Resistance to Named Accounts
What goes wrong: Vendors refuse to use individual accounts because their technicians rotate frequently. They insist on shared credentials “like they always have.” The CISO compromises, and vendor access remains unattributed.
How to prevent it: Write the named-account requirement into the vendor contract renewal. Provide the vendor with a self-service portal for provisioning individual accounts. If the vendor cannot comply, escalate to vendor management – not to a shared-credential exception.
Failure 3: Keeping the VPN “Just in Case”
What goes wrong: After migrating all interactive sessions to the platform, the VPN concentrator remains powered on with its inbound firewall rules intact because someone is “not sure” all sessions have been migrated. The attack surface persists.
How to prevent it: The success criterion for Month 2 is explicit: external scan confirms zero discoverable services. If the VPN is still running, the scan will find it. Make the scan the decision authority, not the comfort level of the team.
Failure 4: Skipping CDR on File Transfers
What goes wrong: CDR scanning is disabled during file sharing migration because it “slows down transfers” or “corrupts certain file types.” Files enter the OT zone unscanned.
How to prevent it: Test CDR compatibility with all OT file types during the parallel operation phase (Weeks 11–12). Create narrow exception rules for specific file types that require alternate scanning – do not disable CDR globally.
Failure 5: No Rollback Plan Per Phase
What goes wrong: The migration is planned as a one-way process. When an issue arises in Month 3, the team has no documented way to return to the previous state without re-deploying decommissioned infrastructure.
How to prevent it: Each phase has explicit rollback criteria defined before execution. Decommissioned VPN and jump server configurations are archived (not deleted) for 90 days. The diode continues operating unchanged throughout – it is always available as the fallback for one-way flows.
How Do You Measure Migration Success?
Dashboard: Before and After
KPI | Before Migration | After Migration (Month 6) | Change |
Inbound Port Exposure Index | 18+ | 0 (platform) + diode-specific ports only | -95%+ |
Vendor count | 4–6 | 1–2 (platform + diode if retained) | -70% |
Products managing IT/OT connectivity | 5+ (diode, VPN, jump server, SMB proxy, TCP connectors) | 1–2 | -70% |
Session Attribution Coverage | 40–60% (vendor and legacy gaps) | 95%+ | +50pts |
MTTI-OT (investigation time) | 3–4 hours | < 15 minutes | -95% |
Zero Trust Coverage | 30–40% | 90%+ | +55pts |
External scan: discoverable OT services | 2–5 services | 0 | -100% |
SIEM log sources for IT/OT connectivity | 4–6 separate formats | 1 Syslog feed | -80% |
How Do You Present This to the Board?
Three slides:
Slide 1 – Before: Diagram showing diode + 4 supplementary products, 5 vendors, 5 attack surfaces, fragmented logs. Include the cost table: total annual spend across all products and integration labor.
Slide 2 – After: Diagram showing platform + diode (retained where mandated), 1–2 vendors, 1 attack surface with zero inbound ports, unified audit. Include the consolidated cost comparison.
Slide 3 – Evidence: KPI dashboard showing before/after values for all metrics. External scan results. Session recording sample. Compliance mapping.
The board does not need technical architecture diagrams. They need: fewer vendors, lower cost, smaller attack surface, faster investigation, measurable compliance progress.
Frequently Asked Questions
How long does the migration actually take?
The 6-month timeline covers assessment through steady state. The highest-risk phase (VPN and jump server decommission) completes in Month 2. File sharing migration completes in Month 4. The remaining 2 months are for one-way flow evaluation and hardening. Organizations with fewer connectivity types or simpler architectures can compress to 4 months; organizations with complex regulatory environments may extend to 9 months for the diode evaluation phase.
Can we keep the data diode for everything and add the platform for interactive access only?
Yes – and this is the recommended starting point for organizations with strong regulatory constraints. The platform handles RDP, SSH, HTTP, and file sharing. The diode handles all one-way flows. The supplementary products (VPN, jump server, standalone SMB proxy) are eliminated. Over time, the CISO evaluates whether non-regulated one-way flows can also migrate to the platform.
What happens if the platform has a software vulnerability?
Unlike a data diode (which has no software attack surface), a software-based platform can have vulnerabilities. The architectural mitigation is that the platform operates with zero inbound ports – the Access Controller initiates all connections outbound. An attacker would need to compromise the outbound tunnel itself (encrypted TLS 1.2/1.3) from a position already inside the OT network. This is a fundamentally different risk profile than an internet-facing VPN concentrator with an inbound port.
Does the migration require an OT outage?
No. The platform deploys in parallel with existing infrastructure. Production SCADA systems are not modified. The Access Controller is a new component that connects outbound – it does not require changes to existing OT workstations, PLCs, or network infrastructure. Users switch from VPN + jump server to the platform; the SCADA workstation is unaware of the change.
What about air-gapped environments?
Truly air-gapped environments (no network connectivity between IT and OT) are outside the scope of this migration – by definition, they have no connectivity to migrate. The playbook applies to environments that claim to be air-gapped but in practice have VPN tunnels, jump servers, or vendor remote access bridging the gap. In the SANS 2025 ICS/OT survey, the majority of organizations reporting OT security incidents had some form of IT/OT connectivity in place.
How does this affect IEC 62443 compliance?
The migration strengthens IEC 62443 compliance for FR1 (identification and authentication), FR2 (use control), FR3 (system integrity), FR5 (restricted data flow), and FR6 (timely response to events) by adding identity-based access control, session recording, and unified audit to connectivity that previously had none. For FR4 (data confidentiality) and FR7 (resource availability), the zero-inbound-port architecture provides equivalent or superior protection to the supplementary products it replaces. The only area where the diode provides stronger compliance is IEC 62443 SL4 physical isolation – which is why the diode is retained for those specific flows.
What is the cost difference?
A typical critical infrastructure site running diode + VPN + jump server + SMB proxy + TCP connectors spends $160K–$380K in hardware plus $30K–$80K annually in maintenance across 4–6 vendors. The consolidated platform eliminates the VPN, jump server, standalone SMB proxy, and TCP connectors – reducing the supplementary spend by 70–80%. The diode cost remains for sites that retain it for regulated flows. The operational savings in integration labor (single console vs. 4+ consoles) and incident response speed (single audit trail vs. fragmented logs) are typically larger than the hardware savings.
Conclusion
The CISO playbook data diode migration is not a technology replacement project. It is an architectural consolidation that eliminates the supplementary products – VPN, jump server, SMB proxy, TCP connectors – that create more attack surface than the diode removes. The diode stays where regulation demands it. Everything else consolidates onto a single platform with zero inbound ports, unified policy enforcement, per-session MFA and recording, and a single audit trail.
Six months. Four phases. Measurable success criteria at every phase boundary. Explicit rollback procedures at every step. And at the end: fewer vendors, smaller attack surface, faster investigations, and a compliance posture that aligns with where every major regulatory framework is heading – not where it was when the diode was deployed.
Start with the connectivity inventory. Deploy the platform in parallel. Migrate the highest-risk component first. Measure. Proceed.
