Security

Physical security

Access control, video and visitor process for the data center and the spaces inside it. Facility owns the rooms and the rating (Building spaces, Ratings). Racks owns cabinet hardware and cage fit-out. Ops owns fire and life safety and the alarm console (Fire and life safety, Monitoring). Control names are from NIST SP 800-53 Rev. 5 (PE family, catalog release 5.2.0). Interface standards are from SIA (OSDP) and ONVIF. No products are ranked. Sources checked 5 Oct 2026.

Who runs it: onsite vs colo

Onsite you run every layer. In colo the provider runs the building, the lobby and the hall, and you remain responsible for who is on your access list and for the controls on your own cage or cabinets. CoreSite puts it as a shared duty: the customer “must grant and enforce strict role-based employee and vendor controls” for access to its equipment (CoreSite). Provider rules differ on whether your own cage readers can act independently of the provider’s access system, so ask before you specify them.

Zones and controls

Build physical security as nested zones, each with stronger entry checks than the one outside it. NIST SP 800-53 PE-3 asks you to enforce authorizations at defined entry and exit points, keep physical access audit logs, escort visitors, secure keys and combinations, and inventory physical access devices. The retention period and the review interval are organization-defined parameters, not fixed values (NIST SP 800-53 Rev. 5). Frameworks that set retention minimums for access logs, visitor logs and video are listed on Governance: Design mapping; take the strictest one in scope. TIA-942 rating levels add physical security criteria at Rated-3 and Rated-4, and the rating itself is on Facility.

The zone-to-control mapping above is editorial practice built on the PE controls; the control text does not prescribe zones.

Access control (PACS)

Reader to controller. Specify OSDP with Secure Channel, not Wiegand. SIA describes OSDP as a more capable replacement for the legacy Wiegand interface; Secure Channel encrypts the reader link with AES-128. The current SIA version is OSDP v2.2.2, the international standard is IEC 60839-11-5:2020, and SIA runs an “OSDP Verified” conformance program, so ask for verified devices rather than “OSDP support” (SIA OSDP).

Authorizations. PE-2 asks for an approved list of people with facility access, issued credentials, periodic review of the list, and removal when access is no longer needed. Drive joiners and leavers from the HR or identity system rather than from a separate PACS spreadsheet, and keep contractor access time-bound.

Fire alarm interlock. Electronically locked doors on egress routes generally have to release or allow free egress on a fire alarm or power loss. The exact rule is set by the life-safety code and the authority having jurisdiction, and the fire system itself is on Ops: Fire and life safety. Agree the door schedule with both.

Network. PACS controllers and servers are OT under NIST SP 800-82r3, so they go in their own zone, not on the user LAN (OT).

Video (VMS and cameras)

Interoperability. Specify ONVIF profile conformance, not “ONVIF support”. ONVIF considers only registered products that conform to a profile to be ONVIF conformant. Profiles S, T and G cover video streaming and recording; A and C cover access control; D and M apply to both. Profile Q was deprecated in April 2022 (ONVIF profiles).

Coverage and retention. Cover every zone entry, the mantrap, the hall aisles and the loading dock. Set retention from policy, compliance and contract requirements before sizing recorder storage; no standard sets a single figure, and the framework minimums that apply to camera and access-control data are on Governance: Design mapping. Recorder storage depends on retention, camera count, resolution, frame rate and codec, so size it from the camera schedule, not a rule of thumb.

Health and time. Monitor camera and recorder health (offline cameras, failed disks, recording gaps), and sync VMS and PACS clocks to the same time source so footage and door events line up in an investigation (Time sync).

Visitor and vendor process

• Pre-register visitors and vendors against a named sponsor and a work order; check identity at the desk
• Escort in the white space unless the person is on the authorized list (PE-3)
• Keep visitor access records, review them on a set schedule, and report anomalies (PE-8)
• Recover visitor badges on exit; disable any that are not returned
• Control shipping and receiving: staging area, inspection, and custody for anything leaving the site, including storage media

Monitoring and review

PE-6 asks you to monitor physical access to detect and respond to incidents, review access logs on a set interval and on defined events, and feed the results into incident response. In practice: alarm on door forced and door held open, send PACS and VMS events to the SIEM (Logging), and display alarms on the ops console (Ops: Monitoring).

Physical security design / build / manage

Design

• Map physical zones (perimeter, lobby, mantrap, white space, cage, support spaces) to access control and camera coverage
• Colo: write down which layers the provider runs and which you run, and put access, escort and shipping rules in the contract (Colo contract)
• Specify OSDP Secure Channel readers and ONVIF profile-conformant cameras
• Set CCTV retention and access-log retention with legal and compliance before sizing storage
• Agree the fire alarm and door-release schedule with Ops and the authority having jurisdiction

Build

• Commission doors and cameras with as-built records: device, location, zone and network address
• Baseline CCTV coverage and retention: walk every camera view and confirm recordings are kept for the agreed period
• Test door-forced and door-held alarms, anti-passback, and fire release with Ops
• Load the access list from the identity or HR system; colo: submit the list and test your cage locks and readers

