27DCIM, CMMS, security and access control, and OT cybersecurity

27.0Scope of this chapter

This chapter covers four systems that sit on top of the electrical, mechanical and controls systems of a data-centre campus. The data centre infrastructure management (DCIM) system holds the inventory of the white space and shows capacity. The computerised maintenance management system (CMMS) holds the asset register and the planned maintenance (PM) schedules that the operations team uses from the first day after handover. The physical security systems (access control, closed-circuit television (CCTV) and intrusion detection) control who enters which room. The operational technology (OT) cybersecurity programme protects the building management system (BMS), the electrical power monitoring system (EPMS) and every other control network from misuse.

1. DCIM functions. What a DCIM system does, the data sources it reads, and the products in common use.
2. DCIM data model. Sites, rooms, cabinets, devices, power chains, sensors and the relations between them.
3. DCIM commissioning. The point-to-point verification of DCIM data against the field, with a worked example.
4. CMMS asset register. The asset hierarchy based on ISO 14224, the asset data fields and the naming rules.
5. Asset data handover. The flow from the equipment schedule to the CMMS, the PM schedules and the acceptance of the asset data.
6. Access control. Readers, controllers, door types, fail-safe and fail-secure locking, and the fire alarm release.
7. CCTV and intrusion detection. Camera coverage, recording, retention and alarm handling.
8. Physical security tests. The door interlock test, the fire release test, the CCTV coverage test and the interface tests with the BMS and the fire alarm system.
9. IEC 62443 and NIST SP 800-82. What each document requires and how they apply to a data-centre OT network. NIST is the National Institute of Standards and Technology (NIST).
10. Zones, conduits and security levels. The zone model of an MSC-1 building, the conduit table and the target security level for each zone.
11. Hardening. The hardening checklist for servers, workstations, controllers, switches and firewalls.
12. Accounts, patching, backups and remote access. The account register, the patch process, the backup and restore test and the remote access path.
13. Protocol security. BACnet Secure Connect (BACnet/SC), Modbus, Simple Network Management Protocol version 3 (SNMPv3) and the risks of each protocol.
14. Cybersecurity acceptance. The tests, the records and the key performance indicators (KPIs) that close the scope.

Cybersecurity documents used: IEC 62443-2-1:2024 (security programme requirements for asset owners), IEC 62443-3-2:2020 (security risk assessment for system design), IEC 62443-3-3:2013 (system security requirements and security levels) and IEC 62443-4-2:2019 (component requirements). Also NIST SP 800-82 Rev. 3 (Guide to Operational Technology Security, September 2023) and the Cybersecurity and Infrastructure Security Agency (CISA) industrial control systems (ICS) advisories. Other documents used: ANSI/ASHRAE 135 (BACnet, Annex AB for BACnet/SC), ISO 14224:2016 (collection and exchange of reliability and maintenance data), ANSI/TIA-942-C (May 2024), NFPA 101 and NFPA 80 (life safety and fire doors), and the DCIM vendor help pages of Schneider Electric EcoStruxure IT.

27.1DCIM: purpose, functions and data sources

27.1.1What DCIM is

A DCIM system is a software platform that holds an accurate model of the physical data centre. The model holds every room, every cabinet, every device in every cabinet, every power connection from the utility to the rack power distribution unit (rPDU), and every sensor. It reads live values from the power and cooling equipment and compares them with the capacity of each part of the model. Before any installation, the operations team uses DCIM to find a position with free space, power and cooling.

The BMS holds the computer room air handler (CRAH) and coolant distribution unit (CDU) data, and the EPMS holds the switchboard and uninterruptible power supply (UPS) data. DCIM joins them with the cabinet, rPDU outlet and reserved-power data that neither system holds.

27.1.2DCIM functions

27.1.3Data sources and protocols

DCIM reads data from devices directly or from the BMS and EPMS servers. The integration method is fixed in the interface control document (ICD) for the DCIM interface (chapter 25).

The Schneider EcoStruxure IT Data Center Expert (DCE) help pages describe discovery processes for SNMPv1, SNMPv3, NetBotz appliances and Modbus TCP devices. A Modbus TCP discovery cannot be scheduled, and every third-party device needs a device definition file (DDF) before its sensors and alarms show correctly. For slow SNMP devices the vendor advice is to raise the timeout to 10 s and the retries to 5. The DCE discovery help lists no BACnet discovery process, and Schneider frequently asked questions (FAQ) page FA383264 states that BACnet is not supported (the FAQ names no version). The supported-device list in the release notes of the installed DCE version is the project record for this point. On MSC-1, BMS data reaches DCE through the BMS server API or a gateway, never by direct BACnet reads.

Other DCIM products in use on hyperscale and colocation sites include Nlyte, Sunbird dcTrack and Power IQ, and the Vertiv Environet and Trellis family. Confirm the features of each product against the vendor documentation for the release bought on the project.

27.1.4Where DCIM sits in the commissioning programme

27.2DCIM data model

27.2.1Objects and relations

Figure F27-2 shows the DCIM data model. Each object has a unique identifier, a parent, and a set of attributes. The power chain is a set of "feeds" relations from an upstream object to a downstream object.

27.2.2Capacity fields

Each capacity object carries four values. DCIM compares them and reports stranded capacity, which is capacity that exists but cannot be used because another resource is full.

Worked example: Capacity of row B2-DH3-R05. The row has 20 cabinets at the 120 kW rack design load of the MSC-1 worked example, so the row design is 2,400 kW. Customer orders reserve 2,180 kW. The 30-day measured peak is 1,712 kW, which is 78.5 % of the reserved value. The available capacity is 2,400 − 2,180 = 220 kW. Three cabinets have 16 U empty each but only 4 kW unreserved power each: their space is stranded. DCIM reports 48 U of stranded space and 0 kW of stranded power for the row. The capacity planner uses this report to place the next devices of up to 4 kW per cabinet in these three positions. The planner can also release reserved power from other cabinets of the row.

