How Does the TSA Pipeline Security Directive Apply to AD and Entra ID?

The request comes from the security team: switch password expiration off, because Microsoft says so. It lands on the desk of the person whose name is on the TSA plan. The request is right about Microsoft, and the plan is right about TSA. This guide sets out what the directive asks of Active Directory and Microsoft Entra ID, where Microsoft’s advice applies, and what the plan has to say before either setting moves.

What 02G is, whom it binds, and why the plan is what gets inspected

A renewal with nothing new in it is how the identity lines in an approved plan roll forward another year without anyone reading them. According to TSA’s transmittal memo and directive, dated May 1, 2026, “SD Pipeline-2021-02G, which cancels and supersedes SD Pipeline-2021-02F, is effective May 3, 2026, through May 2, 2027.” The same memo states: “There are no substantive revisions to the SD Pipeline-2021-02 series through this renewal”. It also says the measures were first issued in July 2021, and that “TSA intends to permanently codify these requirements through notice-and-comment rulemaking.” It gives no date for that rulemaking, and this guide states none.

The directive does not reach every pipeline company. According to the directive, it applies to “Owners and Operators of a hazardous liquid and natural gas pipeline or a liquefied natural gas facility notified by TSA that their pipeline system or facility is critical”. For those operators, the memo is plain about what TSA measures them against: “This plan sets the security measures and requirements against which TSA inspects for compliance.” The plan is the operator’s TSA-approved Cybersecurity Implementation Plan. Where an operator has handed some measures to a Managed Security Service Provider, the directive says the operator “retains sole responsibility under this Security Directive for ensuring compliance” with that plan and the directive.

Whether Active Directory and the Entra tenant sit inside the directive’s scope turns on its definition. According to the directive, “Critical Cyber System means any Information or Operational Technology system or data that, if compromised or exploited, could result in operational disruption.” It adds: “Critical Cyber Systems include business services that, if compromised or exploited, could result in operational disruption.” Which directory accounts reach those systems is the operator’s own determination, recorded in its plan.

Start from the approved plan’s identity lines, not from the tenant’s current settings.

The reset schedule against Microsoft’s never-expire advice

The conflict looks like TSA says rotate and Microsoft says never. Read at source, it is narrower. According to the directive, the operator’s identification and authentication policies must include “A schedule for memorized secret authenticator resets” and “Documented and defined mitigation measures for components of Critical Cyber Systems that will not have passwords reset in accordance with the schedule” required by that paragraph, “and a timeframe to complete these mitigations.” The directive names no interval. It defines a memorized secret authenticator as a character string memorized by, or memorable to, the subscriber.

That term comes from NIST’s vocabulary. According to NIST’s current SP 800-63B, “Passwords were referred to as memorized secrets in the initial release of SP 800-63B.” For its own scope, federal digital identity services, NIST’s guidance states: “Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically.” It pairs that with: “However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.” NIST’s guideline governs federal identity services; this guide cites it for the vocabulary and the direction of current guidance, never as TSA’s rule for a pipeline operator.

Microsoft’s advice is written for a specific population. According to Microsoft’s password policy recommendations, “Microsoft’s latest guidance discourages password expiration policies for cloud-only accounts.” The same page states: “The recommended setting is for passwords to never expire.” Microsoft’s guide to setting the password expiration policy says “By default, passwords never expire for your organization” and that an administrator who sets one can “Choose a number of days from 14 to 730”. Then the sentence that decides where a pipeline operator’s schedule lives: “It doesn’t apply to hybrid identity users who use password hash sync, pass-through authentication, or on-premises federation like Active Directory Federation Services (ADFS).” Older tenants carry a different default; according to Microsoft’s self-service password reset policies, “If the tenant was created before 2021, it has a 90 day expiration value by default.”

On a hybrid estate, then, the schedule is enforced in Active Directory. According to Microsoft’s guide to fine-grained password policies, “Fine-grained password policies apply only to global security groups and user objects.” It continues: “For example, you can apply stricter settings to privileged accounts and less strict settings to the accounts of other users.” One of the mitigations named in Microsoft’s archived Windows 10 reference on maximum password age works at the same domain controllers. According to Microsoft’s page on Microsoft Entra Password Protection for Active Directory, “These checks are performed during password changes and password reset events against on-premises Active Directory Domain Services (AD DS) domain controllers.” It adds: “Domain controllers (DCs) never have to communicate directly with the internet.”