Manage

• Audit access logs and camera health on a set schedule
• Review the authorized list at a set interval and on every leaver
• Review visitor records and report anomalies
• Colo: reconcile the provider’s access reports with your list, and collect its attestation reports each cycle

Perimeter: NGFW pair, HMF and sizing

The firewall pair between the edge routers and the fabric: placement, HA mode, decryption, sizing, the hybrid mesh firewall category, and DDoS. Edge routers, BGP and carriers are on Network: Edge. Inter-zone traffic leaves its zone VRF at a border or service leaf toward the firewall. Route leaking between zone VRFs on the fabric is allowed only for flows the policy model marks L3/L4-only, and each is recorded in the inter-zone matrix. The steering mechanics are on Network: Service insertion. Market leaders and within-vendor model ladders are in Market leaders: HMF / NGFW. Sources: IETF RFC 9411, CISA. No throughput figures are given here; vendor figures stay in the ladders. Sources checked 5 Oct 2026.

Placement: which boundaries the pair inspects

The usual pattern puts the firewall pair behind the edge routers (Network: Edge). Security decides which boundaries are inspected and at what depth; Network decides how traffic reaches the inspection point (Service insertion). Decide this with the policy model, before the overlay is built.

This split (north-south and inter-zone at the firewall, east-west by microsegmentation) is Cloudbit’s design stance, shared with Network. Sending all east-west traffic through central appliances is usually a bandwidth and latency bottleneck at fabric scale.

HA pair

The pair attaches to a border or service leaf pair, dual-homed with EVPN multihoming or MLAG (Network: Service insertion). Keep HA and state-sync links as the vendor’s HA guide specifies. State sync, upgrade behavior and failover timers are vendor-specific; take them from the vendor’s HA guide and test them under load. Firewall management interfaces belong on the OOB.

Decryption policy

Decide what is decrypted before sizing, because decryption is usually the largest driver of firewall load. Outbound user traffic can be decrypted at the perimeter or in the SSE service (Remote access). Inbound traffic to your own services is decrypted where TLS terminates: at the ADC (Network: ADC) or a firewall acting as a proxy. With (EC)DHE key exchange (mandatory in TLS 1.3 and the norm in TLS 1.2), holding the server’s private key is not enough to decrypt a copy of the traffic passively, so inspection means terminating the session. Write the exemption list (privacy-sensitive categories, certificate-pinned applications, mutual-TLS services) as policy, and review it.

Sizing

Vendor throughput figures are measured under different test conditions and are not comparable across vendors (see the notes on each ladder). RFC 9411 (March 2023, obsoletes RFC 3511) is the public benchmarking method for NGFW and NGIPS devices. It recommends testing with TLS inspection, IPS, anti-virus/anti-spyware and application identification enabled, using TLS 1.2 or higher with session resumption disabled: “Each client connection MUST perform a full TLS handshake, and session reuse or resumption MUST be disabled.” It defines KPIs including inspected throughput, TCP or QUIC connections per second, TLS handshake rate, concurrent TCP or QUIC connections, and time to first and last byte (RFC 9411).

• Size for north-south and inter-zone traffic with decryption, IPS and application identification on, not for all east-west traffic
• Size so one unit carries the full load after a failure, then add growth headroom
• Include connections per second and concurrent sessions for DMZ-facing services, not just throughput
• Ask vendors for RFC 9411 results, or reproduce them in a proof of concept with your own traffic mix

Hybrid mesh firewall

“Hybrid mesh firewall” is an analyst category for firewall platforms managed as one policy across physical appliances, virtual firewalls, cloud-native firewalls and cloud-delivered firewall service. Gartner publishes a Magic Quadrant under that name (2026 edition, 7 Sep 2026). The buyer question is whether one policy and management plane across those enforcement points is worth tying them to one vendor, or whether a multi-vendor estate under a separate orchestration tool fits better. The leaders and their ladders are in Market leaders: HMF / NGFW.

DDoS

CISA, FBI and MS-ISAC group denial-of-service techniques into volumetric, protocol and application attacks, note that firewalls and DNS servers can themselves be targets, and recommend a DDoS mitigation provider that filters traffic before it reaches your network, plus coordination with your ISP (CISA/FBI/MS-ISAC DDoS guide, Mar 2024). A stateful firewall pair is not a volumetric control: once the circuit is full, nothing behind it helps. Filtering has to happen upstream.

Perimeter design / build / manage

Design

• Decide which boundaries the firewall inspects with the policy model, and hand the insertion points to Network before the overlay is built
• Size the pair for north-south and inter-zone traffic with decryption on, so one unit carries the full load
• Write the decryption policy and exemption list
• Choose a DDoS option with the carriers and the edge design

Build

• Stand up the HA pair; fail over under load and check that sessions survive
• Validate decrypted throughput, connections per second and session counts against your own traffic mix
• Confirm firewall management is reachable only from the OOB
• Register DDoS contacts with carriers and the mitigation provider; test diversion