27.2.3Naming convention rules

1. One name per object. The DCIM name equals the tag on the as-built drawing, the BMS point name prefix and the CMMS asset identifier. A cabinet named B2-DH3-R05-C12 in DCIM is B2-DH3-R05-C12 on the floor label.
2. Fixed segment order. Building, room, row, cabinet, device. The segments are separated by hyphens and never by spaces.
3. Fixed length segments. Row and cabinet numbers use two digits (R05, C12) so that lists sort correctly.
4. No reuse after decommission. A removed cabinet keeps its identifier in the history and the identifier is not given to a new cabinet.
5. Power side letters. A and B feeds use the letters A and B in every system. A cabinet fed from UPS-A1 and UPS-B1 has rPDUs PDU-A and PDU-B.
6. Approval. The naming convention is a controlled document. The commissioning manager checks it against the BMS points list naming (chapter 21) before the DCIM integrator loads any data.

27.2.4Common errors in the DCIM data model

1. Power chain drawn from design drawings. The integrator loads the power chain from the issued-for-construction drawings. Tap-off positions change during installation, so the model is wrong. Load from the as-built panel schedules and verify by the A and B feed test in 27.3.
2. rPDU outlets not mapped to devices. The rPDU reads outlet current, but DCIM cannot show device power. Map each outlet to a device during the cabinet installation and verify by switching one outlet off in the test in 27.3.
3. Sensor positions unknown. A temperature sensor reads 27 °C but no one knows whether it is at the top or the bottom of the cabinet. The sensor object carries a position attribute and the label on the sensor shows the same position.
4. Duplicate assets. The same device is loaded twice, once by the asset scanner and once from the purchase list. Run the duplicate serial number report before L4.

27.3DCIM commissioning procedure

27.3.1Prerequisites

1. Network ready. The DCIM virtual local area network (VLAN), the firewall rules from the conduit table (27.10) and the SNMPv3 credentials are in place. The network contractor has issued the switch configuration backup.
2. Data loaded. The room, row, cabinet and power chain objects are loaded from the as-built drawings. The DCIM integrator issues the load report with object counts.
3. Device templates. Each device type has a tested template or DDF. The template test sheet for each type is signed at L3.
4. Upstream systems. The BMS and the EPMS have passed their own L4 point-to-point tests for the points that DCIM reads (chapters 22 and 24).
5. Test instruments. A calibrated clamp meter (accuracy ±2 % of reading or better) and a calibrated reference thermometer (±0.3 °C) are available for the field comparison.

27.3.2Point-to-point verification steps

Purpose: Prove that each value and each alarm shown in DCIM comes from the correct device and has the correct value, unit and name.

Owner: The DCIM integrator tests the points. The CxA witnesses a sample and signs.

Steps:

1. Select the sample. The CxA selects the points to witness. On MSC-1 the rule is 100 % of alarm points and 100 % of UPS and PDU feed points. For rPDU outlet points the sample is 10 %, with at least one outlet per cabinet. Time limit: the sample list is issued 2 working days before the test.
2. Compare the identity. The tester reads the device serial number and IP address in DCIM and on the device display. They must match. A mismatch is a category B issue.
3. Compare the value. For a power point, the tester measures the current with the clamp meter at the same time as DCIM shows the value. The acceptance value on MSC-1 is within ±3 % of the clamp reading or ±0.2 A, whichever is larger (project value; the rPDU accuracy class on its data sheet governs).
4. Compare the temperature. The tester places the reference thermometer next to the rack sensor for 5 minutes. The acceptance value is ±1.0 °C (project value).
5. Test the A and B feed. The electrician opens the breaker of PDU-A in one cabinet with the customer's written permission or before IT load is installed. DCIM must show PDU-A at 0 A and PDU-B carrying the full cabinet load within one poll interval. This proves the power chain mapping.
6. Test each alarm. The tester creates the alarm at the source (for example, a high temperature limit lowered on the sensor, or a test alarm from the UPS card). DCIM must show the alarm with the correct name and severity within 2 poll intervals.
7. Test the loss of communication. The tester unplugs the network cable of one rPDU. DCIM must raise a communication loss alarm within the configured time (for example 180 s).
8. Record the results. Each point gets one line in the DCIM point-to-point log with pass or fail.
9. Raise issues. Each failed point is raised in the issue log within 1 working day with the category.
10. Retest. Failed points are retested after the fix and the retest result is added to the same log line.

Records: DCIM point-to-point log DCIM-P2P-B2-DH3, issue log entries, clamp meter calibration certificate.

27.3.3DCIM point-to-point log fields

Worked example: Alarm latency test in hall B2-DH3. The rPDU polling interval is 60 s and DCE is registered as the SNMP notification receiver of the APC devices (priority scanning). The tester lowers the inlet temperature high limit of sensor B2-DH3-R05-C12-TS-TOP from 32 °C to 20 °C at 10:15:00. DCIM shows the alarm at 10:15:09, which is 9 s, well inside the 2-poll limit of 120 s. For a third-party sensor without priority scanning, the alarm appears at 10:16:02, which is 62 s and still inside the limit. Both lines pass. The log records both times and the configured poll interval, so that the operations team can compare later alarms against the same values.

27.4CMMS asset register and asset hierarchy

27.4.1What a CMMS is

A CMMS is the software that the operations and maintenance team uses to plan and record maintenance. It holds the asset register (one record for each maintainable asset), the PM schedules (what task, at what interval, which skill), the work orders, the spare parts and the maintenance history. Common products are IBM Maximo, SAP Plant Maintenance, Infor EAM, ServiceNow and smaller cloud products. The commissioning team supplies the asset data and the first PM schedules; the operations team runs the CMMS. If the data is incomplete at handover, the first PM tasks are not generated and warranty-required maintenance is missed.

27.4.2The ISO 14224 hierarchy

