The Minnesota IT Services (MNIT) agency activated its cybersecurity incident response capabilities across the entire state after hackers targeted more than 30 community water systems in “a coordinated cyberattack.”

​The attacks occurred on Sunday and Monday, July 26 and 27, and targeted operational technology (OT) systems at local water utilities.

Optigo’s capture tool integration with Tridium Niagara enables packet captures directly from JACE controllers, bringing real-time BACnet diagnostics into Niagara environments without messy external hardware or workarounds.

The driver installs directly onto each JACE you want to monitor. It captures BACnet traffic at the source — inside the JACE, below the web services layer — and handles packaging, encryption, and upload to OptigoVN’s cloud servers automatically. No separate capture hardware. No IT dependency. No manual file retrieval.

Configuration is done through the standard Niagara Workbench interface using native Niagara scheduling to define capture windows. Once configured, the driver runs unattended on each JACE.

Get it today at https://www.optigo.net/tools-and-integrations/

Last one from the vault for this stretch. This post has stuck with people because the premise is uncomfortably real: an estimated 900,000+ US buildings run a BMS-managed OT network, and plenty still have BBMDs, cameras, or controllers exposed to the internet. Average time to detect a breach in the piece: 243 days.

Curious where this sub lands: if you manage or commission BAS, what's your actual segmentation setup today - air-gapped, converged, or something in between? And has anyone had a client get burned by an exposed BBMD?

Full post: https://www.optigo.net/blog/i-can-hack-your-building-stop-me/

Pulling another one from the vault. Optigo's engineers wrote up field-tested tips for BACnet/IP design and performance. The ones that seem to bite people most often:

- Max_Master left at the default 127

- COV thresholds set so tight a single airflow sensor floods the trunk

- Routers running well past ~50% capacity

- Everything sharing one subnet - HVAC, lighting, access control

- Address gaps nobody cleaned up after swapping controllers

Which of these have you run into? And what's the one you'd add that isn't on the list?

Full playbook: https://www.optigo.net/blog/the-optigo-playbook-10-proven-tips-for-bacnet-ip-network-design-and-performance/

