Wiresheet Security and IP Protection

Niagara wiresheets carry real intellectual property. The control logic on a sheet is often the accumulated result of years of sequence development, commissioning corrections, and site-specific tuning — and by default, anyone with Workbench access to that station can open it, read it, copy it, or take it somewhere else. For integrators and OEMs who develop proprietary logic, that is a genuine commercial exposure with very little standing between it and the door.

We developed a Niagara module that addresses it: a wiresheet security lock that protects the logic on a sheet from inspection and extraction. We are not aware of another commercially available equivalent in the Niagara ecosystem, though we would not claim to have surveyed every vendor.

What It Does

  • Drag-and-drop protection — dropping the module onto a wiresheet populates and locks it in one action. There is no lengthy configuration procedure to get wrong or skip under deadline.
  • Tamper response — if the protection is interfered with, the protected logic does not simply become readable. It is removed.
  • Extraction resistance — the objective is that the programs and link data on a protected sheet cannot be lifted out and reused elsewhere.

We deliberately do not publish the mechanism. Describing exactly how a protection control detects tampering and what triggers its response is a roadmap for defeating it, and publishing that would make the module less useful to the people relying on it. The technical detail is available under NDA in a direct conversation.

Understand the Trade-Off Before You Deploy It

This is protection with teeth, and that cuts both ways. A tamper response that removes protected content is doing exactly what an IP-protection control should do — and it is also a destructive action on a live building system. That deserves a deliberate decision, not a default.

So we deploy it the same way we deploy anything consequential: the behaviour is explained and agreed in advance, the station owner knows what is protected and what happens if it is disturbed, and backups exist before it goes anywhere near a production station. If a client is not comfortable with the trade-off, the honest answer is that this control is not for them — not that we should quietly soften it.

Who This Is For

Systems integrators and OEMs who have developed genuinely proprietary control logic and are handing stations to clients, contractors, or competitors who will have Workbench access. If your differentiator is your sequences and your logic, and you are currently relying on nobody bothering to look, this closes a real gap.

It sits alongside the rest of our Niagara Framework development work — custom modules, drivers, and the engineering tooling we have built from doing the work. Where the concern is network-level rather than station-level, our sister practice covers OT and BACnet network security.

Tell us what logic you need protected and who will have station access — we will walk you through how the module behaves, what it commits you to, and whether it actually fits your situation.

Related services

Why Station Permissions Do Not Close This Gap

Niagara's own access model is part of why the exposure exists. Station user permissions govern what a logged-in station user sees through a station connection: categories, and read, write, and invoke rights at operator and admin level. They do not govern platform access. Someone holding platform credentials for the host can run a station backup, use the Station Copier, or read the station directory off the file system, and none of those paths is filtered by the station's category permissions. A permission scheme that hides a folder from an operator does not hide it from anyone who can reach the platform.

It is worth being concrete about the routes by which a sheet leaves a site, because they are not all technical and most of them are ordinary service activity rather than bad faith.

  • A station backup taken from the platform, which produces a .dist file carrying the station's configuration and can be restored onto another compatible host
  • The Station Copier, which moves the whole station directory between the platform and a local Workbench machine
  • The station's config.bog on the host file system, readable by anyone with file-level access to the platform
  • Copy and paste of a wiresheet selection into another station or into a local .bog file, which needs no export step at all
  • Saving components into a palette, which turns a working sequence into a reusable block for whoever holds the palette
  • Reading the sheet directly, since link topology and block parameters are visible on screen and a competent engineer with time can transcribe what is in front of them

What This Control Does Not Cover

Protection on a sheet addresses one threat model: a person who is legitimately inside the system and can be expected to have Workbench and platform access. It is not a substitute for the account discipline that decides who gets that access in the first place. Where one set of platform credentials is shared between the owner's staff, a service contractor, and the OEM, sheet protection ends up carrying weight that a credential policy should be carrying.

