Skip to main content
Back to Blog
Security

6 Identity First Controls to Secure Remote Monitoring for IT and OT

October 202612 min read
Secure remote monitoring for IT and OT environments

Secure remote monitoring starts with knowing who and what is connecting to you before you allow access to visibility or control of distributed systems—and this extends throughout the entire session, not just at login. The single most important control is identity-first access: phishing-resistant MFA with continuous session authorization, recommended by NIST SP 800-82 and CISA guidance. We engineer this into every monitoring engagement we provide.

TL;DR:

Credential theft and exposed remote access ports are most commonly exploited to attack remote monitoring systems.

  • Implementing short-lived, policy-driven credentials and separating IT from OT access significantly reduce risk.

Segmentation, DMZs and unidirectional gateways can help contain potential breaches.

By routinely detecting and monitoring session metadata, anomalies, and prohibited tools, you can catch malicious behavior sooner.

  • Prevent supply chain risks by thoroughly vetting vendors and holding them to stringent contracts. Use MFA and session logging to prevent vendor backdoor access.

PODTECH builds better protected monitoring systems at podtech.com. Custom software is designed by PODTECH for mission critical infrastructure control including building telemetry, and critical monitoring integrations. Learn More

Table of Contents

Why secure remote monitoring matters for OT and remote-work environments

Operational technology operates under a set of rules that typical IT security practices ignore. You can’t reboot a controller on the factory floor or a data centre chiller in the middle of the night to apply a patch. Safety interlocks, endless production cycles and legacy gear that vendors no longer support mean that uptime is far more important than confidentiality when calculating risk. The inverse of how IT normally operates.

This incongruity should be front and centre of attackers’ scanning efforts. Remote desktop protocol and remote monitoring and management applications accessible from the internet provide stealthy ingress that appears to be legitimate administrative activity. These are often installed with little thought years previously and then left behind. Think about why NIST SP 800-82 advocates defensive layers such as segmentation, demilitarised zones, and unique credentials for control networks – if IT and OT are one flat network and someone connects a compromised laptop to the plant network, you have a plant-wide compromise.

Evidence of this can be seen in real-life advisories. CISA’s ICS alerts frequently mention accessible remote-access services found on industrial devices, and they each include the same advice: reduce internet exposure, segment control networks and simply expect any service that can be reached to be scanned at some point. Remote-work systems connecting to these networks should take away the same point. It’s not just the device you have to worry about, it’s the connection between them as well. Treat it as hostile until you have confirmed it is not.

Key threats and common attack vectors against remote monitoring systems

Credential theft is still probably the quickest way into a monitoring environment. With valid credentials in hand, attackers can use legitimate remote-management tools to pivot laterally appearing as normal administrative traffic. This is exactly the scenario described in recently published joint CISA, NSA and co-authors guidance which highlights RMM software is commonly exploited because it's already trusted allowlisted on target networks.

Several other vectors deserve immediate attention:

Unpatched firmware: PLCs, HMIs and gateways rarely get updates from vendors years after being deployed.

  • Insecure APIs that expose monitoring data or control functions without proper authentication.
  • Deserialisation flaws and other high-severity bugs in remote-access software components.

Exposed RDP and RMM ports accessible directly from internet with no perimeter control.

One Siemens Remote Connect Server flaw had a CVSS score of 9.6: “This example shows how having just one vulnerability in remote-access software can give an attacker unfettered access.” After urging minimum exposure to such tools altogether, CISA’s alert then advises customers to quarantine vulnerable servers behind firewalls pending patching by the vendor. Sound familiar? It’s a common theme in ICS advisories: the very thing that was meant to make oversight simpler is often the easiest path in.

Core controls: identity, continuous authorisation and least privilege

Zero trust isn't a product or technology, it's a discipline you apply to every remote session. NIST SP 800-207A explains the mechanics: continuous authorisation, short-lived credentials, policy decisions driven by real-time telemetry rather than a single login verification. In OT environments, you have to adapt it rather than copy it wholesale from enterprise IT playbooks; not every control system can support constant re-authentication without interfering with safety functions.

A practical sequence for rolling this out:

  1. Deploy phishing-resistant MFA for all remote sessions, starting with engineers and vendors with standing access to controls.
  2. Replace long-lived credentials with short-lived tokens that expire automatically after a session ends.
  3. Implement device posture checks prior to access being granted that verify patch level, up-to-date endpoint protection, known configuration, etc.
  4. Require step-up authentication for sensitive actions like changing a setpoint or pushing firmware.
  5. Segregate IT and OT credentials completely so that a hacked business account cannot access control-system assets.
  6. Map role-based access to physical function, limiting each account to only the access necessary to do their job.