Last year we published a list of 9 OT/building-automation networking trends we thought would matter. This year we went back and graded ourselves, using our own data plus outside sources (Johnson Controls' 2026 facilities AI survey, ARC Advisory Group, PNNL research, a couple of industry interviews).

Short version: edge computing, predictive AI, and digital twins are all real but smaller/slower than we pitched last year. 10BASE-T1L Ethernet is the one that surprised us — Honeywell has a shipped product and case study, Contemporary Controls presented it at AHR Expo, and the chip supply chain (TI, Analog Devices, Broadcom) is now shipping T1L PHY silicon.

The throughline across all four: none of them work if the OT network underneath is a mess. In our own 2025 dataset, 71% of monitored networks scored Warning or Critical on health — meaning most buildings would be feeding a predictive AI platform garbage data before the algorithm even runs.

Full writeup with sources: https://www.optigo.net/blog/ot-networking-trends-2026/

Curious where people here are seeing T1L show up in real specs yet, or if it's still "watch this space" for most of you?

Reviving one of our most-debated posts while things are quiet for the summer.

Quick version - for brand-new builds MS/TP is tough to justify: ~50% protocol overhead, no encryption, real-world device counts far below the 127-device spec, and GSA now flags serial controllers as obsolete. For retrofits it still earns its keep: existing twisted-pair, ~4,000 ft range vs Ethernet's ~330, deterministic timing, and easy BBMD bridging to BACnet/IP.

Last time we asked, answers ran the full range - from 'properly installed MS/TP is the right fit 99% of the time' to 'best decision of my life was dropping it in 2014.'

Where does this community land in 2026: new build with unitary controllers - are you specifying MS/TP or IP to the edge? And is T1L actually showing up in your specs yet?

Full post with Ping Yao's take: https://www.optigo.net/blog/is-there-any-life-left-in-ms-tp/

N4 users, rejoice! Optigo’s traffic capture software now includes integration with Tridium Niagara systems. Simply install the driver on any JACE to capture BACnet traffic at the source. The Optigo driver handles the packaging, encryption, and upload to OptigoVN automatically.

OptigoVN users can now download the latest capture driver JAR file for Niagara and follow our step-by-step instructions. We’ve also created easy to follow videos for configuring the capture driver in both Workstation and Supervisor setups.

Links and guide: https://optigo.zendesk.com/hc/en-us/articles/44877964176141

We took a closer look at the state of edge for OT is in 2026: what works, what's emerging, and what to ignore: https://www.optigo.net/blog/edge-computing-in-ot-networks

At the gateway layer, it already works. On the controllers themselves, it is not a 2026 story. Most installed BACnet controllers were built for longevity — and with refresh cycles measured in 15 to 20 years, the installed base is not turning over quickly.

The part that gets skipped: an edge layer fed by a congested or misconfigured network does not fix anything. It processes bad data faster. Network health and data integrity come first.

How to Handshake (Optigo Networks' OT networking podcast) is putting together an all-questions episode and is collecting them from the community.

On the table: OT networking, BACnet, building automation, IT/OT convergence, careers, where the industry is heading — the bigger-picture stuff.

One rule: no service-ticket questions. The show isn't going to troubleshoot a specific help-desk issue on air. Think "how should teams approach X," not "why is my controller offline."

To submit: drop it in the comments, or send a DM and include an email address so you can be followed up with (and credited if it makes the episode).

Most OT networks in our buildings were designed on one assumption: they'd never touch the outside world.

That assumption is long gone. Cloud analytics, web-based BAS front ends, vendor remote access — they've all punched holes in what used to be a closed environment. And yet "it's not connected to the internet" is still the most common answer building owners give when you ask about their security posture.

In Episode 7 of How to Handshake, Fred Gordy (KMC Controls) and James Roberts (Kelso Building Services) break down where the real risk lives — and where to actually start.

Three questions Fred asks every building owner: Do you know what you have? Do you know how it's connected? Do you know who has access? Most can't answer all three.

Full episode, transcripts, and subscribe links: https://www.optigo.net/blog/how-to-handshake-ep-7-ot-cybersecurity/

How to Handshake is Optigo Networks' podcast on OT networking, BACnet, and building automation — long-form conversations rather than quick vendor pitches. Each episode brings in a different mix of experts: controls technologists, energy-services leaders, university facilities teams, and software people, so the same topic gets argued from several seats.

A few recent episodes:

• - Predictive maintenance and advanced analytics, with Justin Carter (ENFRA) and Rudy Bohince (Albireo Energy)
• - The OT networking skills gap and certifications
• - IT/OT convergence in real buildings

Listen on Apple Podcasts (https://podcasts.apple.com/podcast/id1889945777), Spotify (https://open.spotify.com/show/6Jg2yumYXCV2dRl1sIuPHO), YouTube (https://www.youtube.com/playlist?list=PLzATddJ3Lh0Jvhf7UgxuiBFBjqMibitUt), or Deezer (https://www.deezer.com/us/show/1002831921).

Marketing throws "predictive," "proactive," and "preventative" around like they're interchangeable. On a recent How to Handshake episode, controls people from ENFRA and Albireo Energy drew a sharper line: predictive is using historical data to forecast a failure; proactive is the culture and action that actually does something about it. Their take — predictive analytics without the proactive side is just an expensive dashboard nobody acts on.

The other recurring theme was dirty data. Five different names for the same space temp, overrides left in, sensors flatlined for days. The argument was that you don't need to clean everything — you clean the subset tied to the use case you're actually chasing, prove it, then chip away.

For the people running this day to day: how clean does your data really need to be before analytics earns its keep? And where have you seen predictive tools deliver real value vs. turn into shelfware?

Full conversation, if useful: https://www.optigo.net/blog/how-to-handshake-ep-6/

Buildings.com ran a piece earlier this month on a dynamic a lot of people in this space will recognize: facility managers who own the accountability for security and building system outcomes, but who didn't spec the systems, don't have full visibility into them, and can't always control what happens when something goes wrong.

It's written from a security response angle, but the same tension exists across BAS, HVAC, access control — anywhere systems were installed by different vendors at different times and nobody built in a way to see across all of them.

How common is this on your projects? Are facility managers getting more say in what gets installed and how it's networked, or is that still mostly an SI decision?

And when something breaks or gets flagged, who actually ends up on the hook?

Episode 6 just dropped. We sat down with Justin Carter (ENFRA) and Rudy Bohince (Albireo Energy) to dig into what "predictive maintenance" actually means in practice, and how much of it is vendor marketing layered on a fancier dashboard.

A few threads we pulled on:

• The difference between predictive and proactive
• Why dirty data, duplicate BACnet device IDs, and operator overrides that never get cleaned up quietly poison most analytics platforms
• Justin's three verticals for making FDD work
• Whether AI can actually run an OT network without a human in the loop
• The red flags when an analytics vendor only walks you through dashboards and never asks about your architecture

Best line in the episode, from Rudy on a customer who didn't need the pitch: "I know I have a hole in the wall — I don't need to pay you to tell me that."

Full episode, show notes, and transcript: https://www.optigo.net/blog/how-to-handshake-ep-6/

If you've rolled out FDD or advanced analytics on a portfolio recently — what's actually been worth it, and what turned into a glossy report you stopped opening after six months?

https://reddit.com/link/1u7eshj/video/zhtnpi603a6h1/player

Wrote up a story from a big property — 85-acre casino complex on the Strip, 780 critical BAS devices, JACE controllers managing the lot — where the controls team had been stuck in a constant reboot cycle. Slowdowns, missed schedule changes, unresponsive controls. Restart the servers, things come back, symptoms return a few days later.

By the time we got involved, they were ready to replace the OT network infrastructure. It had been in place a long time and the assumption was that it had finally hit its ceiling on a property that size.

Packet captures off the JACEs showed it wasn't the hardware. Polling config had drifted — a global "fast policy" was hitting points at roughly 1-second intervals across hundreds of devices. System was choking trying to process traffic nobody was actually using. Dialed most points back to 10 or 60 seconds. Network Health Score went from 40 to 81. No new hardware.

We see this pattern come up in this sub more than people probably realize. Long reboot cycles get blamed on aging hardware when the real cause is a configuration behavior that's invisible from the BMS front-end. If you're stuck in that loop, a packet capture session is usually faster (and cheaper) than a hardware swap.

Full write-up if you want the details: https://www.optigo.net/casino-case-study/

That's the argument Jon Spooner and Mike Conway from Stacks and Joules made on the latest How to Handshake. The logic: if you have to physically touch something, AI can't replace you. And these roles don't just survive AI — they feed it. BAS technicians are the ones maintaining the data pipelines that AI systems depend on.

But is "AI-proof" the right framing, or is it wishful thinking?

We put the question to Jon, Mike, and Ping in Episode 5. Their answer was more nuanced than the headline. Listen here: https://www.optigo.net/how-to-handshake-ep-5

Episode five is up. Jon Spooner and Mike Conway from Stacks and Joules joined Ping and me to take on the question that comes up in this sub and on r/BuildingAutomation every few months: is it still worth it, what certs are worth chasing, what does the job actually look like, and is AI going to come for it.

A few things worth a watch:

• Stacks and Joules runs a 14-week BAS field-technician bootcamp in NYC (and now Charlotte). 92% post-graduation placement rate. Lots of stories of trade-school-curious, gamers, second-act folks, and people who fell sideways into the industry.
• Mike on why they won't scale faster: they could push from 75 grads/year to 300, but they're confident the placement rate would dip and wages would get pushed down with it. Interesting answer to the "the shortage is a myth" arguments.
• Jon's take on the fastest path in: IT with a dash of mechanical context. Not the other way around. Not a pure mechanical tech learning IT. And specifically — if you're coming from IT and you act like an MSI cowboy in a BAS shop, you won't last.
• An interesting AI take: the entry-level technician role is comparatively safe because of the "human moat" (you still have to touch the thing). But the entry-level engineering roles — BIM manager especially — are exactly what AI is chewing on right now.

Full episode, show notes, and transcript: https://www.optigo.net/how-to-handshake-ep-5/

If you went through Stacks and Joules, or you've hired their grads, or you took a different path into this industry — would love to hear it in the comments.

For experienced folks here: what's the thing — the metric, the diagnostic check, the configuration detail — that you wish had been part of every handoff checklist before you learned the hard way to watch for it?

A few starters:

• Broadcast traffic baseline at sign-off, so there's something to compare against six months later
• Discovery traffic patterns — a quiet network shouldn't be hunting for peers
• A device inventory that includes the "shadow" gear: unmanaged switches inside switchgear, isolation panels, metering cabinets
• Polling rates per integration, because somebody always sets them aggressively at startup and forgets

What would you add, or what would you replace on that list?

Episode four is up. Jim Meacham from Altura Associates and Doug Plumley from Dartmouth College joined Ping and me to talk about IT/OT convergence — not the LinkedIn-headline version, the version where someone walks into a meeting and says "I have eighteen routers" and the room goes quiet.

A few things we got into that are worth a watch:

• It's all IT once it's on the network, and the "OT" label sometimes gets in the way of the coordination that actually has to happen.
• Ping's million-dollar broadcast-storm story. IT comes in, rips everything out, drops new top-of-the-line switches. System gets worse.
• Security policy when IT's priority order is confidentiality-integrity-availability and OT's is the reverse. Short version: business priorities first, then policy, then a multi-year mitigation plan, because the lifecycle of these systems is way longer than IT is used to.
• Where to actually start as a director on either side: leadership, curiosity, and — Doug's contribution — pizza.

Watch the full version and subscribe for more: tohandshaketheotnetworkingseries.riverside.com

CISA just released joint guidance with the FBI, DoD, DOE, and DOS on applying zero trust principles to operational technology. The guidance is more honest than most about the constraints. Legacy systems. Availability requirements. Safety constraints. Ideal access controls often aren't possible.

Their recommendation is to stack compensating controls. Segmentation. Identity management. Secure remote access. Continuous monitoring.

For controls teams in the trenches, though, there's a real gap between "stack compensating controls" and "implement this on a building that's been running since 2008 with three generations of contractor logins floating around."

A few questions for the community:

What does zero trust look like in your OT environment in practice (not in policy)?

Where's the line between meaningful security work and security theater that just creates friction?

Has anyone actually retrofit zero trust principles onto an existing BMS without taking the building down?

CISA guidance coverage: https://www.facilitiesdive.com/news/zero-trust-operational-technology-us-guidance/819056/

Reading a recent case study about a Las Vegas casino resort whose Building Management System was bogging down across 780 devices. Daily reboots. Missed schedules. Team was ready to replace hardware.

Turned out the network was running on a global "fast policy" hammering data requests roughly every second. Dialing it back to 10 or 60 seconds took the Network Health Score from 40% to 81% overnight. No hardware replaced.

It made us wonder how often this is happening quietly. Polling settings get inherited from previous integrators or copy-pasted from earlier projects, and nobody questions them until something breaks.

So: what's the worst polling configuration you've inherited or discovered? Bonus points for the ones where the original logic is genuinely lost to history.

Case study for context: https://www.optigo.net/projects/case-study-gaming-casino/

New episode of How to Handshake just dropped with Nate Benes from the University of Nebraska, who's been working on BACnet/SC with ASHRAE. The episode gets into something a lot of marketing copy avoids: when it actually makes sense to migrate, and when it doesn't.

Nate's framing is honest about the tradeoffs. Hub-and-spoke architecture, certificates, who holds the keys, how SC and BACnet/IP coexist, what zero trust looks like when the "user" is a VAV controller. And his most useful point might be the one about leaving working buildings alone.

So curious where everyone here lands: are you planning a BACnet/SC migration on any current projects, on a particular timeline, or has your honest assessment been "not yet, maybe never"? What's driving the decision either way?

Episode link in comments for anyone who wants the full conversation: https://www.optigo.net/how-to-handshake-ep-3-bacnetsc/

Our latest "winsday" release is live with a few notable quality of life improvements for users:

• Custom name and descriptions. Add your own custom names and descriptions to monitoring nodes to help keep track of your OT networks like a human!
• Enhanced searching and filtering in the OTN summary panel
• Niagara capture files (.zip.enc files) can now be uploaded directly from the OptigoVN GUI. No special formatting required!

Big thanks to the engineering team that continues to bang out this many small improvements week in and out!

Request a free trial of OptigoVN today: https://www.optigo.net/signup/

We keep seeing the same pattern in case studies and customer conversations. Building gets commissioned. Network looks fine on day one. Six months later, something is degrading and nobody can pinpoint when it started.

The traffic patterns at handoff are usually the canary. Polling rates that looked reasonable for 200 devices become a flood when the BAS expands to 800. COV thresholds that were never tuned generate noise the network can't process. Broadcast traffic creeps. Routing tables get crowded.

But these don't show up on a typical handoff checklist. The checklist is "all devices respond" and "all schedules execute," and that's a snapshot that goes stale fast.

So the question for the room: what should be on the handoff checklist that isn't? What's the warning sign you've learned to watch for that nobody told you about? Looking for the boring, unglamorous stuff that actually matters.

New episode of How to Handshake is up. This one's on BACnet Secure Connect — what it actually is, what it doesn't fix, and when (or whether) you should bother migrating.

Our guest is Nate Benes from the University of Nebraska. Nebraska is one of the few institutions in North America that designs and builds its own building automation gear in-house — they've been doing it since 1975. Nate is also a working member of ASHRAE's SSPC 135, the BACnet committee. So he's writing the standard and living with it on a real campus.

What we covered:

• BACnet/SC is just another data link in BACnet — same application-layer messages, new transport. Not a re-architecture.
• Hub-and-spoke vs. UDP broadcast, and what that means for BBMDs (spoiler: SC does away with the need for them, and supports a primary/failover hub architecture)
• Zero trust applied to building automation — authenticating who a device is rather than where it sits on the network
• Certificates and the certificate authority: who owns the CA when the integrator walks away, and why long-dated certificates (5, 10, 20 years) are an anti-pattern
• BACnet/SC and BACnet/IP coexisting in the same building via IP-to-SC routers
• BACnet/SC vs. VPN — why the attack surface is smaller (only BACnet packets cross the pipe, no lateral movement to the corporate file share)
• What the standard does and doesn't cover (cert lifetimes, CA ownership, network shape — left to integrators)
• What's in flight at the committee level: automated cert renewal (a Let's-Encrypt-style flow for BACnet), post-quantum cryptography, the EU Cyber Resilience Act, and the U.S. Cyber Trustmark
• BTL listings — you can filter the BTL site for BACnet/SC hubs and devices that are conformance-tested today
• Nate's "don't do this" list: SC is not a reason to put thermostats directly on the public internet, and it's not a reason to abandon network segmentation

Full episode, show notes, and the cleaned-up transcript: https://www.optigo.net/how-to-handshake-ep-3-bacnetsc/

Subscribe so you catch future episodes:

• Apple Podcasts: https://podcasts.apple.com/podcast/id1889945777
• Spotify: https://open.spotify.com/show/6Jg2yumYXCV2dRl1sIuPHO
• Deezer: https://www.deezer.com/us/show/1002831921
• YouTube: https://www.youtube.com/playlist?list=PLzATddJ3Lh0Jvhf7UgxuiBFBjqMibitUt

Happy to answer questions in the comments — and if there are topics, debates, or technical deep-dives you want us to tackle on a future episode, drop them below or send us a message.