Two limits surprise people often enough to be worth stating plainly. Protecting the implementation does not conceal the strategy: point histories, trend logs, and any values published over BACnet or Modbus to a head end still show what the logic does under a given set of conditions, and someone who watches a system long enough can infer a sequence without ever opening a sheet. And protection applies going forward. Station backups, .bog copies, and palettes that were handed out before it was applied are exactly as readable as they were the day they left, and nothing applied afterward reaches them.

The second limit sets the order of work on an existing account. If a body of logic has already been distributed across a fleet of stations built over several years, the useful question is which future stations and which future handovers this changes, and whether the sequence is due a revision anyway. Treating protection as a way to recall what is already out will not work, and planning around it as if it could is the mistake to avoid.

Deciding What Goes Behind the Protection

Applying the protection is the drag-and-drop step described above, and it stays that. What takes the time on a real station is the two things sitting around it: deciding which sheets go behind protection and which slots stay reachable, and getting the module onto the platforms and workstations that need it. Neither of those is configuration of the protection itself, and neither gets easier by being skipped.

The boundary question needs an engineer rather than a policy. A protected sheet still has to leave the station operable by people who are not you: the owner's staff moving a setpoint, a service contractor chasing an alarm at two in the morning, a commissioning agent rebalancing after a tenant fit-out. Where the split lands in the station tree matters as much as which points stay writable. The cleanest boundary usually follows folder lines that already exist, with the proprietary sequence in its own folder rather than interleaved on the same sheet as unit-level wiring and site-specific point mapping. Stations that grew organically across several projects often lack that separation, and restructuring them to get it is ordinary Niagara work that is far easier before protection than after.

What comes out of that exercise is a specific list of the points and setpoints that stay writable once protection is applied, and that list is what you hand the station owner when they ask what they still control. Named points are worth more to them than a general assurance. The list is usually built from the same categories on every station.

  • Setpoints and deadbands the owner's staff adjust as a normal part of running the building
  • Schedules and calendar references, which usually belong outside the protected sheet entirely rather than inside it
  • Alarm limits and alarm enable slots a service contractor has to reach to retune or silence an alarm
  • Manual override and out-of-service points a technician uses while troubleshooting a mechanical fault
  • Points published over BACnet or Modbus to a head end or a third-party front end, which have to keep resolving after protection is applied
  • Any slot a PX graphic links to, since a broken ord there surfaces as a null on an operator's screen rather than as anything that looks like a protection issue

Version, Signing, and What the Controller Has To Carry

The failure mode to recognize before it happens is the difference between a missing module and a protection event. The module has to be present on every Workbench that opens the station, and when it is not, the components on that sheet come up as unresolved. Unresolved is not a tamper response; it means the local Workbench does not have the module, and installing it there resolves them. The distinction matters because the wrong reading of an unresolved sheet is a technician deciding to clean up broken components on a live station.

Niagara modules are built against a Niagara version and are signed, and the platform checks a module's signature against its trust store before installing it. Two consequences follow. A Niagara upgrade on the controller is not a swap-in-place for the station's modules, so it has to be planned as a version-matched set across the controller and every Workbench that connects to it. And a controller replacement, whether a warranty swap or a capacity upgrade, has to include getting the module onto the new host as its own platform-level step rather than as something a station restore takes care of.

Three platform questions are worth settling before anything is scheduled.

  • The controller model, and how much free space and memory headroom it has for another module
  • The other third-party modules already on the platform, and whether their version requirements agree with this one
  • The upgrade path expected over the station's life, since a station protected today will outlive at least one Niagara version

Backups, the Master Copy, and Getting a Station Back

A backup of a protected station is a backup of the protected station. It is intended as a restore path for the station and is not intended as a route back to readable logic, since the extraction resistance the module aims at applies to what comes out of a backup as much as to what comes off the sheet in Workbench. The unprotected engineering copy therefore has to live somewhere else, under the OEM's or integrator's own version control, and that copy is the master.

