Security+ 801 Countdown, T-22: OT Replaces ICS and SCADA as Cloud Gets Deployment Models

Operational technology (OT) is the hardware and software that monitors or controls a physical process: the controller that opens a valve, the operator screen that shows a tank level, the supervisory system that runs a pipeline across a region. Securing OT is a different discipline from securing IT because the asset at risk is a physical outcome rather than a record, and because the equipment was built to run for decades on protocols that predate the idea of a login. The same objective covers the designs used to isolate OT (air gaps and physical and logical segmentation) and, at the opposite end of the spectrum, the cloud deployment models, where the question is how to share infrastructure safely.

SY0-801 objective 3.1, “Compare and contrast security implications of different architecture models,” expands its coverage to name OT as an architecture model in its own right, alongside air-gapped networks, physical and logical segmentation, four named cloud deployment models, and multicloud (CompTIA 2025). The thread that ties these together is the trust boundary: where a design draws it, what is allowed to cross it, and who is responsible on each side.

Operational technology: control systems that touch the physical world

The vocabulary comes from NIST. SP 800-82 Rev. 2 (2015) was the Guide to Industrial Control Systems (ICS) Security; Rev. 3 (September 2023) is the Guide to Operational Technology (OT) Security. Rev. 3 defines OT as “hardware and software that detects or causes a change through the direct monitoring and/or control of physical devices, processes and events in the enterprise,” counts SCADA, DCS, PLCs, building automation, and IIoT as OT system types, and notes that “many OT systems utilize real-time OSs (RTOS)” (Stouffer et al. 2023). CompTIA’s own SecOT+ exam, scheduled for December 2026, lists “PLCs, HMIs, SCADA systems” as OT device roles (CompTIA 2026). Basically, OT is the umbrella term; ICS, SCADA, real-time operating systems, and embedded controllers all sit under it.

The cast of components

The names recur in every OT scenario. A programmable logic controller (PLC) runs control logic against field inputs and outputs: it reads sensors and drives actuators. A remote terminal unit (RTU) is a remote field computer that does the same job at a distant site. A human-machine interface (HMI) is the operator’s interface to the process. A distributed control system (DCS) spreads control across the process, while supervisory control and data acquisition (SCADA) applies control over long distances such as pipelines. A safety instrumented system (SIS) has one job: drive the process to a safe state.

Safety first, then availability

OT inverts IT defaults. Rev. 3 is blunt: “Any security measure that impairs safety is unacceptable.” Outages are often scheduled “days or weeks in advance,” patches need testing by both the vendor and the owner before they are applied, components last “10 to 15 years and sometimes longer” versus three to five for IT, and some vendor agreements forbid third-party security software outright (Stouffer et al. 2023). The usual IT reflexes (patch now, install an agent, reboot) are often unavailable, so if a controller cannot be patched or run an agent, the answer is compensating controls: segmentation, passive monitoring, and strict change control.

Twelve bytes and no identity

The protocols explain why segmentation carries so much of the weight. In this spec-exact Modbus/TCP request, an HMI turns on coil 173 at a PLC (Modbus Organization 2012):

HMI 192.0.2.10 -> PLC 198.51.100.20, TCP 502
00 01   Transaction ID    1
00 00   Protocol ID       0 (MODBUS)
00 06   Length            6 bytes follow
01      Unit ID           1
05      Function code     0x05 Write Single Coil
00 AC   Output address    172 (coil 173; coils count from 0)
FF 00   Output value      ON (00 00 = OFF)

Read the fields and notice what is absent. No field holds a user, a password, a session token, a nonce, or a signature. Anything that can reach TCP 502 on the PLC can write the coil, and the PLC’s normal response echoes the request back. Rev. 3 generalizes the point: “Many OT protocols have no authentication at any level” (Stouffer et al. 2023). A secured variant exists, MODBUS/TCP Security, which runs over mutual TLS with X.509 role-based authorization on port 802, but long-lived OT equipment changes slowly. So the realistic control is detection: filter captured traffic on modbus.func_code for the write function codes 5, 6, 15, and 16, and alert on any source address outside the allowlist of HMIs and engineering workstations.

Separating OT from the enterprise: air gaps, diodes, and VLANs

Because OT cannot be hardened the way IT can, its first line of defense is separation, and SY0-801 names three forms of it that candidates routinely blur together.