Manage

• Trend decrypted throughput, connections per second and session counts against the sizing
• Review rules for drift (Drift) and patch on both tracks (Lifecycle)
• Re-test failover after every major upgrade

Segmentation and microsegmentation

Security owns the segmentation policy: which zones exist, what may talk to what, and where it is enforced. Network owns the plumbing that carries it: VRFs, VNIs and service-leaf insertion (Service insertion, EVPN/VXLAN). Inter-zone traffic leaves its zone VRF at a border or service leaf toward the firewall. Route leaking between zone VRFs on the fabric is allowed only for flows the policy model marks L3/L4-only, and each is recorded in the inter-zone matrix. VRF and VNI definitions are not restated here. Source: CISA, Microsegmentation in Zero Trust, Part One (Jul 2025). Sources checked 5 Oct 2026.

Policy model

CISA distinguishes macrosegmentation, which divides the network into large parts by business need, from microsegmentation, which builds on it at finer grain, down to workloads (CISA, Jul 2025). Draft the macro layer first: it is what the fabric is built around.

• Zones by function and sensitivity. For example: edge and DMZ, user-facing apps, application tier, data, management (OOB), storage, backup, OT and physical security systems (OT), AI tenants (AI tenant isolation).
• Storage zone. Storage data and storage management are separate zones; the storage data path stays out of stateful inter-zone firewalls (Storage: IP SAN segmentation).
• Backup zone. Backup has its own zone, isolated from production administration (Backup: network isolation).
• Default-deny inter-zone matrix. List each permitted flow between zones with its owner and justification.
• Inspected boundaries. Mark which inter-zone flows need L7 inspection at a firewall (Placement) and which need only L3/L4 enforcement.
• Group by label or identity, not by IP. Policy written against workload labels survives readdressing and moves; IP-based rules drift.

Hand Network four outputs: the zone-to-VRF mapping, the list of inspected boundaries, the firewall insertion points, and the list of permitted fabric route leaks (Service insertion).

Enforcement types

CISA groups microsegmentation enforcement by where it runs. The trade-offs below paraphrase CISA; on-prem, the cloud category applies only to hybrid estates.

Agent vs agentless. “Agentless” covers several things in the market: network or hypervisor enforcement, or a central manager that programs each host’s built-in firewall remotely. Ask which one a product means, and what it does for bare metal, appliances and OT. Most estates mix types. CISA notes that where agents are unavailable, as with much OT and legacy equipment, network-based segmentation is needed, which is why OT zones are enforced in the network.

Phased rollout

CISA’s method runs in phases: identify candidate resources, map their dependencies, choose policies, then deploy, first in a permissive mode that flags violations without blocking. CISA says the phases are not one-time tasks. Enforce application by application once the observed flows match the intended matrix.

Policy and ACL drift

Policy drifts as rules are added for incidents and projects and never removed, and as fabric ACLs, firewall rules and host policy are changed separately. Because CISA treats the phases as continuous, run them again on a schedule:

• Compare the deployed rules (firewall, fabric ACLs, host and hypervisor policy) with the intended inter-zone matrix
• Review hit counts; remove unused and shadowed rules through change control
• Alert on rule changes made outside change control
• Re-test default deny between zones, including from the management and backup zones

Segmentation design / build / manage

Design

• Write the zone list and inter-zone matrix before the overlay is built; hand the outputs to Network
• Choose the enforcement type per zone; list the systems that cannot run agents

Build

• Map dependencies and deploy in permissive mode first
• Switch to enforcement application by application; test default deny between zones

Manage

• Review microsegmentation and ACL drift on a schedule; re-test east-west deny defaults
• Re-run the dependency mapping when applications change or move zones

Remote access: ZTNA, SSE, SASE

How users reach private applications in the hall, and how their internet and SaaS traffic is secured. SD-WAN as transport is on Network: SD-WAN. Administrator access to infrastructure is in Identity and PAM, over the OOB. The vendor shortlist is in Market leaders: SSE / SASE. Sources: NIST SP 800-207, NIST SP 1800-35, CISA Zero Trust Maturity Model v2.0. Market labels and product packaging change every year. Sources checked 5 Oct 2026.

ZTNA model and connector placement

NIST SP 800-207 describes zero trust access as a per-session decision by a policy engine and policy administrator, enforced at a policy enforcement point in front of each resource, rather than trust granted by network location (NIST SP 800-207). NIST SP 1800-35 (Jun 2025) shows example builds with commercial products (NCCoE).

Place ZTNA connectors in a dedicated DMZ segment with rules only to the applications they publish, not on a server VLAN. Run at least two connectors per site.

Workforce vs admin paths

Keep two paths. Workforce users reach applications through ZTNA or SSE. Administrators reach infrastructure through PAM, whose jump hosts sit on the OOB (PAM). If admins use ZTNA to reach the PAM portal, publish only the portal: never publish hypervisor, BMC, fabric or firewall management interfaces through workforce access.

