Which practice helps ensure only trusted software is deployed to OT systems?

Which practice helps ensure only trusted software is deployed to OT systems?

• A. Relying on antivirus alone.
• B. Deploying without validation to speed patching.
• C. Signed builds with restricted deployment and strict change controls.
• D. Allowing developers to push directly to production.

Answer: (C)

Verifying the origin and integrity of software before it reaches OT systems is essential to protect operating environments that control critical infrastructure. The idea here is to ensure what gets deployed is literally trusted software from known sources, and that every change goes through a controlled, auditable process. Signed builds provide that trust by attaching a digital signature to the software, confirming it came from the legitimate author and that it hasn’t been altered in transit or on the way to production. When deployment is restricted, only approved systems or environments can receive software, reducing the chance of unvetted or accidental deployments. Combine this with strict change controls, which require formal approvals, testing, documentation, and a tracked rollback plan, and you create a safe, auditable flow from development to production. This combo minimizes the risk of malware, backdoors, or unstable patches entering critical OT operations and makes compliance and incident response more straightforward. Relying on antivirus alone isn’t enough for OT deployments because detection can miss targeted or new threats, and some OT environments can’t rely on real-time scanning due to performance or safety constraints. Deploying without validation bypasses essential checks, increasing the chance that tampered or untested software makes it into operation. Allowing developers to push directly to production removes the necessary governance and accountability that protect critical systems.

Verifying the origin and integrity of software before it reaches OT systems is essential to protect operating environments that control critical infrastructure. The idea here is to ensure what gets deployed is literally trusted software from known sources, and that every change goes through a controlled, auditable process.

Signed builds provide that trust by attaching a digital signature to the software, confirming it came from the legitimate author and that it hasn’t been altered in transit or on the way to production. When deployment is restricted, only approved systems or environments can receive software, reducing the chance of unvetted or accidental deployments. Combine this with strict change controls, which require formal approvals, testing, documentation, and a tracked rollback plan, and you create a safe, auditable flow from development to production. This combo minimizes the risk of malware, backdoors, or unstable patches entering critical OT operations and makes compliance and incident response more straightforward.

Relying on antivirus alone isn’t enough for OT deployments because detection can miss targeted or new threats, and some OT environments can’t rely on real-time scanning due to performance or safety constraints. Deploying without validation bypasses essential checks, increasing the chance that tampered or untested software makes it into operation. Allowing developers to push directly to production removes the necessary governance and accountability that protect critical systems.