An air-gapped network is “not connected physically” to any other network, and data moves across the gap “only manually, under human control” (CNSSI 4009-2022, from RFC 4949; NIST n.d.). The defining feature is the absence of any automated path: no cable, no wireless link, no one-way device. Physical segmentation uses separate hardware: separate cabling, switches, and firewalls, or a data diode, whose hardware “cannot be programmed to allow data to flow in both directions” (Stouffer et al. 2023). Logical segmentation divides a shared physical network by configuration, using VLANs, access control lists, and microsegmentation; Rev. 3 presents it as the option when physical separation costs too much.

The distinction that matters most is that a data diode is physical segmentation, not an air gap: it is one-way and enforced in hardware, but data crosses it with no human involved. An air gap’s weakness is the opposite: the manual path itself. Symantec’s analysis of Stuxnet documents the worm spreading on removable drives through the LNK flaw (MS10-046) and targeting Siemens 6ES7-315-2 PLCs; its attack scenario, which the authors label “only speculation,” has removable drives covering the last hop to a programming device “never connected to an untrusted network” (Falliere, O Murchu, and Chien 2011). Rev. 3 draws the lesson plainly: air gaps alone are “not enough.”

Segmentation needs a reference model to say what belongs where, and the standard one is the Purdue model (ICS-CERT 2016). Level 0 holds the sensors and actuators, Level 1 the PLCs, Level 2 the HMIs and SCADA servers, and Level 3 the historians (databases that record process values over time) and engineering workstations. Above that sits a DMZ, often called Level 3.5, and then Level 4, the business systems such as ERP and email. Rev. 3 recommends blocking direct paths from Level 4 to Levels 2, 1, and 0, so that the business side reaches the process only through the DMZ, and making outbound rules “as stringent as inbound rules” (Stouffer et al. 2023). ISA/IEC 62443 models the same design as zones joined by conduits, each assigned a target security level (ISA 2020).

IoT and OT as threat vectors

An architecture model describes a design; a threat vector describes the path an attacker takes into it. SY0-801’s threat-vector objective (2.3) treats both Internet of Things (IoT) devices and OT devices as vectors, and names cameras, printers, and sensors under IoT. Each has a documented case.

Cameras are the Mirai case. The botnet spread by trying “62 common default usernames and passwords” over Telnet (TCP 23 and 2323), and its September 20, 2016 attack on Krebs exceeded 620 Gbps (CISA 2016).

Printers are the STRONTIUM case. In 2019, STRONTIUM entered corporate networks through a VOIP phone, an office printer, and a video decoder, two of them still on default passwords (MSRC 2019). A device does not need to hold anything worth stealing to be a useful foothold; it only needs to be on the network and reachable.

Sensors are the OT case at its lowest level. Many Level 0 sensors and actuators “cannot be authenticated,” so their readings can be replayed or spoofed, and a controller acting on a false reading acts wrongly in the physical world (Stouffer et al. 2023).

OT as a vector has its own reference case. From November 2023 to January 2024, actors compromised at least 75 internet-exposed Unitronics PLCs, at least 34 of them in U.S. water and wastewater systems, through default or absent passwords on port 20256 (FBI et al. 2023). The mechanism is the Modbus lesson again: a controller reachable from outside and no credential worth the name.

The IT-to-OT path matters as much as the direct one. Volt Typhoon pre-positioned on IT networks “to enable lateral movement to OT assets” (CISA 2024a), the path the Purdue rules about Level 4 exist to close. The hardening baseline is unglamorous (T-16 covers it in detail): change default credentials, disable unused services, and segment whatever you cannot harden. CISA’s Secure by Design alert of December 15, 2023 pushes the first item upstream by asking manufacturers for instance-unique, time-limited setup passwords (CISA 2023).

Cloud deployment models and the responsibility split

At the other end of the spectrum from an air-gapped plant sits the cloud, where the architecture question is not whether to share infrastructure but with whom, and on what terms.

Four models plus multicloud

NIST SP 800-145 defines four deployment models, and SY0-801 adds multicloud, which 800-145 does not define (Mell and Grance 2011; Iorga et al. 2026):

Model	Definition test	Security implication
Public	Open to the general public; provider premises	Multi-tenant; customer misconfiguration is the usual failure
Private	One organization; on or off premises	No other tenants; more of the operating burden is yours
Community	Exclusive to organizations with shared concerns	Shared fate and shared compliance
Hybrid	Two or more distinct clouds bound for portability	The seam: federated identity, data crossing boundaries
Multicloud	Public services from two or more providers (ISO)	Several IAM models and policy languages; drift

