A common engineering reference across agencies
The April 29 guide, Adapting Zero Trust Principles to Operational Technology, was issued by CISA, the Departments of War, Energy and State, and the FBI. It is organized around the six NIST Cybersecurity Framework functions: Govern, Identify, Protect, Detect, Respond and Recover. Asset visibility, identity and access management, and supply chain risk are key focus areas.
That alignment is useful wherever industrial equipment supports a defense mission: manufacturing lines, installation utilities, fuel infrastructure or deployable systems. A supplier can use the same reference to structure conversations with the security team, the equipment operator and the program office. Those groups still have different responsibilities, and each installation has its own operating constraints.
The document provides recommendations. Binding delivery and assessment obligations come from the applicable contract, regulation and customer requirements. A practical proposal should identify which controls are included, how their performance will be demonstrated and which responsibilities remain with the customer. Treating the guide as engineering input produces a much stronger agreement than relying on an undefined promise of “zero-trust compliance.”
Start with equipment the customer can actually see
Legacy control systems can remain useful long after their operating systems, protocols or support arrangements become difficult to secure. Replacing all of them at once may be financially or operationally unrealistic. The immediate design problem is how to make their dependencies and exposure visible without disrupting production.
The guide favors passive discovery for sensitive older equipment while allowing informed use of active techniques with appropriate protocols or newer components. Automated discovery can also leave gaps in isolated network segments. Inventory quality therefore depends on combining available observations with engineering knowledge.
For a supplier, a useful delivery package should answer:
- What is installed? Identify components, firmware, supported configurations and dependencies.
- What must communicate? Document necessary connections and the operational reason for each one.
- What can be observed safely? Describe monitoring coverage, blind spots and any equipment restrictions.
- Who updates the record? Assign responsibility when parts, firmware or connectivity change.
These are also purchasing questions. An inexpensive appliance can create a costly support obligation if its telemetry is proprietary, its monitoring requires unavailable cloud connectivity or its licensing does not cover the customer's deployment model. Ask for those conditions during evaluation, before the architecture depends on them.
Access controls must survive a bad day
An operator may need to recover a process while a network link, directory service or vendor connection is unavailable. Security architecture needs an explicit answer for that situation. The acceptable behavior depends on the equipment, the safety analysis and the mission; a blanket rule to deny every action or allow every action would be inadequate.
Design reviews should walk through normal access, maintenance access and emergency access separately. For each, specify the authorized person or device, the permitted action, the evidence retained and the recovery procedure. If a legacy component cannot enforce a control itself, document where the surrounding architecture provides protection and what limitation remains.
For disconnected deployments, test the loss of external dependencies rather than simply labeling the system “edge capable.” Examine credential expiration, time synchronization, local administration, delayed logs and restoration of connectivity. A successful demonstration includes the operator's ability to recognize the degraded condition and follow an approved procedure.
The same discipline applies to cybersecurity changes. Maintenance windows, safety reviews, rollback capability and operator training belong in the release plan. A security improvement that unexpectedly stops an essential process has not met the customer's complete requirement.
Make supply chain evidence usable
Component provenance and software transparency help customers understand exposure, but older products may have incomplete documentation. A supplier should be candid about that gap and provide the best available evidence: supported versions, vulnerability handling, firmware update controls, subcontractor dependencies and end-of-support plans.
For new purchases, define deliverables precisely. If a software bill of materials is required, identify the format, covered components, update frequency and customer use rights. Specify how the supplier will notify the customer of a newly discovered vulnerability and what assistance accompanies remediation. An artifact delivered once and never maintained offers limited help during a later incident.
The commercial implication is straightforward: security evidence needs an owner, a maintenance process and a price. Procurement and engineering teams should resolve those terms together so that sustainment expectations survive the handoff from proposal to operations.
CMMC planning changed after this article's original publication
September 2026 review update: the DoW CIO's CMMC page records the July 13 suspension of Phase II, previously scheduled for November 10, 2026. Phase I self-assessment requirements remain in effect.
The implementing memorandum allows requiring activities to designate Level 1 or Level 2 self-assessments during the suspension, rather than Level 2 C3PAO or Level 3 DIBCAC requirements. It directs amendments to affected active solicitations and modifications to affected existing contracts before the next option or scheduled administrative modification. DFARS 252.204-7012 remains in effect.
Suppliers should review the actual solicitation or contract with the contracting officer, track any required modification and continue the applicable safeguarding work. A schedule change does not eliminate the need to protect covered information, nor does an announcement automatically rewrite an existing agreement.
Put the next review on a practical footing
- Map obligations. Separate binding contract terms from guidance and proposed improvements.
- Choose a critical workflow. Trace the equipment, identities, connections and safety dependencies supporting it.
- Test degraded operation. Include lost connectivity, unavailable services and emergency access.
- Close evidence gaps. Record unsupported components, compensating controls and accountable owners.
- Fund sustainment. Include vulnerability response, configuration records, training and eventual replacement.
This approach turns a broad security aspiration into a reviewable delivery plan. It also lets the customer compare suppliers on evidence that matters to the operating environment.
Sources and further reading
- Interagency guide: Adapting Zero Trust Principles to Operational Technology
- DoW CIO: current CMMC implementation information
- CMMC Phase II suspension implementing memorandum
Spartan X brings cybersecurity, engineering and program execution together to make these tradeoffs explicit: controls that fit the equipment, evidence the customer can evaluate and sustainment plans that support the physical mission.