ISO 14224 defines a taxonomy with nine levels. Levels 1 to 5 describe the use and location. Levels 6 to 9 describe the equipment subdivision. The equipment unit at level 6 is the reporting level for failure data. Figure F27-6 shows the nine levels for UPS B2-UPS-A1 and marks the level at which each item is held in the CMMS.

On most projects the CMMS holds records down to level 6 for every asset. Assets with separate maintenance tasks (battery strings, generator engines and alternators, chiller compressors) go down to level 7 or 8. Level 9 items are held as spare parts linked to the asset. The owner's CMMS data standard sets the final depth for each equipment class.

27.4.3Asset register fields

27.4.4Asset data rules

1. One record per maintainable asset. If the maintenance team does a separate task on an item, the item has its own record. A battery string with its own quarterly impedance test is its own record under the UPS.
2. Serial number from the nameplate. The serial number is read from the nameplate on site and photographed. A serial number copied from the delivery note can be wrong because the delivery note lists the shipping crate.
3. Same ID in all systems. The CMMS asset ID equals the DCIM object name, the BMS or EPMS device name and the label on the equipment.
4. Criticality by consequence. Criticality A is an asset whose failure can interrupt IT load or life safety (UPS, switchboards, generators, CDU, fire panels). Criticality B is an asset whose failure reduces redundancy. Criticality C is the rest.
5. No placeholder values. "TBC" (to be confirmed), "N/A" (not applicable) and blank are not accepted for mandatory fields. A missing value is raised as a documentation issue against the contractor.

27.4.5Asset counts for one MSC-1 building

Worked example: Asset count for building B2. Building B2 has 3 data halls of 12 MW IT each. Chapter 23 counts 414 EPMS Ethernet devices for the building. The CMMS register for the same building counts the following groups at level 6. The power groups are 17 generators (with 17 engine and 17 alternator subunits at level 7) and 24 UPS systems of 2.5 MW (8 per hall) with 120 modules and 48 battery strings. The cooling groups are 48 CDUs (16 per hall) and 39 CRAH units for the 3 × 2.4 MW of air cooling (13 per hall, as in chapter 21). The other groups are 96 low-voltage switchboard sections, 144 busway runs, 600 rPDUs (2 for each of the 300 cabinets) and about 1,900 fire, valve, damper and sensor items. The level 6 total is 17 + 24 + 48 + 39 + 96 + 144 + 600 + 1,900 = 2,868 records. The level 7 total is 17 + 17 + 120 + 48 = 202 records. At a data collection rate of 120 records per person per day, the 3,070 records take 26 person-days to collect and verify. The contractor starts collection at Level 2 (L2) and finishes it before the L4 tests of each system. The commissioning manager puts this collection as a line in the look-ahead schedule.

27.5Asset data handover flow and PM schedules

27.5.1The handover flow

Figure F27-3 shows the flow of asset data from design to the live CMMS. The data starts in the equipment schedules of the design and the contractor completes it during installation. The commissioning team checks it against the field, and the owner's CMMS administrator loads it into the CMMS.

27.5.2Asset data check procedure

Purpose: Prove that the asset data matches the installed equipment before it is loaded into the CMMS.

Owner: The CxA checks the data. The contractor's document controller corrects the template.

Steps:

1. Run the completeness check. The CxA runs a script or spreadsheet filter on the template for blank, "TBC" and "N/A" values in mandatory fields. The acceptance value is 0 blank mandatory fields for criticality A assets and less than 1 % for B and C assets at the first check.
2. Run the uniqueness check. The CxA sorts by asset ID and by serial number and lists duplicates. The acceptance value is 0 duplicates.
3. Run the cross-system check. The CxA compares the asset IDs with the BMS points list, the EPMS device list and the DCIM object list. Each criticality A asset that has a controller or meter must appear in the matching system with the same name.
4. Select the field sample. The CxA selects 100 % of criticality A assets and 10 % of the others (minimum 20 per system).
5. Check on site. For each sampled asset, the CxA compares the label, nameplate serial number, model and location with the template. Each mismatch is recorded.
6. Judge the result. If more than 2 % of the sample has a mismatch, the contractor rechecks the whole system and the CxA repeats the sample.
7. Issue the record. The CxA issues the asset data check record with the counts and the mismatch list within 3 working days of the site check.

Records: Asset data check record ADC-B2-ELE-01, the corrected template revision, the mismatch list in the issue log.

27.5.3PM schedule fields

27.5.4PM schedule rules

1. Source every task. Each PM task names its source: the OEM maintenance table in the O&M manual, a warranty condition, a statutory requirement or the owner's standard. An example of a statutory requirement is the periodic inspection of lifting equipment and pressure vessels under Indonesian regulations.
2. Warranty tasks first. Tasks that the OEM names as conditions of warranty are flagged. A missed warranty task can void the warranty, so these tasks are loaded and tested before any other task.
3. Start dates from commissioning. The first due date is calculated from the L4 pass date or the energisation date, whichever the OEM uses. A generator with a monthly run test is due one month after its L4 load test.
4. Run-hour triggers. Generators, pumps and fans with run-hour triggers have their run-hour meters read at handover and the reading entered in the CMMS.
5. Test the generation. The CMMS administrator runs the work order generation for the next 90 days and the DCOps lead checks that the expected work orders appear.

Worked example: PM generation test for building B2. The PM schedule has 214 PM templates across the 2,868 level 6 assets. The CMMS generates 3,960 work orders for the first 90 days. The DCOps lead checks three classes. For the 17 generators with a monthly no-load run, 17 × 3 = 51 work orders are expected and 51 appear. For the 48 battery strings with a quarterly impedance test, 48 are expected and 48 appear. For the 39 CRAH units with a 3-month filter change, 39 are expected but only 26 appear: the 13 CRAHs of hall B2-DH3 have no PM link. The DH3 CRAH records were loaded after the PM link was made. The issue is raised as category B, the link is added, and the test is repeated with 39 work orders.