Two traps follow from the definitions. Private does not mean on-premises; 800-145 says a private cloud “may exist on or off premises,” so a provider-hosted environment dedicated to one organization is still private. And hybrid has three competing definitions: NIST’s is “two or more distinct cloud infrastructures” of any type, ISO/IEC 22123-1:2023 says private plus public, and everyday usage says on-premises plus cloud. Multicloud’s role in resilience is at T-17.

Who patches what

The deployment model says who else shares the infrastructure; the service model says who is responsible for each layer of it. Microsoft’s table, literally titled “Responsibility matrix,” condenses to this (Microsoft 2026):

Layer	IaaS	PaaS	SaaS
Data, identities, configuration	Customer	Customer	Customer
Applications	Customer	Shared	Shared
Network controls	Customer	Shared	Provider
Operating system	Customer	Provider	Provider
Physical hosts, network, datacenter	Provider	Provider	Provider

On premises, every row is yours. Serverless follows the same logic; by my derivation from the AWS documentation, Lambda patches the operating system and the managed runtime by default while you own the code, its dependencies, its permissions, and its data, and functions packaged as container images hand runtime patching back to you (AWS 2026). The top row never moves: data, identities, and configuration stay with the customer in every model, and infrastructure as code (IaC) is where that configuration lives. One Terraform rule with cidr_ipv4 = "0.0.0.0/0" on port 22 repeats in every deployment built from it, and so does the fix.

Technical considerations versus business considerations

A design is justified twice: once to the engineers who will run it and once to the people who pay for it. SY0-801 makes this explicit by splitting its architecture considerations into a technical list and a business list (CompTIA 2025):

Technical	Business
Availability	Cost
Resilience	Scalability
Compute	Risk
Ease of recovery	Data sovereignty
Power requirements	Data classification
Proprietary vs. open source	Ownership
Usability	Environmental requirements
Responsibility

The split forces a two-sided justification. Consider a water utility that must host a historian for 12 pump stations and has two options: (A) on premises in an industrial DMZ fed by a data diode, or (B) in a community cloud shared by several utilities. Option B wins on Scalability and Cost, but it splits Responsibility with the provider, raises Data sovereignty and Ownership questions, and requires an outbound path from the OT network to a provider outside the plant. Option A keeps Ownership, but its Power requirements, Environmental requirements, and Ease of recovery are all yours. Neither answer is wrong; the skill being tested is naming which consideration each design trades away.

Proprietary vs. open source cuts both ways. Open source exposes you to upstream compromise: CVE-2024-3094 hid a backdoor in the xz utils 5.6.0 and 5.6.1 release tarballs and scored 10.0 on CVSS 3.1 (CISA 2024b). Proprietary OT ties you to one vendor’s patch cadence. Supply chain vectors are covered at T-31.

What you need to know for SY0-801

• OT means systems that monitor or control physical processes (PLC, RTU, HMI, DCS, SCADA, SIS), often on an RTOS; ICS/SCADA material from the SY0-701 era is OT material now.
• OT ranks safety and availability first; rebooting, patching immediately, or installing an agent on a PLC is usually the wrong answer.
• Many OT protocols, Modbus/TCP included, carry no authentication; anything that reaches the port can write to the controller.
• A device whose failure affects a physical process is OT; cameras, printers, and sensors are the named IoT-based vectors, and default credentials are the common thread.
• Air gap means manual transfer only; a data diode is physical segmentation; VLANs and ACLs are logical segmentation.
• Purdue Level 4 business systems reach Levels 2, 1, and 0 only through the Level 3.5 DMZ, with outbound rules as strict as inbound.
• Private can be off-premises; community is exclusive to organizations with shared concerns; hybrid mixes deployment types; multicloud means several providers.
• Data, identities, and configuration stay with the customer in every service model, serverless included.
• Data sovereignty, Ownership, and Risk are business considerations; Responsibility, Usability, and Power requirements are technical.
• The bulleted examples “are not exhaustive,” so a term absent from the list, such as virtualization, can still appear as context.

Check yourself

These are original practice questions, not exam items.

1. Five regional hospitals contract a provider to host a cloud platform that only they may use, built for their shared HIPAA requirements and located in the provider’s data center. Which deployment model is this?

• A. Public.
• B. Private.
• C. Community.
• D. Hybrid.

Answer: C. A community cloud is exclusive to organizations with shared concerns such as compliance, and it may be hosted off premises. Public is open to anyone, and private serves one organization.

2. A plant engineer says the control network is air-gapped because its only link to the corporate historian is a data diode that sends process data outbound. Which term most accurately describes this design?