This changes what a routine site backup is worth and to whom. A service contractor whose recovery plan has always been "we have a backup" now holds a backup that will restore the station and is not the copy anyone engineers from. Which party holds the master, in which repository, and against which version record, is a question with a specific owner, and it is a separate question from the tamper behavior itself.

The part worth writing down is the restore-to-service path. Which party is authorized to reapply protection after a station is rebuilt, who holds the module and the platform credentials needed to install it, and how a replacement controller gets back to a protected running state are all answerable in advance and awkward to work out during an outage. A station only one person can bring back is its own kind of exposure, and it is not the one this control was bought to address.

Frequently Asked Questions

Is this the same thing as code obfuscation or a license check?

No, and the difference is in what each one tries to stop. A license check gates execution: it decides whether logic is entitled to run on a given host, which is a commercial control rather than a confidentiality one. Obfuscation leaves the logic present and readable and only makes it tedious to follow, which buys time against a casual reader and not much against a determined one. This control is aimed at inspection and extraction of the sheet, and its tamper response removes protected content rather than scrambling it. We do not describe the mechanism beyond that in public, for the reason given above, and the technical detail is available under NDA.

Does this run on a JACE, a Supervisor, or both?

It is a Niagara module, so it installs where Niagara runs, but the surrounding considerations differ by host. On an embedded controller the constraints are space, memory, and the fact that the station restart the install needs lands on a live building. On a Supervisor the constraint is the host itself: the station directory sits on a general-purpose Windows or Linux machine, so anyone with file-level access to that server, including whoever administers it for reasons unrelated to the BAS, can reach the station files. Where proprietary logic runs on a Supervisor, the list of people who can touch the host is usually longer than the list of people with Workbench access, which is worth checking before deciding which host the logic belongs on.

How does installation actually proceed?

The module goes into the Workbench modules directory on the engineering workstation, then installs to the target platform through Software Manager over a platform connection, and the station restarts to pick it up. That restart is the step that needs a maintenance window on an occupied building; the workstation-side part disturbs nothing. Because the install is a platform-level operation it needs platform credentials for that host, which on a client-owned controller may sit with the owner or their service contractor rather than with the party doing the engineering. Sorting out who runs that step is usually a scheduling question rather than a technical one, but it is the step that slips.

Will BQL queries, tags, and reporting tools still see the points on a protected sheet?

Only the points the boundary leaves reachable, which is why anything that walks the component space has to be identified before protection rather than discovered after. BQL queries, tag-driven navigation and hierarchies, history extensions, and third-party analytics that resolve ords into a folder all depend on those ords continuing to resolve. The common surprise is a report or a dashboard nobody remembered was pointed at an intermediate calculation inside the sequence rather than at a published output. The usual fix is to publish an explicit output point for the value the report needs and let the report read that, which is better practice regardless of protection.

Does the building owner still get a sequence of operations?

Yes, and protecting a sheet does not change that obligation. A sequence of operations describes intent: what the system does under given conditions, what the setpoints are, how modes change, what the alarms mean. The wiresheet is the implementation of that intent, and the implementation is where the accumulated engineering sits. Commissioning agents, TAB contractors, and the owner's staff work from the sequence document and the setpoints left writable to them, which is why the document and the sheet can be separated at all.

When is this not worth doing?

When the sheet is stock kitControl wiring that any competent engineer would rebuild directly from the sequence of operations, protection is guarding something that is not scarce. The same applies when the station will only ever be opened by your own people and no contractor, competitor, or client engineer will hold Workbench access, because the exposure the control addresses does not arise. It also does not fit where the proprietary part is software running off-station, in which case the thing to protect is that software rather than the sheet that talks to it. Read the qualifier above in reverse: where the differentiator is service coverage, hardware, or integration reach rather than the sequences themselves, the sheet is not where the value sits.