27.6Access control system

27.6.1What the access control system does

The electronic access control system (ACS) decides which person may open which door at which time, and it records every event. A person presents a credential (card, personal identification number (PIN) or biometric) at a reader. The door controller checks the credential against its local database and, if allowed, releases the lock for a set time. The door contact reports whether the door is open, and the request-to-exit (REX) device allows exit from inside. The ACS server holds the cardholder database, the access levels and the event log. It sends the database to the door controllers, so that each controller can decide alone when the network is down.

27.6.2Security layers on a data-centre campus

Hyperscale programmes divide the campus into layers. Each inner layer needs a stronger credential check than the outer one. ANSI/TIA-942-C (May 2024) includes physical security requirements tied to its rating levels (confirm the per-rating requirements in the security tables of ANSI/TIA-942-C).

27.6.3Fail-safe and fail-secure locks

A fail-safe lock unlocks when its power is removed. A fail-secure lock stays locked when its power is removed, and a person can still exit from inside with the mechanical handle. The choice depends on the door function and the fire code.

Allegion states that electromagnetic locks are only available fail-safe and that fire-rated doors need fail-secure strikes. Under NFPA 101 a door on an egress path with a fail-safe lock must unlock on actuation of the sprinkler or fire alarm system and on loss of power to the lock. A delayed-egress lock releases 15 s after a person pushes the exit device, or 30 s where the authority having jurisdiction approves. The source is NFPA 101, 7.2.1.6.1, as summarised by idighardware.com and state fire marshal guides. The door carries a sign that starts "PUSH UNTIL ALARM SOUNDS". The NFPA 101 edition adopted by the local authority and the Indonesian fire regulation that the authority enforces govern on the project.

27.6.4Interlocked entry (mantrap)

An interlocked entry has two doors. The inner door cannot open while the outer door is open, and the reverse. Some designs add a weight sensor or a people-counting sensor so that only one person passes per credential.

1. Interlock logic. Door 1 open or not locked blocks the release of door 2. Door 2 open or not locked blocks the release of door 1.
2. Fire alarm mode. On a fire alarm from the zone, both doors release so that people inside can leave. The interlock is suspended.
3. Power loss mode. The design states whether the mantrap doors fail-safe or fail-secure. If fail-secure, a mechanical free exit from inside must exist on both doors.
4. Emergency release. A break-glass unit inside the mantrap cuts lock power on both doors.
5. Alarm on fault. If both doors show open at the same time, the ACS raises an interlock fault alarm to the security control room.

27.6.5Access control data fields

27.7CCTV and intrusion detection

27.7.1CCTV system parts

A CCTV system has cameras, a network that carries the video, recorders or a video management system (VMS) with storage, and operator workstations. On a campus the cameras are IP cameras powered by Power over Ethernet (PoE) from access switches in the security network zone.

27.7.2Storage calculation

Worked example: CCTV storage for building B2. The building has 420 cameras. Each camera streams at an average of 4 Mbit/s at the set resolution and frame rate (value from the camera bit-rate calculator and the VMS vendor data). The retention is 90 days of continuous recording.

1. Bit rate. 420 × 4 Mbit/s = 1,680 Mbit/s = 210 MB/s.
2. Per day. 210 MB/s × 86,400 s = 18,144,000 MB = 18.1 TB per day.
3. For 90 days. 18.1 × 90 = 1,633 TB, about 1.63 PB of usable storage.
4. With redundancy. With redundant array of independent disks (RAID) 6 overhead of about 20 % the raw storage is 1.63 / 0.8 = 2.04 PB.

The test of this value is a playback of the oldest recording on day 91 of operation. Before handover, the test is a check that the storage pool shows the calculated retention estimate in the VMS.

27.7.3Intrusion detection

Intrusion detection covers the perimeter fence (fence-mounted sensors, buried cable or microwave barriers), doors in areas without card readers, and roof hatches. Test each zone by a walk or a physical disturbance. The alarm must appear at the security control room with the correct zone name and the linked camera view.

27.8Physical security integration tests

27.8.1Interfaces of the access control system

Figure F27-5 shows the access control interfaces that are tested on a data-centre project.

27.8.2Door test procedure

Purpose: Prove each door works as designed in normal, alarm, fire and power-loss modes.

Owner: The security contractor tests each door. The CxA witnesses. The fire alarm contractor is present for the fire release step. The owner's security manager attends for the critical rooms.

Steps:

1. Valid card. Present a card with the correct access level. The door releases for the set unlock time (for example 5 s), the event shows "access granted" with the card number and door ID at the ACS workstation.
2. Invalid card. Present a card without the access level. The door stays locked. The event shows "access denied".
3. Expired card. Present a card past its end date. The door stays locked.
4. Door forced. Open the door with the mechanical key without a card. The ACS raises "door forced" within 2 s and the linked camera view opens on the operator screen.
5. Door held open. Open with a valid card and hold the door. After the held-open time (for example 30 s) the ACS raises "door held" and the local sounder operates.
6. Exit. Exit from inside with the REX or handle. No alarm is raised.
7. Interlock. On a mantrap, open door 1 and try door 2 with a valid card. Door 2 stays locked. Close door 1 and repeat. Door 2 opens.
8. Network loss. Disconnect the controller network cable. Valid cards still open the door from the local database. Events are stored and appear at the server after the network is restored, with the original time stamps.
9. Fire release. The fire alarm contractor activates a detector in the zone. All egress doors in the zone release within 1 s of the fire relay change (project value), the mantrap interlock is suspended, and the ACS shows fire mode. Fire-rated doors with fail-secure strikes stay latched but open from inside by the handle.
10. Fire reset. After the fire panel resets, the doors lock again and the ACS returns to normal mode.
11. Power loss. Switch off the mains supply to the lock power supply. A fail-safe lock releases. A fail-secure lock stays locked. The battery supports the controller for the design time (for example 4 h, tested by a discharge test on a sample).
12. Emergency release. Operate the break-glass unit. The fail-safe lock releases and the ACS records the event.
13. Record. Each step gets pass or fail on the door test sheet with the time stamps from the ACS event log.