SSE or SASE, one vendor or two

SSE is the cloud-delivered security set (secure web gateway, ZTNA, CASB, DLP). SASE adds the SD-WAN. Gartner publishes separate Magic Quadrants for SASE Platforms (28 Jul 2026) and SSE (29 Jul 2026) (Zscaler release). Single-vendor SASE gives one policy and one console for transport and security. A dual-vendor design keeps the SD-WAN already chosen on Network: SD-WAN and adds SSE from a security vendor. Decide on your existing SD-WAN estate, how much policy consistency matters, and how much contract concentration you accept.

Retiring VPN

Inventory the applications reached over VPN, move web applications to ZTNA first, then thick-client and non-web protocols, and shrink the VPN user base until it can be removed. Internet-facing VPN gateways are a recurring target for exploited vulnerabilities, so every month a gateway stays up is exposure (Lifecycle).

Remote access design / build / manage

Design

• Separate workforce access (ZTNA/SSE) from admin access (PAM over OOB)
• Decide single-vendor SASE or SSE plus the existing SD-WAN
• Place ZTNA connectors in a DMZ segment and add the flows to the policy model

Build

• Publish applications one at a time with identity and device-posture rules
• Scan from outside to confirm no inbound listener remains for migrated applications

Manage

• Review published applications and access rules against the policy model
• Track the VPN user base down to retirement
• Recheck vendor packaging and market labels yearly

Identity and PAM for infrastructure

Administrator identities for hypervisors, BMCs, fabric, firewalls, storage, backup and the PAM system itself. Where jump hosts and BMCs connect, and the break-glass procedure, are on Network: OOB. BMC hardware is on Compute; encryption settings on arrays and backup are on Storage and Backup, and key custody is here (Key management). Sources: NIST SP 800-63B-4, CISA/NSA BMC guidance, NIST SP 800-57 Part 1 Rev. 5, FIPS 140-3 and the CMVP, OASIS KMIP. Sources checked 5–6 Oct 2026.

Separate admin identities

Give administrators separate infrastructure identities, not their everyday workforce accounts, and keep the most privileged tier (hypervisor, fabric, PAM, backup) apart from the rest. Watch the circular dependency: if the identity provider or AAA runs as VMs on the cluster it controls, an outage of that cluster locks you out of the tools you need to fix it. Network calls out the same trap for OOB AAA (OOB). Backup administrators get identities separate from production administrators (Backup).

PAM

• Vault shared and service credentials, and rotate them after use
• Broker admin sessions through jump hosts on the OOB, and record them
• Grant elevation just in time, with an approval and an expiry, instead of standing admin rights
• Inventory machine identities (API tokens, SSH keys, certificates used by automation) and give each an owner and a rotation date
• Treat PAM as the most privileged system: its own HA and recovery, and no dependency on the systems it protects

Phishing-resistant MFA

NIST SP 800-63B-4 (final, Jul 2025) requires verifiers to offer at least one phishing-resistant option at AAL2, and requires AAL3 authenticators to have a non-exportable private key and to be phishing-resistant (NIST SP 800-63B-4). For infrastructure administrators, require phishing-resistant MFA, not just offer it. Document the break-glass exception.

BMCs and management controllers

CISA and NSA note that BMC hardening (credentials, firmware updates, network segmentation) is often overlooked. Their guidance covers replacing default credentials, isolating BMC networks, checking for firmware updates, monitoring firmware integrity, and treating unused BMCs as a risk (CISA/NSA, Jun 2023). BMCs connect to the OOB (Network: OOB).

Break-glass identity policy

Network owns the break-glass transport and procedure (OOB). Security owns the identity policy: named emergency accounts held outside PAM, an alert on every use, a review after every use, and rotation afterwards.

Key management and custody

Encryption at rest is switched on where the data lives: SEDs, controller encryption and the KMIP client settings on Storage: Encryption and keys, and backup and vault encryption on Backup. This section sets who holds the keys, where the key manager runs, and how keys are rotated, backed up and recovered. The baseline is NIST SP 800-57 Part 1 Rev. 5 (May 2020) (NIST). SP 800-53 SC-12 leaves the key management requirements to the organization, and SC-12(1) asks that information stay available if keys are lost, which makes key loss a recovery problem as well as a confidentiality one. Which frameworks require key management, validated cryptography or encryption at rest is on Governance: Design mapping.

Validation. Ask for the CMVP certificate, not “FIPS compliant”, and check that the module name, version and embodiment on the certificate match what you are buying, and its overall security level. FIPS 140-3 defines four levels (FIPS 140-3). In summary, Level 2 adds tamper evidence and role-based authentication, Level 3 adds tamper response and identity-based authentication, and Level 4 adds multi-factor operator authentication and protection against environmental attacks Verify. Specifying Level 3 for HSMs that hold root keys is common practice, not a NIST rule. FIPS 140-2 certificates could be used for new systems until 21 Sep 2026. On 22 Sep 2026 the CMVP moved them to its Historical list Verify. Those modules may still be bought and used for existing systems, but new systems need FIPS 140-3 certificates where validation is required (NIST CMVP, FIPS 140-3 transition).

