iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Monitor a building automation system (BAS) by combining a carefully chosen, non-disruptive packet capture with BACnet-aware analysis and a site-specific baseline of normal devices, relationships, services, and schedules. Capture BACnet/IP where it travels on Ethernet; use a separate serial-capable method for BACnet MS/TP. Then investigate deviations against approved inventories and change records rather than treating every unusual packet as proof of compromise.
This distinction matters because a packet analyzer shows and decodes traffic, while a continuous detection capability also needs asset knowledge, alert handling, evidence retention, and an operational response process. NIST treats BAS as operational technology (OT), so availability, safety, reliability, and control-system impact must shape every monitoring decision.
What exactly are you monitoring in a building automation system?
You are monitoring communications among controllers, gateways, servers, operator workstations, and field networks that operate building services. NIST SP 800-82 Rev. 3 defines the scope this way: “A building automation system (BAS) is a type of OT used to control the many systems used in a building, including heating, ventilation, and air conditioning (HVAC); fire; electrical; lighting; physical access control; physical security; and other utility systems.”
That breadth changes the security objective. A suspicious connection affecting an HVAC controller has different immediate consequences from one involving a fire or access-control system, but all can affect safety, occupancy, continuity, or regulatory obligations. NIST says BAS functions include maintaining environmental conditions, reducing energy and maintenance costs, recording historical data, and monitoring equipment for failures or alarm conditions. Monitoring therefore has to reveal unauthorized activity without interrupting those functions.
#1 Best Overall
Three capabilities are often confused
- Packet observation: obtaining a copy of communications at a defined network point.
- Protocol analysis: decoding BACnet fields and services so an operator can understand who communicated, what object was addressed, and which operation was requested.
- Continuous detection: maintaining an inventory and baseline, identifying meaningful deviations, triaging alerts, preserving evidence, and coordinating an OT-safe response.
Wireshark or a BACnet diagnostic utility can provide the first two capabilities. Neither automatically supplies a complete monitoring program, universal anomaly thresholds, or a safe response process.
Why does BAS traffic monitoring matter for security?
BAS networks often connect systems with different safety and business consequences, and a change that looks like ordinary engineering traffic can alter a physical environment. Monitoring gives defenders evidence about device identity, communication paths, service use, and timing so they can identify unauthorized changes before they become an outage or safety event.
The monitoring design must be risk-based. NIST SP 800-82 Rev. 3 directs organizations to tailor safeguards to their security, business, and operational requirements rather than apply an identical architecture to every site. A hospital, data center, office tower, and campus may all use BACnet but have very different tolerance for a test capture, a controller restart, or a delayed alarm.
Security questions a useful capture should help answer
- Which BAS devices and gateways are communicating, and on which network segments?
- Are communications occurring between approved endpoints, or has an unrecognized device appeared?
- Are devices using expected BACnet services and object types for their role?
- Did traffic volume, timing, destination, or operation change after a maintenance or configuration event?
- Can an operator reconstruct what happened without relying on memory or an incomplete screenshot?
These are investigative questions, not a promise that one capture point will see every system. Visibility depends on the topology, the medium, and where the observer is connected.
How should you scope the BAS before capturing packets?
Start with an inventory and a map. Do not interpret traffic until you know which systems are in scope, which paths are expected, and what operational impact a monitoring change could have.
Build an asset and path inventory
- List BAS assets: servers, supervisory workstations, engineering stations, controllers, routers, gateways, and relevant network infrastructure.
- Record network segments and media: identify Ethernet/BACnet/IP segments and any BACnet MS/TP or other serial trunks. Note which gateways connect them.
- Document approved relationships: record which supervisory systems, controllers, and gateways are expected to exchange traffic.
- Capture operational context: note schedules, maintenance windows, known commissioning activity, and systems where availability or safety is critical.
- Define ownership: identify facilities, controls, IT, and security contacts who can validate an unexpected device or command.
Keep the inventory tied to change records. A new device during an approved retrofit is different from the same device appearing overnight with no work order. The inventory also tells you what a capture cannot cover; a workstation connected to one Ethernet segment cannot automatically reveal a separate serial trunk.
Set a safe monitoring objective
Decide whether the immediate need is troubleshooting one controller, establishing a baseline, investigating an incident, or operating a continuous detection service. A short diagnostic capture may need only a narrow point and retention period. Continuous detection needs repeatable collection, time context, alert ownership, and a process for handling sensitive operational data.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Where should you capture BACnet/IP traffic?
Capture BACnet/IP at an Ethernet location that carries the communications you need to examine, such as the segment linking a BAS server, a BACnet router, and local controllers. A Department of Energy-hosted BAS testbed paper describes Wireshark monitoring on the Ethernet port connecting a BAS server and BACnet router to local controllers. That example demonstrates a useful vantage point; it does not prove that the same point will expose all traffic in another building.
Choose the point based on the question
- Server-to-controller investigation: observe the segment where supervisory traffic and controller responses converge.
- Gateway investigation: observe the Ethernet side of the BACnet router or gateway, while separately considering the downstream medium.
- Unexpected-device investigation: choose the segment where the device is believed to be connected and verify whether routed traffic is visible there.
- Building-wide baseline: map multiple segments and gateways first; one interface may provide only partial visibility.
Coordinate the capture with the BAS owner and network administrator. Use an observation method that does not inject, modify, or block control traffic. The available examples establish capture approaches, not a universal passive-tap design or a guarantee of complete coverage.
Rank #2
How do you capture and inspect BACnet/IP with Wireshark?
Wireshark is a free, open-source network protocol analyzer. Its user guide documents BACnet packet statistics and sorting by instance ID, IP address, object type, or service. Use it for controlled observation and analysis; do not assume that installing it creates persistent alerting or an asset inventory.
- Confirm authorization and scope. Record the building, segment, interface, start time, end time, and operational owner. Establish whether the capture is for a scheduled baseline, troubleshooting, or an investigation.
- Connect to the approved Ethernet observation point. Select the interface that actually carries the BACnet/IP traffic of interest. If the segment is not visible from that interface, stop and correct the vantage point rather than interpreting an incomplete sample.
- Start a bounded capture. Use a defined time window that covers the behavior you need. Note maintenance, occupancy, alarm, or commissioning events occurring during the window.
- Filter and decode BACnet traffic. Use Wireshark’s BACnet display and statistics features to examine source and destination addresses, object types, instance IDs, and services.
- Sort for investigation. Sort statistics by IP address to find communicating hosts, by object type or instance ID to examine affected points, and by service to identify operations that changed.
- Export evidence with context. Preserve the original capture, the filter or statistics view used, the interface and segment, and the analyst’s time zone. Do not rely only on a screenshot.
- Compare with the approved baseline. Validate unfamiliar endpoints, relationships, or services against the asset inventory and change records before escalating.
A capture can show what crossed the selected interface during the selected period. It cannot establish that unseen segments were quiet, that a decoded request was malicious, or that a single unusual packet represents compromise.
Recommended Free Tools
How is BACnet MS/TP captured differently?
BACnet MS/TP is a serial network, so an Ethernet capture does not automatically include it. ABB Technical Note 123 describes using Wireshark for BACnet MS/TP capture and notes that the analyzer can accept input from computer COM ports. BACnet Testing Laboratories (BTL) also lists Wireshark for IP, Ethernet, or MS/TP captures.
Prepare a serial capture path
- Identify the trunk and its physical interface. Confirm that the target network is MS/TP and determine where a compatible computer interface can observe it without disturbing controller communications.
- Validate the adapter and wiring. A USB-to-RS-485 adapter may enable a computer-based capture, but suitability depends on electrical isolation, interface characteristics, drivers, and wiring requirements. No single adapter is universally appropriate, and not every installation needs one.
- Coordinate with the controls specialist. Confirm connection points, polarity and termination practices, and whether connecting the analyzer could affect the trunk. The capture method must be approved for that site.
- Configure the host interface. Use the required COM-port or serial settings specified for the installation and the capture software. Record the interface name and configuration with the evidence.
- Capture a defined period. Include enough operational context to distinguish normal polling and scheduled work from unexpected activity.
- Decode and correlate. Examine MS/TP frames in the analyzer, then correlate device identities and events with the BAS inventory and any Ethernet-side gateway traffic.
Do not describe a generic Ethernet mirror as MS/TP visibility. The medium, host interface, and physical connection determine whether the serial traffic can be observed at all.
Which protocol details are useful for security analysis?
Protocol-aware analysis turns raw frames into questions an operator can answer. Focus on relationships and behavior that can be validated against the site, rather than chasing every unusual field.
Endpoint and identity changes
Review source and destination IP addresses, device identifiers, and object instances. An endpoint that is absent from the approved inventory, a controller communicating with a new peer, or a gateway appearing on an unexpected segment is a lead for validation. Check for an approved installation, address change, or temporary engineering activity before calling it an incident.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Service and object changes
Use service and object-type statistics to find operations that are unusual for a device’s role. For example, a supervisory workstation may normally read values while a commissioning tool performs writes. The packet itself does not establish intent; confirm who authorized the operation and whether it matches the maintenance record.
Timing and volume changes
Compare traffic with normal schedules and operating modes. A burst during a documented startup sequence may be expected, while the same pattern at an unapproved time deserves review. Record the observation window and building state because traffic volume without context is easy to misclassify.
Cross-segment relationships
Correlate the Ethernet side of a gateway with the MS/TP or other downstream network when possible. A capture at only one side may show a request but not the field-network response, or may hide a device that is reachable through another segment.
How do you build a useful baseline?
A baseline is a documented description of expected BAS behavior for a defined scope and operating state. It should be specific enough to investigate deviations but flexible enough to account for schedules, seasonal changes, maintenance, and commissioning.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchRecord the baseline dimensions
- Approved devices, addresses, and roles.
- Expected communication pairs and gateway paths.
- Normal BACnet services and object types for each role.
- Typical operating schedules, maintenance windows, and alarm conditions.
- Network medium and capture point used to establish each observation.
- Known gaps, such as segments or serial trunks not visible from the chosen point.
Establish separate observations for materially different states, such as occupied and unoccupied operation or normal operation and planned maintenance. A single “normal” sample can create false alarms if it represents only one schedule.
Use deviations as investigation leads
Rank deviations by operational consequence and confidence. An unknown endpoint on a life-safety-related segment deserves faster validation than a benign change on a test network, but neither should be blocked automatically based only on a packet. Ask the BAS owner to confirm the device, the change record, and the expected function.
The official guidance available for this topic does not define a universal BACnet anomaly threshold, packet count, or false-positive rate. Set local criteria through risk assessment and operational testing, and document why a deviation is considered actionable.
What is the difference between packet analysis and continuous monitoring?
Packet analysis is an analyst-driven activity: capture traffic, decode it, and investigate a question. Continuous monitoring adds repeatable collection, storage, baseline maintenance, alert triage, and a response workflow.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Capability | Packet analysis | Continuous detection |
|---|---|---|
| Primary purpose | Examine a defined communication window | Identify and manage deviations over time |
| Typical inputs | Capture at a selected interface | Ongoing captures or telemetry plus asset and change data |
| Human work | Analyst filters, decodes, and interprets packets | Operators triage alerts, validate changes, and escalate incidents |
| Coverage | Limited to the selected point and period | Depends on the deployed collection points and maintained scope |
| Evidence | Capture file, filters, statistics, and notes | Retained events, alert history, investigations, and response records |
| Security outcome | Better understanding of observed traffic | A managed process for detecting and responding to suspicious behavior |
Some products combine these functions, but the product name alone does not prove that it provides complete inventory, alerting, or response. Confirm the actual features, supported media, host interfaces, retention, and support model before deployment.
Which tools can help monitor BACnet traffic?
Choose tools according to the medium, the question, and the required operating model. The official listings identify useful options but do not provide a complete, current head-to-head ranking or independent performance test.
| Option | What the cited material establishes | What to verify before use |
|---|---|---|
| Wireshark | Free, open-source protocol analyzer; BACnet statistics and sorting are documented; can be used for IP, Ethernet, or MS/TP captures when the host interface is suitable. | Capture-point coverage, serial interface compatibility, storage, analyst workflow, and how ongoing alerting will be supplied. |
| BACnet-focused tools listed by BTL | BTL lists BACbeat, BACeye/SC, Cimetrics BACnet Explorer, BACnet Quick Test, BOSS Explorer, CAS BACnet Explorer, YABE, BACTrax Explorer, BACtrace, and Wireshark. | Supported media, operating systems, protocol functions, licensing, maintenance, and whether the tool is diagnostic, analytical, or monitoring-oriented. |
| Tools listed by the BACnet committee’s developer-aids page | The page lists commercial BACnet suppliers and tools. | Current compatibility, support, security practices, pricing, and whether a listing is appropriate for your site’s use case. The page describes its supplier list as a sample, not an endorsement or warranty. |
| BACnet Network Auditor | BACnet Interoperability Testing Services describes it for installers and troubleshooting. | Whether its current functions match your monitoring objective, supported network media, deployment impact, and commercial terms. |
| BACnet Network Monitor | BACnet Interoperability Testing Services describes it for end users. | Alerting, inventory, retention, integrations, support, compatibility, and current licensing. |
| USB-to-RS-485 interface | Can be a task-enabling physical item for a compatible computer-based MS/TP capture setup. | Electrical isolation, interface type, drivers, wiring, and approval for the specific trunk; it is not a universal requirement. |
BTL and the BACnet committee provide resource lists, not a guarantee that every listed tool meets your security-monitoring needs. Obtain current technical and commercial details from the relevant supplier and test within the site’s change-control process.
How should you operate monitoring without disrupting building services?
Treat the capture as an OT change, even when the intended action is passive. The safest design observes traffic without injecting packets, changing controller settings, or creating a new control path.
Rank #4
Before collection
- Obtain approval from facilities or controls personnel and the network owner.
- Define the exact segment, medium, interface, time window, and retention period.
- Identify systems where a disruption could affect safety, occupancy, security, or critical operations.
- Prepare a rollback plan for the physical connection and host configuration.
- Decide who will review unexpected findings and who can authorize an operational response.
During collection
- Monitor interface health and confirm that the capture is receiving the intended traffic.
- Record schedule, occupancy, alarms, maintenance, and commissioning activity.
- Avoid active tests or configuration changes unless they are separately approved.
- Protect capture files because they may reveal building layout, device identities, and operational behavior.
After collection
- Verify file integrity and preserve the original evidence.
- Document the capture point, medium, interface, timestamps, filters, and known blind spots.
- Compare findings with inventories and change records.
- Escalate only validated concerns through the site’s OT incident process.
What should you do when traffic looks suspicious?
Use a staged investigation rather than immediately blocking or disconnecting a device. OT controls can fail when a well-intended security action interrupts a required communication path.
- Validate the observation. Check that the capture point, timestamp, decoder, and scope are correct.
- Identify the endpoints and function. Map addresses, device roles, object instances, services, and gateway paths to the inventory.
- Check approved activity. Contact the controls or facilities owner and review work orders, commissioning, software updates, and schedule changes.
- Assess operational impact. Determine whether the behavior touches HVAC, fire, electrical, lighting, access control, physical security, or another utility function.
- Preserve evidence. Keep the original capture and investigative notes before changing collection or device state.
- Escalate through OT procedures. If the activity remains unexplained or presents material risk, involve the designated incident team and system owner.
- Choose containment deliberately. Any block, isolation, or configuration change should be approved by people who understand the control process and its safe operating state.
An unexpected packet is a lead, not automatic proof of compromise. The reviewed guidance supports risk-based OT monitoring but does not prescribe a universal BACnet response threshold.
What are the most common monitoring mistakes?
Assuming one capture point sees the whole building
Routed Ethernet segments, gateways, and serial trunks create visibility boundaries. Map those boundaries and report the uncovered portions instead of presenting a local capture as building-wide evidence.
Using Ethernet methods for MS/TP
MS/TP requires a suitable serial observation path and host interface. An Ethernet analyzer connected away from the trunk cannot substitute for that setup.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Confusing decoding with detection
A decoded packet explains a communication; it does not create an alert queue, asset inventory, baseline, or response team. Define those operating functions separately.
Calling normal maintenance malicious
Commissioning and engineering work can introduce new devices, services, and traffic patterns. Correlate deviations with schedules and change records before escalation.
Ignoring operational constraints
Capture methods and investigative actions can affect fragile or safety-relevant systems if implemented carelessly. Require facilities and controls review, and favor non-disruptive observation.
Keeping evidence without context
A file without interface, segment, timestamps, filters, and operating-state notes is difficult to interpret. Preserve those details with the original capture and record known blind spots.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhat does current NIST guidance say about BAS monitoring?
NIST SP 800-82 Rev. 3 is the finalized guide, published September 28, 2023. Use it as the settled reference for OT security concepts, risk-based assessment, and tailoring safeguards to operational requirements.
NIST released an initial public draft of SP 800-82 Rev. 4 on September 21, 2026. The draft expands discussion of Building Automation and Control Systems (BACS), adds guidance on asset management and network monitoring and detection, and discusses protection of system-management functions and zero trust principles. As of October 25, 2026, it remained a draft, with comments due November 30, 2026; treat its additions as proposed guidance rather than final requirements.
The practical implication is consistent across both versions: understand assets and communication paths, assess risk in the site’s context, and design monitoring around safety, availability, reliability, and business needs. Do not claim that a draft recommendation is already a finalized mandate.
What is a practical implementation sequence?
A phased sequence limits operational risk while producing useful security evidence early.
- Define scope and owners. Identify BAS functions, segments, gateways, operators, and the person accountable for safe monitoring.
- Map media and paths. Separate BACnet/IP Ethernet visibility from BACnet MS/TP serial visibility and document gaps.
- Run a bounded diagnostic capture. Use an approved observation point and record complete context.
- Build the inventory. Tie observed devices, relationships, services, and object types to approved records.
- Collect baseline states. Cover relevant schedules and planned maintenance rather than relying on one operating window.
- Define investigation criteria. Specify which deviations require validation, escalation, or immediate OT coordination; do not invent universal thresholds.
- Select operating tools. Confirm protocol support, interfaces, host systems, retention, alerting, compatibility, licensing, and support.
- Test the workflow. Exercise evidence preservation, owner notification, and safe response without disrupting control operations.
- Review and maintain. Update the inventory, baseline, capture coverage, and contacts after changes to the building or BAS.
This sequence keeps packet visibility, protocol interpretation, and continuous detection as related but distinct deliverables.
Frequently Asked Questions
Is there a universal BACnet traffic threshold that proves an attack?
No. The available NIST guidance does not establish a universal packet count, service frequency, or anomaly score that proves compromise. Thresholds should be justified through the building’s risk assessment, operating schedules, approved changes, and the consequences of a false alarm.
Will a USB-to-RS-485 adapter work with any BACnet MS/TP installation?
No. Compatibility depends on the adapter’s electrical characteristics and isolation, host drivers, wiring, and the specific trunk. Confirm those requirements with the controls owner before connecting equipment; the capture examples do not establish one universally suitable adapter.
Can a packet capture be used as the only record during a BAS incident?
A capture is valuable evidence, but it should be accompanied by the interface, segment, timestamps, filters, operating state, inventory references, and analyst notes. Without that context, another investigator may not be able to determine what the file actually covers.
How often should a BAS traffic baseline be refreshed?
There is no single interval that fits every building. Refresh it after approved topology, controller, gateway, software, or schedule changes, and whenever seasonal or operating-state differences make the existing profile unreliable.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