Records: Door test sheet per door (ACS-DT-B2-xxx), ACS event log export for the test day, fire alarm event log for the release step.

27.8.3Common errors found in door tests

1. Fire relay wired fail-unsafe. The fire panel relay closes on alarm to release the door. A cut wire then never releases the door. The relay must open on alarm, so that a broken wire releases the door. The CxA checks the relay wiring drawing before the test.
2. Lock power from a non-released supply. The fire relay cuts the controller output, but the maglock takes its power from a separate supply that the fire relay does not cut. The test in step 9 finds this.
3. REX shunts the alarm but does not release a maglock. A maglock door needs the REX to cut the lock power. Where the code requires it, the door also needs a mechanical free exit device.
4. Time not synchronised. ACS and VMS times differ by 3 minutes, so the video of a forced door does not match the event time. Check NTP on every server before the test.
5. Wrong access levels. Contractors' temporary cards still have data hall access after their work ends. The security manager reviews the access level report weekly.

Worked example: Fire release test in hall B2-DH3. The hall has 14 doors in fire zone B2-FZ-DH3: 2 mantrap doors (fail-safe maglocks with free exit), 8 corridor doors (fail-secure strikes on fire-rated doors) and 4 emergency exits (fail-safe with delayed egress). The fire contractor activates detector B2-DH3-SD-112 at 14:02:10. The fire panel relay opens at 14:02:11. The ACS event log shows the release of all 6 fail-safe doors between 14:02:11.2 and 14:02:11.6, which is inside the 1 s limit. The 8 fail-secure doors stay latched and each opens from inside with the handle, which the tester checks by walking through each one. The tester also pushes the exit device of one delayed-egress door: it opens at once, because the fire alarm cancels the 15 s delay. The result is pass for 14 of 14 doors. The test sheet lists each door with its time.

27.9OT cybersecurity: IEC 62443 and NIST SP 800-82

27.9.1Why OT cybersecurity is part of commissioning

The BMS, the EPMS, the CDU programmable logic controllers (PLCs), the generator controllers and the UPS network cards are computers on a network. A person who reaches them can open a breaker, stop a pump or change a set point. Find default passwords, open ports and unpatched servers before handover.

Public advisories show that data-centre OT products have real vulnerabilities. CISA has published several advisories for Schneider Electric EcoStruxure Power Monitoring Expert (PME). Advisory ICSA-23-290-01 covers a deserialization vulnerability listed as Common Vulnerabilities and Exposures (CVE) entry CVE-2023-5391. Its Common Vulnerability Scoring System (CVSS) v3 base score is 9.8, and a hotfix fixes it. Advisory ICSA-25-037-01 covers CVE-2024-9005 and notes that PME 2021 and earlier versions have reached end of life. Advisory ICSA-25-224-03 covers a directory traversal and a pre-authentication server-side request forgery in PME. Researchers have also found BACnet devices that were reachable from the internet on User Datagram Protocol (UDP) port 47808. Before acceptance, check the PME version and hotfix level and the BMS controller firmware against the current advisories.

27.9.2The IEC 62443 series

IEC 62443-2-1 edition 2.0 was published on 7 August 2024. It sorts the requirements into security programme elements, removes overlap with an information security management system, and defines a maturity model. It allows compensating measures for legacy systems that cannot meet a requirement, for example where software is no longer supported and cannot be patched.

27.9.3The seven foundational requirements

The security level of a zone is a vector of seven values, one for each FR. A zone can have SL2 for FR4 and SL3 for FR5, for example. IEC 62443-3-3:2013 has 51 system requirements (SR), SR 1.1 to SR 7.8 in clauses 5 to 11, with requirement enhancements for the higher levels.

27.9.4Security levels

The standard uses three forms of the level. The target level (SL-T) is chosen in the risk assessment. The capability level (SL-C) is what a product or system can give when configured correctly. The achieved level (SL-A) is measured on the installed system. Commissioning proves the achieved level against the target. The ISA-62443-3-3 preview uses the same three terms. It states that the standard covers the capability level SL-C, and that SL-T and SL-A are out of its scope.

27.9.5NIST SP 800-82 Rev. 3

NIST SP 800-82 Rev. 3, "Guide to Operational Technology (OT) Security", was published in September 2023 and replaced Rev. 2 of 2015. It describes OT system types and topologies, typical threats and vulnerabilities, and recommended safeguards. It contains an OT overlay of the NIST SP 800-53 Rev. 5 controls, with tailored baselines for low, moderate and high impact OT systems. On a data-centre project, NIST SP 800-82 guides the security programme and the network architecture. IEC 62443-3-3 is the requirement set in the specification, because it gives testable requirements per security level.

27.10Zones, conduits and security levels

27.10.1Definitions

A zone is a group of assets that share the same security requirements, for example all EPMS meters and relays of one building. A conduit is the set of communication paths between two zones, together with the security controls on those paths (firewalls, encrypted tunnels, data diodes). IEC 62443-3-2 requires the asset owner to divide the system under consideration into zones and conduits. The owner then assesses the risk of each and sets a target security level for each.

27.10.2Risk assessment steps of IEC 62443-3-2

The steps below follow the seven zone and conduit requirements (ZCR 1 to ZCR 7) of IEC 62443-3-2:2020, clauses 4.2 to 4.8, as listed in the ISA-62443-3-2 table of contents.

