Welcome back to our Decoding NERC CIP blog series, part of Foxguard’s ongoing Decoding NERC CIP Podcast. This post is the second installment accompanying Episode 3: “Bridging Patch Management and Vulnerability Strategies for NERC CIP.”
In our previous post, we explored how organizations manage the growing volume of security patches and related vulnerability information under CIP-007 R2, focusing on prioritization within fixed environments. This post builds on that discussion by shifting focus to environments where that assumption no longer holds: devices that move between networks.
Transient Cyber Assets (TCAs) highlight a gap in traditional vulnerability management models, which often assume assets are static, continuously monitored, and consistently controlled.
The Unique Risk Profile of TCAs
An important cyber security risk recognized in industrial environments for decades is the implicit trust boundary created by roaming devices. When a laptop or portable diagnostic tool moves between an external environment and an internal control network, it bypasses many of the traditional perimeter defenses that protect BES Cyber Systems.
As discussed earlier in this series, asset identification is foundational to NERC CIP compliance. However, TCAs challenge that model by introducing devices that are not continuously visible within a fixed inventory or security boundary.
Although this risk had been well documented for two decades, it was not until CIP-010-2 that Requirement R4 first introduced formal requirements for managing TCAs and RMs. These requirements later evolved through subsequent versions of CIP-010. Requirement R4 addresses TCAs (usually laptops) and RMs (portable disk drives, thumb drives, etc.).
- This requirement is divided into three sections:
- Transient Cyber Asset(s) Managed by the Responsible Entity
- Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity
- Removable Media
Since Sections 1 and 2 focus on fully capable computers, software vulnerability management (specifically patching) is the primary focus for those areas. These assets represent a higher risk than fixed assets because they are designed to move between security zones, often bypassing the ESP’s traditional barriers.
Strategic Approaches to CIP-010-4 Compliance
Section 1.1 outlines three compliance paths in which NERC entities can manage Transient Cyber Assets (TCAs):
- “in an ongoing manner to ensure compliance with applicable requirements at all times”,
- “in an on demand manner applying the applicable requirements before connection to a BES Cyber System”, and
- “a combination of both (1) and (2) above”.
For entity-managed TCAs that are used regularly, many organizations find ongoing management easier to sustain than point-in-time preparation immediately before connection. However, the appropriate approach depends on factors such as asset ownership, usage frequency, and operational constraints.
Regardless of which compliance path is selected, vulnerability management should still function as an ongoing process rather than a point-in-time “cleansing” activity. Maintaining a continuous state of readiness helps ensure the device will be “site-ready” when connected for updates and reduces reliance on reactive mitigations that may miss dormant threats or overlooked vulnerabilities.
This aligns with the “Virtuous Loop” discussed in series 1, where vulnerability management is treated as a continuous operational discipline rather than a periodic compliance exercise.
Vulnerability Risks in Roaming Assets
How should software vulnerabilities be managed in a TCA?
There is a clear distinction between managing vulnerabilities on a laptop that remains connected to one or two stable networks and managing vulnerabilities on a laptop that regularly connects to external environments (e.g., substations) outside its normal operating context. The latter introduces significantly greater risk.
As explored in our earlier discussion on OT patching challenges, many vulnerability management processes assume persistent connectivity. TCAs break that assumption, often missing scheduled scans, centralized updates, and routine monitoring activities.
The primary risk in NERC environments is that a TCA introduces malicious code or exploitable software into a BES environment during connection to a substation network. Because TCAs often operate outside tightly controlled environments between connections, they may carry latent malware or exploitable software that is not present on protected systems but becomes active once introduced into that environment.
A related but secondary risk is that a TCA may be compromised while operating on a less secure or untrusted network and later transfer that compromise into a BES environment during a subsequent connection.
These scenarios are well-documented in environments where devices move between networks, particularly in field service contexts where devices routinely traverse untrusted or unmanaged environments. In these cases, TCAs fundamentally change the risk model. The device is no longer just an endpoint, but a carrier of system state and potential compromise between environments in both directions. As a result, they require a higher level of protection than devices that remain within a stable ‘home’ network, since they must protect both themselves and every environment they connect to. Therefore, vulnerabilities must be managed as frequently and thoroughly as possible on TCAs.
A further challenge is that TCAs often miss network scans, automated patching, and other routine vulnerability management activities applied within their home environment. This makes it essential that they are explicitly included in vulnerability management processes and are not inadvertently excluded from routine controls.
Methods for Software Vulnerability Mitigation
Section 1.3, Software Vulnerability Mitigation, lists four methods “to achieve the objective of mitigating the risk of vulnerabilities posed by unpatched software on the Transient Cyber Asset.” These are:
- Security patching, including manual or managed updates;
- Live operating system and software executable only from read-only media;
- System hardening (e.g., disabling unused ports or unnecessary services); or
- Other method(s) to mitigate software vulnerabilities.
In practice, a layered approach is often the strongest, but the selected methods should align with the TCAs capability, use case, and connection model. CIP-010-4 allows one or a combination of methods for this reason, and the compliance position should be grounded in documented risk mitigation rather than assuming every method applies equally to every asset.
Security patching is typically the most direct and commonly used control, but it is most effective when combined with other compensating measures where appropriate.
Managing Third-Party and Contractor TCAs
Section 2.1 addresses “software vulnerabilities mitigation” of TCAs managed by a third party.
This is a much harder problem than mitigating vulnerabilities in TCAs managed by the NERC entity, since the entity presumably has no control over the TCA when it is not connected to one of its networks.
This shifts the problem from control to assurance. The Responsible Entity is no longer managing the asset directly but evaluating whether the third party’s controls meet the required standard.
This also extends the supply chain considerations discussed earlier in the series, where trust in external providers—including patch sources and validation processes—must be established and verified before software or systems are introduced into the environment.
This section lists four methods for mitigating the risk of vulnerabilities posed by unpatched software on the TCA managed by a third party:
- Review of installed security patch(es);
- Review of security patching process used by the party;
- Review of other vulnerability mitigation performed by the party; or
- Other method(s) to mitigate software vulnerabilities.
Note that none of these four methods is easy to execute, since they all presumably require a knowledgeable expert to spend some serious time reviewing their subject.
Furthermore, Section 2.3 mandates that the Responsible Entity determines if “additional mitigation actions” are necessary before connection if the initial review is insufficient.
If a third-party technician arrives at a substation without prior validation, the resulting operational delays can be significant, as connection cannot occur until compliance evidence is verified. This means the NERC entity must proactively engage third parties and conduct these reviews on a regular basis—ideally through contractual and SLA requirements—so that compliance evidence is confirmed in advance and does not delay work or prevent connection.
Ultimately, proactive engagement ensures vendors are compliant and prepared before they ever step foot on a site.
Section 2.3 reads: “For any method used to mitigate software vulnerabilities or malicious code as specified in 2.1 and 2.2, Responsible Entities shall determine whether any additional mitigation actions are necessary and implement such actions prior to connecting the Transient Cyber Asset.”
In other words, if the review of the third party’s patching program finds something that is unsatisfactory, the NERC entity should require mitigations, not just ignore what they found.
Moving Forward Together
Grid security requires a comprehensive strategy that accounts for every device crossing the electronic perimeter. When roaming hardware moves between secure and insecure zones, it creates a potential bypass for established defenses. Maintaining a rigorous, ongoing vulnerability program for TCAs ensures that these essential tools remain assets to operations rather than liabilities to the network.
Foxguard helps utilities bridge the gap between fixed asset policies and the roaming devices that service them. By centralizing patch intelligence and automating the documentation required for CIP-010 R4, organizations can reduce the manual burden on field technicians while ensuring every connection is verified.
TCAs expose a fundamental truth about OT security: controls built around fixed boundaries do not extend cleanly to mobile assets. Effective TCA management requires treating these devices not as exceptions, but as extensions of the environment—subject to the same rigor in vulnerability management, verification, and documentation.
In our next post, we will take a deeper dive into the technical metrics of this strategy, examining how to specifically leverage CVE data, CISA KEV ratings, and EPSS scores to assess the real-world exploitability of software vulnerabilities.
When managed correctly, TCAs stop being a blind spot and become a controlled, auditable part of the system, ensuring that mobility never comes at the cost of security.