API 1164 is the standard the US pipeline industry wrote for its own control systems - and the third edition, published in 2021, quietly became one of the most consequential documents in pipeline operations. It rebuilt the industry's SCADA security playbook on the international ISA/IEC 62443 foundation, replaced the old checklist with risk-scaled security profiles, and arrived just as TSA's directives made a documented security program non-optional for critical operators. This guide explains what the standard covers, how the profile approach works, how it relates to IEC 62443 and TSA requirements, how operators actually apply it - and what to ask any SCADA vendor who claims alignment.
From the Merobix industrial security hub - every security, compliance & certification guide in one place.
API 1164, "Pipeline Control Systems Cybersecurity," is published by the American Petroleum Institute - the same body behind the mechanical and operational standards pipeline engineers already live by - with the full text available for purchase through API's standards program. That provenance matters: this is not a generic IT security framework adapted for industry, but a standard written by and for pipeline operators, in their vocabulary, about their systems.
What it is: a comprehensive statement of the security capabilities and program practices a pipeline control environment should have, scaled to risk. What it is not: a law, a certification scheme, or a product endorsement. No regulator audits directly against API 1164, and no certificate exists to hang on a wall. Its force is commercial and practical - it defines the standard of care the industry recognizes, it is the natural blueprint for the implementation plans TSA requires of critical operators, and it is the reference customers and insurers reach for when they ask "is your SCADA secure?" For how it sits in the broader regulatory stack, see our oil and gas compliance overview.
Scope is the first thing third-edition readers notice. Earlier editions concentrated on SCADA - the servers, HMIs, and communications of the central monitoring and control function. The third edition covers the whole pipeline operational technology environment: SCADA hosts and control rooms, yes, but also local control at stations and terminals, field devices such as RTUs and flow computers, the communication links between all of them, and the boundaries where this world touches corporate IT.
The second edition (2009) served its era: a SCADA-focused set of security practices you could read as an extended checklist. By the late 2010s it was showing its age - written before cloud platforms, before ransomware-as-a-business, and before the industry had a shared international vocabulary for control-system security. The third edition - announced by API in August 2021 after a development effort involving more than 70 organizations - is not an update to that document; it is a replacement with three structural decisions:
The standard's signature idea solves a real fleet problem: a mainline compressor station and a low-throughput gathering site do not warrant identical controls, but "use judgment" is not a standard. API 1164 defines security profiles - coherent sets of requirements drawn from the IEC 62443 catalog and tuned to pipeline contexts - so an operator assigns each zone of its environment a profile matching its risk and criticality, then implements and assesses against that profile. A baseline profile sets the floor everywhere; elevated profiles add requirements where a compromise would matter most.
Under the profiles sits IEC 62443's structure of seven foundational requirement families. They are worth knowing because they double as a complete evaluation lens for any SCADA platform:
| Foundational Requirement | What It Means for Pipeline SCADA | What to Demand from a Platform |
|---|---|---|
| Identification & authentication control | Every human and device is uniquely identified before touching the system | Named accounts, MFA, unique device registration and credentials |
| Use control | Authenticated users can only do what their role permits | Granular roles, control-action authorization, step-up auth for critical writes |
| System integrity | Data and software cannot be tampered with undetected | Signed telemetry with replay detection, signed software updates, audit chains |
| Data confidentiality | Operational data is protected in transit and at rest | TLS everywhere, encryption of sensitive data, tenant isolation in shared platforms |
| Restricted data flow | Network paths exist only where the design says they should | Zone/conduit fit - ideally outbound-only connectivity, no inbound rules |
| Timely response to events | Security-relevant events are detected, logged, and reach responders | Runtime detection, security alerting, SIEM export, reliable delivery |
| Resource availability | The system degrades gracefully and recovers from failures | Store-and-forward buffering, redundancy options, tested backup and restore |
Think of the three documents as one stack. The ISA/IEC 62443 series is the international foundation: requirement catalogs, security levels SL1–SL4, and the zones-and-conduits network model. API 1164 is the pipeline application of it: the same requirements, organized into profiles that fit pipeline topologies and risk tiers, in pipeline language. The TSA security directives are the mandatory layer for designated critical operators: performance-based outcomes - segmentation, access control, monitoring, patching - that an API 1164-shaped program satisfies almost by construction. The efficient strategy follows directly: build once against API 1164, and let the same evidence serve TSA plans, customer audits, and insurer questionnaires. The directive requirements are covered in detail in our TSA pipeline security directives guide.
The alignment also pays off in vendor evaluation. Because 1164 inherits 62443's structure, a vendor who has mapped its platform to IEC 62443 has effectively pre-answered most of an API 1164 assessment - one mapping serves both conversations.
A realistic first pass through the standard looks like this:
Timeline for a full program: commonly six to eighteen months from first assessment to steady state, varying with legacy debt and fleet size. The failure mode to avoid is treating the assessment as the deliverable. The standard describes an operating posture, not a report.
API 1164 is architecture-neutral: it specifies capabilities, not hosting models. A cloud platform can conform or fail exactly as an on-premise one can - the difference is who does the work and how much of it your assessment inherits versus verifies. That said, the profile requirements translate cleanly into cloud-vendor evaluation criteria, and Merobix illustrates what the mapping looks like in practice: unique device registration with device-held signing identities and Ed25519-signed telemetry envelopes with replay detection address identification and system integrity; granular roles, control-tag authorization, setpoint bounds checking, and step-up authentication for high-risk workflows address use control; an outbound-only gateway with no inbound firewall rules addresses restricted data flow; runtime threat detection with security event delivery to email, SMS, webhooks, or SIEM addresses timely response; and store-and-forward buffering at the edge addresses availability. Merobix maps these controls to IEC 62443 - the same mapping an API 1164 assessment consumes - runs a SOC 2 readiness program, and treats independent penetration testing as part of its ongoing validation program; the documentation lives on the security page.
When a vendor claims 1164 or 62443 alignment, these questions separate mappings from marketing:
A vendor comfortable with those five questions will make your assessment shorter. One who is not will make it longer, every year. You can put the same five to Merobix engineers directly in a guided demo.
Key takeaway: API 1164 third edition turned pipeline SCADA security from a checklist into a risk-scaled program built on IEC 62443 - which means one well-run gap assessment now feeds your TSA implementation plan, your customer audits, and your vendor evaluations from a single body of evidence. Zone the environment, assign profiles honestly, fix remote access and authentication first, and demand a requirement-by-requirement mapping from every vendor who says the word "compliant."
API 1164 is the American Petroleum Institute's standard for pipeline control systems cybersecurity - the US pipeline industry's own definition of what a sound SCADA and control-system security program looks like. The third edition, published in 2021, covers the full pipeline operational technology environment, from SCADA hosts and control rooms to field devices and the communications between them. It is voluntary in law, but it functions as the industry benchmark: TSA's security directives push operators toward exactly the kind of program it describes, and customers and insurers increasingly expect conformance.
API 1164 third edition is built directly on ISA/IEC 62443 - it takes the international standard's requirements and organizes them into pipeline-specific security profiles, so operators apply requirements appropriate to each asset's risk rather than one flat checklist. This means work done against API 1164 translates naturally into IEC 62443 language and vice versa: a vendor that maps its controls to IEC 62443 has effectively pre-answered most of an API 1164 assessment, and an operator's 1164 program will satisfy customers and partners who ask in 62443 terms.
No formal certification scheme exists for API 1164 - unlike IEC 62443, which has recognized certification programs such as ISASecure. Conformance with API 1164 is demonstrated through assessment: operators run gap assessments themselves or engage third-party assessors, document conformance and deviations, and maintain the evidence. When a vendor claims API 1164 alignment, the right follow-up is to ask for the mapping - which requirements they address, at which profile, with what evidence - rather than accepting the claim at face value.
The third edition, published in 2021, was a fundamental rebuild rather than an update. The second edition of 2009 was a relatively narrow SCADA security checklist; the third edition adopts ISA/IEC 62443 as its foundation, broadens scope from SCADA hosts to the entire pipeline control environment including field and local control systems, and introduces a profile-based approach that scales requirements to asset risk. It also reflects a lifecycle view of security - program governance, assessment cadence, and supplier considerations - rather than a one-time hardening exercise.
Start with an inventory of your control-system environment and segment it into zones by function and criticality. Select the appropriate security profile for each zone, then run a gap assessment of current controls against the profile requirements - most operators engage a third party for the first pass, commonly a matter of weeks for a focused SCADA scope. Risk-rank the gaps, remediate the highest-leverage items first - typically remote access, authentication, and segmentation - and put a repeatable assessment cadence and evidence collection in place. The same program then feeds TSA implementation plans and customer audits.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Signed telemetry, control-action authorization, outbound-only connectivity, and audit evidence - mapped to the requirement families your assessor will use.