1. Identify the system under consideration (ZCR 1). List the systems in scope (BMS, EPMS, CDU PLCs, generator controls, fire alarm interfaces, access control, CCTV, DCIM) and their boundaries. Owner: OT security lead. Record: system under consideration document.
2. Initial risk assessment (ZCR 2). Assess the worst consequence of a compromise of each system, without counting controls. A compromised EPMS that can open MV breakers has a consequence of loss of IT load in a hall.
3. Partition into zones and conduits (ZCR 3). Group assets by consequence and by function. Draw the zone and conduit diagram (Figure F27-1).
4. Compare with tolerable risk (ZCR 4). If the initial risk of a zone is above the owner's tolerable risk, continue with a detailed assessment.
5. Detailed risk assessment (ZCR 5). For each zone, list threats, vulnerabilities and existing controls, and decide the target security level per FR (ZCR 5.6, determine SL-T).
6. Document the requirements (ZCR 6). Write the cybersecurity requirements specification: zone list, conduit list, SL-T per zone, assumptions and constraints.
7. Asset owner approval (ZCR 7). The owner signs the cybersecurity requirements specification before the integrators finalise their designs.

27.10.3Zone model of an MSC-1 building

The SL-T values above are an example for a hyperscale building. Each project sets its own values in the approved risk assessment.

27.10.4Conduit table

27.10.5Conduit verification test

Purpose: Prove that the firewalls allow only the flows in the conduit table.

Owner: The network contractor runs the test. The OT security lead or an independent tester witnesses.

Steps:

1. Export the rule base. The network contractor exports the firewall rule base. The OT security lead compares each rule with the conduit table. Each rule without a conduit line is an issue. Rules with "any" in source, destination or service are rejected.
2. Test allowed flows. From a test laptop placed in the source zone, the tester opens each allowed flow, for example a Modbus TCP read from the PME server address to a meter. Each allowed flow works.
3. Test denied flows. From the same laptop, the tester tries flows that are not in the table: Z1 to Z4 directly, Z7 to Z4, Z5 to Z4 Modbus write. Each denied flow fails and appears in the firewall log within 60 s.
4. Scan. The tester runs a port scan of each zone from each other zone with a tool and settings approved in the test method statement. A scan of field devices must use a low rate (for example one probe per second) because some controllers stop responding under fast scans. The open ports must match the conduit table.
5. Record. The results go to the conduit test record with each flow, expected result, actual result and the log reference.

Records: Conduit test record OT-CT-B2-01, firewall rule base export with checksum, scan output files.

Worked example: Conduit C5 read-only test. The fire alarm gateway in Z6 is configured to allow reads only. The tester sends a Modbus function code 03 (read holding registers) from the BMS server: the gateway returns the values. The tester sends function code 06 (write single register) to the same register: the gateway returns exception 01 (illegal function). The tester sends a BACnet WriteProperty to the gateway's BACnet object: the gateway rejects it with an error. The firewall log shows 3 allowed flows and 0 denied, because the rejection was made by the gateway. The OT security lead accepts the result. As a second layer, the lead adds a firewall rule that blocks Modbus function codes 05, 06, 15 and 16 toward Z6, using the deep packet inspection function of the firewall. The data sheet of the installed firewall model states whether its Modbus inspection filters by function code; the OT security lead files that page with the rule base export.

27.11Hardening checklist

27.11.1What hardening means

Hardening is the removal of every function, account, service and port that the system does not need, and the setting of the security options that the product supports. Figure F27-4 shows the hardening checklist as a matrix of device types and controls. The integrator does the hardening. The commissioning team checks it with a sample and records the result.

27.11.2Hardening items per device type

27.11.3Hardening check procedure

1. Receive the hardening record. The integrator submits a hardening record per device with each item answered "done", "not supported" or "not applicable", with a reason for each "not supported".
2. Check the "not supported" items. The OT security lead checks each "not supported" item against the product manual. If the product supports it, the item goes back to the integrator.
3. Sample the devices. The CxA and OT security lead select 100 % of servers, firewalls and core switches. They select 10 % of each type of field device (minimum 3 per type).
4. Test default passwords. The tester tries the vendor default credentials from the product manual on each sampled device. Any successful login with a default credential is a category A issue.
5. Test closed services. The tester checks with a port scan that Telnet (23), FTP (21) and HTTP (80) are closed where the product supports their removal.
6. Check versions. The tester reads the firmware or software version on each sampled device and compares it with the approved version list.
7. Check logs. The tester logs in with a wrong password three times on a sampled device and checks that the events appear on the syslog server within 60 s.
8. Record. Each sampled device gets one line in the hardening check record.

27.11.4Hardening check record fields

27.12Accounts and privileged access

27.12.1Account register

Every account on every OT system is listed in an account register before handover. The register is a controlled document held by the owner's OT security lead.

27.12.2Account rules

1. Named accounts. Each person has a named account. Shared accounts such as "admin" or "operator" are disabled. Where a product supports only one administrator account, its password is held in a password vault and each use is logged.
2. Least privilege. Operators can acknowledge alarms and change set points inside the limits. Engineers can change logic and graphics. Administrators manage accounts. One person holds one role per system unless the owner approves an exception in writing.
3. Contractor accounts removed. At handover all contractor and commissioning accounts are disabled. The OEM support accounts that remain are listed, have an end date and are disabled until a support request opens them.
4. Emergency account. One emergency ("break-glass") account per system is kept in a sealed envelope or a vault. Its use raises an alarm and is reviewed within 1 working day.
5. Password length. Passwords meet the owner's policy; where the product allows, at least 12 characters (project value from the owner's password policy).
6. Review. The account register is reviewed every 3 months. The first review is in the first quarter after handover.

Worked example: Account clean-up before handover of building B2. The account export from the BMS server lists 64 accounts. Of these, 41 belong to the BMS contractor and commissioning staff and 12 to the owner's operations team; 6 are service accounts and 5 are built-in accounts. The OT security lead disables the 41 contractor accounts and keeps 12 named operations accounts with MFA. The lead documents the 6 service accounts with their purpose and disables 4 of the 5 built-in accounts. The fifth is the product's local administrator, which cannot be removed, so its password is changed to a vault-held value of 20 characters. The result is 19 active accounts (12 named, 6 service and the local administrator), each with an owner in the account register.