KMIP. OASIS KMIP is the common protocol between key managers and their clients: arrays, SED controllers, tape libraries and backup software. Version 2.1 (Dec 2020) is the latest OASIS Standard Verify (OASIS KMIP). Interoperability is certified per product pair and KMIP version, so check both vendors’ interop lists. The client certificates that KMIP clients authenticate with are machine identities: give each an owner and a rotation date (PAM).

Custody. Key custodians are a separate role from storage and backup administrators. A storage admin can enable encryption and enroll a KMIP client, but cannot export, delete or restore keys. A KMS admin manages keys but has no access to the data. KMS and HSM administrators are tier-0 identities (Admin tiering). Put destructive and export operations (key destroy, HSM re-initialization, master-key export or restore) under dual control or an M-of-N quorum. SP 800-57 defines split knowledge as splitting a key into shares that reveal nothing about the key on their own.

Rotation. SP 800-57 §5.3 sets cryptoperiods per key type from risk and consequence factors, not as one figure for every key. Rotating a key-encryption or wrapping key re-wraps the data keys and is cheap. Re-keying a data-encryption key means re-encrypting the data. On an SED, changing the media encryption key erases the data cryptographically, so routine rotation applies to the authentication or wrapping key held in the KMS. Check each platform’s documentation for what its “rekey” operation actually changes.

Backup, archive and escrow. SP 800-57 separates key backup, used for recovery during a key’s cryptoperiod (§8.2.2.1), from key archive, used for recovery after it (§8.3.1). The archive is kept apart from operational data, with copies in physically separate locations. Data-encryption and key-wrapping keys can be backed up; private signature keys generally should not be (Table 7). In practice:

• Replicate or back up the KMS or HSM keys to the second site, under the same custody rules
• Keep archived keys for as long as any backup or archive encrypted under them is retained (Backup: Retention). Destroying the key ends access to the data.
• Never let the only copy of the KMS backup sit inside the backup system whose keys it holds. That circle cannot be restored (Backup: Admin plane).
• Escrow keys to a third party only where a contract or regulation requires it
• Keep a key inventory and a documented compromise-recovery plan. SP 800-57 lists its contents: who is notified, who recovers, how to re-key, and where every key is.

Break-glass and placement. If the KMS is unreachable at boot, encrypted arrays and hosts stay locked. Run KMS nodes at both sites. Never host the KMS on the datastore or cluster it unlocks. Put KMS nodes on the in-band management or infrastructure-services segment as their own zone in the policy model, and accept KMIP (TCP 5696) only from enrolled clients. KMS administrators reach the KMS consoles and HSM management from the OOB through the jump host and PAM, so recovery does not depend on production (OOB for admin access). Emergency access to the KMS follows the break-glass identity policy above: quorum cards or key shares in separate safes, held by named custodians, and tested on a schedule. In the DR runbook, bring up identity, DNS and time, then the KMS, before any encrypted data tier. Time comes first because KMIP’s mutual TLS fails when clocks are badly skewed (Backup: DR runbooks).

Identity and PAM design / build / manage

Design

• Define admin tiers and separate admin identities before cutover
• Place the infrastructure identity provider and AAA so they survive loss of the cluster they manage
• Define PAM for BMC, fabric, storage, backup and break-glass paths
• Choose the key manager category and custody model; place the KMS so it survives loss of what it unlocks (Key management)

Build

• Integrate PAM with jump hosts on the OOB; vault shared credentials
• Enroll admins in phishing-resistant MFA
• Replace BMC default credentials and record certificate and secrets ownership for mTLS and automation
• Enroll KMIP clients with owned certificates, replicate KMS keys to the second site, and start the key inventory

Manage

• Review admin entitlements and standing privilege on a schedule
• Rotate machine credentials on their recorded dates
• Test break-glass accounts and review every use
• Rotate wrapping keys on their cryptoperiods; test KMS restore and the custodian quorum; keep archived keys while encrypted copies exist

OT / facility network security

Network security for the systems that run the building: BMS/BAS, EPMS, generator and ATS controls, chiller and CDU controls, fire-panel interfaces, PACS and VMS, and networked UPS and PDU cards. The equipment is on Power and Cooling; the platforms, telemetry collection and alarm handling are on Ops. Sources: NIST SP 800-82r3, ISA/IEC 62443-3-2, CISA et al. OT fact sheet (May 2025), CISA/DOE UPS Insights (Mar 2022). Sources checked 5 Oct 2026.

What is in scope

NIST SP 800-82r3 (Sep 2023) explicitly includes building automation systems, physical access control systems and physical environment monitoring systems in OT (NIST). In a data center that covers:

Zones and conduits

ISA/IEC 62443-3-2 sets the method: define the system under consideration, partition it into zones and conduits, assess risk for each, and assign each a target security level (IEC 62443-3-2:2020). CISA and partner agencies recommend segmenting IT and OT with a demilitarized zone for passing control data to the enterprise (CISA et al., May 2025). A data center version:

