Join our Newsletter — 33% off our NHI Course

How can security teams detect serial COM access?

Security teams detect serial COM access by watching for unexpected use of serial interfaces on systems or equipment where that access should be rare. Check host and device logs, inventory changes, and physical connection events, and alert on new processes or users opening COM ports. Restrict local access, disable unused ports, and verify authorised maintenance activity.

Serial COM access is easiest to spot when it stands out from the normal device baseline: a workstation, server, or controller that rarely uses serial ports suddenly shows port opens, attached hardware, or maintenance-style activity. The signal is strongest when host telemetry, physical access records, and change history all point to the same unusual serial session rather than a one-off legitimate service action.

Detection works best when you correlate multiple layers. Host logs can show processes or users opening COM ports, device and inventory records can show a new serial peripheral, and physical or console access events can show someone present at the rack or enclosure. If those signals do not line up with an approved maintenance window, treat the activity as suspicious.

Serial access is often low-noise because many environments do not monitor it closely, and attackers or insiders may use it to bypass network-based visibility. On OT and building systems, serial paths can connect directly to controllers or management interfaces, so a successful serial session may expose configuration changes, firmware actions, or operator-level control without touching standard remote access controls. One useful baseline is the OT Security Guide, which helps frame serial access as part of a broader segmentation and industrial access problem. For building and facilities environments, the Building Management System Security Guide is a strong fit because serial links often sit alongside other local management channels.

What to watch for on hosts, consoles, and attached devices

Look for new or rare COM-port activity on endpoints that normally do not talk to serial hardware. That includes unfamiliar processes opening serial devices, unexpected users interacting with local console tools, and sudden changes in attached USB-to-serial adapters or embedded management interfaces. In many environments, the most valuable clue is not the serial event alone, but the fact that it appears on an asset that should be stable and remote-managed.

Device-side evidence matters as much as host telemetry. Logs from controllers, embedded systems, hypervisors, or management appliances may show console access, configuration writes, or session timing that lines up with the host event. If the environment includes industrial or facilities systems, serial activity should also be checked against approved engineering work, because legitimate serial maintenance is common enough to create false positives if you do not maintain a clean baseline.

Why serial access is a security problem, not just an audit detail

Serial connections can bypass the controls teams rely on for remote access, including network segmentation, jump hosts, MFA, and perimeter monitoring. That makes them attractive for troubleshooting, but also for abuse when an insider, contractor, or attacker has physical proximity. The practical issue is that a serial session often looks like trusted maintenance unless you already know who was expected to use it and when.

In environments with operational technology or local equipment management, serial access can alter system state with little visibility to central security tooling. If a port is left enabled, a console account is shared, or a local adapter is connected without logging, the access path can become a quiet persistence channel. The security question is therefore not only whether serial access occurred, but whether it was authorised, attributable, and necessary for the asset in question.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
CIS Controls v8 CIS-1 — Inventory and Control of Enterprise Assets Serial COM detection depends on knowing which assets expose or should not expose serial interfaces.
CIS-8 — Audit Log Management Host and device logs are central to spotting unexpected COM-port opens and maintenance abuse.
Recommendation — Maintain an accurate asset inventory and flag unexpected serial-capable devices or attachments. Collect and review logs that record serial-port opens, users, and process activity.
NIST SP 800-53 Rev 5 AU-6 — Audit Record Review, Analysis, and Reporting Detecting serial access requires reviewing correlated audit evidence for unusual local console use.
AC-6 — Least Privilege Serial interfaces should be restricted to only the personnel who genuinely need local maintenance access.
Recommendation — Analyze audit records for uncommon serial-port activity and escalate anomalies. Limit serial-port use to approved maintenance roles and remove unnecessary local access.
ISO/IEC 27001:2022 A.8.15 — Logging Serial access detection relies on logs from hosts, devices, and access events.
Recommendation — Enable logging for serial access events and retain records for review.

Practitioner Guidance

What to verify: Confirm which assets should ever expose serial access, which users or teams are allowed to use it, and whether the event occurred during an approved maintenance window. A serial connection on a low-touch server or controller deserves faster attention than the same event on a bench-lab system.

Decision rule: If the serial session cannot be tied to an approved person, device, and work order, treat it as suspicious until proven otherwise. If the event is expected, preserve the evidence anyway, because serial access is often the first place where undocumented maintenance habits show up.

What good looks like: You have a current inventory of serial-capable assets, logs that record who opened the port and why, and a clear process for disabling unused interfaces. Where serial access is genuinely required, it should be rare, attributable, and easy to reconcile with change records.

Practitioner takeaway: Serial COM access is a correlation problem, not a single-alert problem, so the strongest detections combine endpoint, device, and physical evidence to separate authorised maintenance from hidden console use.