27.13Patching and vulnerability management

27.13.1Patch process during construction and handover

1. Approved version list. At the start of L3, the OT security lead issues the approved version list: the operating system, software and firmware version for every product. The integrator installs these versions.
2. Advisory review. Every 2 weeks during commissioning, the OT security lead checks the CISA ICS advisories for every product in the list. The lead also checks the vendor security notification pages, for example Schneider Electric security notifications.
3. Assess each advisory. For each advisory that affects an installed version, the lead records the CVE, the CVSS score and whether the vulnerable function is reachable through the conduits. The lead then records the decision: patch now, patch at a planned window, or apply a compensating control.
4. Test before install. A patch is installed first on a test server or one controller, then on the rest. The BMS or EPMS L4 tests for the affected functions are repeated on the first device.
5. Freeze before IST. The approved version list is frozen 10 working days before IST. A patch after the freeze needs the commissioning manager's approval, because it can invalidate IST results.
6. Handover list. At handover, the approved version list is updated with the installed versions and every open advisory with its decision.

27.13.2Vulnerability register fields

27.14Backups and restore tests

27.14.1What is backed up

27.14.2Restore test procedure

1. Choose the item. The CxA chooses one server backup and two controller programs for the restore test.
2. Restore the server. The integrator restores the server backup to a spare virtual machine on an isolated network. The server starts and the application opens.
3. Compare. The tester compares point counts, alarm counts and the last recorded values with the live server. The acceptance value is the same point count and data up to the backup time.
4. Restore a controller. The integrator downloads the backup program to a spare or test controller of the same type. The program version and checksum equal the repository record.
5. Time the restore. The tester records the time from start to working system. The owner uses this time for the recovery time objective in the operations plan.
6. Record. The restore test record lists items, times and results.

Worked example: BMS server restore test for building B2. The backup of 2026-12-08 02:00 is restored to a test virtual machine. Restore of the image takes 46 minutes and the database restore takes 18 minutes. The restored server shows 38,412 points, equal to the live server, and alarm history up to 01:59. The restore time of 64 minutes is recorded against the owner's recovery time objective of 4 hours (project value). The result is pass.

27.15Remote access

Remote access is the conduit with the highest risk, because it starts outside the OT zones. Figure F27-7 shows the one permitted path from a vendor laptop through the jump host to an OT server. It also shows the path that is not allowed and the three login cases of the commissioning test.

1. One path only. Remote access to OT goes through the jump host in the OT DMZ. No modem, cellular router or vendor cloud connection is allowed in any OT zone unless the owner approves it in the risk assessment and it is listed as a conduit.
2. Multi-factor authentication. Every remote session needs MFA on the jump host.
3. Session approval. A vendor session is opened by the operations team for a work order with a start and end time. The account is disabled outside the window.
4. Recording. Remote sessions are recorded where the jump host supports it, and the recording is kept for the owner's retention period.
5. No file transfer by default. File transfer to OT goes through the patch server with a malware scan.
6. Test. The tester tries a remote login with a disabled vendor account (must fail) and with an enabled account without MFA (must fail). The tester then logs in with an enabled account with MFA inside the window (must work and be logged).
7. Search for unlisted paths. The tester checks each OT switch for unknown media access control (MAC) addresses. The tester also walks each electrical and mechanical room to look for cellular routers or modems in vendor panels. Vendor panels of chillers and generators sometimes arrive with a cellular modem for the vendor's remote service.

27.16Protocol security: BACnet, Modbus and SNMP

27.16.1Protocol risks and controls

27.16.2BACnet Secure Connect

BACnet/SC is defined in Annex AB of ANSI/ASHRAE 135. It carries BACnet messages over WebSocket connections secured with TLS 1.3, and each device holds an operational X.509 certificate and the issuer certificates that it trusts. Devices connect to a hub (primary and failover hub), so a BACnet/SC network does not need broadcasts or BBMDs. The standard does not fix a port; 443 is common because firewalls allow it. One vendor knowledge base reports that a BACnet/SC hub did not start on port 443 on one controller model, because the controller web server already used the port. The fix was to move HTTPS to port 8443.

Commissioning checks for BACnet/SC:

1. Certificate register. Each device certificate is listed with its expiry date. The BMS raises an alarm 60 days before expiry (project value).
2. Hub failover. The tester stops the primary hub. Devices reconnect to the failover hub and the BMS shows all points within the time set in the specification.
3. Rejected device. The tester connects a device with a certificate from an untrusted issuer. The hub rejects the connection and logs it.

27.17Cybersecurity acceptance tests and records

27.17.1Acceptance test list

27.17.2Blocking rules

1. Before energisation of the EPMS network. The conduit C3 rules and the Z4 hardening of protection relays are complete. A relay with a default password is never connected to a network that reaches a server.
2. Before IST. The conduit test, the hardening check and the version freeze are complete. Any category A cybersecurity issue blocks IST.
3. Before handover. All acceptance tests in 27.17.1 have passed, and the account register shows 0 active contractor accounts.

27.18KPIs for DCIM, CMMS, security and OT cybersecurity

27.19Checklist for site use

