Persistent access can be the objective
In February 2024, CISA, NSA, and FBI assessed that PRC-sponsored Volt Typhoon actors were positioning themselves in U.S. critical-infrastructure IT networks for possible disruption during a major crisis or conflict. The advisory emphasized living-off-the-land techniques: using legitimate tools and existing access to make malicious activity harder to distinguish from administration. This is an attributed government assessment, not proof that every infrastructure network has been compromised. CISA advisory announcement.
State-sponsored activity is only part of the risk. Criminal intrusions, ransomware, insider misuse, and ordinary configuration mistakes can also interrupt operations. A useful defense plan addresses the paths to harm rather than assuming one actor or one motive explains every event.
The Defense Industrial Base is one of the nation's 16 critical-infrastructure sectors. Its companies support research, production, delivery, maintenance, software, and other defense requirements. Sensitive information matters, but so do the facilities and services that keep those activities operating. Defense Industrial Base Cybersecurity Strategy.
Supplier access is part of the system boundary
A prime contractor may depend on subcontractors, managed service providers, equipment vendors, and software publishers. Those relationships can carry necessary access into sensitive environments. The risk depends on the permissions and trust involved, not simply the supplier's size or tier.
The SolarWinds incident is a concrete example. CISA documented malicious code inserted into the software lifecycle and signed with a legitimate certificate. The compromise exploited trust in a management product; the resulting risk varied with installation, privileges, and subsequent attacker activity. CISA's December 2020 advisory.
A simpler scenario can create a similar trust problem: a compromised subcontractor account sends a convincing request to a program manager, or a vendor's maintenance credentials remain active after the work ends. These examples should be tested against the organization's actual workflow rather than treated as reasons to block every supplier connection.
For each important relationship, establish:
- What information or equipment the supplier can reach.
- Who approves access and when that access expires.
- How unusual use is detected and investigated.
- Who must report an incident and how quickly.
- Whether operations can continue while the connection is suspended.
OT security must respect the physical process
Manufacturing equipment, industrial control systems, building controls, laboratory instruments, and test systems can have different maintenance and availability requirements from business computers. A security change that is routine in an office may interrupt a process, invalidate a test, or introduce a safety hazard on the production floor.
NIST SP 800-82 addresses those performance, reliability, and safety constraints. It provides OT-specific guidance on architectures, risks, and countermeasures. That is why OT security work needs participation from the people who understand the equipment and process, alongside cybersecurity staff. NIST OT security guide.
Start with an accurate map of legitimate data flows. Segmentation should restrict unnecessary paths between business and industrial environments while preserving approved functions. A boundary that is repeatedly bypassed for maintenance provides less protection than its diagram suggests.
Monitoring also needs process context. An unusual command, new engineering workstation, or out-of-sequence configuration change may matter more than a raw traffic-volume spike. Scanning, endpoint tools, and patches should be assessed for compatibility and introduced through an approved maintenance process. Where immediate patching is unsafe, record the exposure, compensating controls, owner, and plan to resolve it.
Compliance establishes obligations; operations need evidence
NIST SP 800-171 requirements and applicable contract clauses address safeguarding covered information. CMMC adds assessment and affirmation requirements according to the current program and contract. Those obligations do not replace an operational assessment of a production line or its dependencies.
Later policy update: in July 2026, the department suspended CMMC Phase II implementation while retaining Phase I self-assessment requirements. Contractors should check current clauses and modifications rather than assume all controlled-information environments require an immediate third-party CMMC assessment. Underlying safeguarding obligations remain relevant. Official CMMC status and implementation memorandum.
For a small contractor, a focused plan is more useful than an expanding list of disconnected tools. Prioritize the identities, remote connections, systems, and recovery assets whose loss would stop delivery or expose covered information. Document what is implemented, what is not, and what evidence supports that conclusion.
Rehearse containment without making the outage worse
Planning for a successful intrusion is prudent; it does not mean prevention is futile or that compromise is inevitable. Prevention, detection, response, and recovery reinforce one another.
A realistic exercise should require the team to make operational decisions:
- Identify the affected mission. Which production, test, or delivery activity depends on the suspect system?
- Choose a safe containment boundary. Determine what can be isolated immediately and what requires an orderly process shutdown.
- Preserve communication and evidence. Use an alternate coordination path if the business network may be compromised.
- Restore a known condition. Recover trusted configurations and data, then verify process behavior before resuming production.
- Address the enabling weakness. Remove unnecessary trust, correct the access path, and test the revised control.
Executives should see the results in terms they can act on: likely downtime, untested recovery dependencies, access that cannot be explained, and the resources needed to close those gaps. Cybersecurity becomes an operational discipline when those decisions are owned and revisited with the same seriousness as quality and delivery.
A restored server is not a released production process
For a manufacturer, recovery has at least two questions: can the system operate again, and can the resulting work be trusted? Restoring an engineering workstation from backup may recover access while leaving uncertainty about which approved configuration is present or whether an interrupted process requires additional checks. Cybersecurity staff should not have to resolve those production questions alone.
NIST's OT guidance connects recovery planning with the environment's reliability and safety needs. SP 800-82 Revision 3, section 3.3.9 is a useful starting point for the recovery discussion. The organization's operations, engineering, and quality or safety personnel should define what evidence permits a return to the affected work.
A tabletop might begin with an unavailable maintenance workstation and an urgent delivery commitment. The point is not to invent a dramatic attack. It is to establish who can authorize a safe pause, which approved records are needed for restoration, and who confirms that the process is ready to resume. Use the actual equipment owners and contractual responsibilities rather than a generic incident-response roster.
The exercise should distinguish decisions that can be made immediately from those requiring technical confirmation. It should also identify a workable communication route if ordinary business systems are unavailable. A plan stored only in the environment the team is trying to recover may be difficult to use when needed.
Give leadership a choice it can fund
Executives do not need a longer vulnerability list to make every resilience decision. They need to understand the exposure that matters to delivery, the options for reducing it, and the operational burden each option creates.
For a supplier maintenance connection, the alternatives might include a more limited approved access arrangement, an on-site support visit, or a planned outage for an equipment change. The right approach depends on the process and the risk. A security measure that cannot be maintained in routine work may be bypassed; a convenient connection without accountable access can preserve an avoidable path to disruption.
Present the decision with a named owner, required resources, expected benefit, and the evidence that will show the change works. Where an exposure must remain temporarily, make the reason and review point explicit. Recording an exception is not equivalent to fixing the condition, but it prevents the responsibility from disappearing between IT and operations.
The next readiness review should trace one critical production dependency through prevention, containment, and restoration. A break in that chain gives leadership specific work to assign. A tested chain gives the organization more confidence that its delivery commitments can survive a cyber incident without an improvised restart.
Sources and further reading
- CISA: Volt Typhoon and living-off-the-land guidance
- DoD: Defense Industrial Base Cybersecurity Strategy
- CISA: SolarWinds supply-chain compromise advisory
- NIST SP 800-82 Rev. 3: OT security
- CMMC: current program status
Spartan X combines cybersecurity, engineering, and operational planning to connect security controls with the facilities, suppliers, and delivery commitments they protect. That perspective keeps resilience grounded in how the business actually produces and recovers.
