Cybersecurity Checklist Before Buying a Remote Monitoring System

Before comparing dashboards or communication options, define the evidence each device, supplier, and connection must provide so that remote monitoring cybersecurity requirements can be tested rather than accepted as a vague “secure” claim. A supplier’s marketing sheet may list encryption, authentication, or compliance keywords. But unless the procurement document specifies what artifact to request, what test to run, and who owns the result, those words carry no verifiable weight.

This checklist draws on three NIST baselines: SP 800-82 Rev. 3 for OT architecture and remote-access controls, NISTIR 8259A for device cybersecurity capabilities, and NISTIR 8259B for supplier documentation and lifecycle support. It converts them into procurement and acceptance questions for connected monitoring systems.

Start with the Data Path, Not the “IoT” Label

A threat list that begins with “IoT devices are vulnerable” does not tell procurement which component needs which control. Map the actual data path instead:

1. Field sensor – the measurement source (water level, flow, water quality, weather, displacement).
2. Data logger or gateway – collects, stores, and forwards readings. A system such as the GEOVOS 1000 data logger connects field sensors via RS-485, stores data locally, and transmits over 4G. Each function creates a distinct interface that needs its own access rule.
3. Communication link – cellular, satellite, radio, or wired. Choosing a connectivity medium is a separate design decision; the cybersecurity question is how traffic on that link is authenticated and encrypted.
4. Server, cloud, or dashboard platform – receives and presents data. Systems like ONLIMO for water quality or AWLR for water level provide real-time dashboards connected to field devices.
5. Users – operators, engineers, administrators, and auditors who access data and configuration.
6. Maintenance and remote-access paths – firmware updates, diagnostic sessions, vendor support tunnels.

Mark a trust boundary wherever data crosses from one component or network zone to another. NIST SP 800-82 Rev. 3 places physical environment monitoring and measurement systems within its OT scope and calls for security controls tailored to operational performance, reliability, and safety. Each boundary above becomes a row in the procurement checklist. Not because every system is identical, but because every system has these transitions.

Six Device Capabilities That Must Be Demonstrable

NISTIR 8259A defines six baseline capability areas as a starting point for identifying device cybersecurity requirements. For each, turn the capability into a procurement question and a requested evidence artifact:

1. Device identification – Ask how the exact unit is uniquely identified logically and physically, and how that identifier is recorded in inventory. Requested evidence: device identity documentation and inventory registration procedure.
2. Configuration control – Request evidence that only authorized entities can change configuration and that an approved secure configuration can be restored. Requested evidence: configuration-lockdown procedure and restore demonstration.
3. Data protection – Define which stored and transmitted data needs confidentiality, integrity, or both, then request the device’s supported mechanisms. Requested evidence: data-at-rest and data-in-transit protection specification.
4. Interface access control – Inventory interfaces, identify which are required, and ask how access is restricted or how unused interfaces are disabled. Requested evidence: interface inventory and access-restriction settings.
5. Software update – Ask how updates are authorized, verified, initiated, and recovered when supported. Requested evidence: update procedure, verification method, and rollback documentation.
6. Cybersecurity state awareness – Ask what security-relevant events or logs the device can report and who can access them. Requested evidence: log or event specification and access rules.

These six capabilities are a starting point, not a universal pass/fail certification. The actual depth of evidence depends on the consequence classification of the monitoring application and the controls that the surrounding architecture provides. A river gauge with public data has different stakes than a dam safety sensor feeding automated gate controls.

What Must Supplier Support State in Writing?

Device features alone do not sustain cybersecurity over the system’s lifetime. NISTIR 8259B defines four non-technical supporting capability areas that buyers should evaluate before purchase and throughout the device lifecycle:

• Documentation – Request lifecycle documentation covering installation, hardening, operation, maintenance, and decommissioning. This documentation should be available to operators, maintainers, and assessors.
• Query and vulnerability reception – Ask where security questions and vulnerability reports are submitted, who responds, and how status is tracked. Document the channel and expected response scope.
• Information dissemination – Require a named notification route for relevant vulnerability alerts, resolutions, and end-of-support announcements. Agree on recipients, method, and timeline.
• Update terms and end of support – Put software-update support terms and end-of-support notice requirements in writing. Include the update mechanism, minimum support period, and what happens after support ends.

The biggest mistake I see in procurement is treating these questions as optional. If the supplier cannot answer them in writing before purchase, document that gap as a risk acceptance, not something to revisit later. You will not revisit it later. Nobody does.

Constraining Connectivity and Remote Access

NIST SP 800-82 Rev. 3 states that increased IT connectivity and remote access reduce isolation and create a greater need to secure OT systems. Treat every new external connection or remote-access path as a design decision requiring controls:

• Network segmentation – Document network zones, allowed flows, and enforcement points. Do not place every component on one unrestricted network.
• Separate credentials – Assign only required privileges and avoid reusing corporate-network accounts as OT accounts where the architecture follows this guidance.
• Least privilege – Each user and service account accesses only what the role requires.
• Multifactor authentication – Require MFA for remote access where the selected architecture and components support it, or document an approved compensating control.
• Encryption – Specify how remote sessions are encrypted, what protocols are used, and how keys are managed. Where a device lacks modern encryption, VPN gateways may provide a compensating control.
• Managed access points – Route remote access through monitored entry points rather than direct device connections.
• Logging – Define what remote-access events are logged, where logs are stored, who reviews them, and what triggers an alert.
• Disconnect capability – Test the remote-access disconnect procedure. Disconnecting a remote session should not disrupt ongoing monitoring operations; verify this before an incident forces you to find out.

These requirements are risk-tailored: a water-quality station and a dam safety system need different segmentation depth, authentication strength, and logging retention. State the requirements, document exceptions, and assign owners.

Evidence for RFQ, FAT/SAT, and Handover

Every requirement above becomes a row in a procurement and acceptance matrix. For each, record what evidence to request, how to verify it, who owns the result, and what happens if a gap remains.

Representative rows:

Requirement	Requested Evidence	Acceptance Check	Owner	Exception
Device unique identification	Identity spec, registration procedure	Confirm unique ID matches inventory record during FAT	System integrator	Document if device lacks configurable identity
Configuration restore	Hardening guide, restore procedure	Demonstrate restore from approved config at SAT	Supplier + operator	If no restore capability, document manual procedure
Data-in-transit protection	Encryption spec per interface	Verify encrypted session between logger and server	System integrator	If device cannot encrypt, document compensating VPN or gateway
Supplier vulnerability channel	Contact, response scope, format	Confirm the channel accepts a test submission	Procurement	If no channel exists, document risk and mitigation timeline
Update terms and end of support	Written support terms	Review update mechanism and support period before PO	Procurement + engineering	If no support term, define maximum acceptable gap
Network segmentation	Architecture diagram with zones	Verify enforcement points block unauthorized flows at SAT	Network/OT engineer	If flat network is accepted, document compensating monitoring
Remote-access MFA	MFA specification per access path	Test MFA login during FAT/SAT	IT/OT security	If MFA is not supported, document compensating control
Remote disconnect test	Disconnect procedure	Disconnect remote session during SAT; verify operations continue	Operations + IT	If disconnect disrupts operation, define safe procedure
Incident contacts and escalation	Named contacts, escalation path	Verify contacts are reachable before handover	Operations manager	If contacts are TBD, define deadline and interim owner

Use the matrix at three stages: attach requirements to the RFQ so suppliers respond with evidence, verify evidence at FAT/SAT, and confirm handover artifacts are complete before operational acceptance.

Who Owns Updates, Vulnerability Alerts, and Incidents After Handover?

A procurement checklist expires at commissioning unless ongoing ownership is assigned. After handover:

• Update responsibility – Decide whether the supplier, integrator, or internal team applies firmware and software updates. Define the trigger (supplier notification, vulnerability severity, scheduled window) and the approval authority.
• Vulnerability alert routing – Connect the supplier’s notification channel to the internal team that triages and applies patches or compensating controls. If the supplier’s channel is informal, assign someone to monitor it.
• Incident response – Assign incident contacts, evidence retention responsibility, and containment authority before handover. Do not promise a recovery time without tested procedures. NIST SP 800-82 Rev. 3 includes incident-response and recovery capability as part of OT security planning.
• End-of-support transition – When a device reaches end of support, the owner must know the deadline, the supplier’s last update commitment, and the compensating controls for the transition period.

If nobody is assigned to act when the supplier publishes a vulnerability notice after commissioning, the checklist requirements expire with the handover signature.

Next Step: Take the Matrix into Technical Review

Adapt the matrix to the actual consequence classification, architecture, device model, and supplier evidence available for the project. Replace placeholder rows with project-specific requirements.

Where a requirement cannot be met, document the exception and the compensating control. Never delete the row. An explicit exception with an owner is more defensible than a silent omission.

In Indonesia, the regulatory environment for certain monitoring applications (such as SPARING wastewater or BMKG-connected weather stations) may impose additional cybersecurity or data-integrity requirements. Verify applicable Indonesian regulatory obligations separately; this checklist covers technical procurement, not jurisdiction-specific legal compliance.

Fortuna Argatech’s connected monitoring systems (including data loggers like the GEOVOS 1000, ONLIMO water-quality monitoring, and AWLR water-level monitoring) cover the sensor-to-dashboard path this checklist addresses. If you are putting together procurement requirements for a monitoring project, running the matrix against the specific device capabilities and supplier documentation is a reasonable place to start.