1. DCIM naming. The DCIM naming convention equals the drawing tags, the BMS names and the CMMS IDs.
2. DCIM power chain. The power chain is loaded from as-built panel schedules and proved by the A and B feed test.
3. DCIM points. The point-to-point log covers 100 % of alarms and feeds and the sample of rPDU outlets; values inside ±3 % or ±0.2 A.
4. DCIM alarm time. Alarms appear within 2 poll intervals and communication loss alarms within the set time.
5. Asset template. The asset data template follows the owner's CMMS data standard and the ISO 14224 levels.
6. Asset data check. Completeness, uniqueness, cross-system and field sample checks are recorded; mismatch below 2 %.
7. PM schedules. Each PM task has a source; warranty tasks flagged; the 90-day work order generation is tested.
8. Run hours. Run-hour readings at handover are entered for generators, pumps and fans.
9. Door tests. Each door passes the 13 steps in 27.8.2, including the fire release and the power loss steps.
10. Fire relay wiring. The fire release relay opens on alarm, so a broken wire releases the doors.
11. Mantraps. Interlock, fire mode, power loss mode and emergency release are tested.
12. CCTV. Coverage, resolution, frame rate, time synchronisation and the retention estimate are recorded.
13. Zones and conduits. The cybersecurity requirements specification is approved; the zone diagram and conduit table are current.
14. Conduit test. Allowed flows work; denied flows are blocked and logged; no "any" rules.
15. Hardening. No device accepts a default credential; versions equal the approved list.
16. Accounts. Contractor accounts are disabled; every active account has an owner.
17. Advisories. The vulnerability register is current at handover with a decision for each advisory.
18. Backups. The restore test is done and the time is recorded.
19. Remote access. One path through the jump host with MFA; no modem or cellular router in OT panels.
20. BACnet/SC. Certificates are registered with expiry dates; hub failover is tested.

27.20Sources

1. IEC, "IEC 62443 Background", Systems Committee Smart Energy, accessed 31 October 2026. https://syc-se.iec.ch/deliveries/cybersecurity-guidelines/security-standards-and-best-practices/iec-62443/
2. IEC 62443-3-3:2013, Industrial communication networks, Network and system security, Part 3-3: System security requirements and security levels, IEC. https://webstore.iec.ch/en/publication/7033
3. IEC 62443-3-2:2020, Security for industrial automation and control systems, Part 3-2: Security risk assessment for system design, IEC. https://webstore.iec.ch/en/publication/30727
4. IEC 62443-2-1:2024 (edition 2.0), Security programme requirements for IACS asset owners, IEC. https://webstore.iec.ch/en/publication/62883
5. ISA, ISA-62443-3-2 table of contents, accessed 31 October 2026. https://www.isa.org/getmedia/4cfc5f8a-1f19-4e97-9382-c7d46e3b04a5/isa-62443-3-2-toc.pdf
6. NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023. https://csrc.nist.gov/pubs/sp/800/82/r3/final
7. CISA, ICS Advisory ICSA-23-290-01, Schneider Electric EcoStruxure Power Monitoring Expert, accessed 31 October 2026. https://cisa.gov/news-events/ics-advisories/icsa-23-290-01
8. CISA, ICS Advisory ICSA-25-037-01 (Update B), Schneider Electric EcoStruxure Power Monitoring Expert, accessed 31 October 2026. https://www.cisa.gov/news-events/ics-advisories/icsa-25-037-01
9. CISA, ICS Advisory ICSA-25-224-03, Schneider Electric EcoStruxure Power Monitoring Expert, accessed 31 October 2026. https://www.cisa.gov/news-events/ics-advisories/icsa-25-224-03
10. CISA, ICS Advisory ICSA-25-203-03, Schneider Electric EcoStruxure, accessed 31 October 2026. https://cisa.gov/news-events/ics-advisories/icsa-25-203-03
11. DIVD, "Exposed BACnet Devices", case report 2022-00005, accessed 31 October 2026. https://vintage.divd.nl/reports/2022-00005%20-%20Exposed%20BACnet%20Devices
12. Dragos, "Assessing the BACnet Control System Vulnerability", accessed 31 October 2026. https://www.dragos.com/blog/assessing-the-bacnet-control-system-vulnerability
13. Chipkin, "What BACnet Secure Connect Is", accessed 31 October 2026. https://docs.chipkin.com/protocols/bacnet/secure-connect/
14. ASHRAE, "Protecting Building Automation Systems with BACnet Secure Connect", accessed 31 October 2026. https://www.ashrae.org/news/esociety/protecting-building-automation-systems-with-bacnet-secure-connect
15. Forest Rock, "BACnet Secure Connect (BACnet SC)" knowledge base, accessed 31 October 2026. https://docs.forestrock.co.uk/bacnet-secure-connect-bacnet-sc
16. Schneider Electric EcoStruxure IT, "Device discovery processes", Data Center Expert help, accessed 31 October 2026. https://dcimsupport.ecostruxureit.com/hc/en-us/articles/360038795874-Device-discovery-processes
17. Schneider Electric, FAQ FA383264, third-party devices and DDF files in Data Center Expert, accessed 31 October 2026. https://www.se.com/eg/en/faqs/FA383264/
18. CPCON Group, "ISO 14224 Equipment Taxonomy", accessed 31 October 2026. https://cpcongroup.com/insights/article/iso-14224-equipment-taxonomy/
19. Accendo Reliability, "Setting up an asset hierarchy", accessed 31 October 2026. https://accendoreliability.com/setup-asset-hierarchy/
20. Allegion, "Fail Safe and Fail Secure" article 112140, accessed 31 October 2026. https://www.allegion.ca/content/dam/allegion-us-2/web-documents-2/Article/Allegion_Fail_Safe_Fail_Secure_Article_112140.pdf
21. SecurityInfoWatch, "Know Your Codes: IBC and NFPA access control hardware requirements", accessed 31 October 2026. https://www.securityinfowatch.com/access-identity/access-control/door-hardware/article/10754829/ibc-and-nfpa-access-control-hardware-requirements
22. TIA-942 summary (ANSI/TIA-942-C, May 2024), Wikipedia, accessed 31 October 2026. https://en.wikipedia.org/wiki/TIA-942
23. Uptime Institute, "Uptime Announces Annual Outage Analysis Report 2025", press release, accessed 31 October 2026. https://uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2025

Educational field reference compiled from public standards, guides, manufacturer documents and published incident reports; sources close each chapter. The project specification, the Engineer of Record and the OEM documents govern; check the current edition of every standard before use. Worked examples use an example campus (MSC-1: 4 buildings, 12 halls of 12 MW), not project data. Independent research; not affiliated with any current or former employer. Privacy · Terms.