Tip: Begin your MFA rollout with third-party vendors and remote engineers. They are the highest risk access vector and the smallest user group, making this change the easiest to force quickly.

Our phased roadmap for zero trust in OT provides guidance on how to orchestrate these controls without stopping production. Operations continuity matters more in OT than any other constraint listed here.

Network and architecture patterns for safe remote monitoring in OT

Architecture decisions set the limit for how far an attacker can progress once past first line of control. While remaining the foundational design pattern prescribed by NIST SP 800-82, segmenting IT and OT networks with a demilitarised zone (DMZ) and using stateful inspection firewalls still provides a basic level of security. For the most safety-critical control channels, unidirectional gateways allow information to flow one way – out of the OT network -- and prevent any commands from being sent to process equipment.

Segmentation does the heavy lifting. Zoneing a flat network isolates systems so a hacked engineering workstation in one zone can't access a safety instrumented system in another zone. You contain an incident rather than allowing it to propagate.

Several patterns reduce exposure without compromising the monitoring visibility teams actually need:

  • DMZs between corporate IT networks and OT networks where all traffic is inspected at the boundary.
  • Unidirectional gateways for the most critical safety and control paths.
  • Network segmentation by function and criticality, not just by physical location.

Agentless or proxy-based access to legacy PLCs and HMIs because placing agents on older devices can corrupt them.

Use jump hosts or managed gateways for the single, logged entry point to remote sessions.

Agentless access is worth special note here with respect to brownfield environments. Some industrial equipment was never designed to have third-party software executed on it, and according to NIST’s OT guidance, that proxy-based access to IoT devices through a gateway can actually be the safer method because it does not interact with the device itself.

Secure remote monitoring pathRemote userMFA + device postureIdentity policyshort-lived accessDMZjump hostsession loggingOT Zone AOT Zone BMonitoring platformtelemetry out, commands restrictedverify user + deviceauthorize per sessioninspect, broker, recordsegmented OT access

Monitoring, logging and detection: making remote sessions visible and actionable

An unobserved remote session is an blind spot, no matter how well authenticated. Detection begins by capturing appropriate session metadata: who logged in, from where, with what tool, what commands they ran and when they logged off. Correlating that information across identity logs, network flow logs and endpoint telemetry transforms disparate events into a story an analyst can understand.

Useful signals to prioritise:

  • Session start and end times correlated against expected maintenance windows.
  • Geographic or network anomalies. For example, your vendor account is suddenly connecting from somewhere it's never connected from before.
  • Command-level logging for any session touching control-system configuration.

Use of RMM tools not present on approved allowlists (detected by pattern identified in previous joint advisories)

Many remote-management tools are abused because they come pre-allowlisted/trusted on target networks. That's why behavioural monitoring is just as important as access control. Authorization of a tool doesn't guarantee all sessions using it are valid.

Retention is just as important as collection. Logs should be sent to a system that cannot be modified by the session itself. And when a vendor or managed service provider is granted access, customers should demand visibility into what that provider’credential sessions are doing rather than accepting a summary after-the-fact. Our work on LifeSafety.ai detecting unauthorised remote sessions in construction safety applications follows this same logic, just in a different arena: telemetry doesn’t do you any good if nobody (or nothing) is watching it.

Managing third-party and MSP remote access safely

Many times vendors and managed service providers will have the widest open door into your monitoring environment. The fix begins in the contract, not just the firewall. Agreements should be set up before access is granted that clearly define what a vendor has access to, who has access to their logs and how soon they must report an incident.

A practical checklist for managing this relationship:

  1. Define access scope explicitly in the contract, naming systems, not blanket network access.
  2. Require logging rights, so the customer can audit vendor activity independently.
  3. Set incident notification timelines, including obligations covering nested subcontractors.
  4. Issue dedicated service accounts per vendor, never shared credentials.
  5. Enforce MFA and time-bound access keys that expire automatically after the engagement window.
  6. Record sessions for any vendor touching production or control systems.

For any provider with connections into a cardholder data environment the PCI SSC guidance document on connected-to service providers further emphasizes these same controls (MFA, logging and contractual assurance), whether that provider is a software provider or maintenance contractor.

OT deployment trade-offs: patching, compensating controls and safe testing

Patch windows for OT environments can be infrequent, with some organizations only having one scheduled outage annually. This means that VM needs to rely on compensating controls in lieu of expecting timely patching. Segmentation, detection and limiting access can provide the control a patch would have, without updating the device.

When there is absolutely no delay possible, at least having staged testing on a representative non-production system, complete with rollback plan documented, can lessen the chance that your attempted fix triggers the outage it was designed to prevent. Redundancy in vital control paths allows your team the time to quarantine and remediate one unit while the remainder of the process continues operation.