• A zone per plant system (power, mechanical, physical security), each with its own conduit rules
• A monitoring DMZ where the DCIM and telemetry collectors sit; collectors poll the zones, and IT reads from the DMZ (Ops owns the collection path)
• No direct path from the IT network or the internet to a controller
• Enforcement in the network: OT controllers rarely accept host agents (Enforcement types)

PDU and UPS cards: OOB or OT zone

Networked rack PDUs and UPS cards are claimed by two models. Network: OOB puts switched PDUs and UPS cards on the OOB so they can be reached for remote power cycling when production is down. The power team often wants them in the EPMS zone with the rest of the power telemetry. Cloudbit splits by device class:

• On the OOB: switched rack PDUs, in-rack transfer switches (rack ATS/STS) for single-corded loads, and the network cards of UPS units whose output feeds only IT racks. They are the remote power-cycle and recovery path, and in colo they are the only power devices you own.
• In the facility OT power zone (zoned per IEC 62443): any UPS that feeds fixed distribution (panelboards, RPPs, busway, floor PDUs), upstream STS, RPP and floor-PDU branch-circuit monitoring, busway tap-off metering, EPMS meters and gateways, and generator, paralleling and utility/generator ATS controls. Sort by what the output feeds, not by size: a rack-mount UPS that feeds a panelboard is facility plant.
• One conduit between them: the EPMS/DCIM collector in the monitoring DMZ polls the OOB rack devices through a single filtered conduit, read-only: an SNMPv3 user at authPriv with no write view; Modbus write function codes blocked, or no Modbus TCP; and for Redfish, a device account with the ReadOnly role. Redfish runs over HTTPS, so the conduit firewall cannot tell a GET from a PATCH or POST; read-only has to be enforced by the account role on the device, not at the firewall (DMTF Redfish, DSP0266). Device alarms (SNMP traps or informs, syslog) return on the same conduit. Write actions such as outlet control, configuration and firmware come only from OOB admin sessions, never from the collector. Nothing routes from the OT zone into the OOB.

UPS shutdown signaling is a separate flow. Servers and hypervisors must learn that a UPS is on battery and running low. Broker this through a shutdown orchestrator in the monitoring DMZ or an IT management zone: it reads UPS state and calls the hypervisor’s API, so UPS cards and OT devices never open sessions into production. Alarm when this path is lost, and re-test it after firewall or card firmware changes. UPS hardware and runtime are on Power.

Cooling devices follow the same rule: sort by what they serve. Facility CDUs, CRAHs and CRACs, chillers and their controls, and leak-detection panels go in the OT mechanical zone with the BMS (Cooling). Only rack-integrated cooling that is managed through the rack’s own management controller, such as in-rack CDUs in rack-scale AI systems, goes on the OOB with the rest of that rack’s management plane (AI Factory: GPU systems).

The table below is the reasoning for the split.

Baseline mitigations

The May 2025 fact sheet from CISA, FBI, EPA and DOE lists five primary mitigations, paraphrased here: remove OT connections from the public internet; change default passwords; secure remote access over a private connection or a VPN with phishing-resistant MFA and least privilege; segment IT and OT with a DMZ; and practise manual operation (CISA et al.). The CISA/DOE UPS Insights found threat actors reaching internet-connected UPS devices, often through unchanged default credentials, and advise enumerating UPS devices, taking them off the internet, and putting VPN and MFA in front of any remote access that is needed (CISA/DOE).

Vendor remote access

Facility vendors often need remote access for support. Broker it: a named account, phishing-resistant MFA, access only to that vendor’s zone, a time limit, session recording, and approval per session. No standing VPN, cellular modem or remote-desktop tool installed by the vendor. Use the same PAM as for IT admins where it can reach the OT zone through a defined conduit (PAM).

Asset discovery and monitoring

Keep an inventory of every networked facility device, its firmware and its zone. CPS protection platforms (an analyst category; leaders are noted below) discover assets passively and monitor industrial protocols, which matters because active scanning can upset some controllers. Monitoring dashboards and alerting are on Ops. Keep and exercise a manual-operation procedure for each plant system.

Onsite vs colo

Onsite, every system above is yours. In colo the provider’s BMS, EPMS and plant controls are outside your network and your scope; ask about their OT security in the colo evaluation. Your own rack PDUs, in-cage sensors and any monitoring feed or API you take from the provider are in scope. The provider’s upstream UPS and EPMS data reaches you through its portal or API into your DMZ collector, not as an OT-zone flow, so a colo cage usually needs the OOB rack-device rules above but no facility OT power zone of its own.

OT security design / build / manage

Design

• Segment OT/facility networks from IT: define zones, conduits and the monitoring DMZ
• Place power devices by what their output feeds: rack devices on the OOB, facility power plant in the OT power zone (split)
• Define the UPS shutdown-signaling path and test a full shutdown sequence
• Define the vendor remote-access path before the first vendor asks