Microsoft’s archived Windows 10 reference on Maximum password age, kept on a previous-versions path, puts both halves in one place: “The security baseline recommended by Microsoft doesn’t contain the password-expiration policy, as it is less effective than modern mitigations.” And: “However, companies that didn’t implement Microsoft Entra Password Protection, multifactor authentication, or other modern mitigations of password-guessing attacks, should leave this policy in effect.”

A plan can describe one of three designs under the directive’s reset schedule. They are options this guide sets out, not TSA’s words or Microsoft’s, and this guide does not say which TSA would approve:

• One domain-wide maximum password age covering every account.
• A schedule scoped by fine-grained password policy to the groups that reach Critical Cyber Systems, with never-expire plus Microsoft Entra Password Protection and multi-factor sign-in for the accounts outside it, each listed with its mitigation and timeframe.
• Either of those, with forced resets named in the schedule on evidence of compromise and when a shared-account holder leaves.

Two adjacent decisions stay separate: local administrator passwords on servers and workstations are their own decision, and accounts that sign in without a password fall outside a password schedule, with the passwordless rollout a decision of its own.

List every account population that reaches a Critical Cyber System, name the policy object that enforces its schedule, and list every account left off it with its mitigation and timeframe.

Shared accounts, and why emergency access accounts count

A common miss in a shared-account inventory is the account built, on purpose, to be used by more than one person. According to the directive, the operator needs “Enforcement of standards that limit availability and use of shared accounts to those that are critical for operations, and then only if absolutely necessary.” Where shared accounts are used, the directive requires policies under which “Individuals who no longer need access do not have knowledge of the password necessary to access the shared account.” Access rights sit under “Policies and procedures to manage access rights based on the principles of least privilege and separation of duties.” The definition is what matters: “Shared Account means an account that is used by multiple users with a common authenticator to access systems or data.” And: “Group accounts do not have common authenticators.”

Microsoft’s own design for emergency access accounts reads against that definition. According to Microsoft’s guidance to manage emergency access accounts in Microsoft Entra ID, “Create two or more emergency access accounts.” It says: “Don’t associate emergency access accounts with any individual user in the organization.” And: “Store credentials in a known secure location that’s available to multiple members of the administration team.” And: “Validate account functionality at least every 90 days.” Microsoft’s Conditional Access guidance to require multifactor authentication for all users lists emergency access or break-glass accounts among the accounts to exclude from that policy.

This guide’s reading, labelled as a reading and not as TSA’s classification: an emergency access account built to Microsoft’s design has one credential available to several administrators, which is a common authenticator, so the plan should name it as a shared account critical for operations and say how people who leave lose knowledge of its credential. How TSA classifies it is for the operator’s compliance function and TSA.

Inventory every account with a common authenticator, keep only those critical for operations, and write the leaver procedure for each.

Multi-factor sign-in, and the control-room line the plan must still write

Requiring multi-factor sign-in in Conditional Access answers part of the directive’s question, not all of it, because the directive asks about every access path to a Critical Cyber System. According to the directive, the operator needs “Multi-factor authentication, or other logical and physical security controls that supplement password authentication to provide risk mitigation commensurate to multi-factor authentication.” Where an operator does not apply multi-factor authentication “for access to industrial control workstations in control rooms regulated under 49 CFR parts 192 or 195”, the directive says the operator shall specify “what compensating controls are used to manage access.”

On the Active Directory side, Microsoft’s best practices for securing Active Directory state: “Require multifactor authentication when using privileged accounts or doing administrative tasks.” And: “Never administer a trusted system from a less-trusted host.”

Control-room workstations are operational technology, so that line of the plan is written by the operator’s OT team, and this guide does not describe it. For the reader deciding the multi-factor baseline itself, see MFA baseline under NIST SP 800-53.

Map each access path to a Critical Cyber System to multi-factor sign-in or a named commensurate control, and let the OT team write the control-room line.

Domain trusts, and the review no one scheduled

A forest trust created for an acquisition can outlive the reason it was created. The directive states that the operator needs a “Schedule for review of existing domain trust relationships to ensure their necessity and policies to manage domain trusts.” As with passwords, it names no interval; the plan sets one. According to Microsoft’s page on how trust relationships work for forests in Active Directory, “Active Directory Domain Services (AD DS) provides security across multiple domains or forests through domain and forest trust relationships.” A trust that no one owns is still extending that security to the other side.