The logic is simple: if you are being exploited and you can't patch, quarantine. If you have a verified patch window, patch. If neither of those are true, remediate in another way - for example, turn off a service you're not using.

Practical implementation checklist and phased plan

Hardening remote monitoring works best as a sequence, not a single project.

Phase one, discovery:

  1. Inventory every remote-access tool, account and endpoint currently in use, including shadow IT.
  2. Identify exposed RDP and RMM ports reachable from the internet.

Phase two, short-term controls:

  • Enforce MFA on all remote sessions immediately.
  • Block or restrict inbound access to common RMM ports at the firewall.
  • Revoke unused or orphaned vendor accounts.

Phase three, medium-term hardening:

  • Implement network segmentation between IT and OT.
  • Deploy session logging and correlate it centrally.
  • Formalise vendor governance contracts and staged patching cycles.

Measure progress with tangible metrics: ports closed (exposed to the internet), % of sessions protected by MFA, mean time to detect unusual vendor activity. You can see a more detailed 3-12 month version of this same plan in our industrial IoT security roadmap for teams looking to implement a larger program.

PODTECH perspective: engineering secure remote monitoring for mission-critical environments

We treat secure remote monitoring as an engineering challenge. Identity controls, telemetry and segmentation are designed into the platforms we build, not retrofitted. This includes datacenter telemetry, containment monitoring, as well as integration of building management, power management and network management systems since they all rely on remote visibility that must not become a risk.

Achieving OT safety and security starts with never treating a control system like a typical endpoint on the IT network. We scope changes around existing maintenance windows and safety constraints. Each control is validated in a pilot prior to touching production. A typical engagement will transition from assessment (mapping a baseline of current remote-access risk) to a scoped pilot (proving out proposed architecture) before scaling throughout the enterprise. Our monitoring products and platforms are built with this same phased mentality, ensuring safe operation in environments where downtime is unacceptable.

The gap between compliance and actual security

The majority of remote monitoring programmes will pass an audit and still become breached. This is because compliance checklists focus on documenting a system, not how it's used. You can pass every box in a framework yet continue to run your RMM tool without endpoint detection disabled (to prevent false positives), creating a massive trust gap hackers take advantage of.

"Patching everything, and turn on MFA" is advice that is good but incomplete. It avoids the harder question of what to do once authentication succeeds. Session monitoring and continuous authorization/behavioral monitoring is more important than any checkbox control because attackers don't stop at the login prompt. They use stolen identities and legitimate tools.

If forced to choose one thing we would recommend folks focus on today for a new reader, it wouldn’t be another firewall rule. It would be the remediation of any visibility gap between what a vendor/RMM tool is permitted to do and what it actually does during a given session. That gap, more than any unchecked CVE, is where the majority of OT incidents have their roots.

— Harry

How we can help you secure remote monitoring

We design and implement the identity, telemetry and segmentation controls described in this article as standard in the platforms we engineer for data centres, construction safety and critical infrastructure customers. From a targeted review of existing remote-access risk exposure to a managed proof of concept pilot that validates an architecture ahead of broad deployment, our datacenter telemetry and monitoring services are architected for just this type of collaboration.

If you're looking at a remote monitoring upgrade, the next most valuable step is likely an exposure assessment of your existing RDP, RMM and vendor access paths. Contact us through our services overview to discuss what that would entail for your environment.

FAQ

Can someone monitor your computer without you knowing?

Yes, RMM tools can run silently without displaying alerts if they have administrative privileges installed. Malicious or rogue RMM software is a known attack vector. Companies should keep an allowlist of approved tools and watch for rogue remote-access software running outside of that allowed set.

How much does remote monitoring cost?

Price varies based on scope. This can include how many endpoints there are, what monitoring platform you select and if your deployment covers IT, OT or both. We provide quotes for each engagement separately depending on what systems are involved. For this reason we feel the most accurate price comes from an assessment of your environment versus a ballpark figure.

What is the most popular remote patient monitoring?

As this article deals with secure remote monitoring technologies for IT and OT environments rather than clinical remote patient monitoring, we haven't addressed healthcare platforms specifically. For that topic, start with a source or regulatory body that focuses on healthcare instead of general OT security best practices.

How does secure remote access work?

Secured remote access is able to authenticate the user via phishing-resistant MFA and then consistently authorize the session. Instead of trusting users after they've logged in once, continuous verification is used. This framework is outlined in NIST’s publication on zero trust. Secured remote access also often involves ephemeral credentials, device posture, and network segmentation so that if an account is compromised, attackers can't access anything outside of that users allowed permissions.

Sources

Recommended