IEC 62443 and NIST in Plain Language for BAS Techs

A few years ago, the cybersecurity section of a BAS specification was a paragraph about passwords. Now it's increasingly a page that says "the system shall comply with IEC 62443" or "align with NIST SP 800-82", often pasted from somewhere else, sometimes by someone who hasn't read either.

This article is a field tech's map of those documents. It isn't legal advice or a substitute for reading them, and I'll flag where the detail matters enough that you should check the standard itself or ask the owner's security team. The goal is to let you recognise what's being asked, answer what you can, and push back honestly on what you can't.

Why these documents apply to buildings

Building automation is operational technology (OT): computers that control physical equipment. The security standards written for industrial control systems — plants, utilities, factories — apply to it with very little translation. The same problems show up: devices that can't be patched quickly, protocols with no authentication, equipment that has to keep running, and a long service life. NIST's OT guidance names building automation systems explicitly, and 62443's concepts fit a BAS network naturally.

The IEC 62443 series

IEC 62443 isn't one standard. It's a series of documents, each aimed at a different party: the asset owner, the system integrator, the product supplier. The trick to reading a spec clause is working out which part applies to whom. The parts you'll meet most often:

There's also a part, 62443-2-4, that sets requirements for service providers such as integrators and maintenance contractors. If you run a BAS contracting business, it's the part most directly about you; it's worth asking whether a spec that cites "62443" means it. I'd check the current edition before quoting its contents, as parts of the series have been revised.

Zones and conduits

This is the most useful idea in the series for field work, and you probably already do a version of it. A zone is a group of assets with the same security requirements — the BAS controllers, say, or the supervisory servers. A conduit is a communication path between zones, with the allowed traffic defined and protected.

In practice, a BAS zone is usually a VLAN and subnet with a firewall at its edge, and a conduit is the set of firewall rules between it and another zone. The value of the vocabulary is that IT and security teams already use it. If you describe your design as "controllers in one zone, supervisor in another, one conduit to corporate for operator access and one for remote access, each with named flows", you're speaking their language. Segmentation and firewall rules turns that into a request you can hand over.

Security levels

62443 describes four security levels, roughly in terms of who you're defending against:

• SL 1 — protection against casual or accidental misuse.
• SL 2 — protection against intentional attack using simple means, limited resources and general skills.
• SL 3 — protection against intentional attack using sophisticated means, moderate resources and skills specific to control systems.
• SL 4 — protection against sophisticated attack with extensive resources.

The standard distinguishes the level you're aiming for (the target), the level a component or system is capable of, and the level actually achieved once it's installed. It groups its requirements under seven foundational areas, covering things like identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. For a BAS, most practical specs aim at SL 1 or SL 2 for most zones; SL 3 and above generally implies product capabilities and design effort beyond what typical building controllers offer today. Treat that as a rule of thumb, not a reading of any particular project.

NIST SP 800-82 Rev. 3

NIST Special Publication 800-82 Revision 3, published in September 2023, is the Guide to Operational Technology (OT) Security. Earlier revisions focused on industrial control systems; Rev. 3 broadened the scope to OT generally and names building automation systems among the systems it covers.

It's guidance rather than a certification standard. It explains OT risks, recommends architectures (including segmentation and defence in depth) and maps security controls to OT environments. For a BAS tech, it's the most readable place to see why an owner is asking for what they're asking for. It's free from NIST, and even skimming its architecture chapters is worthwhile.

NIST Cybersecurity Framework 2.0

The NIST Cybersecurity Framework (CSF) 2.0, released in February 2024, is an organisation-wide framework, not a technical standard. Owners use it to describe and measure their overall security programme. It's organised into six functions, and every BAS security task you do fits under one of them:

When an owner says "we use the NIST CSF", this table is the conversation. Frame your deliverables in those six words and they'll slot straight into the owner's reporting.

What an owner may reasonably ask of a contractor

Whatever standard the owner follows, the requests tend to converge on the same list. Expect some or all of these:

• An asset inventory: devices, firmware and software versions, addresses.
• A network diagram showing zones, conduits and the flows through each.
• Documentation of accounts and roles, and confirmation that default credentials are changed. See default passwords and shared logins.
• Your remote access method, and agreement to use theirs. See remote access.
• A hardening and patching approach for supervisors and controllers. See the hardening checklist.
• Backup and recovery procedures, with evidence of a test restore.
• Incident notification: how quickly you'll tell them if you suspect a problem, and who you'll call. See the first hour.
• Personnel controls: that you'll tell them when a technician with access leaves.
• Product evidence: any security certifications or assessments the manufacturers hold for the products you're supplying.

Most of that is documentation you should have anyway. Contractors who can hand it over at the tender stage stand out.

Answering "shall comply with IEC 62443" honestly

When a spec says the system shall comply with 62443, don't tick "complies" and hope. Equally, don't just take an exception to the whole clause. A better approach:

1. Ask which parts and which level. Raise a question during tender: does the owner mean 3-3 at a target SL for specific zones? Product certification to 4-2? Contractor processes under 2-4? A risk assessment under 3-2? The answer changes what you're pricing.
2. Respond requirement by requirement. Where the spec lists specific requirements, answer each one: meets, meets with a compensating control (name it), requires owner action (such as providing the VPN), or can't be met by the specified products.
3. Separate product claims from system claims. If a manufacturer holds a certificate, quote its scope exactly as issued — which product, which part, which level — and attach it. Don't extend it to the whole system.
4. Be clear about legacy devices. Where existing BACnet/IP or Modbus devices stay in place, say they rely on zone-boundary controls.
5. Don't sign what you can't evidence. A compliance statement is a contractual claim. If you can't show how a requirement is met, don't say it is.

Owners and their consultants generally respond well to that kind of answer. It shows you've read the clause, and it gives them a clear list of what's met and what still needs deciding.

The takeaway

You don't need to memorise the standards. Know that 62443 is a series with different parts for owners, integrators and suppliers; that zones and conduits are segmentation with better vocabulary; that security levels describe who you're defending against; that NIST 800-82 is the OT guide and CSF 2.0 is the owner's programme framework. Then answer specs one requirement at a time and never claim more than you can show.

Found a wrong number or a broken link? Tell me and I’ll fix it.