Cybersecurity Requirements in Controls Specs

The controls section on your last bid had a new article in Part 1 titled Cybersecurity. It was a page and a half, you skimmed it, and you priced it at zero because the controllers you always use have passwords. After award the owner's IT group reviews your network submittal and sends it back: no segmentation plan, default accounts still listed, a cellular modem for remote support that nobody approved, and no asset inventory. Each item is a fair reading of that page and a half, and each one is labor you didn't carry.

This article covers what cybersecurity articles in controls specs commonly ask for, what IEC 62443 is when a spec cites it, and what to submit to show you complied.

Where the requirements show up

Cybersecurity language turns up in a few places, and a single book can use all of them:

• A dedicated article in Part 1 of the controls section, in 23 09, Division 25, or the process control section.
• A separate cybersecurity section, often written by the owner and dropped into Division 25 or Division 40.
• The owner's IT or OT standard, attached as an appendix or referenced by name, which the spec says governs.
• Division 27, which covers the owner's network and decides who furnishes switches, firewalls, and addressing.
• Federal and some utility jobs, which bring their own cybersecurity criteria and an approval process that can take longer than the submittal review.

Read all of them. The requirement that costs money is often in the owner's standard, not the controls section.

What they commonly ask for

The wording varies a lot, but the topics repeat. Expect most of these.

Network segmentation. The control system runs on its own network or VLAN, separated from the owner's business network by a firewall. No controller is reachable from the internet. Connections to outside systems pass through a defined point, often a separate zone between the control network and the business network. Read closely for who furnishes and configures the firewall, because specs often say the owner owns it and the integrator documents what crosses it.

Accounts and passwords. No default credentials left on any device. Individual accounts instead of shared logins, with roles that limit what each user can change. Password length and complexity rules, lockout after failed attempts, and a secure handover of every credential to the owner at turnover. On a large job this is a real list: every controller, switch, workstation, and server.

Remote access. Only through a method the owner approves, usually the owner's own VPN or remote access system, often with multifactor authentication and logged sessions. No vendor-installed remote desktop tools, modems, or cellular routers without written approval. Some specs require remote access to be off by default and enabled per session.

Patching and firmware. Software and firmware at a current, supported version at turnover. A list of installed versions. Some specs ask for the manufacturer's support lifecycle, so the owner knows when a product stops getting security updates, and a described process for applying updates after turnover.

Hardening. Disable services and ports you don't use, such as unencrypted web, Telnet, and FTP. Shut off unused switch ports. Use encrypted protocols where the equipment supports them. On BACnet jobs, a spec may ask for BACnet Secure Connect, a secured transport added to the BACnet standard in recent years, which only works if your controllers and front end support it. Check the datasheets before you assume.

Backups. Current program and configuration backups for every controller and server, kept offline, with a written restore procedure. Some specs ask you to demonstrate a restore before acceptance.

Logging. Audit logs on the front end and network devices, synchronized clocks, and logs retained for a stated period.

Documentation. This is the part that becomes a submittal: network diagrams, an asset inventory, a list of ports and protocols, account lists, and the procedures above in writing.

Every one of these is ordinary good practice. The spec turns it into a deliverable with a review, which means hours.

IEC 62443, in general terms

When a spec cites a standard, it is usually the IEC 62443 series. It is a family of standards for securing industrial automation and control systems, developed with the ISA99 committee. It was written with industrial and process systems in mind, and building automation specs cite it too.

A few ideas from it show up in specs constantly:

• Roles. The series separates the asset owner, the system integrator, and the product supplier, with different parts written for each. As the integrator, you sit in the middle: you choose the products and you design and configure the system.
• Zones and conduits. Group equipment with similar security needs into zones, and control every connection between zones through a defined conduit. A segmentation plan is this idea drawn on a riser.
• Security levels. The series defines levels of protection, each against a more capable attacker. A spec may name a target level for the system or for a zone.
• System versus component. Specs most often cite 62443-3-3, which covers security requirements for a system, or 62443-4-2, which covers individual components. A controller certified as a component does not make your system compliant. The system requirements depend on how you put the parts together.

Two practical notes. First, a spec that says "comply with IEC 62443" without a part or a level is ambiguous, and that is an RFI before bid, not an interpretation after award. The judgment call is in submittal vs RFI. Second, don't claim certification you don't hold. "Designed in accordance with" and "certified to" are different statements, and the reviewer knows the difference.

What to submit

The cleanest way to show compliance is a compliance matrix: one row per requirement in the spec, with how you meet it and where the evidence is. It answers the reviewer's question before they ask it, and it turns a page and a half of prose into a checklist both sides can tick.

Behind the matrix, the documents that usually make up the package:

1. Network riser diagram with zones, the firewall boundary, IP ranges, and every connection to an outside system. What a good riser carries is in the network riser diagram.
2. Asset inventory: device, model, firmware version, location, network address, and role.
3. Ports and protocols list: what talks to what, on which port, and why.
4. Account and role plan: roles, what each can do, and how credentials will be handed over. Never put live passwords in a submittal.
5. Remote access description, matching the owner's approved method.
6. Hardening checklist per device type.
7. Backup and restore procedure.
8. Manufacturer security documentation where the spec asks for it, including any component certifications, quoted for what they actually cover.

Timing matters. Submit the network design and the matrix before controllers are configured, because the owner's IT review can force changes to addressing and remote access that are cheap on paper and expensive in the field. Credentials, final firmware versions, and backups belong in the closeout turnover.

Pricing it

Read the article at bid with a pencil. The hours are in hardening every device, writing the documents above, meeting with the owner's IT group, possibly furnishing managed switches or firewalls, secure remote access licenses, and a second round of network review. If the spec is silent on who owns the firewall or what security level applies, write your assumption into the bid.

How Submittal Kit handles this

A cybersecurity article read once at bid and priced at zero comes back as a rejected network submittal. In Submittal Kit, when you upload the spec book and claim the controls section, it is read for what it requires you to submit, with each demand quoted beside its article reference. A documentation requirement buried in Part 1 shows up as a line you create, mark already covered, or mark not required, instead of surfacing at the IT review. Bind the compliance matrix and its documents as their own named sections with a Custom Upload in configure sections. If Part 2 names a feature your controllers must support, the spec check reads their datasheets against it and flags what they don't state.

Disclosure: I build Submittal Kit. None of the requirements above depend on which tool assembles the package.