List every domain and forest trust with its direction, owner and business reason, set the review schedule, and write what removes a trust that no longer has one. At each review, decide each trust one of two ways: keep it, with its owner and reason recorded again, or remove it. Where the trust policy is a measure in the approved plan, a removal meant to last 45 or more calendar days is a permanent change under the directive, so it goes on the same change record as the plan amendment.

When the policy changes, the plan changes first

The quickest way to fall out of step with an approved plan is to improve the tenant without touching the plan. According to the directive, a permanent change is one intended to be in effect for “45 or more calendar days”, and “The Owner/Operator must file the request for an amendment to its Cybersecurity Implementation Plan with TSA no later than 50 calendar days after the permanent change takes effect, unless TSA allows a longer time period.” If the password or trust policy is a measure in the approved plan, turning expiration off for accounts the plan puts on a schedule is the kind of change that section describes; the operator’s compliance function decides whether it is.

Put the identity policy change and the plan amendment on the same change record.

Identity in the annual assessment rotation

An identity measure assessed in one year of three is easy to leave undocumented in the other two. According to the directive, “The Owner/Operator must submit its Cybersecurity Assessment Plan on an annual basis to TSA for approval.” Its schedule must provide that “at least one-third” of the plan’s policies, procedures, measures and capabilities are assessed each year, “with 100 percent assessed over any three-year period”. The assessment plan must also “Include a cybersecurity architecture design review at least once every two years”.

Place the password schedule, shared-account, trust and multi-factor measures in the rotation, and keep the evidence each produces (a policy export, the group memberships, a trust inventory, the sign-in log) ready for the year it is assessed. Write into the Cybersecurity Assessment Plan the year each of these measures is assessed, so every one falls inside the three-year cycle, and run the trust review before the architecture design review the directive requires at least once every two years, so the review reads a current trust inventory.

When this guide is the wrong starting point

This guide reads one directive against one Microsoft estate, and several situations call for a different starting point. Each case in this list turns on the directive’s own applicability and scope:

• An operator TSA has not notified as critical: the directive does not apply.
• An operator whose approved plan already fixes a schedule it will not reopen this cycle: the work is evidencing the plan, not redesigning it.
• A company that is also an electric utility: NERC CIP carries its own password requirements, which this guide does not describe.
• A question that is really about OT or control-room access: that is an OT engineering decision this guide does not make.
• A question about which product or firm to use: that is a product decision this guide does not make.

What to ask of whoever maps it with you

Hold any internal or external support to an inventory and evidence you can put in front of your compliance function and, through the plan, in front of TSA’s inspection. Ask them to:

• Show every account population that reaches a Critical Cyber System and the policy object enforcing its schedule.
• Show every account off the schedule with its mitigation and timeframe.
• Show every shared and emergency access account with its leaver procedure.
• Show every domain and forest trust with its owner, reason and review date.
• Show each access path’s multi-factor sign-in or commensurate control.
• Show which assessment year covers each identity measure.
• Hand the configuration, the inventory and the evidence to your own team to run.

No provider, product or assessor is named or compared in this guide.

How i3solutions answers

i3solutions governs identity and access for regulated Microsoft estates with senior, U.S.-based engineers and records what it configures. For this directive, that means a project, with embedded specialists where your team needs them, that maps the directive’s identity measures to Active Directory and Microsoft Entra ID, configures the password, shared-account, trust and multi-factor controls on the Microsoft side, and evidences them for your own plan and assessment. i3solutions maps governance to named control families, enforces it in the platform through Entra ID, Purview, and Azure Policy, and records the evidence for each control as it configures it. i3solutions has done hundreds of Okta to Entra ID conversions. i3solutions has been a Microsoft Partner with 30 years of enterprise technology delivery experience and has delivered 1,500+ Microsoft engagements across aerospace and defense, financial services, and health sciences.

An i3solutions project engagement does not by itself include ongoing support of what it delivers, which i3solutions scopes separately as Application Managed Services, and it is not a replacement for the internal team, open-ended scope expansion, or vendor lock-in. The work stays on the Microsoft side: operating security as a service, control-room and operational technology systems, and the judgment on whether a plan meets the directive sit with the operator, its OT team, its compliance function and TSA.

For how this fits the wider identity program, see identity and access management services.