Build

• Change every default credential at commissioning; confirm no facility device is reachable from the internet
• Record every facility device, its firmware and its zone
• Test the collector paths with Ops: polls from the DMZ work, inbound from IT is denied

Manage

• Reassess OT exposure after any BMS, EPMS, UPS or CDU change
• Patch facility firmware through the security lifecycle and Ops change windows
• Exercise manual operation
• Vendor cloud call-home on PDU and UPS cards is handled on Network: OOB
• Stage PDU and UPS card firmware inside the OOB, and watch ICS advisories for management cards, for example CISA ICSA-21-313-01 (network management cards for UPS, PDU and other infrastructure devices)

Patching and end of support

Patch policy for the systems this page owns: firewalls, VPN and ZTNA gateways, PAM, PACS and VMS, and facility OT devices. Change windows and runbooks are on Ops. Production switches and ADCs are patched on Network’s cadence; console servers and OOB switches per Network: OOB. Sources: CISA KEV catalog, CISA ED 25-03. Sources checked 5 Oct 2026.

Two tracks

Internet-facing firewalls and VPN gateways are a recurring target for exploited zero-days, so a calendar cadence alone is not enough. Internet-facing ADCs belong on the emergency track too. Run a routine track on the change calendar, and an emergency track triggered by an entry in the CISA Known Exploited Vulnerabilities catalog or a vendor security advisory for a product you run (CISA KEV). Set the emergency service level in advance, and patch the standby unit of an HA pair first.

Recent example: CISA Emergency Directive 25-03 (Sep 2025, updated Apr 2026) covers exploited vulnerabilities in a vendor’s firewall software. The actor modified device ROM to persist through reboot and upgrade, so patching alone did not remove an existing compromise; the directive also required unsupported hardware to be disconnected (CISA ED 25-03). The lesson applies to every vendor: after a known-exploited hit, follow the vendor’s and CISA’s integrity and forensic steps, not just the upgrade.

End of support

Track end-of-sale and end-of-support dates for firewall, VPN, PAM, PACS/VMS and OT hardware and software, and plan replacement before support ends. Unsupported internet-facing hardware cannot receive the emergency track at all.

Lifecycle design / build / manage

Design

• Define routine and emergency patch tracks and their service levels
• Choose HA designs that allow patching one unit at a time

Build

• Subscribe to the CISA KEV catalog and each vendor’s security advisories
• Record end-of-support dates for every security and OT device

Manage

• Patch firewalls, VPN and ZTNA gateways, PAM, PACS/VMS and jump hosts on the routine track; use the emergency track for known-exploited vulnerabilities, including on internet-facing ADCs
• After a known-exploited hit, run the integrity checks, not just the upgrade
• Replace hardware before end of support

Logging and coordination

Log sources and volume

The security design fixes the log sources: firewalls (the largest, especially with decryption and URL logging on), PAM sessions, PACS and VMS events, OT monitoring, ZTNA and SSE, and identity providers. Estimate volume and retention from these sources early, because they size the SIEM and its storage. Monitoring, alerting and runbooks are on Ops.

Log retention and protection

Retention periods come from frameworks, contracts and legal holds, not from this page. NIST SP 800-53 AU-11 leaves the period to the organization, while other frameworks set minimums, some with a separate period that must be immediately searchable. The per-framework values are on Governance: Design mapping. Take the strictest one that applies to each source, then split it across tiers:

Protection, mapped to the SP 800-53 AU controls (catalog release 5.2.0):

• Off the source quickly. Forward events as they are generated to a collector on a different system (AU-4(1), AU-9(2)), so an attacker with admin rights on a firewall or hypervisor cannot erase the record locally. Buffer at the collector so a SIEM outage does not drop events. Prefer syslog over TLS (RFC 5425) to plain UDP 514 where sources support it (RFC 5425).
• OOB sources. Devices on the OOB log from the OOB. Put a collector or relay inside the OOB that buffers and forwards outbound to the log zone through the OOB firewall as one defined flow (Network: OOB).
• Separate admin domain. Only a named subset of privileged users manages the logging pipeline and the log store (AU-9(4)). Analysts get read-only access (AU-9(6)). Log-store admins are not the firewall, hypervisor or directory admins whose actions are being logged, and the log store does not authenticate against the production directory it monitors (Admin tiering).
• Immutability and integrity. Put the archive tier on WORM or object lock in a mode that no administrator, including the log-store admin, can shorten. Add cryptographic integrity such as signing or hash chaining where the platform supports it (AU-9(3)). Alert on any attempt to delete or modify logs (AU-9), and on gaps and logging failures (AU-5). Object locks trust the storage clock, so they depend on the time design below.
• Separate network. Joint guidance from ASD’s ACSC, CISA and partners (Aug 2024) recommends keeping logs on a separate or segmented network and hardening the SIEM apart from general IT (CISA: Best Practices for Event Logging and Threat Detection). Make the log store its own zone in the policy model, allowing in only collector-to-store flows, plus analyst and admin access through PAM.

