{"id":3626,"date":"2026-10-27T13:00:00","date_gmt":"2026-10-27T05:00:00","guid":{"rendered":"https:\/\/cnbygele.com\/?p=3626"},"modified":"2026-10-26T19:08:44","modified_gmt":"2026-10-26T11:08:44","slug":"power-meter-network-security","status":"publish","type":"post","link":"https:\/\/cnbygele.com\/vi\/blog\/power-meter-network-security\/","title":{"rendered":"B\u1ea3o m\u1eadt m\u1ea1ng c\u1ee7a c\u00f4ng t\u01a1 \u0111i\u1ec7n: B\u1ea3o v\u1ec7 d\u1eef li\u1ec7u \u0111o l\u01b0\u1eddng v\u00e0 c\u1ea5u h\u00ecnh"},"content":{"rendered":"

Power meter network security starts with knowing which devices can reach the meter, which commands they can send and how the installation recovers after a configuration change. Inventory the meter and gateways, restrict communication to approved systems, separate routine readings from configuration access, and test recovery without disturbing the electrical process. A working Modbus connection is not evidence of authenticated or encrypted communication. Check the capabilities of the exact instrument and every gateway rather than assuming that an Ethernet connection, serial cable or password on one application protects the entire route.<\/p>\n

This guide concerns defensive planning for an authorized metering installation. For establishing a functional connection first, use the power meter Modbus setup guide<\/a>. Network changes must follow the site’s operational approval and maintenance procedures.<\/p>\n

Start with the real communication path<\/h2>\n

Draw the path from the instrument to the system that consumes its readings. Include serial buses, serial-to-network gateways, switches, engineering laptops, data collectors, remote support routes and cloud connectors where they actually exist. Distinguish devices that initiate requests from systems that only receive exported data. An undocumented maintenance laptop can be more consequential than a well-controlled dashboard.<\/p>\n

Record model, firmware, interface option, location, owner and purpose for each component. Keep network addressing and serial unit identifiers in a protected configuration record. Identify shared buses: changing a gateway can affect many meters even if the ticket names only one. Confirm who owns the electrical process and who can authorize communication interruptions.<\/p>\n

The CNBYG BY194 instrument family<\/a> offers an optional RS485\/MODBUS interface in its published product description. This does not establish native Ethernet, encryption, user accounts or role permissions for an ordered variant. Obtain the specific manual and gateway documentation before making a security claim. The product illustration identifies the exterior reference and does not demonstrate installed security features.<\/p>\n

Define what must remain trustworthy<\/h2>\n

For some sites the priority is reliable energy reporting. Others use readings for alarms, supervisory decisions or contractual allocation. Identify the consequence of missing, delayed or altered data. Also identify configuration changes that could corrupt readings without stopping communication: a modified ratio, scale, unit or clock can leave an apparently healthy dashboard showing misleading information.<\/p>\n

Document which values are informational and which systems act on them. A metering connection should not acquire unnecessary write access merely because a commissioning tool supports it. Where the actual product does not enforce permissions internally, assess controls at the gateway, network boundary and operating procedure. Record those controls as installation measures, not as native meter functions.<\/p>\n

The NIST Guide to Operational Technology Security<\/a> provides a useful framework for balancing security with availability, reliability and safety. Its recommendations require adaptation to the installation. An office-computer patching or scanning routine should not be applied automatically to an operational meter network.<\/p>\n

Separate access paths and responsibilities<\/h2>\n

Routine acquisition should use the minimum access needed to obtain approved measurements. Configuration access should have an identified owner, defined purpose, authorized time window and change record. Confirm whether the collector, gateway or device can enforce the distinction. If it cannot, document the compensating boundary and residual limitation.<\/p>\n

Use approved network segmentation and explicit communication rules where supported by the site’s architecture. Define permitted sources, destinations and services from the real data flow. Test the rules with the operational team. A rule that blocks needed time or management services can create new failures, so begin with an accurate dependency list and a recovery route.<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Control area<\/th>\nPractical question<\/th>\nAcceptance evidence<\/th>\n<\/tr>\n<\/thead>\n
Asset inventory<\/td>\nIs every meter and gateway assigned an owner?<\/td>\nReviewed device and path record<\/td>\n<\/tr>\n
Routine acquisition<\/td>\nWhich systems are allowed to read?<\/td>\nApproved connection list and successful collection<\/td>\n<\/tr>\n
Configuration<\/td>\nWho can alter ratios, clocks or settings?<\/td>\nAuthorized role or documented boundary control<\/td>\n<\/tr>\n
Remote support<\/td>\nHow is access opened and closed?<\/td>\nTime-bounded session and closure record<\/td>\n<\/tr>\n
Recovery<\/td>\nCan the correct settings be restored?<\/td>\nTested backup and verified readings<\/td>\n<\/tr>\n
Monitoring<\/td>\nCan stale or changed data be recognized?<\/td>\nQuality flags and reviewed event records<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

These are qualitative controls adapted from OT security principles. They are not a certification checklist or a claim that the illustrated instrument implements each function.<\/p>\n

\"Disconnected
Product-reference illustration of the disconnected BY194 exterior. Context materials illustrate the review process; this image does not establish interface options, register formats, security capabilities or measurement specifications.<\/figcaption><\/figure>\n<\/p>\n

Understand the limits of protocol protection<\/h2>\n

The Modbus Application Protocol specification<\/a> describes requests, responses, functions and data addressing. Do not treat a normal reply as proof of the sender’s authorization. The actual protection depends on the protocol variant, implementation and surrounding controls. Verify any claim about authenticated or encrypted communication against documentation for both endpoints.<\/p>\n

A VPN or other approved secure connection can protect a particular transport segment, but it does not automatically restrict what an authenticated remote user does after connection. Likewise, encrypting communication to a gateway does not prove that its downstream serial segment has the same protection. Document each boundary separately and identify where trust is transferred.<\/p>\n

A serial cable is not an access-control policy. Physical access to cabinets, service ports and gateways matters. Keep maintenance adapters controlled, identify permitted connection procedures and prevent casual attachment of unmanaged devices. Cabinet work must remain under qualified personnel and the site’s electrical safety procedures; security testing does not authorize live electrical intervention.<\/p>\n

Plan remote support as a controlled activity<\/h2>\n

Identify the business reason for remote access and the person responsible for the session. Use the site’s approved access service and individual identities where available. Avoid permanently open routes created for a one-time commissioning issue. Preserve the ability to revoke access without losing the plant’s normal local monitoring.<\/p>\n

Before the session, agree on allowed actions and a rollback point. During the work, capture configuration changes and relevant communication events. Afterward, close the access route, verify collection and compare critical settings against the approved baseline. If a shared support credential is unavoidable under existing equipment limitations, record its controlled handling and replacement procedure rather than implying individual accountability exists.<\/p>\n

Do not expose a gateway directly to public access merely to simplify data collection. Route the design through the site’s security and operations teams. Choose a supported architecture that serves the actual monitoring need and can be maintained over the equipment lifecycle. A hurried workaround can become an undocumented permanent dependency.<\/p>\n

Keep a recoverable configuration baseline<\/h2>\n

A backup should identify the exact equipment, firmware, interface settings, transformation ratios, units, clocks and relevant gateway rules. Include software versions needed to read the file. Keep access secrets in the approved protected store rather than embedding them in an openly shared engineering report.<\/p>\n

Test restoration on suitable spare or isolated equipment where possible. Confirm that the recovered configuration produces the expected measurements and communication behavior. A backup file that has never been opened is weaker evidence than a documented restoration test. Do not restore blindly to a different hardware or firmware revision.<\/p>\n

Following an authorized change, compare the important settings and data path with the baseline. Check that the expected unit, scale and destination remain correct. Use the meter accuracy verification guide<\/a> when a change affects the measurement chain. A successful network login cannot validate electrical measurement accuracy.<\/p>\n

Monitor data quality as well as connection status<\/h2>\n

A connected collector can repeatedly receive stale or misinterpreted values. Track freshness, communication failures, unexpected resets and configuration changes where the equipment exposes them. Distinguish the time a measurement was created from the time a collector received it. The meter time synchronization guide<\/a> explains why timestamp assumptions need their own checks.<\/p>\n

Set alert behavior according to operational consequence. A temporary communication gap should be identifiable without creating an uncontrolled flood of retries. Maintain clear quality flags in downstream reports; do not silently turn a missing reading into zero energy. Review unexpected changes against maintenance records before assuming either a cyber incident or an electrical fault.<\/p>\n

Collect only logs that the site can protect and review. Establish retention and ownership appropriate to the task. Baseline normal behavior so that a new data source, unusual connection or unexplained configuration change can be investigated. Avoid intrusive scans of operational equipment unless the method and maintenance window have been approved and validated for that environment.<\/p>\n

\"Disconnected
Product-reference illustration of the disconnected BY194 exterior. Context materials illustrate the review process; this image does not establish interface options, register formats, security capabilities or measurement specifications.<\/figcaption><\/figure>\n<\/p>\n

Test the design without disrupting operations<\/h2>\n

Begin with a documented test plan and a representative isolated setup where available. Confirm approved collection, blocked unapproved routes, remote-session closure and recovery. Test failure handling using safe simulated communication loss rather than creating uncontrolled interruptions on a production bus. Define who can stop the test and how normal service is restored.<\/p>\n

Record both positive and negative observations. A firewall rule entered into a console is configuration evidence; a controlled connectivity test demonstrates its effect under the tested conditions. A successful test from one laptop does not establish protection against every route. State the tested sources, destinations and time so that later changes can be evaluated honestly.<\/p>\n

Procurement questions that prevent hidden assumptions<\/h2>\n

Ask for the exact interface option, supported firmware lifecycle, configuration export method and recovery instructions. For gateways, request supported management interfaces, authentication options, update procedures and logging capabilities. Ask which protections apply to upstream traffic and which apply to the meter side. Require written evidence for any claimed encrypted or authenticated protocol support.<\/p>\n

Select the design with the team that must operate it. A sophisticated feature that cannot be maintained is not automatically a better choice than a simpler controlled architecture. Preserve a documented owner, supported replacement route and verified commissioning baseline throughout the installation’s life.<\/p>\n

Educational background: transport security<\/h2>\n

The educational lesson below explains Transport Layer Security and why protected communication involves more than connecting a cable. It supports the discussion of transport boundaries. It does not establish TLS support in BY194 or prove that a gateway’s downstream link is protected; those capabilities require exact product documentation.<\/p>\n