Operational Lifecycle 

Third-party access requirements vary across the operational lifecycle of an OT asset. Commissioning concentrates vendor presence and tolerates higher-bandwidth, less-bounded access; the controls in Pattern B and the discipline of documented entry and exit are essential. Day-to-day operations occur with no third-party access most of the time; the controls in Patterns A and C are dormant until the next vendor visit. Ad-hoc maintenance is the most common pattern in practice and the focus of this guide; the minimum-viable controls in Patterns C and D apply. Incident response demands break-glass access that the degraded-mode rules above already cover. Decommissioning requires the explicit removal of access paths, credentials, and keys; this is the step most often skipped, and the source of forgotten tunnels and standing privilege that this guide describes as the antipattern. The five lifecycle phases share the five core principles; the depth of implementation varies. Third-party access requirements remain constant across the lifecycle, but the operational context changes how they are applied.

• During commissioning, access windows are longer, vendor-driven, and often involve vendor-owned equipment (Pattern B/D). Strict network containment and device validation are critical.
• During day-to-day maintenance, access is predictable and should be pre-approved, time-bound, and tied to named individuals with repeatable workflows.
• During ad-hoc support, access is reactive and must remain fully brokered, explicitly approved per session, and tightly time-scoped.
• During incident response and recovery, speed is critical, but controls must not be bypassed. Pre-approved emergency access procedures, including break-glass accounts with full session logging, should be defined in advance.
• During decommissioning, all third-party access paths, credentials, and dependencies must be removed, verified, and documented as part of system closure.