What the SIEM must keep. Beyond each framework’s list, keep at least:

• Authentication and elevation events for every admin identity, PAM session metadata, and break-glass use (Identity)
• Configuration and policy changes on firewalls, fabric, hypervisors, storage, backup and the KMS, including KMS key operations (create, rotate, export, destroy) (Key management)
• Inter-zone allow and deny decisions at the boundaries in the policy model, and microsegmentation policy changes
• PACS door events and alarms, and VMS health and recording gaps (Physical monitoring)
• OT conduit traffic and CPS-platform alerts (OT monitoring)
• Time-sync alarms, and the logging pipeline’s own audit trail: who changed parsers, retention or forwarding
• The raw events for the forensic period, not only the parsed fields, because a parser change can drop data you later need

Recordings of PAM sessions can be large. Keep them in the PAM store under the same retention and immutability rules, and index only their metadata in the SIEM. Review and alerting on these events are on Ops: Monitoring.

Time sync

Correlation, evidence and time-based locks all depend on clocks. AU-8 asks for timestamps in UTC, with a fixed offset from UTC, or with the local offset included in the timestamp. SC-45 asks for clocks to be synchronized within and between systems. SC-45(1) adds comparison against an authoritative source with a drift threshold, and SC-45(2) adds a secondary authoritative source in a different geographic region. Design:

• Hierarchy. Run redundant internal stratum-1 sources (GNSS-disciplined time servers) at each site, or at least redundant upstream authoritative sources. Serve clients from internal stratum-2 servers, never from the internet directly. Give each client enough servers for a faulty one to be outvoted: RFC 8633 (BCP 223) says operators who care about accuracy should use at least four independent, diverse sources (RFC 8633). The four must trace to independent upstream references, for example each site’s stratum-1 pair plus the other site’s, or an authenticated external source. Using the other site also meets SC-45(2)’s secondary source in a different region. Count GNSS jamming and spoofing as a common-mode failure, and include a non-GNSS source or a holdover oscillator.
• Authenticated time. Use NTS (RFC 8915, Sep 2020) where clients support it. Its key exchange runs over TLS 1.3 on TCP 4460, and it then authenticates each NTP packet. It does not hide the time itself, which is sent in the clear (RFC 8915). Where devices do not support NTS, which is common on network gear, BMCs and OT controllers, use NTP symmetric-key authentication with AES-CMAC (RFC 8573) rather than MD5, as RFC 8633 §4.1 recommends, and restrict which servers each client will accept. Support varies by platform and release, so check each one.
• Placement. Make time sources reachable inside the OOB, so the management plane, AAA and logging keep correct time when production is down (Network: OOB). Serve each plane from its own interface or instance: GNSS appliances with a separate port per network and no routing between them, or separate stratum-2 servers in the OOB and in the shared-services VRF (Network: Service insertion). Never route production clients into the OOB for time.
• OT time. A GNSS or holdover source local to the OT zone avoids the conduit, and is preferred where OT must keep time during an IT outage. Otherwise serve time from the monitoring DMZ as a defined conduit flow, one direction only, from the time source to the clients, on UDP 123 only (Zones and conduits). NTS is rarely supported on OT controllers. OT devices never use internet time servers.
• PTP. Where a workload needs sub-microsecond time, IEEE 1588-2019 PTP carries it. Its integrated security mechanism (an authentication TLV, Annex P) needs a key management system that the IETF is still standardising (draft-ietf-ntp-nts-for-ptp-04, 7 Aug 2026, an Internet-Draft; fast-changing). In practice, isolate PTP, and accept it only on configured ports and VLANs. The transport and clock design belong to Network.
• Monitoring. Alarm on offset beyond the SC-45(1) threshold, on loss of sources, and on a change of stratum. Do not mix leap-smearing and non-smearing servers in the same client pool, because they disagree during a leap event (RFC 8633 §3.7.1).

Backup

Immutability, air gap, the recovery vault and ransomware recovery design are on Backup. Security sets two requirements: backup administrators have separate identities (Identity), and the backup network is its own zone in the policy model.

AI Factory

Tenant isolation. If one GPU cluster serves several tenants, isolate them on every network the cluster has, not only the front-end. On an InfiniBand back-end, partitions (P_Keys) do this: the subnet manager enforces them, and a port outside a partition cannot exchange InfiniBand traffic with its members whatever the physical connectivity (NVIDIA Infra Controller: InfiniBand partitioning). On an Ethernet back-end and on the storage and front-end networks, give each tenant its own VRF or segment and treat each as a zone in the policy model. Which networks a cluster has is on AI Factory: Network separation.

Admin planes. Cluster managers, schedulers and Kubernetes control-plane nodes (AI Factory: Control plane) are tier-0 infrastructure: administer them through separate admin identities and PAM, with management interfaces on the OOB, and never reachable from tenant networks.

Secrets. Keep tenant credentials, registry and model-store tokens, and automation secrets in a vault with an owner and rotation date per secret (PAM), not in job scripts or container images.