Start with the conclusion
First, turn “security” into questions that can be answered
A field switch connects PLCs, HMIs, and data collection systems on one side, and may connect maintenance computers or upper-layer networks on the other. Security testing must answer not whether the device name sounds “industrial” enough, but who can change it, which devices can communicate with each other, and whether a wrong configuration or failure will interrupt critical services. Checks should be based on the real connection relationships and the actual firmware, and should keep evidence that can be verified repeatedly.
Network security testing and reliability tests such as high/low temperature, vibration, and electromagnetic compatibility are not the same thing. The former looks at access, configuration, and communication boundaries; the latter looks at performance under specified physical conditions. A product listing industrial environment specifications does not prove that it has completed a specific cybersecurity certification. An ordinary on-site check also cannot automatically be called a formal compliance assessment.
The management plane and the forwarding plane work on different objects
The management plane is the entry point for accessing device configuration, status, and logs, such as Web, SSH, or SNMP. The forwarding plane handles service frames between terminals, letting PLCs, HMIs, or servers exchange data. The two types of messages may enter through the same physical port, but the device processes them along different logical paths: messages sent to the management address enter the management service, while ordinary service frames go to the outgoing port according to the corresponding forwarding rules.
Therefore, normal service communication does not prove that the management entry point is correctly restricted; using HTTPS on the management page does not prove that PLC service traffic is encrypted. Testing needs to look at both “can the device be accessed or modified” and “can the device be used to reach areas that should not be reached.” A successful login or a successful ping cannot replace all conclusions.
Draw the boundary first, then check assets and responsible persons
List the switches, firmware versions, management addresses, service ports, uplinks, maintenance sources, and responsible persons, and mark on the network diagram whether they belong to the control, collection, or maintenance area. The lines in the diagram should be findable on site, and port labels should correspond to the configuration. If assets and boundaries are unclear, it is hard to judge who an alert from a scan belongs to and what it affects.
Temporary maintenance computers, wireless access, and newly added cameras should also be included in the diagram. A temporary network cable may connect areas that were originally separate; a management address may also be accessed from unnecessary network segments. The testing scope should clearly state the specific devices, interfaces, time, and test conditions. Other areas cannot be judged safe just because “no problem was found.”
Check accounts, not just whether default passwords were changed
Account checks should look at personnel duties and permissions: whether people who only view status must have permission to modify configuration, how accounts are disabled after someone leaves or hands over duties, and how default or shared credentials are managed. Authentication confirms who is accessing; authorization decides what they can do. The two cannot be mixed into one “login works” check item.
Which account levels, authentication services, and log fields are actually supported depends on the model and firmware. The public features of Feichang Technology product 2241 include multiple management methods, authentication-related functions, and access rules, which are suitable to list item by item as check items. A feature name on a product page does not mean the currently delivered device has been configured or verified according to project requirements.
Management protocols should be checked together with source restrictions
HTTPS and SSH can protect the transmission of the corresponding management sessions, but the enabled versions, credentials or certificates, and allowed access sources still need to be checked. SNMP is a commonly used monitoring protocol, and different versions have different authentication and privacy capabilities. When a corresponding secure version exists, it should be selected based on actual support and the monitoring system, and it should be confirmed whether old, unnecessary management entry points have been closed.
Source restrictions can reduce unnecessary management exposure, but the rules must also cover the interfaces and protocols actually used. During testing, verify separately from allowed and disallowed maintenance locations: allowed personnel can complete the required work, and unauthorized locations cannot enter the corresponding management service. At the same time, confirm that the result remains after the configuration is saved and after a restart; do not check only one temporary session.
VLANs divide broadcast domains; cross-area permission still needs rules
A VLAN is a method of dividing a Layer 2 network into different logical broadcast domains. Which VLAN a port joins, where untagged frames belong, and how the uplink carries tags all affect the actual boundary. It is not turning cables into physical insulation, nor does it guarantee that any two areas can never communicate. A Layer 3 interface or external gateway may still connect different network segments.
Cross-area access needs to be restricted with routing, access control lists, or appropriate security devices. ACLs can allow or deny based on supported conditions such as addresses and protocols; the match position, direction, rule order, and default action all affect the result. A switch supporting ACLs does not mean it has deep inspection for any industrial protocol or full firewall capability, and even less does it mean it has been configured correctly.
Suppose the maintenance area needs to access a collection server, while the control area PLC does not need to be accessed by all maintenance terminals. The required sources, destinations, and services can be written into a communication matrix, and then the allowed and denied items can be verified. Proving only that two VLANs cannot ping each other does not mean other services are denied; similarly, allowing one maintenance session should not open up the entire area as a side effect.
Service protection depends on the actual load, not just feature switches
Capabilities such as port admission, address binding, storm suppression, and loop protection can limit some abnormalities under appropriate configuration, but mismatched thresholds or rules may also affect legitimate communication. For example, if the MAC changes after a device is replaced, old binding rules may block it; if broadcast limiting is too strict, it may affect terminals that need discovery or configuration.
Before verification, first record the frame types, peaks, cycles, and error conditions of normal services, and then check the impact of the rules in an appropriate test environment. The availability and security goals of a formal control network should be considered together. Do not treat enabling more restrictions by default as safer, and do not simplify testing into applying high load to production equipment without a plan.
Logs and time are the conditions for reconstructing the operation process
Logs should at least support the logins, configuration changes, and key states that the project needs to check; the actual event types and storage methods should be confirmed according to product capabilities. When clocks on different devices are not aligned, it is hard to judge the order of several alerts. Time settings, event records, and centralized storage mechanisms should be checked, and the behavior after a restart or when log space is insufficient should be reviewed.
Configuration backups also need controlled storage: backups may contain accounts, addresses, and network rules, and they should not be shared freely just because they make recovery convenient. Keep versions and differences before and after remediation, and record who changed what; only then, during retesting, can you know which specific change produced the result, rather than an accidental recovery.
Different product capabilities mean different test objects
Feichang Technology product 2241 publicly lists management functions such as VLAN, ACL, system logs, and configuration import/export, which can be used to check management access, cross-area rules, and recovery processes. Whether it meets project requirements also depends on the actual hardware, firmware, and configuration. The port photos shown on the official website are for identifying the product and cannot be used as proof of cybersecurity results.
The Feichang Technology mini five-port unmanaged product 2262 is mainly used for small Ethernet access. Its support for transmitting VLAN-tagged frames does not mean it provides configurable VLAN boundaries or management accounts. For such devices, the focus should be on access location, physical ports, upstream partitioning, and external control measures; the check screens and conclusions for managed devices cannot be copied directly.
Write remediation and retesting into the same record
A useful finding should include the test source, target device or interface, actual behavior, evidence, and service impact. Then write down the remediation measure, responsible person, time, and retest method. This is how different facts can be distinguished: “an old protocol was seen,” “an unauthorized area can indeed enter the management plane,” and “a service interruption has already occurred.”
Before configuration adjustments or firmware upgrades, prepare a verified backup and recovery process, and verify it in an appropriate environment or maintenance arrangement. After completion, recheck allowed access, denied access, critical services, logs, and configuration persistence, and record conditions that cannot be verified. The value of testing is to make boundaries and recovery capability checkable, not to put a permanent “absolutely safe” label on a device.
Compare with the physical photos in the product center
Provides copper ports, pluggable optical module slots, and Console; management and security features should be checked against the delivered firmware. Original official website photo; the device has not been redrawn.
Suitable for small copper port access; support for tagged frame transmission does not mean VLAN isolation can be configured. Original official website photo; the device has not been redrawn.
Material note: The illustrations are general mechanism diagrams and have been technically checked; appearances marked with model numbers refer to official website photos, and other cutaway views and components do not represent the actual internal circuits of Feichang Technology products. They are not measured waveforms or real project sites; wiring and power supply should follow the delivered manual.
Verification materials: Managed DIN-rail industrial switch with four 10G optical ports and eight Gigabit Ethernet copper ports
Feichang Technology mini five-port gigabit unmanaged switch (product 2262)
NIST SP 800-82r3: OT Security Guide
CISA: Communications Infrastructure Visibility and Hardening Guide
Translated from the Chinese technical article. Source first published: 2021-01-05. Source last revised: 2026-10-13T10:22:10+08:00. Read the Chinese source
