TSA Pipeline-2021-02F is not a current control mandate

Make instrument status a required field

A security requirement record needs more than a control label. Preserve the issuing authority, exact instrument, covered audience, issue date, effective period, amendment or memorandum, status, source, and the basis for applying it to a particular operator. Pipeline-2021-02F's published end date means a mapping that simply says TSA required is incomplete for a decision made after May 2, 2026.

Expiration does not erase the historical record. Evidence created while the directive applied may remain relevant to audits, investigations, risk management, contractual commitments, or later requirements. The disciplined response is to retain the dated mapping and its evidence while opening a separate current-status review, not to relabel the old directive as active or delete the work it generated.

Verify the current authority before assigning controls

Current applicability can depend on a later directive, notification, order, regulation, amendment, operator status, facility scope, or communication that is not established by the 2021-02F PDF. The accountable legal, compliance, and security owners should identify the live authority and preserve the exact source and date used. A search result, vendor crosswalk, archived checklist, or inherited governance record cannot supply that conclusion by itself.

The control register should distinguish an active obligation, historical obligation, proposed rule, voluntary framework, contractual commitment, internal policy, and recommended practice. Those sources can point toward similar activities while carrying different legal status, audience, evidence, exception, reporting, and enforcement implications. One consolidated control statement should link to each source without flattening those distinctions.

Retest products against the dated requirement set

A provider may map asset inventory, architecture, identity, monitoring, incident response, testing, or evidence features to the expired directive. That mapping describes the provider's interpretation of product support; it does not show that an operator enabled the capability, covered every relevant asset, operated the control effectively, met a current requirement, or obtained TSA acceptance. Buyers should require the mapped clause, product version, configuration boundary, evidence output, owner, and unresolved dependency.

Evaluation should also test change handling. Ask how the product or service labels an expired authority, introduces a successor without overwriting history, preserves prior assessment evidence, flags unmapped new requirements, and prevents a dashboard from showing compliance when the underlying source is stale. The goal is traceable status and evidence, not disclosure of security-sensitive configurations or operator details.

Keep this public record within its limits

The TSA PDF is primary evidence for the directive's title, stated audience, effective period, and published requirements. It does not establish a particular operator's designation, present applicability, compliance, security posture, control effectiveness, successor obligations, or communications with TSA. This analysis deliberately omits actionable implementation detail and does not infer any nonpublic pipeline architecture or vulnerability.

OT Defense Review rechecked the registered directive on August 12, 2026. The source remained reachable, and the review did not establish a post-August 11 material change or successor through this record. Operators should confirm current authority through official TSA channels and qualified counsel, then maintain the dated directive, current instrument, local scope decision, evidence, exceptions, and approvals as separate linked records.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

OT Defense Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.