The Department of War (DoW) has issued a definitive mandate to adopt Zero Trust (ZT) principles across Operational Technology (OT) and Control Systems. This directive, codified in Zero Trust for Operational Technology - Scope and Purpose and underpinned by DTM 25-003, represents a shift from perimeter-centric security models to a data-centric, continuously authenticated architecture. The urgency of this transition stems from the convergence of IT and OT environments, where legacy industrial protocols, flat network topologies, and air-gapped assumptions no longer provide sufficient defense against sophisticated nation-state actors.
This paper analyzes how BlastWave’s software-defined perimeter (SDP) and microsegmentation architecture enable DoW Agencies to comply with the Zero Trust Operational Technology Activities Outcomes framework without disrupting the operational environment.
BlastWave directly supports 20 of the 86 Target Level requirements and indirectly supports 14 other requirements that require API or BlastWave input to achieve comprehensive compliance. The protection offered by BlastWave is the first step in Zero Trust Compliance, providing “air cover” for agencies as they implement the remaining Target and Advanced requirements.
BlastWave serves as a foundational architectural pillar for the Network, User, and Device pillars, specifically addressing critical requirements for secure remote access, network cloaking, and lateral movement prevention through microsegmentation. By acting as a secure cryptographic overlay that renders critical assets invisible to unauthorized entities, BlastWave directly addresses the DoW’s requirement to “transition away from trusted networks” to an environment of “continuous authentication and finegrained policy enforcement”. BlastWave uniquely accomplishes this without requiring changes to the underlying network, enabling a transition from a firewall- and VPNbased architecture to a Zero Trust network with minimal disruption to the OT network.
While BlastWave provides the essential connectivity and segmentation fabric, Zero Trust is inherently an ecosystem approach. No single product meets all the requirements of the seven pillars. Therefore, the analysis includes a gap analysis to identify the specific “Partner Product Classes” such as Enterprise SIEM, Identity Providers (IdP), and Endpoint Detection and Response (EDR) required to complement the BlastWave deployment and achieve full compliance with the Target and Advanced levels of the DoW mandate.
The fundamental premise of the DoW’s Zero Trust strategy is the recognition that the “trusted network” concept is obsolete. In traditional OT environments, security relied heavily on the Purdue Model’s stratified architecture, assuming that separation between the Enterprise Layer (Level 4/5) and the Process Control Layer (Level 0-2) via firewalls or air gaps was sufficient. However, the digitization of industrial processes, the requirement for predictive maintenance data, and the integration of IIoT (Industrial Internet of Things) devices have perforated these boundaries.
The ZT for OT Activities and Outcomes explicitly states that applying standard IT security approaches to OT can be “ineffective and potentially dangerous”. OT environments prioritize operational availability and safety above all else. Active scanning can crash a Programmable Logic Controller (PLC); automated patching can violate safety certifications; and multifactor authentication (MFA) can impede emergency response if not designed for the factory floor.
The DoW has adapted its initial IT-based Zero Trust requirements with new requirements tailored for OT, and released its “fan chart” with the requirements, shown below:
BlastWave’s architecture addresses this dichotomy by functioning as a non-intrusive overlay. It does not require re-architecting the legacy switching fabric or upgrading the firmware of fragile controllers. Instead, it wraps these assets in a secure enclave, satisfying the DoW’s requirement for “continuous and reliable operations” while enforcing rigorous access controls.
The DoW guidance simplifies the traditional Purdue Model into two primary zones for Zero Trust implementation:
The mandate requires that ZT principles apply “up to and including the point of demarcation” and extend to the boundary of Weapon Systems or Defense Critical Infrastructure.
BlastWave acts as the unified policy enforcement engine across both layers. By deploying gateways at the ingress of the Operational Layer and shielding the Process Control Layer, BlastWave ensures that a compromise in the enterprise IT network cannot propagate laterally into the critical control zone, a direct response to the “prevent lateral movement” objective of the Target Level ZT activities. In fact, the entire Operational and Process Control Layers are undiscoverable to the Enterprise IT Layer due to BlastWave’s Network Cloaking.
The compliance framework differentiates between Target Level and Advanced Level activities.
This analysis demonstrates that BlastWave enables fast Target Level compliance, providing an immediate “stop-gap” against lateral movement. Since BlastWave acts as an overlay ot the OT environment, it deploys far more quickly than firewall-based protection mechanisms, and the most challenging requirements to comply with (the protection and segmentation mandates) can lay the foundation for total compliance. At the same time, its API-first architecture lays the groundwork for Advanced Level orchestration.
The following sections specify which activities in the OT Fan Chart BlastWave directly impact compliance, as well as those in which BlastWave contributes to multi-system or APIbased compliance.
The User pillar focuses on ensuring that only authorized human actors can access OT resources. Given the prevalence of shared accounts and static passwords in legacy OT, this is a significant modernization challenge.
Requirement Analysis: The DoW mandates identifying all user accounts (local, privileged, and shared) and implementing an Authorized Credentialing Service. The goal is to migrate away from hardcoding local “admin/admin” credentials in PLCs towards a centralized Identity Provider (IdP).
BlastWave Compliance: BlastWave integrates with DoW-approved IdPs (e.g., Azure AD, Okta, CAC/PIV systems) to serve as the Policy Enforcement Point (PEP). While BlastWave is not the directory itself (Activity 1.1.1.OT is a process/partner requirement), it enforces the directory’s authority.
If an admin disables a user in the central IdP, BlastWave immediately revokes their network access to the OT enclave, fulfilling the outcome of Activity 1.2.1.OT by ensuring rigorous enforcement of the attributes defined in the credentialing service before establishing a network session. BlastWave also supports a self-contained passwordless MFA and hardware (FIDO2 keys) options to supplement partner authentication.
Requirement Analysis: This Target Level activity requires “strict role-based access controls before access or connection”. It explicitly highlights remote and third-party access, requiring that vendors access only the specific equipment they maintain. This requirement means that traditional VPNs are not sufficient because they are often binary; once a vendor tunnels in, they usually have network-level visibility of the entire subnet.
BlastWave Solution: BlastWave replaces the VPN concentrator with a micro-perimeter. Through its “Software-Defined Perimeter” architecture, segmentation configurations grant an authenticated user access to a “Segment of One.” A technician servicing a Siemens turbine sees only that turbine. They cannot ping the neighboring Rockwell controller or scan the network for other assets, thereby failing to satisfy the requirement to limit third-party access to the “account of least privilege required to perform work”.
Requirement Analysis: MFA implementation is non-negotiable for Target Level ZT. However, the guidance acknowledges the need for “alternative authoritative credentialing solutions” where standard IT MFA might interfere with operations (e.g., in a clean room or tactical environment).
BlastWave Solution: BlastWave supports FIDO2-compliant passwordless authentication, allowing operators to authenticate using hardware tokens (like YubiKeys) or biometrics, which are faster and more secure than typing complex passwords on HMI touchscreens. By enforcing this MFA at the network ingress, BlastWave ensures that no packet reaches the OT asset until strong authentication is complete, fulfilling the “Verify Explicitly” principle.
Requirement Analysis: The mandate requires procuring a PAM solution to manage critical privileged use cases.
BlastWave Solution or Partner Integration: BlastAccess can meet the requirements of a PAM solution that leverages BlastShield’s authentication capabilities. For networks that already have a PAM in place, BlastWave serves as the secure transport layer for PAM. While a PAM product manages vaulting and credential rotation, BlastWave ensures that access to the PAM interface and from the PAM jump host to the target device is cryptographically secured and segmented, creating a defense-in-depth architecture in which the PAM solution is hidden from the general network and accessible only via BlastWave-secured tunnels.
Requirement Analysis: The DoW requires authentication “at the start of every session” (Target) and eventually “continuous authentication” (Advanced)
BlastWave Solution: BlastWave enforces session-based authentication. Unlike a firewall rule that remains open based on IP address, a BlastWave ties a session to the user’s cryptographic identity. If the risk profile changes (for instance, if the user moves to an unauthorized location), the session can be terminated immediately (Activity 1.8.3.OT). This capability moves the DoW closer to the “transaction-based authentication” goal of the Advanced state.
The Device pillar addresses the security of the vast array of hardware in the OT environment, from Windows-based engineering workstations to embedded PLCs and sensors.
Requirement Analysis: The DoW requires a centralized inventory of NPEs and the deployment of X.509 certificates to supported devices. The challenge in OT is that many legacy devices (Process Control Layer) cannot host certificates or agents.
BlastWave Solution: BlastWave solves the “unmanageable device” problem through its Gateway architecture. For legacy PLCs that cannot accept an agent or certificate, a BlastWave Gateway sits in front of them (physically or virtually). The Gateway holds the X.509 certificate on behalf of the legacy assets behind it. To the rest of the network, the legacy PLC is a fully authenticated, encrypted node, allowing the DoW to achieve the outcome of Activity 2.1.2.OT (“NPEs are managed via available PKI”) without a “rip and replace” of legacy hardware.
Requirement Analysis: The guidance mandates “compliance-based network authorization”. Devices should not be allowed to connect if they do not meet security standards.
BlastWave Solution: BlastWave does not natively include device posture checks in its admission policy. However, it is in our roadmap to validate with the EDR solution deployed on any system before initiating a secure connection. In this solution, before establishing a tunnel, the BlastWave agent checks the connecting device (e.g., a maintenance laptop) for required security attributes (such as running antivirus software, specific OS patches, or disk encryption). If the device fails the check, deny network access to the device until it passes the compliance check, enforcing the Target Level requirement for “compliance-based network authorization” at the edge.
Requirement Analysis: Configuration control solutions must ensure that files (e.g., ladder logic) are not altered or uploaded except by authorized individuals.
BlastWave Solution: While BlastWave does not inspect the content of the ladder logic file (a Data pillar function), it secures the transport mechanism. By restricting who can connect to a PLC’s engineering port, BlastWave significantly reduces the attack surface for unauthorized configuration changes. Only a user with the specific “Engineer” role and a verified device can open the connection required to upload new logic. BlastAccess acts as a PAM to allow or disallow file transfers to the remote system, providing an additional barrier against malware when using a remote desktop.
Requirement Analysis: Bring Your Own Device (BYOD) and non-Government Furnished Equipment (non-GFE) are generally restricted but may be authorized with deviation processes.
BlastWave Solution: BlastWave authenticates secure BYOD needed for 3rd-party maintenance activities on a military installation. By creating an encrypted, containerized session from the BYOD asset to the specific OT resource, BlastWave prevents the unmanaged device from laterally exploring the network. The “Default Drop” policy ensures that when a malware-compromised BYOD device attempts to scan the network, it fails, protecting the OT environment from the “dirty” device.
Requirement Analysis: The implementation of EDR tools is a Target Level requirement.
Partner Integration: BlastWave is not an EDR. However, it enhances EDR effectiveness. By microsegmenting the network, BlastWave forces an attacker to execute code on endpoints to move laterally (since network scanning is blocked), increasing the likelihood that the deployed EDR solution (e.g., CrowdStrike, SentinelOne) will detect the adversary’s behavior. BlastWave and EDR function as complementary controls: BlastWave protects the network, and EDR protects the compute host.
This pillar focuses on securing the software that runs the critical infrastructure, from SCADA masters to HMI applications.
Requirement Analysis: The DoW requires an inventory of all applications and the implementation of application control solutions to preventunauthorized execution.
Partner Integration: This is primarily the domain of Allowlisting software (e.g., Carbon Black, McAfee Application Control). BlastWave’s role is to ensure that the management consoles for these application control systems are themselves secured and accessible only to authorized administrators, preventing adversaries from disabling the protections.
Requirement Analysis: These activities focus on DevOps and DevSecOps processes, including CI/CD pipelines and Software Bill of Materials (SBOM).
BlastWave Solution: For OT environments moving toward modern DevOps (e.g., updating containerized applications on edge gateways), BlastWave can secure the CI/CD pipeline. By ensuring that the code repository and the build server communicate only through mutually authenticated tunnels, BlastWave prevents “man-in-the-middle” attacks on the software supply chain during deployment.
Requirement Analysis: The OT Vulnerability Management program prioritizes vulnerabilities based on risk to mission.
BlastWave Solution: BlastWave ensures that OT devices are cloaked from external scans, and can restrict protocols and users to protect systems to mitigate risks to the mission.
Requirement Analysis: All applications and capabilities must support a complete Attribute-Based Access Control (ABAC) solution.
BlastWave Solution: BlastWave extends ABAC to the network layer. Traditionally, firewalls use static rules (IP A can talk to IP B). BlastAccess can extend that to policies based on application attributes on BlastAccess servers and a BlastShield policy. For example, a policy can state that “Only the SCADA Server Application can communicate with the Historian.” In this scenario, only the certified application is present on the server, preventing rogue applications from being used. BlastWave can block any upload to the remote desktop, enforcing ABAC at the workload level and blocking any unauthorized protocols from that server as well.
The Data pillar is often the most challenging in OT due to the prevalence of proprietary, binary protocols that resist standard tagging and inspection.
The Data pillar is often the most challenging in OT due to the prevalence of proprietary, binary protocols that resist standard tagging and inspection.
Requirement Analysis: The mandate calls for methods and protection mechnisms for datas sharing outside the OT environment.
BlastWave Enablement: BlastWave acts as the “pipe,” not the “packet inspector.” It is used to authenticate users into the OT environment, and connect physically separate OT enclaves with secure conenctions to prevent data from being intercepted or modified in flight.
Requirement Analysis: DLP analytics process enables policy enforcement for how sensitive data is handled and shared, and enables monitoring and detection of data loss events.
BlastWave Enablement: BlastWave acts as the “pipe,” not the “packet inspector.” It is used to authenticate users into the OT environment, and connect physically separate OT enclaves with secure conenctions to prevent data from being intercepted or modified in flight.
This pillar represents the core of the BlastWave value proposition. The DoW guidance emphasizes segmentation, encryption, and the removal of implicit trust, all native capabilities of the BlastWave platform.
Requirement Analysis: The mandate requires the creation of “granular access rules and policies” and the definition of data flow patterns.
BlastWave Solution: BlastWave operates on a “Zero Trust Default Drop” model. No traffic is allowed unless explicitly permitted, forcing the creation of granular rules. Unlike a firewall, where “Allow Any” rules often creep in for troubleshooting, BlastWave requires specific identity-to-identity mapping, aligning perfectly with the requirement to define persistent and ephemeral data flows. BlastWave makes this simple in large-scale OT environments with thousands of devices by creating user and device groups that drastically accelerate and simplify configuration for least-privilege access.
Requirement Analysis: DoW Components must implement programmable communication pathways that utilize Segmentation Gateways and Authentication Decision Points integrated into SDN.
BlastWave Solution: BlastWave is a programmable SDN overlay. It functions as a distributed Segmentation Gateway. The “Authentication Decision Point” is the BlastWave Orchestrator, which validates identities, and the “Segmentation Gateway” is the BlastWave Edge/Gateway software. This architecture allows policies to be updated programmatically via an API (fulfilling 6.6.1.OT) without manually configuring Access Control Lists (ACLs) on hundreds of physical switches.
Requirement Analysis: The guidance mandates segmentation between control, data, and management planes. In legacy OT, this was done physically (separate cables).
BlastWave Solution: BlastWave enables Cryptographic Plane Segmentation between gateways and/or remote user connections, ensuring that all traffic leaving the local network is encrypted. Further segmentation is policy-based. Traffic from specific devices to remote devices or users must be explicitly allowed by policy, and a system must be prohibited from sending or receiving management-plane traffic unless approved. If the end device supports tagged VLANs or multiple connections, the BlastShield solution will segment each connection separately, with unique policies applied to each.
Requirement Analysis: This is a critical Target Level activity. Microsegmentation is essential to OT networks, where lateral movement is the most common malware technique. Nation-state hackers leverage lateral movement to live off the land and hide from detection systems.
BlastWave Solution: BlastWave enables microsegmentation down to the individual host level, independent of network VLANs. In an OT network, software-defined segmentation ensures that re-IPing devices to create smaller subnets is not needed, reducing operational risks. BlastWave overlays the existing flat network, logically enforcing segmentation. For example, HMI-A can only talk to PLC-A, even if HMI-B and PLC-B are on the same subnet, preventing a compromised HMI from attacking other controllers (Lateral Movement Prevention).
Requirement Analysis: The DoW requires protection for data in transit per policy. Protocols like Modbus, DNP3, and Telnet send credentials and data in clear text, so when those communications cross insecure boundaries, encryption must be used to secure the traffic.
BlastWave Solution: BlastWave’s microsegmentation (when paired with L2 port isolation mode) ensures that even local LAN traffic is not broadcast across the entire network, but instead managed with BlastShield’s segmentation policies. BlastWave encapsulates all traffic leaving the local area network in AES-256-encrypted tunnels, effectively upgrading legacy, clear-text protocols to military-grade encryption standards without requiring changes to endpoint devices. This “Protocol Cloaking” ensures that even if an adversary gains physical access to the network switch, they cannot sniff sensitive operational commands.
This pillar represents the core of the BlastWave value proposition. The DoW guidance emphasizes segmentation, encryption, and the removal of implicit trust, all native capabilities of the BlastWave platform.The scale of DoW operations requires that security be automatable. The “human in the loop” remains critical for OT, but orchestration is the future in an automated OT environment.
Requirement Analysis: The DoW requires a catalog of access control policies and the establishment of attribute-driven access profiles
BlastWave Solution: The BlastWave Orchestrator serves as the centralized repository for all access policies. It provides a single pane of glass where administrators can view, audit, and modify access rules across the entire OT estate. This centralization simplifies the “Policy Inventory” requirement by replacing decentralized firewall configurations with a unified policy database.
Requirement Analysis: The implementation of Security Orchestration, Automation, and Response (SOAR) tools is a Target Level activity.
BlastWave Solution: BlastWave integrates with SOAR platforms (e.g., Splunk SOAR, Palo Alto XSOAR) via REST API. When the SOAR platform detects a threat (e.g., from the SIEM), it can trigger a BlastWave policy change to isolate the infected host. BlastWave enables the Response part of SOAR by providing the enforcement mechanism that the SOAR tool drives. BlastWave Orchestrator serves as the centralized repository for all access policies. It provides a single pane of glass where administrators can view, audit, and modify access rules across the entire OT estate. This centralization simplifies the “Policy Inventory” requirement by replacing decentralized firewall configurations with a unified policy database.
Requirement Analysis: The mandate requires establishing API standards to ensure tool interoperability.
BlastWave Solution: BlastWave is built on an API-first architecture. Every function available in the GUI is accessible via API, allowing DoW agencies to create custom workflows or integrate BlastWave into existing “Single Pane of Glass” dashboards, ensuring that the OT security stack acts as a cohesive system rather than a collection of point products.
You cannot secure what you cannot see. This pillar focuses on logging, monitoring, and threat intelligence.
Requirement Analysis: DoW Components must identify, collect, and map all log sources.
BlastWave Solution: BlastWave generates high-fidelity access logs. It records who connected, from where, to what, for how long, and denied access. BlastWave exports the logs in standard formats (Syslog) to the Enterprise SIEM. While BlastWave is not the log parser (Activity 7.1.2.OT is a SIEM function), it provides the critical “Access Data” that the SIEM needs to detect anomalies.
Requirement Analysis: A critical requirement is the ability to “physically or logically” disconnect infrastructure during an incident to prevent further damage.
BlastWave Solution: BlastWave provides a “Digital Kill Switch.” In the event of a detected compromise, security teams can instantly revoke the certificates associated with a specific zone, site, or user group, logically air-gapping the compromised segment within milliseconds, stopping the spread of the attack (e.g., ransomware) without requiring personnel to pull cables at remote sites. This capability is essential for meeting the “prevent further intrusion” requirement of 7.2.1.OT.
Requirement Analysis: DoW CTI data feeds are integrated into the OT SIEM solution and utilized by the appropriate PEPs.
BlastWave Solution: BlastWave enforces a Zero Trust model, any denied connection attempt is a high-fidelity indicator of compromise (IoC). In a trusted network, a denied packet might be noise; in a BlastWave network, it means someone is scanning a dark network. BlastWave takes the policies pushed by SIEM/SOAR solutions and applies the appropriate policy to the network to protect from threats.
The following table summarize the specific requirements that BlastWave addresses directly through its native capabilities.
Zero Trust is a journey that requires a stack of technologies working in concert. While BlastWave provides the "Connect" asn "Protect" layers. the following chart identifies the requirements where BlastWave acts as a consumer or integrator, necessitating a partner solution to fulfill the DoW mandate.
The ZT for Operational Technology Activities and Outcomes document explicitly warns of the dangers of applying IT-centric security tools to OT environments. This section analyzes how BlastWave’s architecture mitigates these specific risks.
Most DoW OT environments are “brownfield” deployments, a mix of modern IIoT sensors and 30-year-old legacy controllers running unpatched firmware. Re-architecting these networks to achieve segmentation (Activity 5.3.1.OT) using traditional firewalls requires changing IP addresses, re-cabling, and extensive downtime, luxuries that mission-critical systems cannot afford.
BlastWave Strategic Advantage:
BlastWave operates as a transparent bridge or gateway, enabling quick deployment into an existing network segment without requiring IP changes to the protected assets. The “Invisible Overlay” capability allows DoW engineers to implement Zero Trust segmentation immediately, creating a secure enclave around legacy assets without disrupting the underlying process communications. BlastWave’s secure overlay directly addresses the DoW’s need for “flexible and adaptable” solutions that do not rigidly adhere to the 5-layer Purdue topology, resulting in faster deployment and lower maintenance requirements.
Safety Instrumented Systems (SIS) are the last line of defense against physical catastrophe. The DoW guidance implies that ZT implementation must not compromise safety performance.
BlastWave Strategic Advantage:
BlastWave supports the creation of “Safety Zones” that are logically isolated from the rest of the Operational Layer. By using the “Deny by Default” policy (Activity 1.7.1.OT), BlastWave ensures that no external entity (not even a compromised administrator workstation) can communicate with the SIS unless explicitly authorized and authenticated with high-assurance credentials, protecting the integrity of the safety systems while allowing for necessary data extraction (e.g., for compliance reporting) through strictly controlled, unidirectional-style tunnels.
The requirement to support “Base, Camp, Post, and Station” implies deployment in tactical environments where bandwidth is scarce, and latency is critical. Traditional VPNs and heavy encryption protocols can introduce unacceptable latency for real-time control loops.
BlastWave Strategic Advantage:
BlastWave utilizes a lightweight, peer-to-peer mesh architecture. Unlike hub-and-spoke VPNs that backhaul traffic to a central concentrator (adding latency), BlastWave facilitates direct, encrypted connections between the user and the resource. The protocol overhead is minimal, ensuring that the “significant need for continuous and reliable operations” is met even over constrained satellite or radio links.
It isn’t likely that SkyNet or an actual Terminator will come any time soon to attack your OT network. However, the quality and frequency of attacks will grow dramatically over the next few years. A 2024 report by Slashnet showed that malicious phishing emails increased by 4,154% since the launch of ChatGPT.
A different perspective is needed when looking at Critical Infrastructure and OT cybersecurity challenges. A famous entertainer once said, “Just when they think they have all the answers, I change the questions.” The essence of this quote is that we need to challenge assumptions that we hold and maintain the initiative over attackers rather than simply reacting. Cybersecurity history tells us that some things will never change:
If we hold these three truths as selfevident, many current security strategies echo the strategies of the Dutch Boy and the Dike – keep putting your fingers in to plug the holes and hope that more don’t occur.
“What if?” is the question we need to ask ourselves.What if the hackers could not discover the OT systems and devices hidden behind a gateway? What if your access used biometrics, not passwords, and your mobile device’s security certificate, just like Apple Pay? What if peer-to-peer encrypted tunnels secured all connections, and no lateral movement was allowed, even on a Layer 2 network?
So what should the new question be?
What if I could protect my network, not just react to attacks?
Cybersecurity for Critical Infrastructure is all about breaking the kill chain – and breaking multiple links, not just one. If you want to change the game and protect your OT network, explore Blastwave’s Network Cloaking technology and get a demo.
Getting started with BlastShield is easy and free. Follow the three steps below and get up and running fast.
%20(1).svg)
Create a Free Trial
Account
.svg)
Download the BlastShield Authenticator & Client
.svg)
Make Your Host Invisible
In Minutes
.svg)