• A. Air-gapped network.
• B. Physical segmentation.
• C. Logical segmentation.
• D. Microservices.

Answer: B. The diode is an automated, hardware-enforced one-way connection: physical segmentation. An air gap allows only manual transfer, and logical segmentation is configuration such as VLANs.

3. A company moves its ticketing system from IaaS virtual machines to a SaaS product. Which responsibility stays with the company after the move?

• A. Patching the guest operating system.
• B. Maintaining the hypervisor hosts.
• C. Managing user identities and access to the application.
• D. Physically securing the data center.

Answer: C. Identities, data, and configuration remain the customer’s in every service model. The other three are the provider’s in SaaS.

This is T-22 of the Security+ 801 Countdown: one change from SY0-701 to SY0-801 every morning until the new exam launches on November 17, 2026. Tomorrow, T-21: Zero Trust Drops the NIST Plane Vocabulary. New here? Start with T-38: The Blueprint Was Reweighted and Trimmed to 27 Objectives.

References

AWS (Amazon Web Services). 2026. “Understanding How Lambda Manages Runtime Version Updates.” AWS Lambda Developer Guide. Accessed October 12, 2026.

CISA (Cybersecurity and Infrastructure Security Agency). 2016. “Heightened DDoS Threat Posed by Mirai and Other Botnets.” Alert TA16-288A.

CISA (Cybersecurity and Infrastructure Security Agency). 2023. “Secure by Design Alert: How Manufacturers Can Protect Customers by Eliminating Default Passwords.” December 15, 2023.

CISA (Cybersecurity and Infrastructure Security Agency). 2024a. “PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure.” Cybersecurity Advisory AA24-038A.

CISA (Cybersecurity and Infrastructure Security Agency). 2024b. “Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094.” March 29, 2024.

CompTIA. 2023. CompTIA Security+ SY0-701 Certification Exam Objectives. Version 5.0.

CompTIA. 2025. CompTIA Security+ SY0-801 V8 Certification Exam Objectives. Document Version 2.0.

CompTIA. 2026. “SecOT+ Certification V1.” Accessed October 12, 2026.

Falliere, Nicolas, Liam O Murchu, and Eric Chien. 2011. W32.Stuxnet Dossier. Version 1.4. Symantec Security Response.

FBI, CISA, NSA, EPA, INCD, CCCS, and NCSC. 2023. “IRGC-Affiliated Cyber Actors Exploit PLCs in Multiple Sectors, Including US Water and Wastewater Systems Facilities.” Joint Cybersecurity Advisory AA23-335A. Last revised December 18, 2024.

ICS-CERT. 2016. Recommended Practice: Improving Industrial Control System Cybersecurity with Defense-in-Depth Strategies. Department of Homeland Security.

Iorga, Michaela, Ned Goren, Joyce Hunter, Chris Carpenter, Brian Ruf, Sanjiev Chattopadhya, Katie Digon, and Larisa Gabudeanu. 2026. Multi-Cloud Architecture Challenges: Security and Compliance Implications. NIST IR 8613, initial public draft.

ISA (International Society of Automation). 2020. ANSI/ISA-62443-3-2-2020, Security for Industrial Automation and Control Systems, Part 3-2: Security Risk Assessment for System Design. Preview. See also the ISA/IEC 62443 series page.

Mell, Peter, and Timothy Grance. 2011. The NIST Definition of Cloud Computing. NIST Special Publication 800-145.

Microsoft. 2026. “Shared Responsibility in the Cloud.” Microsoft Learn. Updated August 24, 2026.

Modbus Organization. 2012. MODBUS Application Protocol Specification V1.1b3. See also the MODBUS Messaging on TCP/IP Implementation Guide V1.0b (2006) and the MODBUS/TCP Security Protocol Specification (2021).

MSRC (Microsoft Security Response Center). 2019. “Corporate IoT: A Path to Intrusion.” August 5, 2019.

NIST (National Institute of Standards and Technology). n.d. “Air Gap.” CSRC Glossary, citing CNSSI 4009-2022 and RFC 4949. Accessed October 12, 2026.

Stouffer, Keith, Michael Pease, CheeYee Tang, Timothy Zimmerman, Victoria Pillitteri, Suzanne Lightman, Adam Hahn, Stephanie Saravia, Aslam Sherule, and Michael Thompson. 2023. Guide to Operational Technology (OT) Security. NIST Special Publication 800-82 Rev. 3.