Pearl · ps-ot-protect-redundancy-and-graceful-degradation

Protect Redundant OT Paths and Prove Graceful Degradation

Apply equivalent governance to primary and redundant OT paths and prove project-defined normal-to-emergency or manual transition and recovery.

Construction terms explained

OT:: operational technology

Controls and OT

What to check before the work begins

Apply equivalent security and configuration governance to primary and redundant OT paths, then prove the project-defined transition from normal to emergency or manual operation and back.

Apply equivalent security and configuration governance to primary and redundant OT paths, then prove the project-defined transition from normal to emergency or manual operation and back.
Reconcile primary and redundant path assets, versions, protections, time, configuration, monitoring, and dependencies.
Define expected normal-to-emergency, degraded, manual, and recovery behavior under project criteria.
Witness transition and recovery while preserving alarms, control authority, evidence, and safe physical-process state.

Use in the project example

What the sources describe

NIST SP 800-82r3 describes redundancy and progression from normal to emergency or manual graceful degradation and states that redundant OT communications should receive the same protection as primary communications. Build Pearls converts that architecture and protection principle into a path-equivalence register and project-defined degradation/recovery test prompt. The alternate path is stale, misconfigured, less protected, unavailable, or causes uncontrolled degradation and ambiguous recovery.

Evidence to confirm

Primary and redundant OT path equivalence register
Controls integration lead · Before the relevant work begins
Assets, versions, configuration, security controls, monitoring, time, dependencies, backups, and owners are reconciled across paths.
Graceful-degradation, manual-mode, and recovery test record
Controls integration lead · Before the relevant work begins
Approved primary failure, alternate transition, degraded/manual behavior, alarms, control authority, and recovery results are witnessed and accepted.

Conditions to resolve before proceeding

The redundant path is excluded from patch, backup, monitoring, or configuration governance.
The test proves failover but not degraded/manual behavior or return to the primary path.

When this applies

Integrated systems testing
Operations acceptance and ready for service

Assess each lesson against your project, equipment, and local requirements with the people responsible for the work.

Limitations and context

Applies when: Integrated failure-mode testing and operations acceptance of redundant OT architecture
Outside scope: Exact redundancy architecture, manual mode, safety sequence, and acceptance criteria come from the project.
Outside scope: The source is not proof of fault tolerance, availability, electrical capacity, or functional safety for a specific system.
Exact redundancy architecture, manual mode, safety sequence, and acceptance criteria come from the project.
The source is not proof of fault tolerance, availability, electrical capacity, or functional safety for a specific system.
An installed redundant network or controller is protected, synchronized, available, and behaviorally equivalent when the primary path fails.

Where the lesson comes from

Sources

Use the original material to understand the evidence, scope, and context behind this Pearl. Suggested project actions are Build Pearls’ interpretation.

Guide to Operational Technology (OT) Security — NIST SP 800-82 Revision 3
National Institute of Standards and Technology · OT overview; §5.3.2.1 redundant communications; Page Printed pp3–4 and p80 · Accessed: 2026-08-06
Open source